클로드 코드 개발자의 실제 사용법 — 음성 코딩, 규칙 파일, 에이전트 5개 병렬 실행

핵심 메시지

• 클로드 코드를 만든 보리스 체르니는 코딩 대부분을 타자가 아니라 말로 한다. 말하기가 타자보다 세 배 빠르고, 말로 하면 프롬프트에 담기는 맥락도 훨씬 많아지기 때문이다.
• 이제 결과물의 한계를 정하는 것은 모델의 능력이 아니라 사람이 건네는 지시다. 팀은 모델이 물어본 것보다 훨씬 많은 일을 할 수 있는데도 우리가 그만큼 묻지 않는 상태를 '능력 과잉'이라고 부른다.
• 오퍼스 5가 나왔을 때 클로드 코드 팀은 시스템 프롬프트의 80% 이상을 지웠고, 규칙과 예시를 걷어내자 모델이 오히려 더 잘했다.
• '지도는 영토가 아니다.' 프롬프트와 문서가 침묵하는 지점에서 에이전트는 묻지 않고 추측하며, 그것도 확신을 가지고 틀린다.
• AI가 실수할 때마다 다시 하라고 말하는 대신 규칙 파일에 적어 둔다. 교정은 그 순간만 바꾸지만 규칙은 이후 모든 작업을 바꾼다.

쉽게 이해하기

클로드 코드를 만들고 총괄하는 보리스 체르니는 자신이 코딩 대부분을 타자가 아니라 말로 한다고 밝혔다. 가장 단순한 이유는 속도다. 말하기가 타자보다 세 배 빠르다. 하지만 그는 속도가 전부는 아니라고 덧붙인다. 말로 하면 프롬프트가 훨씬 더 상세해지고, 타자로는 귀찮아서 생략하던 맥락까지 자연스럽게 다 들어간다는 것이다. 방법 자체는 간단해서, 명령어 하나를 치고 스페이스바를 누르거나 맥에서는 펑션 키를 두 번 누르면 된다.

같은 팀에서 사용법에 대한 글을 쓰는 동료 타릭은 지금 상황을 '능력 과잉'이라고 표현한다. 모델은 우리가 묻는 것보다 훨씬 많은 걸 할 수 있는데 우리가 그만큼 묻지 않는다는 뜻이다. 결과를 망치는 주범은 모델이 아니라 얇은 지시와 불필요한 제약이라는 것이다. 이를 뒷받침하는 사건이 오퍼스 5 출시 때 있었다. 클로드 코드 팀이 시스템 프롬프트의 80% 이상을 지우고 규칙과 예시를 걷어냈더니 모델이 더 잘 동작했다. 모델이 사람이 준 예시보다 상상력이 풍부하다는 것을 발견했기 때문이다. 예시를 잔뜩 주는 일은 도움이 아니라 천장을 씌우는 일이 될 수 있다.

타릭이 반복해서 꺼내는 비유는 '지도는 영토가 아니다'라는 말이다. 지도는 내가 AI에게 건넨 모든 것, 즉 프롬프트와 지시와 문서다. 영토는 실제 코드베이스와 그 이력, 문서에 없는 제약, 요청 뒤에 숨은 진짜 의도다. 아무리 잘 써도 지도는 영토를 다 담지 못하고, 지도가 침묵하는 그 지점에서 에이전트는 확신을 가지고 틀린다. 한 번의 추측은 사소해 보이지만 작업이 길어질수록 추측이 쌓이고 결과물 전체가 무너진다. 직관과 반대로, 모델이 좋아질수록 지도를 더 철저히 실행하기 때문에 구멍의 대가는 오히려 더 비싸진다.

그래서 타릭은 '모름'을 네 가지로 나눈다. 안다는 걸 아는 것, 모른다는 걸 아는 것, 알고 있지만 말하지 않은 것, 그리고 모른다는 것조차 모르는 것이다. 특히 흔한 것은 세 번째로, 나에게 너무 당연해서 굳이 말하지 않은 것들이다. 가장 비싼 대가를 치르는 것은 네 번째인데, 지시에 넣을 생각조차 못 했으니 AI가 그 부분을 통째로 추측하게 된다. 그가 권하는 실천법은 네 가지다. 코드를 건드리기 전에 내 요청을 AI가 자기 말로 다시 설명하게 하고, 그럴듯한데 틀린 결과가 나오면 그것을 신호로 보아 프로젝트 규칙 파일에 적어 두고, 깊이 생각하게 만드는 기능은 진짜 모호한 일에만 쓰고, 새 모델이 나오면 예전에 필요했던 제약이 이제는 방해가 아닌지 다시 점검하는 것이다.

보리스의 실제 운영 방식도 참고할 만하다. 그는 깃 워크트리를 최대 생산성 해금이라고 부르며, 작업 폴더를 나눠 두고 클로드를 다섯 개까지 동시에 돌린다. 여기에 웹과 모바일 세션을 더하면 열 개가 넘어가기도 한다. 그는 최신 모델에서는 계획 모드가 필요 없다고 보고 대신 오토 모드를 쓴다. 안전한 작업은 자동으로 넘기고 위험한 것만 걸러 내는 방식인데, 모든 확인창을 하나하나 읽다 보면 주의력이 떨어져 정작 중요한 걸 놓치기 때문에 오히려 더 안전할 수 있다는 설명이다. 그는 AI 도입을 막힌 단계, 보조, 병렬, 감독형, 자율, AI 네이티브의 다섯 단계로 정리하며, 단계가 올라갈수록 다루는 에이전트 수가 하나에서 열, 백, 천 개로 늘어난다고 말한다.

주요 인사이트

• 예시와 규칙을 많이 넣을수록 좋다는 통념이 실제 운영에서는 뒤집혔다. 클로드 코드 팀은 시스템 프롬프트를 대폭 덜어 내는 쪽에서 성능 향상을 얻었고, 복잡성은 그 값어치를 스스로 증명해야 한다는 원칙을 남겼다.
• 모델 성능이 올라간다고 지시의 부실함이 자동으로 보정되지는 않는다. 좋은 모델일수록 주어진 지도를 더 철저히 실행하므로 지시의 구멍이 더 비싸진다.
• 가장 큰 손실은 '모른다는 것조차 모르는' 영역에서 나온다. 그래서 코드가 바뀌기 전에 AI가 요청을 자기 말로 되짚게 하는 것이 가장 값싸게 모름을 찾아내는 방법이다.
• 일회성 교정 대신 규칙 파일에 축적하는 습관이 에이전트를 몇 시간씩 돌려 둘 수 있게 만드는 실질적인 차이를 만든다.
• 모든 확인창을 일일이 검토하는 것이 반드시 더 안전하지는 않다. 반복 확인은 주의력을 갉아먹어 정작 중요한 순간을 놓치게 만든다.

자주 묻는 질문

관련 AI 소식