#어떤 일을 할 때 고통 받다 떠오른 생각: 대화는 분기해도 지식은 병합되어야 한다

낯선 코드베이스에서 일을 시작할 때마다 제일 먼저 부딪히는 문제는 “이걸 내가 제대로 이해하고 있는가”다. 주어진 작업을 이해하려고 큰 덩어리를 작은 덩어리로 쪼개고, 그 하위 작업을 하나씩 처리한다. 여기까진 그럴듯하다. 문제는 실제 작업을 할 때 내가 만든 계획이 계획대로 흘러가지 않는다는 데 있다. 작업을 하다 보면 새로운 의문이 생겨 조사로 빠지고, 코드를 읽다가 실험을 하고, 실험이 실패해서 디버깅을 하고, 디버깅 중에 문서를 뒤지고, 그 과정에서 또 다른 하위 작업이 튀어나온다. 거기다가 가장 치명적인 변수가 있다. 내 전제가 틀릴 수 있다는 것. “당연히 이럴 거야”라고 생각했던 부분이 실제로는 반대로 동작하거나, 내가 놓친 조건 하나 때문에 모든 해석이 틀어지기도 한다. 그러면 그때까지 쌓아 올린 이해는 그냥 무너지지 않고, 은근히 다른 곳에까지 영향을 퍼뜨린다. 결론적으로 작업은 선형으로 진행되지 않는다. 작업은 자연스럽게 분기된다. 마치 나무 뿌리가 사방으로 뻗어가듯이, 하나의 줄기에서 시작한 생각이 여러 갈래로 갈라지고, 그 갈래마다 서로 다른 문맥과 근거와 결론을 만든다.

최근에 Cursor 같은 도구를 쓰면서 이 분기가 더 빠르게 일어난다는 느낌을 받았다. 질문을 던지고 답을 받고, 그 답으로 또 질문이 생기고, 그 질문으로 다시 다른 실험을 하고, 어느 순간 대화가 여러 갈래로 나뉜다. 한 대화에서 계속 붙잡고 갈 수가 없다. 컨텍스트 한계 때문이기도 하고, 내가 스스로 대화를 “이 주제는 이쪽”, “저 주제는 저쪽”으로 분리해버리기도 한다. 그런데 이렇게 분기한 대화들은, 이상하게도 다시 합쳐지지 않는다. 분기 자체는 자연스럽고 효율적이다. 문제는 병합이 안 된다는 것이다. 각각의 가지에서 나온 내용이 다시 한곳에 모이지 않으면 맥락은 흩어진다. 흩어진 맥락은 며칠 뒤 내가 다시 그 문제로 돌아왔을 때 나를 괴롭힌다. “내가 어디까지 확인했더라?” “이 결론은 어떤 근거로 내렸지?” “이건 확정된 사실이었나, 그냥 추측이었나?” 이런 질문에 답을 찾느라 다시 대화 로그를 뒤지고, 코드 히스토리를 헤매고, 결국 이미 했던 생각을 또 한다. 고통은 여기서 생긴다. 실력이 부족해서라기보다, 지식이 ‘업데이트’되는 방식이 내 손을 떠나 흩어지기 때문이다.

그래서 떠오른 생각이 있다. 대화는 분기해도 되지만, 지식은 반드시 병합되어야 한다. 내가 원하는 건 똑똑한 답변이 아니라, 내가 작업을 진행하면서 바뀌는 전제와 새로 밝혀진 사실과 결정된 결론이 하나의 모델로 수렴하는 구조다. 다시 말해 “중앙 지식 노트” 혹은 “지식 지도” 같은 것이 필요하다. 이건 거창한 개인 지식 관리 시스템을 만들자는 얘기가 아니다. 적어도 지금 하고 있는 테스크 하나에 한해서라도, 사실과 결론과 오해 수정과 남은 질문들이 한 곳에서 계속 갱신되어야 한다는 이야기다. 그래야 시간이 지나도 내가 다시 돌아왔을 때 맥락을 복원할 수 있다. 그리고 이 맥락은 나에게만 도움이 되는 게 아니다. 내가 AI를 잘 쓰고 싶다면 더더욱 필요하다. AI는 대화 속에서 순간순간 최적의 답을 만들 수 있지만, “어제의 내가 수정한 전제”와 “오늘 새로 확정된 사실”을 자동으로 한 장의 지도로 합쳐서 업데이트해주지는 않는다. 결국 그 병합은 사용자의 책임이다.

