勢いよく流れ込む多数の線が中央で不透明な絡まりになり、傍らの小さなレンズ越しにだけ数本が整った並行線に見えている抽象イラスト

지난 기사의 마지막에 "만들 수는 있는데, 내용을 알 수 없다는 새로운 고민이 생겼다"라고 적었습니다. 이번에는 그 이야기에 관한 것입니다. Claude Code로 개발이 빨라질수록, 자신의 시스템을 읽을 수 없게 되어가는——그 부작용과 현재 시도하고 있는 대처법을 솔직하게 적어보겠습니다.

빠르다. 오히려, 멈출 수 없다

Claude Code를 이용한 개발은 어쨌든 빠릅니다. 사진 편집 도구는 하루 만에 기본 기능이 완성되었습니다. 감각적으로는 대부분의 도구가 "기본 기능만이라면 하루" 정도입니다. 처음에 구상을 어느 정도 입력하여 방침만 정해지면, 나머지는 스마트폰으로 "OK", "조금 이렇게 해줘", "OK" 정도의 답장만으로 구축되어 갑니다.

물론 시간을 들여 만드는 것도 있습니다. 주식이나 FX 자동 매매, 워크스페이스 전체 관리, 무료 AI 활용 로직, 이 블로그와 같은 상업용 프로젝트 등입니다. 이들은 보안이나 금전적 리스크를 조금씩 제거하며 쌓아 올리기 때문에, 2~3개월이 지나도 계속 "가상 완성" 상태로 개선을 이어가고 있습니다.

다만, 빠른 것이든 느린 것이든 공통점은 자동으로 척척 진행되는 것이 즐거워서 멈출 수 없다는 점입니다. 아이를 재우고 난 뒤 스마트폰을 열면 개발이 진행되어 있습니다. 이 즐거움 자체는 지금도 변함이 없습니다.

문제는 이 속도에 "다른 무언가"가 전혀 따라오지 못하고 있었다는 점이었습니다.

"다 쓰지 않으면 아깝다"는 함정

Claude Code의 구독 서비스에는 5시간 단위의 이용 한도와 주간 상한선이 있으며, 시간이 되면 리셋됩니다.

이 "리셋된다"는 점이 까다로웠습니다. 다 쓰지 않으면 아깝다는 마음이 생기는 것입니다. 그래서 딱히 만들고 싶은 것이 정해지지 않았는데도 억지로 개발을 진행한 적이 한두 번이 아닙니다.

그 결과 어떻게 되었을까요. 하나는 필요 없는 기능까지 늘어났습니다. 또 다른 하나는 나중에 사양서——AI와 공유하고 있는 설계 메모——를 다시 살펴보면, 기억에 없는 규칙이 적혀 있다는 것입니다. 어떤 기능이 어디서 작동하고 있는지 스스로 알 수 없게 되어갔습니다.

계기 이용 한도가 시간 단위로 리셋된다. "다 쓰지 않으면 아깝다"는 마음이 생긴다 -
행동 만들고 싶은 것이 정해지지 않았는데도 억지로 개발을 진행한다 -
결과 1 필요 없는 기능까지 늘어난다 -
결과 2 사양서에 기억에 없는 규칙이 쌓인다 -
도달하는 곳 어떤 기능이 어디서 작동하고 있는지 스스로 알 수 없게 된다

냉정하게 생각하면 "한도가 남으면 쉬면 된다"는 이야기일 뿐입니다. 하지만 개발이 자동으로 진행되는 즐거움과 아까워하는 심리가 겹치면 손을 멈출 수 없습니다. 구독 한도는 개발을 가속하는 메커니즘인 동시에, 내용을 알 수 없는 것들을 양산하는 압박이기도 했습니다.

만들 수는 있는데, 읽을 수 없다

처음에 "이건 좀 위험할지도 모르겠다"라고 생각한 것은 토큰 소비가 유독 커졌을 때였습니다. 자신이 파악하지 못하는 수준에서 문서와 소스 코드가 불어나고 있었습니다. AI는 매번 그것을 읽고 작업을 수행하므로, 비대해진 것은 그대로 소비량 증가로 돌아옵니다.

사실 코드를 읽는 것 자체는 훨씬 이전에 포기했습니다. Claude Code를 쓰기 전, GAS(Google Apps Script)——Google의 스프레드시트 등을 자동으로 작동시키는 메커니즘——로 AI에게 코드를 쓰게 하던 시절에는, 수백 줄이 되었을 때 이미 읽지 않았습니다. 읽을 시간도 없었고, AI가 작성한 것을 완전히 이해하는 것은 힘겨웠기 때문입니다.

