나는 ‘메모어’라는 모임에서 주말마다 회고를 한다. 지난 한 주의 행동과 생각을 돌아보고, 다음 주에는 무엇을 다르게 해볼지 고민하는 시간이다. 회고를 처음 시작했을 때만 해도 이 과정은 무척 새롭고 흥미로웠다. 그러나 모든 일이 그렇듯, 시간이 흐르자 매너리즘이 찾아왔다. “참 재미있었다”라는 한마디로 끝나는 여름방학 일기처럼 나의 회고도 점점 짧고 무성의해졌다.

10주간의 메모어 활동을 마치고 다음 기수가 시작되기 전까지 잠시 쉬는 동안, 그동안 쓴 회고를 다시 읽어보았다. 처음에 쓴 글과 비교하니 생동감이 확연히 줄어 있었다. 같은 방식으로 회고를 반복하는 것만으로는 이 권태를 벗어나기 어려워 보였다. 새로운 동력이 필요했다.

그래서 회고를 도와주는 도구를 직접 만들어보기로 했다. 내가 생각한 도구는 글을 대신 써주는 작가보다, 미처 들여다보지 못한 부분을 끈질기게 묻는 인터뷰어에 가까웠다. 먼저 AI가 회고 초안을 읽고 내용이 부족하거나 모호한 지점을 찾아 질문한다. 나는 그 질문에 답하면서 당시의 상황과 감정을 조금 더 구체적으로 돌아본다. 충분한 답변이 모이면 AI가 초안과 인터뷰 내용을 바탕으로 하나의 회고를 완성한다.

여기에 약간의 재미를 더하기 위해 인터랙티브 소설 형식을 빌렸다. 인터랙티브 소설은 독자의 선택이나 입력에 따라 이야기의 흐름이 달라지는 소설이다. 나는 이야기의 콘셉트를 ‘평행우주’로 정했다.

양자역학의 다세계 해석은 가능한 결과들이 서로 다른 세계에서 실현된다는 발상을 담고 있다. 여기서 아이디어를 빌려, 회고에 등장하는 후회와 선택의 순간마다 또 다른 우주가 갈라진다고 상상해보았다. “그때 다른 말을 했다면?”, “그 일을 맡지 않았더라면?” 같은 질문이 하나의 분기점이 되는 것이다. 사용자가 회고를 작성하면 AI는 그 안에서 선택의 순간을 찾아낸다. 그리고 선택하지 않았던 길이 각각의 평행우주에서 어떻게 이어졌을지 이야기로 만든다. 사용자는 그렇게 만들어진 우주를 하나씩 여행하며 자신의 선택을 여러 방향에서 되짚어본다.

이 앱을 만들며 나는 AI에게 답을 잘 쓰게 하는 것만큼, 필요한 맥락을 먼저 질문하게 하는 일이 중요하다는 것을 알게 됐다.

또한, 이번 앱을 만드는 과정에서 ‘Twine’이라는 오픈 소스 도구를 새롭게 알게 되었다. Twine은 선택에 따라 흐름이 달라지는 인터랙티브 이야기를 시각적으로 만들 수 있는 도구다. 이번 글에서는 Twine을 활용해 평행우주를 여행하는 회고 앱을 만든 과정과, 그 안에서 AI에게서 답이 아닌 질문을 얻기 위해 노력한 경험을 소개하려 한다.

인터랙티브 시나리오를 만드는 도구, Twine

Twine은 비선형적인 이야기를 만드는 도구다. 각 장면을 선으로 연결해 사용자와 상호작용하며 전개되는 시나리오를 만들 수 있다. 편집은 그래프를 그리는 방식으로 이루어진다. 각각의 장면은 하나의 노드가 되고, 그 장면에서 여러 갈래로 뻗어나오는 장면을 새로운 노드로 추가하면 된다. Play 버튼을 누르면 첫 장면이 재생되고, 사용자는 버튼으로 제공되는 선택지를 클릭하면서 장면을 탐색할 수 있다.

나는 바로 이러한 비선형성이, 회고라는 활동과 잘 어울린다고 생각했다. 선택의 순간을 하나의 장면으로 만들고, 선택의 결과들을 여러 갈래로 탐색해보는 것이 재미있을 것 같았다.

