코딩 에이전트 작업 환경 구성의 마지막 글이다. 앞선 글에서는 설계와 검증을 건너뛰지 않게 하는 도구(1편)와, 성능은 지키면서 불필요한 토큰 사용을 줄이는 도구(2편)를 다뤘다. 이번에는 조금 다른 관점에서, 에이전트가 만든 결과를 사람이 빨리 이해하고 다음 행동으로 옮기게 만드는 설정들을 정리한다.
에이전트가 좋은 결과를 만들어도, 사용자가 내용을 다시 읽고 현재 상태를 파악하고 다음 행동을 정해야 한다면 그만큼 작업 흐름이 끊긴다. 그래서 에이전트의 성능뿐 아니라 결과를 사람이 받아들이는 방식도 일정하게 만드는 것을 중요하게 본다.
1. i-have-adhd: 답의 모양을 정하기
i-have-adhd는 에이전트의 답변을 행동 중심으로 구조화하는 플러그인이다. 핵심은 설명을 많이 하는 게 아니라, 현재 상태와 다음 행동을 빨리 찾을 수 있게 답변의 순서를 일정하게 만드는 것이다. 주요 규칙은 이렇다.
- 첫 줄에 바로 실행할 수 있는 행동을 둔다.
- 여러 단계라면 한 단계에 행동 하나만 둔다.
- 지금 어디까지 왔고 다음에 무엇을 할지 보여 준다.
- 오류는 위치 → 원인 → 해결 순서로 설명한다.
- 작업이 끝나면 무엇이 실제로 동작하게 됐는지 보여 준다.
- 남은 일이 있으면 마지막에 바로 할 수 있는 다음 행동 하나를 남긴다.
긴 설명 뒤에서 할 일을 찾게 하기보다, 먼저 "이 파일의 설정값을 바꾸세요"라고 제시하고 필요한 설명을 뒤에 붙이는 식이다.
항상 짧게만 답하게 하는 건 아니다. 원리 설명이 필요하면 충분히 설명하고, 되돌리기 어려운 작업은 실행 전에 확인하게 하는 등 정확성과 안전이 필요한 상황에는 예외를 둔다.
2편의 Serena나 서브에이전트가 에이전트의 작업 과정을 효율화한다면, i-have-adhd는 그 결과를 사람이 받아들이는 과정을 효율화한다. 이 차이가 꽤 중요하다고 느꼈다. 코딩 에이전트가 아무리 좋아져도, 결과를 확인하고 방향을 정하는 구간에는 결국 사람이 있기 때문이다.
2. archify: 구조를 설명하기
최근에는 프로젝트 구조를 다른 사람에게 설명할 때 archify라는 스킬도 쓴다. 프로젝트를 분석한 뒤 아키텍처를 인터랙션 가능한 HTML 다이어그램으로 만들어 주는 도구다.
일반 모델에 다이어그램을 직접 요청할 수도 있지만, archify는 프로젝트를 살펴보는 과정과 결과물의 형태가 어느 정도 정형화돼 있어 편했다. 문서에 넣을 정적인 그림보다는, 지금 시스템 구조를 다른 사람과 함께 보거나 설명할 때 유용하다. 이 시리즈의 다이어그램도 archify로 만들었다.
3. 직접 만들어 쓰는 스킬
공개된 플러그인 외에도 내 작업 방식에 맞게 개인 스킬을 몇 개 만들어 쓴다. 지금 주로 쓰는 것은 astra-workstyle과 wrap이다.
astra-workstyle: 작업 결과 정리
작업 단위가 끝났을 때 결과를 일정한 형태로 정리하려고 만든 스킬이다. 무엇을 했는지, 어떤 결과가 나왔는지, 남은 일이 무엇인지 정리하고, 다른 사람에게 공유해야 할 때는 /report로 보고용 형태를 만들게 해 두었다.
i-have-adhd가 매 응답의 구조를 정한다면, astra-workstyle은 작업 하나가 끝난 뒤 결과를 정리하는 역할에 가깝다.
wrap: 병렬 작업 마무리
Claude Code와 Codex를 CLI에서 함께 쓰고, Git worktree로 여러 작업을 병렬로 진행하기도 한다. 작업이 끝난 뒤 결과를 확인하고, 필요한 내용을 메모리에 남기고, 커밋과 병합을 처리하고, 쓴 worktree까지 정리하는 데 wrap 스킬을 쓴다.
프로젝트 메모리도 큰 파일 하나에 계속 쌓지 않는다. 파일 하나에는 가능한 한 사실 하나만 저장하고, MEMORY.md에는 필요한 내용을 찾기 위한 짧은 색인만 둔다.
이 스킬을 만든 목적은, 작업은 끝났는데 정리가 남아 있는 상태를 한 번에 처리하는 것이다.
4. 여러 규칙을 함께 쓰는 방법
규칙을 무작정 더하면 서로 충돌할 수 있다. 그래서 각 도구가 맡는 영역이 겹치지 않게 구성한다.
- ponytail: 코드의 복잡도와 구현 범위를 줄인다.
- caveman: 답변의 표현을 압축한다.
- i-have-adhd: 그 내용을 어떤 순서로 전달할지만 정한다.
같은 답변에 여러 규칙이 적용되더라도 구현, 표현, 구조라는 서로 다른 축을 맡도록 나눈 것이다.
5. 한계
이런 규칙도 항상 이득만 주지는 않는다. 플러그인과 스킬의 지침 자체가 컨텍스트에 들어가니, 설정이 많아질수록 고정 입력 토큰도 는다.
행동 중심으로 답변을 압축하면 빠르게 작업할 때는 편하지만, 새로운 개념의 원리와 배경을 깊이 이해해야 할 때는 오히려 설명이 모자랄 수 있다. 그래서 빨리 실행할 작업과 깊이 이해할 작업을 구분하고, 후자에는 "원리부터 설명해 줘"처럼 원하는 답변 방식을 따로 지정한다.
결국 규칙을 많이 넣는 게 목적이 아니라, 반복되는 불편을 실제로 줄여 주는 규칙만 남기는 것이 중요하다.
6. 시리즈 마무리
이 시리즈는 Claude Code와 Codex를 쓰면서 하나씩 더해 온 플러그인과 스킬을 목적별로 다시 나눠 보는 데서 시작했다. 세 편을 정리하면 이렇다.
| 편 | 다룬 것 |
|---|---|
| 1편 | 설계와 검증을 건너뛰지 않게 개발 과정을 관리하는 방법 |
| 2편 | 에이전트가 말하고, 만들고, 읽는 범위를 줄여 불필요한 토큰 사용을 줄이는 방법 |
| 3편 | 에이전트의 결과를 사람이 빨리 이해하고 다음 행동으로 옮기게 만드는 방법 |
결국 이 환경은 세 가지 문제를 줄이기 위한 것이었다.
- 개발 과정에서 필요한 단계를 건너뛰는 문제
- 컨텍스트와 토큰을 불필요하게 쓰는 문제
- 결과가 나와도 사람이 다시 정리해야 하는 문제
구성은 꽤 많아졌지만, 새 기능을 계속 붙이기보다 이 세 가지 문제를 실제로 줄여 주는지를 기준으로 남기려 한다.
쓰는 모델과 도구, 에이전트가 많아질수록 이를 관리하는 것 자체가 또 하나의 부채가 된다. 쏟아지는 결과물에 파묻히지 않을 방법을 계속 고민하게 된다. 최종적으로 판단하고 책임지는 것은 결국 개발자 한 명이다. 그래서 더 많은 에이전트를 쓰는 것보다, 결과를 빨리 파악하고 통제·검수할 수 있는 구조를 만드는 것이 더 중요하다고 느낀다.
여기서 소개한 방식 중 상당수는 특정 코딩 에이전트에 묶인 개념이 아니다. 다른 도구를 쓰더라도 각자의 환경에 맞게 일부 아이디어는 적용해 볼 수 있다. 물론 지금 구성이 정답은 아니다. 프로젝트와 작업 방식에 따라 필요한 도구는 달라지니, 각자 필요한 부분만 골라 쓰는 것이 가장 적절하다.