내가 생각한 최소한의 운영 방식은 간단하다. 먼저 중앙 지식 지도 하나를 만든다. Obsidian에서는 task-xxxxx-map.md 같은 파일 하나거나 Canvas 한 장이면 된다. 그리고 Cursor나 ChatGPT에서 대화가 분기될 때마다 분기 노트를 만든다. 분기 노트는 실험 로그와 추론과 스크랩을 담는 공간이고, 중앙 지도는 확정된 것만 적는 공간이다. 분기에서 나온 내용 중에서 “확정된 사실”, “결정된 결론”, “수정된 전제(오해 정정)”, “남은 질문”, “다음 행동”만 중앙 지도에 병합한다. 여기서 중요한 건 병합을 선택 사항으로 두지 않는 것이다. 분기 노트를 닫기 전에 중앙 지도에 반영하지 않으면 작업이 끝난 게 아니라고 정의한다. 마지막으로 각 항목에는 근거를 연결한다. 코드 위치, PR, 문서, 그리고 가능하면 해당 대화 링크까지. 이유는 단순하다. 시간이 지나도 “왜 그렇게 결론을 내렸는지”를 추적할 수 있어야 지식이 지식으로 남는다.

다만 솔직히 말하면, 나는 아직 이 방법을 실제로 시도해보지 않았다. 그래서 이게 내 생각처럼 잘 통할지는 모른다. 그렇지만 이 글을 쓰는 김에 스스로에게 약속을 하나 걸어두고 싶다. 빠른 시일 내에 지금 하고 있는 일에 이 방식을 적용해보고, 결과가 어땠는지도 여기다 이어서 적어보고 싶다. 지금의 나는 회사 도메인이라는 거대한 세계 한복판에 던져진 느낌으로 일한다. 어떤 영역은 이미 보인다. 내가 건드린 코드, 내가 읽은 문서, 내가 해결한 작은 문제들은 마치 스타크래프트에서 미니맵을 하나씩 밝혀가듯 점점 드러난다. 그런데 아이러니하게도, 이 점들이 한 장의 지도 위에 놓여 있지 않다. 그래서 밝힌 점들은 늘어나는데도, 나는 여전히 어두운 곳에서 헤매는 기분을 느낀다. 만약 지식 지도를 그리기 시작하면, 적어도 “모든 점이 한 장의 지도 위에 있다”는 가정이 생긴다. 그리고 그 가정 아래에서 나는 ‘지역’의 지도를 그려나갈 수 있다. 한 테스크의 지도를 그리다가 다른 테스크의 지도를 이어 붙이고, 어느 순간 회사 전역의 지도가 그려질 수도 있다. 물론 회사 지도 안에 어두운 구역은 남을 수밖에 없다. 그건 당연하다. 하지만 중요한 건 어두운 구역이 있다는 사실 자체가 아니라, 그 어두움이 지도 위에서 “여기가 아직 미개척”이라고 표시된다는 점이다. 더 나아가서는 회사와 맞닿아 있는 다른 회사들, 파트너, 외부 시스템, 경계면 같은 것들도 지도 위에 올라올 수 있을 것이다. 그렇게 되면 나는 더 이상 막막한 어둠 속을 뚫고 나아가는 느낌이 아니라, “아, 이런 구조였구나. 여기서 이렇게 돌아가는구나”라는 감각으로 세상을 바라볼 수 있게 될 것 같다. 더 높은 통제감이라고 표현해도 될까. 적어도 내가 어딘가에 서 있고, 내가 어디로 가는 중이며, 아직 어디가 비어 있는지 아는 상태. 나는 아마 어찌됐든 그런 감정을 느끼는 방식으로 행동하고 살아갈 것 같다. 그래서 이 글은 단순한 생산성 팁이 아니라, 내가 덜 괴롭고 더 명료하게 살기 위해 붙잡아보려는 하나의 시도에 가깝다.

자, 이제 지도를 그리기 시작해보자.