클로드 코드 사용 패턴 스냅샷

Opus 4.5 이후 클로드 코드 사용 방법이 꽤 달라진 걸 느껴서 아카이빙 하기 위해 기록.

아직은 vibe coding과 agentic coding의 실제 코딩 패턴, 결과물의 품질, 각 방법론을 적용 가능한 프로젝트의 규모 등에 큰 차이가 있다. 큰 프로젝트, 방대한 맥락, 복잡한 모듈 구현 등에는 vibe coding을 할 수가 없다. 프로젝트 작업을 원활하게 진행하려면 코딩 에이전트에 하네스를 잔뜩 둘러서 agentic coding을 해야만 한다.

모델이 업그레이드 되고, claude code 툴에 내장된 하네스가 좋아지면 둘 사이의 갭이 조금씩 메워지겠지만, 하여튼 2026년 1월 현재는 그렇다.

Research, Plan, Implementation

아래 두 영상에서 공통적으로 제시하는 워크플로우를 절찬리에 적용 중.

모든 것은 에이전트의 작고 소중한 컨텍스트 윈도우를 어떻게든 아끼려는 노력에서 출발한다. LLM을 쓰다 보면 경험적으로 누구나 알게 되는 사실이 있다. LLM이 제공하는 컨텍스트 윈도우의 퀄리티는 균일하지 않는 것이다. 클로드 기준, 200k 윈도우 중 대략 40%, 75k 전후를 쓸 때부터 소위 "dumb zone"에 진입한다. LLM이 바보가 되는 것이다. 그래서 smart zone 안에서 최대한 작업을 끝내야 한다.

Dex Horthy가 제시하는 research-plan-implementation 워크플로우는 이럴 때 유리하다. 작업을 계획하기 위해 필요한 모든 리서치를 문서로 모으고, 리서치 결과로부터 작업 계획을 문서로 만들고, 클로드와 함께 작업 계획 문서를 열심히 뒤집어엎는다. 작업 계획 문서가 잘 작성됐으면 implementation 단계로 넘어간다.

외부 메모리를 최대한 활용하고, 작업의 세부 스텝을 잘게 쪼개서 컨텍스트 윈도우에는 정말 필요한 정보만 일부 들고 있게 하자는 전략이다. 나는 곧바로 plan 단계로 들어간다. 단, researcher 에이전트를 별도로 만들어서, 메인 에이전트가 plan 스텝에서 미리 researcher에게 리서치를 먼저 시킨다. 이렇게 해도 컨텍스트 윈도우가 충분히 절약된다.

실제 업무에는 워크플로우를 정의해둔 몇몇 명령들과 서브에이전트들을 활용한다. 그래서 조금 더 복잡하다.

• ·/create-plan: 메인 에이전트가 내부 루프를 돌며 researcher 서브에이전트를 충분히 가동시킨다. 각 서브에이전트는 자신의 리서치 결과를 마크다운 파일로 저장한다. 리서치가 끝나면, 메인 에이전트는 리서치 결과 파일을 읽어들이고 나와 문답을 몇 번 주고받은 뒤, 계획 파일을 마크다운으로 저장한다.
• ·/update-plan: 계획 파일을 내가 충분히 만족할 만큼 개선한다. 이 때에도 researcher 서브에이전트를 사용한다.
• ·/research: 아주 가끔, 리서치가 필요한 대상을 클로드가 놓쳤을 경우 내가 직접 리서치를 시킨다.
• ·/implement-plan: 계획 파일 리뷰가 끝나면 구현할 차례다. 구현 관련 몇몇 원칙들을 주입시키기 위한 커맨드.
• ·/enhance-code: 구현이 끝나면 code-reviewer와 code-simplifier 서브에이전트를 가동시켜 코드 품질을 올린다.
• ·/commit-push-pr: 귀찮은 git 작업을 워크플로우로 정의.

요즘은 코드보다는 주로 계획 파일 리뷰에 시간을 많이 쏟는다. 아무래도 사람의 말로 적혀 있는 계획 파일이 읽기 더 좋다. 확실히 느낀 점은, 계획이 잘 작성되어 있다면 매우 높은 확률로 손 댈 필요 없는 코드가 나온다는 것이다. 물론, 작업의 크기는 충분히 작아야 한다. 일반 SWE가 30분-1시간 안에 해낼 수 있는 정도의 사이즈로.

Declarative over Imperative

대체로 how를 일일이 기술하지 않는다. 계획 대부분은 desired end state 형태로 선언적으로 작성돼있다. 계획의 개별 phase만 그나마 절차적인 느낌. 사실.. 많은 how들이 command/skill/subagent 정의에 적혀 있긴 하다. 내 입맛에 맞게 에이전트의 동작을 조종하려면 어쩔 수 없다. 그래도 예전에 비하면 절차보다 목표를 훨씬 더 많이 적게 된다.

Meta-thinking

요즘 즐겨 쓰는 프롬프팅 방식. LLM들은 대체로 내 입력을 곧이곧대로 받아서 처리하려는 경향이 있다. 내 의도, 현재 상황, 맥락, 구현 목표 등에 대해 한 층위 밖에서 메타적으로 사고하면, 종종 더 좋은 관점 또는 솔루션을 얻을 수 있다. 그래서 요즘은 '내 의도와 현재 상황에 대해 메타적으로 사고하고 작업을 진행해줘' 라는 프롬프트를 자주 쓰고 있다. 물론 굳이 이런 프롬프팅을 해주지 않아도 종종 내가 원하는 레벨의 메타 사고를 하긴 한다. 그래도 이렇게 사고방식을 강제시키면 지침을 잘 따라주기 때문에, 전반적으로 조금 더 높은 퀄리티의 출력을 기대할 수 있다.