Twine 패시지 맵에 '바로 알린 우주'·'하루 더 확인한 우주'·'혼자 해결한 우주' 등 선택지별 갈래가 화살표로 연결된 구조 — <출처: Twine>

Claude 스킬

하지만 막상 사용해보니 바로 난관에 봉착했다. 우선 Twee라는 형식이 낯설었다. Twee는 Twine 이야기를 장면 단위로 표현하는 평문 형식이다. 장면의 제목과 본문, 장면 사이의 연결 관계를 일정한 규칙에 따라 적는다. 여기에 Harlowe 같은 스토리 포맷의 변수와 매크로까지 사용하려면 별도의 문법도 익혀야 했다. 내게는 새로운 프로그래밍 언어를 하나 더 배우는 것처럼 느껴졌다. 익숙해지면 편리하겠지만, 반드시 배워야 하는지 의문이 들었다. 이 부분을 AI가 도와줄 수 있을 것 같았다. 변환은 AI에게 맡기고, 나는 시나리오 생성에만 집중하기로 했다.

그리고 노드를 직접 만드는 일도 생각보다 번거로웠다. 그래프 위에 노드의 위치를 정하고, 다른 노드와 연결하는 작업을 반복해야 했다. 그래프를 보기 좋게 정리하는 일까지 생각하면 글을 쓰는 시간보다 구조를 만드는 시간이 더 길어질 수도 있었다. 나는 이것 역시 인터랙티브 시나리오 작가의 몫이 아니라고 생각했다. 그래서 장면과 연결 관계를 사람이 하나씩 만들지 않도록, AI가 전체 이야기를 Twee 형식으로 생성하게 했다. 이 파일을 Twine으로 불러오면 각 장면이 노드로 만들어지고, 이야기의 흐름도 그래프에서 확인할 수 있었다.

처음 만든 것은 Claude 스킬이었다. 자연어로 작성한 회고 초안을 스킬에 전달하면 AI가 내용을 읽고, 장면과 연결 관계를 담은 Twee 파일로 바꿔준다. 이 과정에서 내가 직접 Twee 문법을 작성하거나 노드를 하나씩 연결할 필요는 없었다.

사용자가 자연어로 회고 초안을 작성한다.
AI가 초안을 Twee 텍스트로 변환한다.
사용자가 이 Twee 텍스트를 Twine 로컬 스토리지에 붙여넣으면 바로 플레이할 수 있다.

Claude 스킬 대신 웹앱으로 만들기

1) 저장 공간

앞서 로컬 스토리지를 언급했다. Twine을 브라우저에서 사용하면 이야기가 브라우저의 로컬 스토리지에 저장된다. 아이패드와 맥북을 오가며 작업하는 데 익숙한 나는 계정에 연결된 데이터베이스가 아니라, 기기마다 별도로 저장되는 방식이 불편했다. 또한 앞서 만든 Claude 스킬이 생성한 Twee 텍스트를 복사해 붙여넣기에는 로컬 스토리지의 입력 화면이 너무 작아 내용을 한눈에 확인하기 어려웠다. 애초에 로컬 스토리지는 사용자가 직접 데이터를 편집하기 위해 만들어진 공간이 아니었다.

브라우저 개발자 도구에 twinery.org 로컬 스토리지의 twine-passages·twine-prefs 키와 값 목록이 표시된 화면 — <출처: Twine 웹사이트>

저장 공간이 필요했다. 나는 우선 클라우드 저장소 연동이 가능한지 확인하기 위해 깃허브의 twinejs 레포지토리를 찾아보았다. 나 말고도 클라우드 저장소를 원한 유저가 이슈를 올린 적이 있었지만, 운영상의 부담과 복잡도를 이유로 보류된 것으로 보였다. 납득이 가는 설명이었다. 나였어도 같은 부담을 느꼈을 것 같아서 공감이 되었다. 하지만 어쨌든, 당장 나의 회고 앱에는 클라우드 저장소가 필요했다. 명색이 AI 앱인데, 사용 과정에 ‘로컬 스토리지에 텍스트 붙여넣기’라는 수동적인 절차가 포함되어 있는 것은 너무 원시적이었다.

