내 OS를 만들고 싶었다

맥북 안에 갇힌 작업 환경

Claude나 ChatGPT를 쓰다 보면 어느 순간 답변 자체보다 더 불편한 게 생긴다.

AI가 일을 못해서가 아니었다. 오히려 답변은 꽤 잘했다. 문제는 내가 AI를 쓰는 환경이 너무 조각나 있다는 점이었다.

내가 쓰던 AI_System은 거의 맥북 안에 갇혀 있었다. 파일은 로컬에 있었고, 맥북을 열어야만 접근할 수 있었다. 밖에서 폰으로 이어서 쓰기도 애매했고, 맥북이 꺼져 있으면 아무것도 돌아가지 않았다.

AI도 마찬가지였다. 내가 직접 채팅창을 열고, 필요한 파일을 찾아주고, 지금 뭘 하던 중이었는지 설명해야 움직였다. Claude는 Claude대로, Codex는 Codex대로, 프로젝트 파일은 프로젝트 파일대로 따로 있었다.

처음 불편했던 건 거창한 “지식 관리”가 아니었다. 그냥 내 작업 환경이 특정 기기에 묶여 있는 게 싫었다.

나는 AI를 챗봇처럼만 쓰고 싶었던 게 아니라, 내 작업 환경의 일부처럼 쓰고 싶었다. 맥북에만 있는 폴더나 메모가 아니라, 어디서든 접근할 수 있고, 내가 하던 작업을 계속 이어갈 수 있는 환경. 말하자면 내 개인 OS 같은 걸 만들고 싶었다.

내 개인 OS라는 생각

여기서 말하는 OS는 진짜 운영체제를 만들겠다는 뜻은 아니다.

내가 원했던 건 내가 쓰는 도구, 파일, 프로젝트, 메모, AI 대화가 한곳에서 이어지는 작업 환경이었다. 어떤 기기에서 들어가도 같은 맥락을 보고, 내가 하던 프로젝트를 이어가고, 필요한 자료를 꺼내고, AI와 대화하면서 다시 작업으로 돌아갈 수 있는 환경.

지금 생각하면 이게 ATLAS의 출발점이었다.

처음의 ATLAS는 완성된 지식 엔진이라기보다, “맥북 안에 있던 내 AI 작업 환경을 클라우드 위로 꺼내보자”에 가까웠다. GCE VM 위에 Next.js PWA를 올리고, Claude API를 붙이고, Firestore에 대화 기록을 저장하고, Face ID 인증을 붙이는 식으로 시작했다.

이미 여러 프로젝트를 운영하면서 비슷한 문제를 겪고 있기도 했다. Digging Music이나 Campus Koe 같은 프로젝트들이 각각 Cloud Run에서 따로 돌고 있었고, 서비스가 늘어날수록 비용과 관리가 부담스러워졌다. 그래서 일부 프로젝트를 하나의 GCE VM으로 모으고, Caddy로 도메인과 HTTPS를 처리하는 구조를 만들었다.

ATLAS도 그 흐름 위에 올라갔다. 서버를 새로 판 이유가 ATLAS 하나 때문은 아니었지만, 그 인프라는 “내 개인 OS를 클라우드에서 돌린다”는 생각을 실제로 해볼 수 있게 만든 기반이 됐다.

흩어진 프로젝트를 하나의 환경으로 보기

내가 하고 있던 작업들은 하나의 프로젝트가 아니었다.

Digging Music도 있었고, Campus Koe도 있었고, 포트폴리오도 있었고, 공부 기록도 있었다. 각각은 서로 다른 프로젝트처럼 보였지만, 실제로는 완전히 분리되어 있지 않았다. 한 프로젝트에서 배운 배포 방식이 다른 프로젝트에 쓰였고, 어떤 글에서 정리한 생각이 나중에 다른 기획으로 이어지기도 했다.

그런데 기존 방식에서는 이 연결이 잘 보이지 않았다.

프로젝트마다 폴더가 따로 있고, 대화가 따로 있고, 메모가 따로 있고, 배포 환경도 따로 있었다. AI에게 물어볼 때도 “이건 Digging Music 이야기고, 이건 포트폴리오 이야기고, 이건 예전에 정한 방향인데...” 같은 설명을 반복해야 했다.

나는 이걸 하나의 환경 안에서 보고 싶었다.
각 프로젝트가 완전히 섞이는 건 싫지만, 서로 연결될 수는 있어야 했다.
필요할 때는 구분되고, 필요할 때는 이어지는 구조가 필요했다.

이때부터 ATLAS는 단순한 채팅창보다는, 여러 작업을 한곳에서 이어주는 허브에 가까운 느낌을 갖기 시작했다.

챗봇 하나를 더 만들고 싶었던 건 아니었다

처음에는 웹에서 접속 가능한 AI 앱을 만들면 꽤 많은 문제가 해결될 줄 알았다.

