물이 술이 되어갈때

물이 술이 되어갈때

Tags
AI
Vibe Coding
Software Development
Published
March 1, 2026
Author
얼마 전, 지인의 요청으로 “바이브 코딩을 잘하는 법”에 대한 1시간짜리 세션을 진행했다. Claude Code를 회사에 도입한 지 일주일 정도 되었는데, 잘 쓰는 법에 대해 질문을 받았고, 어쩌다 보니 지인 회사 분들과 같이 이야기 하는 온라인 세션이 되었다.
 
발표자도 발표를 듣는 사람처럼, 발표 시간에 발표자료를 처음 마주하는, 매우 바이브한 발표였다.
발표자도 발표를 듣는 사람처럼, 발표 시간에 발표자료를 처음 마주하는, 매우 바이브한 발표였다.
 
매일 같이 쓰고 있는 Claude Code였지만, 참석 인원이 꽤 되다 보니 나도 자료를 찾고 내용을 정리해야 했다. 최근에 블로그 글을 쓰면서 정리한 내용들도 있지만, 아무래도 가장 최근에 읽었던 자료들은 내 Threads 계정에 제일 많이 있었다. 읽어본 글들 중 괜찮은 것들을 엄선하고, 거기에 몇줄 정도 내 코멘트를 달아올리고 있으니 말이다. 그렇게 그걸 정리해서 맹글면 되겠구나, 생각을 했어요. 그런데,
 
내가 올린 게시물인데도, 기억이 안 나는 내용들이 많았다. 불과 한달 전에 올린 게시글에, 내가 원문 요약을 한 내용이 짧지도 않았다. 그러니까 그 글을 정독 했고, 요약하면서 한번 더 읽었던 글이었다. 그런데도 불구하고 그 글을 봤다는 것을 까먹고 있었다. 그러다 내가 올린 게시물 목록에서 보고 나서야 드디어 기억이 떠올랐다. 그리고 거기까지였다. 구체적인 내용은 여전히 기억이 안나서 다시 또 원문을 읽고, 또 다시 정리해야했다.
 

대체 이게 무슨 일이람?

 
분명히 이야기를 하고, 시간을 보냈는데, AI와 여러 도구들 덕분에 시간은 압축되고, 압축된 시간이 쌓아 놓은 기억은 더더욱 압축 되어서 단편만 기억 나거나, 혹은 아예 중간이 잘려 있었다. 마치 술을 마시며 나눈 이야기처럼.
 

요약의 시대

 
몇년 전에, 모임에서의 일이다. 6명 정도 저녁을 먹으며 이야기를 나누고 있었는데, 그 때 엄청 유행하던 드라마에 대한 이야기가 화제로 나왔다. 그 드라마가 재밌다고 어느 누가 이야기를 했고, 나를 제외한 나머지 5명은 모두 그 드라마를 보고 재밌다고 이야기를 해주었다. 작품 괜찮다고.
 
‘그렇게 재밌나? 하지만 난 그래도 안 보겠지’라는 생각을 하며, 사람들이 하는 드라마 이야기를 듣다가, 평소에 궁금하던 질문이 하나 생각이 났다. 나는 영화도, 드라마도, 유튜브도 배속으로 안 본다. 그런데 7~8년 전에 유저 딥인터뷰를 하다가 모두들 배속으로 보고, 넘겨보기로 본다는 사실에 충격을 받은 적이 있다. 나에겐 영상을 배속으로 보는 건, 노래가 너무 좋아서 빨리 듣고 싶다고 배속으로 듣는 것과 비슷하게 생각되어서. 아무튼, 그 때 했던 질문을 여기서 또 해보고 싶었다. 그 때는 보통 1.2 ~ 1.5 배속이 많았는데 요즘은 어떻게 되었을지? 혹은 배속이 아닌 요약이나 중요 시점 건너뛰기를 많이 쓰는지 등을 포함해서.
 
그렇게 배속으로 봤냐고 물어봤는데, 그 분은 사실 자기는 드라마를 다 안 봤고 1~2화만 봤다고 이야기 했다. 그 분이 이야기를 하니, 옆에 계신 분도 유튜브에 드라마를 20분짜리 요약이 된게 있는데 그걸 봤다고 했다. 그렇게 한분 한분 이야기를 하더니, 결국 여기에 그 드라마를 다 본 사람이 없었다. 모두가 요약을 보고 있었고, 요약을 보고 모두가 드라마를 봤다고 말하고 있었다. 다 같이 이런 현실을 확인하니, 재밌어서 다 같이 그걸로 또 한번 웃을 수 있었다.
 