하지만 클라우드 저장 기능을 붙이려니 또 다른 고민이 생겼다. 지금은 나 혼자 쓰는 앱이지만, 사용자가 늘어나면 그들의 회고가 내가 관리하는 저장소에 쌓이게 된다. 회고에는 업무에서의 실수나 인간관계, 당시의 감정처럼 민감한 이야기가 담길 수 있다. 그런 기록을 맡는 순간부터 나는 저장 공간의 비용뿐만 아니라 보안까지 책임져야 한다. 운영자인 나조차 필요 이상으로 내용을 들여다볼 수 없게 하고, 외부 공격이나 실수로 데이터가 유출되지 않도록 지켜야 한다. 누군가의 기록을 보관한다는 것은 작은 사이드 프로젝트가 가볍게 감당할 수 있는 일이 아니었다.

그래서 Notion을 저장소로 사용하기로 했다. Notion은 무료 플랜으로도 꽤 많은 용량을 저장할 수 있다는 점, OAuth 연동이 쉽다는 점, 편집 툴로서 편리하다는 점이 이유였다. 사용자는 OAuth 화면에서 앱이 접근할 페이지를 직접 선택해주기만 하면 되었다. Twine에 동기화해주는 기능만 추가해주면, Notion에서 직접 편집할 수 있어서 사용성이 높아질 것 같다는 생각이 들었다.

2) 동기화

Notion의 강력한 텍스트 편집 기능을 십분 활용하기 위해 Twine의 로컬 스토리지와 Notion 페이지 간의 동기화 기능을 추가했다. 웹에서 글을 수정하면 먼저 브라우저의 로컬 스토리지에 저장하고, 수정이 멈춘 뒤 3초가 지나면 Twee 형태의 스냅샷을 Notion으로 보낸다. 반대로 앱을 열 때는 Notion에 저장된 이야기를 불러와 로컬 사본과 비교한다. 두 내용이 다르면 수정 시각이 더 최근인 쪽을 선택한다. 이 앱은 협업 도구를 의도한 것이 아니어서 동시 수정 충돌은 별도로 처리하지 않았다. 따라서 두 기기에서 동시에 글을 수정하면 나중에 저장된 사본이 이전 내용을 덮을 수 있다.

결론적으로, 이 회고 웹앱의 최종적인 사용 흐름은 다음과 같다.

회고 생성 버튼을 클릭한다.
Notion 계정을 연결한다.
회고를 저장할 Notion 페이지를 고른다.
사용할 AI 모델의 API 키를 입력한다.
회고 제목과 초안을 작성한다.
AI가 던지는 질문에 답한다.
내용이 충분해지면 인터랙티브 회고가 생성된다.
Play 버튼을 눌러 평행우주를 여행한다.

3) AI 호출 비용, 누가 낼까?

이 앱을 만들 때 가장 큰 고민은, AI 토큰 비용을 누가 지불하는가 하는 것이었다. 이 고민을 하면서, 왜 많은 앱들이 서버 비용을 벌기 위해 광고를 붙이는지 이해가 되었다.

인터랙티브 회고를 한 번 만들 때마다 AI 호출 비용이 발생한다. AI는 회고 글을 읽고, 그 내용을 바탕으로 질문한 뒤 최종 스토리까지 생성한다. 이 과정마다 토큰이 사용되는데, 사용자가 많아진다면 비용이 어디까지 늘어날지 생각하니 아찔했다. 설령 이 앱이 많은 사용자에게 공개되더라도 오픈 소스 프로젝트 기반이라 수익을 내는 앱이 아니기에, 모든 사용자의 회고 생성 비용을 직접 부담하는 것은 무리라는 판단이 들었다.

그래서 사용자가 자신의 API 키를 입력하고 모델을 고르는 BYOK(Bring Your Own Key) 방식을 사용했다. 그리고 선택한 제공업체에 따라 지원되는 AI 모델들을 나열해서 사용자가 선택할 수 있도록 했다.

인터랙티브 회고 앱에서 Claude Opus 5·Sonnet 5·Haiku 4.5 등 모델과 가격을 선택하는 드롭다운 화면 — <출처: 작가>

