18
도구는 바뀌어도 자산은 남는다
클로드 코드에 새 기능이 추가되었다는 소식을 거의 매일 접한다. 한 달에 패치가 열 번 넘게 나오고, 릴리스 노트를 읽는 것만으로도 시간이 간다. 트위터에는 새로운 프롬프트 기법이 올라오고, 유튜브에는 "이 설정 하나면 생산성 10배"라는 제목의 영상이 쏟아진다. 한동안 이 흐름을 따라가려고 부지런히 움직였다. 그러다 어느 순간 멈춰 서서 생각했다. 나는 지금 뭘 쌓고 있는 건가.
지난 몇 달간 하네스 엔지니어링에 적지 않은 시간을 투자했다. CLAUDE.md를 정교하게 설계하고, 에이전트를 역할별로 분리하고, 훅으로 품질 게이트를 걸고, MCP 서버를 연결하고, 컨텍스트 윈도우를 절약하기 위한 최적화를 했다. 배운 것도 많았고 실제로 생산성이 올라가기도 했다. 그런데 어느 지점부터 불편한 감각이 생겼다. 이 노력의 상당 부분이 모델이 지금 충분히 잘 못한다는 전제 위에 서 있다는 걸 깨달았기 때문이다.
640KB이면 충분했던 시절
1981년 IBM PC가 출시되었을 때 기본 메모리는 16KB였다. 프로그래머들은 바이트 단위로 메모리를 관리했다. 변수 이름을 한두 글자로 줄이고, 데이터 구조를 비트 단위로 압축하고, 함수 하나의 메모리 영향을 일일이 계산했다. 빌 게이츠가 "640KB면 누구에게나 충분하다"고 말했다는 유명한 일화가 있다. 진위 여부는 불분명하지만, 그 시대의 인식을 정확히 드러낸다. 지금의 한계가 영원할 것이라는 착각이다.
그 착각은 불과 10여 년 만에 깨졌다. 메모리 가격이 떨어지고 용량이 늘면서, 바이트 단위 최적화에 쏟던 시간은 의미를 잃었다. 지금 프로그래머 중에 변수 이름 길이가 메모리에 미치는 영향을 걱정하는 사람은 없다. 디스크 용량도 마찬가지다. 한때는 파일 하나를 플로피 디스크에 맞추려고 안간힘을 썼지만, 지금은 테라바이트 SSD가 노트북에 기본 장착된다. 한 세대 전에 가장 중요했던 제약이 다음 세대에는 아무도 신경 쓰지 않는 일이 되는 패턴은 컴퓨팅 역사에서 반복적으로 등장한다.
AI의 토큰과 컨텍스트 윈도우가 지금 정확히 이 경로에 있다. 3년 전만 해도 GPT-3.5의 기본 컨텍스트는 4천 토큰이었다. 지금은 100만 토큰 모델이 나왔다. 토큰 단가는 분기마다 하락하고 있다. 이 추세가 갑자기 멈출 이유가 보이지 않는다. 프롬프트를 압축하고, 불필요한 컨텍스트를 잘라내고, 토큰 효율을 최적화하는 작업은 1980년대 프로그래머가 변수 이름을 한 글자로 줄이던 것과 구조적으로 같은 종류의 노력이다. 기술이 발전하면 자연스럽게 풀릴 문제에 우리의 시간을 쏟고 있는 셈이다.
하네스에 유통기한이 있다는 것
나는 하네스 엔지니어링을 꽤 전방위로 해봤다. CLAUDE.md에 역할과 규칙과 워크플로우를 촘촘하게 적어두었고, 에이전트를 기능별로 분리해서 파이프라인을 구성했고, 훅으로 편집 후 자동 검증을 걸었고, 메모리 시스템으로 세션 간 맥락을 이어가게 했다. 한동안은 이 시스템이 정교해질수록 결과물의 품질이 올라갔다. 그래서 더 정교하게 만들었다.
전환점은 내가 만든 설계가 오히려 모델의 능력을 제한하는 순간들을 발견하면서 왔다. 규칙을 너무 많이 박아두니 모델이 경직되었다. 에이전트를 너무 세분화해서 나눠놓으니 단순한 작업에도 불필요한 오버헤드가 생겼다. 컨텍스트를 아끼려고 정보를 압축했더니 모델이 중요한 맥락을 놓쳤다. 가장 선명했던 순간은 LLM Wiki라는 새로운 접근을 도입하려 했을 때다. 기존에 내가 만들어둔 문서 업데이트 훅, 메모리 시스템과 곧바로 충돌이 발생했고, 복잡성이 순식간에 올라갔다. 새 것을 받아들이려면 이전에 쌓아둔 하네스부터 뜯어내야 했다.
이 경험에서 깨달은 것은 하네스가 쓸모없다는 게 아니었다. 하네스의 본질적 전제가 문제였다. 하네스는 모델이 충분히 잘 못한다는 판단 위에 세워진다. 모델이 맥락을 놓치니까 컨텍스트 관리를 해주고, 모델이 실수하니까 검증 훅을 걸고, 모델이 일관성을 유지 못하니까 규칙을 박아둔다. 이 판단들은 지금 이 순간에는 대부분 맞다. 그런데 유효기간이 생각보다 짧다.
매 분기 새 모델이 나올 때마다 전제들이 하나씩 흔들리는 걸 이미 체감하고 있다. 하네스 엔지니어링 자체를 부정하는 게 아니다. 지금 단계에서는 분명히 필요하다. 그 위에 쌓는 시간의 유통기한이 짧다는 것을 인식하자는 이야기다.
모델이 바뀌어도 바뀌지 않는 것
그렇다면 뭘 쌓아야 하는가. 내가 직접 해보면서 확인한 답은 자산화다. 조직의 암묵지, 흩어진 데이터, 사람 머릿속에만 있는 판단 기준을 AI가 활용할 수 있는 형태로 정리해두는 것이다. 모델이 아무리 강해져도 우리 조직의 의사결정 히스토리는 AI가 스스로 만들어낼 수 없다. 고객 데이터의 맥락, 도메인 전문가의 판단 기준, 이 프로젝트가 왜 이런 구조로 되어 있는지의 이유. 이런 것들은 우리만 가진 것이고, 모델이 강해질수록 오히려 더 중요해진다. 차이는 이걸 매번 사람이 구두로 설명하느냐, AI가 스스로 읽어갈 수 있는 형태로 정리되어 있느냐에 있다.
자산화의 실패를 나는 세 가지 형태로 겪었다. 첫째는 담당자 이직과 함께 지식이 사라지는 경험이다. 특정 사람의 머릿속에만 있던 판단 기준이나 노하우가 그 사람이 떠나면서 조직에서 증발했다. 둘째는 AI에게 일을 시키려 할 때의 답답함이다. 우리 조직의 맥락, 이전 의사결정의 배경, 이해관계 구조를 전달할 방법이 마땅치 않았다. 셋째는 반복 설명의 피로다. 같은 컨텍스트를 매번 새 세션마다 처음부터 다시 전달해야 했다. 이 세 가지는 전부 같은 뿌리에서 나온다. 우리의 지식이 AI가 접근할 수 있는 형태로 정리되어 있지 않다는 것이다.
반대로 자산화가 잘 된 경우도 있었다. 반복 작업의 워크플로우와 품질 기준을 명시적으로 정의해두었을 때, AI는 놀라울 정도로 일관된 결과를 냈다. 아티클 작성 프로세스, 콘텐츠 구조, 디자인 규칙 같은 것들이다. 이건 프롬프트 테크닉이 아니다. 이건 자산이다. 프롬프트 테크닉은 다음 모델 업데이트에 구식이 될 수 있지만, 우리 프로젝트의 콘텐츠 구조와 워크플로우는 어떤 모델이 와도 유효하다. 자산화에는 세 가지 층위가 있다고 생각한다. 암묵지의 명시화, 데이터의 구조화, 워크플로우의 정의. 이 세 가지는 모델이 바뀌어도, 도구가 바뀌어도, 팀이 바뀌어도 가치가 유지된다.
시간을 어디에 쓸 것인가
하네스를 전방위로 만들어본 사람으로서 내가 내린 결론은 이렇다. 도구 사용법을 최적화하는 시간의 상당 부분을 우리의 지식과 데이터를 자산화하는 데 돌려야 한다. 클로드 코드의 새 기능을 따라가는 것보다 우리 팀의 암묵지를 AI가 읽을 수 있는 형태로 만드는 게 더 오래 가는 투자다. 물론 하네스 엔지니어링이 지금 당장 불필요하다는 뜻은 아니다. 모델이 완벽하지 않은 지금, 좋은 하네스는 분명히 차이를 만든다.
내가 말하고 싶은 건 비율의 문제다. 도구를 다듬는 시간과 자산을 쌓는 시간의 비율을 의식적으로 점검할 필요가 있다. 그리고 그 비율은 모델이 발전할수록 자산 쪽으로 기울어야 한다. 1980년대에 바이트 최적화에 쏟던 시간은 결국 메모리 기술이 흡수해버렸다. 토큰 절약과 하네스 최적화에 쏟는 시간도 같은 경로를 밟을 가능성이 높다. 기술이 풀어줄 문제가 아니라, 기술이 풀어줄 수 없는 문제에 시간을 쓰는 편이 낫다.
이 글을 쓰면서 스스로에게 던진 질문이 하나 있다. 내가 지금 쌓고 있는 것은 다음 모델 업데이트에도 살아남는가. 이 질문에 예라고 답할 수 있는 것만 남기려 한다. 당신이 매일 쏟고 있는 시간은, 도구를 다듬는 데 가고 있는가, 자산을 쌓는 데 가고 있는가.
0
0