물이 술이 되어갈때

 
2시간짜리 영화는 몇십분짜리 유튜브로, 유튜브는 몇십초짜리 쇼츠로 바뀌는 세상에 우리는 어떤 것을 얻고 어떤 것을 잃어버렸을까? 그리고 AI가 코딩해주고, AI가 보고서나 발표자료를 만들고 요약도 해주는 세상에서는 어떤 것을 얻고 어떤 것을 잃게 될까?
 
한가지 분명한건, 기억이 잘 안난다는 것이다.
 
내 홈페이지 겸 포트폴리오 사이트를 지도 형태로 만든 이유는 단기간에 바이브 코딩을 만든게 많아지다보니, 나조차도 내가 만든게 내가 만든걸 기억하지 못해서였다. 불과 만든 지 반년도 안 된 것들조차 말이다. 단어나 이런걸 외울 때 장소에 맵핑하면 잘 외워지는 것처럼, 아이디어에 떠오른 장소에 맵핑하면 좀 더 기억이 나지 않을까? 해서 이 방식을 썼다. 그럼에도 이 방식도 올려놓은 모든게 기억이 나진 않는다.
 
한 때, 최애 프로젝트였던 탑글스도 야구 시즌이 아니니, 존재를 까먹고 있었다.
한 때, 최애 프로젝트였던 탑글스도 야구 시즌이 아니니, 존재를 까먹고 있었다.
 
2시간짜리 영화를 요약해서 알려주는 영화 유튜버의 20분짜리 영상을, 다시 요약한 1분짜리 쇼츠를 본다면, 우리는 그 영화에 대해 얼마나 알게 되는 것일까? 영화를 안다고 말할 수 있을까? 아니면 모른다고 해야 할까? 각각 영화 1편을 다룬 1분짜리 쇼츠를 2시간짜리를 본다면, 120개의 영화에 대해 알았으니, 2시간 동안 영화 1편을 본 것과 많은 것을 알게 된다고 할 수 있을까?
 

기억력 검사

스타크래프트1에서 SCV를 클릭하고 ‘C’ key를 누르면 어떤 행동을 하는지 말해보시요?
 
최근에 깨닫게 되어서 깜짝 놀란 일이 있다. 스타크래프트에서 일꾼을 컨트롤 할 때, 쓸 수 있는 단축키로 ‘C’가 있다. 지난 10년 사이에 난 해당 단축키의 존재를 까먹었고(1), 까먹었다는 사실 자체도 잊어버렸다(2). 과거의 나는 분명히 알고 있던 것이었고, 실제로 내가 스타를 할 때도 쓰던 것인데, 어느 새 까먹었고, 심지어 까먹었다는 것조차 몰랐다. 그런 단축키가 있는거 자체를 잊어버렸다.
 
또 내가 스타에 대해 까먹거나, 알았다고 생각하지만 실질적으로는 못하는게 뭐가 있을까? 조금 더 생각해 보았다.
  1. 다크템플러 가격이 얼마지? 까먹었다. → 모른다는 걸 안다.
  1. 파일런 넘기기는? 파일런 넘기기가 있고, 예전에 해왔고, 지금도 할 수 있다고 생각했지만, 잘 생각해보니 지금은 어떻게 해야 원하는 방향으로 넘어가는지 모른다. → 안다고 생각했는데, 실제 하려고 해보니 모른다는 걸 알았다.
  1. 그리고 수 많은 것들 → 뭘 모르는 지도 모르는 것들이 있을 것이다.
 
이렇게 정리하고 나니, 용량이 다 찬 스마트폰을 쓰는 사람이 되었다는 생각이 들었다. 이제 더 이상 빈 공간에 쓰기만 하는 것을 불가능하고, 가득찬 용량에서 뭔가를 덮어쓰기 해야만 새로운 기억을 쌓을 수 있다. 그리고 사라지고 잊혀지는 것들이 그렇듯이, 덮어쓰기 되는 것들은 이름도 없이 사라진다.
 

기술 부채에서 인지 부채로

 
앞에서 말했던 것처럼 AI로 만든 것은 기억에 잘 남지 않는다. 그리고 기억에 잘 남지 않는다는 건, 단순히 알았다가, 몰랐던 과거 상태로 돌아간다는 의미가 아니다. 오히려, 난 알고 있다고 잘못 생각하는 경우와 과정을 거쳤으니, 정확히 기억은 안 날지언지, 다 알고 있다고 잘못 생각하는 경우라는 더 큰 위험이 도사리고 있다.
 
나만 이렇게 느끼나? 했는데, 인지 부채(Cognitive Debt)라는 좋은 용어가 있다는 걸 알게 되었다. 최근에는 <생성형 및 에이전트형 AI가 기술적 부채에서 인지적 부채로 관심을 전환시키는 방법>이라는 글도 나오고, 해당 글을 보고 Simon Willison이 글을 쓸 정도로 이야기가 좀 나오고 있는 듯 하다.
 