4) API 키 관리 문제

BYOK 방식으로 비용 문제를 해결했지만, 보안 문제가 남아있었다. AI를 호출하려면 앱이 사용자의 API 키를 전달받아야 하기 때문이다.

처음에는 평문 키를 Notion 페이지에 적어두고 서버에서 읽는 방식도 생각했다. 하지만 Notion 페이지는 오래 남고 공유나 검색의 대상이 될 수 있다. 비밀값을 보관할 장소로는 적절하지 않다고 판단해 이 방식은 바로 폐기했다.

최종적으로는 사용자가 입력한 AI API 키와 Notion 접근 토큰을 하나의 세션 정보로 묶었다. 세션 전체를 AES-256-GCM 방식으로 암호화한 뒤, 브라우저의 자바스크립트에서 읽을 수 없는 HttpOnly 쿠키에 저장했다. 세션은 30일 동안 유지되며, 세션 정보가 다시 저장될 때마다 만료 시각도 갱신된다. 서버는 AI나 Notion API를 호출할 때만 쿠키를 복호화한다.

그렇다고 암호화 쿠키가 모든 문제를 해결해주는 것은 아니다. AI 호출 시점에는 서버가 복호화된 키를 다루게 된다. 서버가 복호화할 수 있다는 사실은 서버가 침해되었을 때 키가 노출될 가능성도 있다는 뜻이다. 따라서 이 앱에서만 사용할 별도의 API 키를 발급하고, 가능한 경우 사용 한도를 낮게 설정하며, 사용을 마친 뒤에는 제공업체 콘솔에서 키를 폐기하는 편이 안전하다.

5) 좋은 회고를 위한 좋은 질문

기능만 놓고 보면 앱은 처음 상상했던 모습에 꽤 가까워졌다. 회고를 작성하면 AI가 질문하고, 답변을 반영한 Twee를 만들고, Notion에 저장한 뒤 바로 플레이할 수 있다. 클라우드 저장과 모델 선택, 비용과 보안 문제도 나름의 방식으로 해결했다.

이제는 정말 이야기를 생산하는 데에만 집중할 시간이었다. 새삼 AI에게 고마웠다. 하마터면 도구의 사용법을 익히느라 시작도 하기 전에 지칠 뻔했으니 말이다.

그런데 결과물의 문장이 어딘가 마음에 들지 않았다. 여전히 추상적인 경우가 많았고, 심지어 내가 하지 않은 일을 지어내는 경우도 있었다. AI가 빈칸을 상상으로 채운 이야기는 재미있었지만, 그것은 더 이상 나의 회고가 아니었다.

그래서 나는 프롬프트에 중요한 규칙을 추가했다. 회고 초안에 선택이나 갈림길이 잘 드러나지 않고 맥락·감정·결과가 비어 있다면 곧바로 변환하지 말고, 질문을 통해 살을 붙이도록 했다. 예시 질문도 몇 개 제시하고, 충분하다고 판단할 때까지 반복해서 질문하게 했다.

AI가 회고의 빈 부분을 채우라며 '가장 망설였던 선택은', '선택하지 않은 길에서 얻은 것은' 등을 되묻는 화면 — <출처: 작가>

그때의 핵심 결정이나 전환점은 무엇이었나?
그때 함께 고민했지만 고르지 않은 선택지는 무엇이었나?
그 길을 갔다면 어떻게 됐을 것 같나?
지금 다시 그 좌표에 선다면 무엇을 다르게 할까?
그 순간의 감정과 상황은 어땠나?
실제 결과와 이후의 변화는 어땠나?

그리고 마지막으로는, 선택지들을 띄워주면서 사용자에게 가장 마음에 드는 선택지를 다시 한번 고르게 하고 그 우주의 나에게 메시지를 보낼 수 있게 했다. 마치 우주에서 신호를 보내는 것처럼 보이도록, 메시지가 깜빡거리는 효과를 주었다.

과거의 나에게 보낸 메시지가 '신호가 시공의 얇은 막을 통과한다'는 문구와 함께 우주 배경에 표시되는 화면 — <출처: 작가>

답을 만드는 AI가 아니라, 질문하는 AI

