도구를 바꾼 게 아니라 일하는 방식이 바뀌었다
AI를 쓰는 것과 AI와 일하는 시스템을 갖는 것은 다른 일이다. 도구를 여러 번 갈아타는 동안 정작 더 크게 바뀐 건 작업 방식 그 자체였다.
기억은 자동으로 쌓이지 않는다
처음엔 옵시디언에 세션 로그를 쌓으면 '위키화'까지 자동으로 굴러갈 줄 알았다. 착각이었다. 6월에 확인해보니 raw 세션 로그가 2,500개 그대로 쌓여 있었다. 정작 필요할 때 같은 문제를 처음부터 다시 디버깅하고 있었던 것이다.
구조는 두 계층으로 정비했다.
- 메모리(요약·포인터) — 빠르게 참조할 핵심만. RAM 역할.
- 옵시디언 위키(상세 원본) — 결정 근거, 디버깅 전말, 실패 맥락. SSD 역할.
위키화는 지금 백그라운드 크론으로 돌리고 있다. 밀린 2,500개를 거슬러 처리하는 만큼 토큰이 꾸준히 녹아나가는 중이다. LLM의 컨텍스트는 휘발성이 강하다. 그 휘발성을 외부 기억으로 메우는 게 핵심이었다.
검증을 '믿음'이 아니라 '절차'로
골든 테스트로 동작 동일성 고정
대규모 리팩터링 전에, 현재 동작을 입출력 경계에서만 고정하는 테스트를 깔아둔다. 내부 로직은 들여다보지 않는다. AI가 코드를 다시 쓴 뒤에도 이 테스트가 GREEN이면 동작이 보존됐다는 뜻이다. "겉보기엔 똑같이 도는데 미묘하게 달라진" 코드를 정확히 이 단계에서 잡아낸다.
배포 전엔 AI를 '공격자'로 돌린다
운영 직전, AI에게 역할을 바꿔 시킨다. "이 코드를 깨뜨려봐." 만들 때의 AI와 부술 때의 AI를 분리한다. 이 방식으로 실제로 boolean 하나의 의미가 정반대로 뒤집혀 있던 결함을 잡았다. 값은 채워지고 테스트도 초록불인데, 그 값이 뜻하는 바가 거꾸로였던 경우다. 만드는 시선으론 절대 안 보이던 게, 부수는 시선엔 보였다.
모든 작업은 워크트리로 격리
기능 단위 작업은 전부 git worktree로 격리한다. AI에게 일을 맡기면 실험 횟수 자체가 늘어나고, 그중 상당수는 버려진다. 격리해두지 않으면 버리는 비용이 커진다. "한 실험이 망해도 메인은 깨끗하다"는 안전감이 셋업 비용을 충분히 정당화한다.
TDD는 Classicist로 강제
AI에게 그냥 테스트를 짜라고 하면 Mockist 편향이 강하게 나온다. 협력 객체를 mock으로 발라버리고 호출 횟수를 검증하는 테스트 — 리팩터링만 해도 우수수 깨지고, 정작 동작이 틀려도 통과한다.
그래서 Kent Beck식 Classicist TDD — 실패하는 테스트부터 쓰고, 실제 협력 객체로 행위와 출력을 검증하는 방식 — 를 에이전트에 강제했다. mock은 시스템 경계(네트워크·DB·파일시스템)에서만 쓴다.
골든 테스트, 적대적 리뷰, 워크트리 격리, Classicist TDD를 조합한 구체적인 설정과 코드는 원문에서 확인할 수 있다.
👉 원문 전체 보기 — k3nta.com
생산성 폭증의 역설
5월 중순, AI가 우리를 대체하겠다는 두려움이 옅어지기 시작했다. 그런데 두려움이 사라진 자리를 채운 건 여유가 아니라 더 많은 일이었다.
속도가 오르자 동시에 굴릴 수 있는 작업 수가 늘었고, 머릿속에 올려야 할 맥락도 늘었다. 생산성의 병목이 'AI의 속도'에서 '내 컨텍스트 스위칭 능력'으로 옮겨갔다. 위의 검증 절차와 2계층 기억 장치는, 사실 이 폭증을 견디기 위한 방어이기도 했다. 머리로 다 붙들 수 없으니 시스템에 맡긴 것이다.
살아남는 사람의 윤곽
개발자인지 기획자인지 헷갈릴 지경이 됐다. 경계가 흐려지고, 한 사람이 하나의 팀처럼 움직이게 된다.
지금으로선 두 부류가 살아남지 않을까 싶다. 하나는 AI와 사람 사이의 간극을 조율할 수 있는 사람, 다른 하나는 토큰을 전략적으로 쓸 수 있는 사람.
그리고 '대체의 공포'가 가라앉은 자리엔, 전혀 다른 결의 두려움이 자라고 있었다. AI가 나를 대체하는 게 아니라, AI 없이는 내가 아무것도 못 하게 되는 것 아닌가.
다음 편은 그 두려움과 로컬 LLM까지 굴려본 이야기다. 이번 글의 맥락과 세부 내용 전체가 궁금하다면 원문에서 이어 읽을 수 있다.