인지 부채를 설명하기 위해, 첫번째 글에 있는 일부분을 인용하는게 좋겠다.
 
'인지 부채'라는 용어는 빠른 속도로 개발하는 과정에서 누적되는 부채가 개발자의 두뇌에 남아 그들의 실제 경험과 '빠르게 개발'하거나 변경하는 능력에 영향을 미친다는 개념을 전달합니다. AI 에이전트가 이해하기 쉬운 코드를 생성하더라도, 개발자는 프로그램의 의도를 파악하지 못하고, 의도가 어떻게 구현되었는지, 또는 어떻게 수정해야 하는지 이해하지 못할 수 있습니다.
마가렛-앤은 자신이 코치했던 학생 팀에 관한 일화를 통해 이를 더욱 자세히 설명합니다.
하지만 7~8주 차에 접어들면서 한 팀은 한계에 부딪혔습니다. 예상치 못한 문제를 일으키지 않고는 간단한 변경조차 할 수 없게 된 것입니다. 제가 그 팀과 만났을 때, 처음에는 기술 부채를 원인으로 지목했습니다. 즉, 지저분한 코드, 부실한 아키텍처, 성급한 구현 등을 꼽았습니다. 하지만 더 깊이 파고들수록 진짜 문제는 드러났습니다. 팀원 중 누구도 특정 설계 결정이 내려진 이유나 시스템의 각 부분이 어떻게 연동되어야 하는지 설명할 수 없었던 것입니다. 코드가 지저분했을 수도 있지만, 더 큰 문제는 시스템에 대한 이론, 즉 팀원들 간의 공통된 이해가 파편화되거나 완전히 사라졌다는 점이었습니다. 기술 부채보다 인지 부채가 훨씬 빠르게 쌓여갔고, 그것이 그들을 마비시킨 것입니다.
 
 
모 회사 기술 면접을 준비하기 위해, 내가 만든 GemBack library의 코드를 다시 보면서 공부한 적이 있다. 그 때 가장 놀랐던 것은 내가 버전을 v0.1에서 v0.3까지 꾸준히 만들었고, 내가 만든 다른 여러 프로젝트에서 해당 library를 쓰고 있는데도 불구하고, README.md 파일에 있는 Quick Start에 적힌 부분을 제외하고는 잘 모른다는 것이었다. 그러니까, 내가 만들었는데도 이걸 프로젝트를 가져다가 쓰는 사용자 정도의 이해 밖에 없었다. 이건 내가 만들었는데 말이다!/
 
기술 부채처럼 인지 부채도 해결하거나 혹은 완화 할 방법은 없을까?
 

AI야, 좋은 방법 없을까?

 
라고 물어봐서 AI가 해준 답으로는
  1. 의도적인 속도 조절과 검증된 개발 관행 실천
  1. 팀 차원의 완화 전략(Mitigation Strategies) 수립
  1. 조기 경고 신호(Warning Signs) 파악하기
  1. AI 도구를 역으로 활용하여 인지 부하 관리
 
이렇게 4가지가 있었다. 그 중에서 나에게 가장 현실적으로 느껴지는 건, 2번째 항목이었다.
팀 내부에 인지 부채가 쌓이는 것을 막기 위한 명시적인 규칙과 프로세스를 세워야 합니다.
  • AI 생성 코드에 대한 '인간의 이해' 필수화: AI가 작성하거나 변경한 코드를 배포하기 전에, 팀 내에 최소 한 명 이상의 개발자는 해당 내용을 완벽하게 이해하도록 규칙을 정해야 합니다.
  • '무엇'이 아닌 '왜'를 문서화: 단순히 어떤 코드가 변경되었는지(What)를 넘어서, 왜 그런 설계 결정을 내렸는지(Why) 그 맥락을 반드시 기록해야 합니다.
  • 정기적인 체크포인트 마련: 코드 리뷰, 회고(Retrospectives), 지식 공유 세션 등을 정기적으로 개최하여 파편화된 시스템 지식을 하나로 모으고 동기화해야 합니다.
 
요약하자면, 1) 누군가 1명은 이걸 이해하는 사람이 있어야 하고, 2) 왜 그런 결정이 내려졌는지 그 이유를 기록해야 하고, 3) 이런 지식을 주기적으로 모아야 한다. 라고 말 할 수 있을 것이다.
 
 
이게 답일지, 나도 모르겠다. 그래도 이거라도 시도해봐야 하지 않을까?
술에 취한 듯한 이 세상에서, 기억을 조금이나마 더 잡아두고 있기 위해선.