하지만 조금만 생각해봐도 단순한 채팅 UI는 별 의미가 없었다. Claude를 한 번 더 감싼 화면을 만든다고 해서 내가 원하는 환경이 생기는 건 아니었다. 이미 Claude 앱은 충분히 잘 만들어져 있었고, 내가 같은 걸 더 못생기고 느리게 만들 이유는 없었다.

내가 원한 건 채팅창 자체가 아니었다.

중요한 건 내가 어떤 프로젝트를 하고 있는지, 어떤 선택을 했는지, 어떤 자료를 자주 쓰는지, 어떤 방식으로 공부하고 글을 쓰는지 같은 것들이었다. AI와 대화할 때마다 이걸 다시 설명하지 않아도 되는 작업 환경을 만들고 싶었다.

다만 이 단계에서 아직 “ATLAS는 이런 지식 엔진이 되어야 한다” 같은 선명한 결론이 있었던 건 아니다. 그냥 여러 불편함이 겹쳐 있었다. 로컬에 묶인 파일, 흩어진 프로젝트, 반복되는 설명, 이어지지 않는 대화, 따로 노는 AI 도구들. 그걸 내 방식대로 한 번 묶어보고 싶었다.

프롬프트보다 앞에 있는 것

요즘 AI를 잘 쓰는 방법에 대해 이야기할 때 프롬프트 엔지니어링이나 루프 엔지니어링 같은 말이 자주 나온다.

프롬프트 엔지니어링은 한 번의 요청을 더 잘 쓰는 기술에 가깝다. 어떤 역할을 주고, 어떤 형식으로 답하게 하고, 어떤 조건을 넣을지 설계하는 방식이다.

루프 엔지니어링은 조금 더 작업 흐름에 가깝다. AI가 결과를 만들고, 사용자가 피드백하고, 다시 고치고, 다시 검토하는 반복 구조를 잘 설계하는 것이다. 글쓰기, 코드 작성, 리서치, 기획 같은 작업에서는 이 반복 구조가 꽤 중요하다.

그런데 내가 느낀 문제는 그보다 앞에 있었다.

좋은 프롬프트를 쓰려면 먼저 좋은 맥락이 있어야 한다. 지금 어떤 프로젝트를 하고 있는지, 이전에 어떤 방향을 버렸는지, 이 글은 어디에 올라갈 예정인지, 내가 어떤 표현을 싫어하는지, 어떤 결정을 이미 했는지 같은 것들이다.

이런 건 프롬프트 하나에 매번 복붙해서 해결하기 어렵다. 그리고 대화가 끝난 뒤 따로 정리하려고 하면 이미 많은 정보가 사라져 있다. 그때의 고민, 선택지, 망설임, 버린 방향, 갑자기 바뀐 판단 같은 것들은 최종 결과물만 보면 잘 보이지 않는다.

그래서 맥락은 일하는 중에 수집되어야 한다고 생각했다.

완성된 글이나 최종 결정만 저장하는 것이 아니라, 작업 중에 생기는 판단의 흔적을 같이 남겨야 했다. 그래야 다음에 AI를 쓸 때 단순히 “이전에 뭐 했더라”를 찾는 수준을 넘어서, 내가 왜 그렇게 생각했는지까지 이어갈 수 있을 것 같았다.

맥락이 병목이 되는 순간

AI 모델은 계속 좋아지고 있었다. 하지만 모델이 좋아지는 것과 내가 더 편하게 쓰는 것은 조금 다른 문제였다.

모델은 강해졌지만, 내가 매번 넣어주는 맥락은 여전히 빈약했다. 프로젝트의 히스토리, 현재 상태, 이전 결정, 내가 싫어하는 표현, 최근에 바꾼 방향 같은 것들이 빠지면 답변은 금방 일반론으로 돌아갔다.

이때 느낀 건 AI의 성능 문제가 아니라, 맥락 전달의 문제였다.

내가 이미 알고 있는 것들을 AI에게 매번 다시 설명해야 하고, 설명을 조금만 빼먹으면 답변의 방향이 어긋났다. 그러면 다시 “아니 그게 아니라...”로 시작해서 같은 맥락을 반복해야 했다.

이 반복이 생각보다 피곤했다.

그래서 ATLAS에서 하고 싶었던 일은 처음부터 거창한 자동화가 아니었다. 우선 내가 반복해서 설명하던 것들을 덜 반복하게 만드는 것. 그리고 그 맥락이 특정 채팅창이나 특정 모델 안에만 갇히지 않게 하는 것. 그 정도가 출발점이었다.

Obsidian과 Zettelkasten

이런 생각을 하다 보면 자연스럽게 Obsidian이나 Zettelkasten 같은 방식이 떠오른다.

Obsidian은 마크다운 파일을 기반으로 한 지식 관리 도구다. 로컬에 파일을 저장하고, 노트끼리 링크를 걸고, 그래프처럼 연결을 볼 수 있다. 특정 회사의 서버에 모든 걸 맡기지 않아도 되고, 내가 쓴 글이 그냥 파일로 남는다는 점이 좋다.