이번 앱을 만들기 전까지 나는 AI를 주로 답을 얻기 위한 도구로 사용했다. 모르는 것을 물어보고, 필요한 코드를 요청하고, 작성한 문장을 다듬었다. 내가 질문하면 AI가 답하는 방식에 익숙했다.

그런데 이번 프로젝트에서는 반대로 AI에 질문하는 역할을 맡겼다. 사용자가 작성한 회고를 읽고, 이야기로 만들기에 부족한 부분을 찾아 다시 묻게 했다. 당시 어떤 감정을 느꼈는지, 다른 선택지는 없었는지, 그 선택이 이후에 어떤 영향을 주었는지 질문하도록 했다.

앱으로 나의 회고를 만들던 중, AI가 이렇게 물었다.

“아무리 별로였던 순간조차도, 그 안에서 얻은 것이 있지 않아?”

그동안 나는 회고를 하면서 잘못한 점을 찾고 자책하는 데 익숙해져 있었다. 무엇을 잘못했는지, 다음에는 어떻게 고쳐야 할지만 고민했다. 그런데 이 질문을 받고 나니 실패라고 생각했던 선택에서도 나름의 이유와 괜찮았던 점이 보이기 시작했다.

업무상 저지른 실수를 되짚어보면서는 개인의 부주의만이 아니라, 같은 실수를 반복하게 만드는 구조에도 문제가 있다는 것을 발견했다. 덕분에 업무 구조를 개선해야 할 필요성을 느꼈다. 틀어진 인간관계를 돌아보면서는 내가 어떤 사람과 관계를 편안하게 느끼는지, 반대로 어떤 상황에서 힘들어하는지를 조금 더 분명하게 알게 되었다.

후회했던 선택을 실제로 바꿀 수는 없다. 하지만 이야기 속 평행우주를 여행하며 선택하지 않은 가능성을 살펴볼 수는 있다. 그리고 여행을 마치고 현실로 돌아왔을 때, 다음 갈림길에서는 이전과 조금 다른 선택을 할지도 모른다.

사람은 자신이 한창 몰두하고 있는 일의 빈틈을 발견하기 어렵다. 대화 상대에게 내 생각이 이미 충분히 전달됐다고 여기거나, 글에 필요한 내용이 모두 담겼다고 착각하기도 한다. 이때 한 걸음 떨어진 곳에서 질문을 던지는 조수가 있다면 미처 보지 못한 빈칸을 발견할 수 있다. AI는 내가 머릿속으로만 알고 있는 맥락까지 알 수 없다. 모르는 내용을 그럴듯하게 채우게 하기보다 필요한 맥락을 파악할 때까지 질문하도록 만들면, AI는 내가 놓친 빈틈을 발견하도록 돕는 조수가 된다.

적어도 회고에서는 답이 내 안에 있는 경우가 많았다. AI가 해야 할 일은 그럴듯한 결론을 대신 내려주는 것이 아니라, 내가 아직 꺼내지 못한 생각을 발견하도록 돕는 일이었다. 문장을 얼마나 멋지게 썼는지보다 어떤 질의응답을 주고받았는지에 따라 결과물의 품질이 달라졌다.

이 회고 앱은 혼자 사용할 목적으로 만들었지만, 만들다 보니 애정이 생겨 주변 사람들의 피드백도 듣고 싶어졌다. 언젠가 나와 함께 회고하는 사람들이 이 도구를 통해 자신의 평행우주를 여행하는 모습을 보고 싶다. 그러기 위해 지금 필요한 것은 더 좋은 질문을 통해 사용자의 생각을 자연스럽고 깊게 끌어내는 회고 앱을 만드는 일일 것이다.

이 글은 AI를 활용해 작성했습니다. 작가가 주제와 구성, 실제 개발 경험과 코드를 제공했으며, AI는 공식 문서를 바탕으로 한 자료 조사와 초안 작성을 도왔습니다. 이후 작가가 원고 전체 문장을 직접 고쳐 썼고, AI는 맞춤법과 문장 표현, 사실관계를 점검했습니다. 최종 검수와 퇴고는 작가가 직접 진행했습니다.

<참고>