그래도 전부 개인용이기에 개의치 않고 계속 만듭니다. 그러다 보니 완성된 것을 만져보는 것이 뒤로 밀리게 되고, 막상 만져보려 하면 버그가 다발하는 일도 있었습니다.

상징적인 사건이 하나 있습니다. 개인용 지식 노트를 만들려고 했더니, Claude Code가 "수동적인 화면은 만들지 않는 규칙이 있습니다"라며 제안을 거절한 것입니다. 기억에 없는 내용입니다. 찾아보니 주식 완전 자동 매매 도구를 만들려고 했을 때 정했던 규칙이 왜인지 작업 공간 전체의 규칙에 섞여 들어가 있었습니다.

내가 만든 규칙에 의해 나의 제안이 거절당한다.

실질적인 피해는 아직, 하지만 확실한 브레이크

"그래서 실질적인 피해가 있었느냐"라고 묻는다면, 솔직히 말해 "없다고 한다면 없다"입니다. 매매에서 손해를 봤다거나 데이터가 삭제되었다는 식의 사고는 일어나지 않았습니다.

하지만 브레이크는 확실히 걸려 있습니다.

가장 알기 쉬운 예가 주식 자동 매매 툴입니다. 이제는 무엇을 만들고 있는지조차 모르는 상태에서, Claude Code의 "다음은 이렇게 합시다"라는 제안에 올라타 기능을 마구 집어넣은 결과, 지금 이 툴이 무엇을 할 수 있는지 알 수 없게 되었습니다. 만든 본인이 말이죠. 이렇게 되면 사양(Specification)을 바꾸려 해도 무엇이 어디에 있는지 알 수 없기 때문에, 바꾸고 싶은 첫 단계부터 무거워집니다.

또 다른 하나는 토큰(Token) 소비입니다. 문서와 코드가 비대해진 결과, 주간 한도에 3일 만에 도달하게 되었습니다. 5시간 분량의 할당량이 단 1 세션 만에 날아가 버리기도 합니다.

3주 한도에 도달하기까지 (일)
15시간 할당량이 날아감 (세션)
수백줄의 코드 읽기를 포기한 행수 (GAS 시절)

"모르는 채로 만드는" 대가는 사고가 아니라, 속도 그 자체를 깎아먹는 형태로 돌아왔습니다. 빠르게 만들 수 있는 것이 장점이었는데, 그 속도가 줄어들고 있습니다. 지금 생각해보면 이것이 가장 실질적인 피해입니다.

그래서, 확인할 수 있는 속도를 만든다

대응책으로 선택한 것은 "열심히 코드를 읽는 것"이 아니었습니다. 읽을 수 없다는 사실은 GAS 시절부터 명확했습니다. 그 대신, 짧은 시간 안에 내용을 확인할 수 있는 도구를 만들기로 했습니다. 만드는 속도에 확인하는 속도를 따라잡게 하겠다는 방향입니다.

구체적으로 두 가지를 만들었습니다. 하나는 각 프로젝트의 진척도나 현재 위치를 일람할 수 있고, 사용 중인 툴이나 시스템의 전체도를 볼 수 있는 관리 툴입니다. 다른 하나는 여기저기서 자동으로 돌아가고 있는 부분—정해진 시간에 알아서 실행되는 처리 등—의 정보를 전부 수집하여, 하루 3번 상황을 보고해 주는 메커니즘입니다.

이것이 효과가 있었습니다. 마구 만들어낸 결과 여기저기서 돌아가고 있는 시스템의 재고 조사와 정리가 진행되었고, 마침내 전체를 이해할 수 있게 되었습니다. 지금은 아침에 1분만 보고를 확인하면 전체를 파악할 수 있습니다.

그럼에도 "전체가 보이지 않는 채로 계속 만드는" 상태에서는 벗어날 수 있었습니다. Claude Code로 만드는 것이 빨라질수록, 확인하는 메커니즘의 가치는 올라갑니다. 만약 똑같이 "만들 수는 있지만, 점점 알 수 없게 된다"라고 느끼기 시작한 사람이 있다면, 다음에 만들 한 가지는 기능이 아니라 확인 도구로 만들어 보세요. 만드는 속도가 그것만으로도 다시 조금은 회복될 것입니다.

Discussion