Zettelkasten은 조금 더 방법론에 가깝다. 독일어로 “메모 상자”라는 뜻인데, 핵심은 거대한 문서를 한 번에 쓰는 게 아니라 작은 생각 단위를 카드처럼 쌓고, 그 카드들을 서로 연결하면서 지식을 발전시키는 방식이다. 하나의 노트는 하나의 생각을 담고, 그 노트들이 서로 링크되면서 나중에 더 큰 글이나 아이디어로 이어진다.

이 방식은 꽤 매력적이었다. 내가 하는 프로젝트나 공부도 사실 완성된 문서로 한 번에 정리되는 게 아니라, 작은 생각들이 여기저기서 생기고 나중에 연결되는 경우가 많았기 때문이다.

하지만 나는 Obsidian을 그대로 쓰고 싶었던 건 아니었다.

Obsidian은 사람이 직접 읽고 쓰는 지식 관리 도구에 가깝다. 반면 내가 만들고 싶었던 것은 AI가 직접 읽고, 판단하고, 작업에 사용하는 지식 구조였다. 사람에게 보기 좋은 노트 구조와 AI가 작업에 쓰기 좋은 노트 구조는 조금 다를 수 있다고 생각했다.

예를 들어 사람은 “프로젝트”라는 폴더 안에 문서를 넣어두면 어느 정도 이해할 수 있다. 하지만 AI가 그 노트를 제대로 쓰려면 이 노트가 단순 기록인지, 현재 유효한 결정인지, 예전 판단을 대체하는 내용인지, 어떤 글의 재료인지, 어떤 실수를 막기 위한 규칙인지가 더 명확해야 한다.

그래서 ATLAS에서는 지식 구조를 내가 원하는 방식으로 직접 실험해보고 싶었다.

내가 원하는 지식 구조를 실험하기

이 단계에서 내가 정답을 알고 있었던 건 아니다. 오히려 정답을 모르기 때문에 직접 바꿔가며 실험할 수 있는 구조가 필요했다.

어떤 기록은 그냥 날것의 로그로 남겨야 할 수도 있다. 어떤 기록은 나중에도 재사용할 수 있는 인사이트가 될 수 있다. 어떤 것은 공개 가능한 글로 정리될 수 있고, 어떤 것은 AI가 다음 작업에서 참고해야 하는 규칙이 될 수 있다.

태그도 마찬가지다. 단순히 project, study, health 같은 식으로 분류하는 것만으로 충분할지, 아니면 더 세밀한 상태값이 필요할지 알 수 없었다. 노트끼리의 관계도 단순 링크만으로 충분할지, supports, updates, derivedFrom 같은 관계를 따로 둘 필요가 있을지 실험해보고 싶었다.

결국 내가 만들고 싶었던 건 “Obsidian보다 좋은 메모 앱”이 아니었다. 내가 AI를 쓰는 방식에 맞춰 지식 구조 자체를 직접 설계하고 바꿔볼 수 있는 환경이었다.

특정 모델 안에 갇히지 않는 기억

한 가지 더 신경 쓰였던 건 기억이 특정 모델이나 앱 안에 갇히는 문제였다.

Claude에서 한 대화는 Claude 안에 있고, ChatGPT에서 한 대화는 ChatGPT 안에 있고, 내가 따로 정리한 파일은 또 로컬 폴더 안에 있었다. 각각은 쓸 수 있었지만, 서로 자연스럽게 이어지지는 않았다.

물론 이때부터 모든 모델을 연결하는 완성된 구조가 있었던 건 아니다. 다만 방향은 있었다. 내가 쓰는 AI가 바뀌더라도, 내 프로젝트의 맥락이나 내가 쌓아온 기록이 특정 앱에만 잠겨 있으면 안 된다고 생각했다.

모델은 계속 바뀔 수 있다. 오늘은 Claude를 쓰고, 내일은 ChatGPT를 쓰고, 나중에는 다른 모델을 쓸 수도 있다. 그렇다면 내가 쌓는 맥락은 특정 모델의 부가 기능이 아니라, 내가 소유하고 조정할 수 있는 별도 층에 있어야 했다.

시작점

처음 ATLAS는 꽤 단순한 욕망에서 시작했다.

맥북을 열지 않아도 내 작업 환경이 살아 있었으면 했다.
AI와 대화할 때마다 같은 설명을 반복하지 않았으면 했다.
프로젝트와 공부와 글쓰기와 영어 학습이 따로 놀지 않았으면 했다.
내가 AI를 쓰는 방식 자체를 내가 원하는 모양으로 바꿔보고 싶었다.

아직 이 시스템이 어디까지 갈지는 몰랐다.
다만 한 가지는 분명했다.

나는 AI 앱을 하나 더 만들고 싶었던 게 아니라, AI를 쓰는 내 환경 자체를 다시 만들고 싶었다.