이번 주에 무엇을 했는가?
1. 쿠팡 가격과 관련된 프로젝트의 Core Logic을 카테고리 별로 정리했다.
2. Airtable에 프로젝트 관련 8개의 Core Logic을 정의하고, @logic-designer subagent를 호출해 기존에 있던 Inbox의 모든 데이터를 기반으로 로직을 정리해달라고 요청했다.
3. 1주일 간 운영 데이터를 쌓고, @logic-enhancer를 호출해 기존의 로직을 수정 및 강화해달라고 요청했다.
4. @pattern-automator subagent에게 core logic 파일을 기반으로 패턴을 발견하고, 자동화가 가능하다고 판단되는 영역을 추출해달라고 요청했다. 추출된 결과물을 Notion 파일로 생성하고, 개발 PM과 자동화 가능 영역을 리뷰했다.
이 과정에서 어떤 시행착오를 겪었는가?
1. MCP로 Airtable의 데이터를 끌어오는 과정에서 토큰이 25000으로 제한되어있다는 오류가 지속적으로 나왔다. 문제를 해결하기 위해 토큰을 10만으로 변경했다.
2. agnet를 어떻게 정의하여 활용할지에 대한 생각이 하루에도 몇 번이나 왔다갔다 했다. 하나의 subagent에게 너무 큰 역할을 주면 본인에게 주어진 책임에 집중하지 못할까 싶어 이를 몇 개의 subagent로 나눴다, subagent와 협업하는 workflow를 과도하게 복잡하게 만들었다 싶어 이를 다시 합치는 과정을 몇 번이나 반복했다. 처음에는 필요하다 싶어 역할을 부여해둔 agent가 실제 가치있게 사용되지 않았다. 회사를 운영하는 사람도 이와 비슷한 과정을 경험하겠다 싶었다. 필요하다고 싶어서 뽑았는데, 실제 채용해보니 별로 필요하지 않았거나 다른 일이 더 중요해진다. 맥락은 계속 바뀌고, 필요한 agent도 그에 따라 바뀐다. 이 과정에서 agent를 어떻게 archive 하고, 다시 살려내어 사용할 수 있을지를 몰라 버벅였다. .agent 하위에 archive 폴더를 만들어 밀어넣어 뒀는데, 계속 @를 사용하여 호출이 되는 상황을 해결하지 못해서 며칠을 헤맸다. 결국 md 파일 확장자를 disabled로 변경하면서 문제가 해결되긴 했는데, 이를 가장 잘 할 수 있는 정공법이 무엇인지 알고싶었다. 어떻게 필요없는 agent를—직원은 그럴 수 없지만— 바로 해고해버릴 수 있을까? 시스템에서 이를 어떻게 해야할까?
3. 처음에는 agent와 관련된 내용을 claude.md에 agent 별로 명시하도록 했다. 그런데 agent가 CRUD 됨에 따라, 특정 agent 관련 가이드가 claude.md 파일에 명시되어 있으니, 이를 업데이트 하는 게 일이 됐다. agent 관련 rule을 정리하는 건 agent_rules 폴더를 만들고, airtable에서 rule을 가져오는 방식으로 어느정도 추상화 시켰는데 claude.md 파일에서는 어떻게 해야하지? 일단은 .claude/agents 하위의 파일을 참조해!와 같은 방식으로 추상화 했다. 엔지니어라면 모든 것을 만들 때 추상화에 대한 고민을 처음부터 할 텐데, 추상화에 대한 연습이 되어있지 않으니 겪게 되는 문제인 듯하다.
4. subagent와 user command 관의 관게를 어떻게 잡아야 할지에 대한 혼란이 있었다. command는 subagent가 활용하는 'tool'인가? 아니면 subagent를 orchestration 하기 위한 명령(command)인가? 내가 내린 결론은 command는 subagent를 조율(orchestration)하기 위한 도구다. 관련 아티클(https://every.to/vibe-check/vibe-check-claude-s-new-agents-are-confusing-as-hell)이 생각을 정리하는 데 도움이 됐다.
앞으로 무엇을 더 해보고 싶은가?
1. 에이전트와 협업하는 가장 본질적인 능력이 무엇일까에 대한 생각을 하게 된다. 지금까지 내가 내린 결론은, 내가 풀고자는 문제가 무엇인지를 찾고, 이를 분석적으로 접근하는 능력이다. 내가 처리하고 싶은 일이 무엇인지, 그 일은 어떤 단계를 거쳐서 완결되는지, 각 단계의 입력 - 처리 - 출력 - 다음 단계는 무엇인지, 그 때 사용하는 데이터와 룰은 무엇인지, 어떤 시스템과 툴을 사용해야 하는지를 정의할 수 있어야 한다. 그래야지 agent에게 전체의 일에서 어떤 단계의 일을 적확하게 풀어달라고 할지 요청할 수 있고, 그에 필요한 툴을 쥐여줄 수 있다. 더불어 agent가 낸 결과물이 기존의 일하는 방식, 시스템과 맞아떨어지게 된다.
2. 누구나 이 과장을 가장 어려워 한다. 현황 파악과 문제 정의 단계, 이 단계를 탁월하게 해내야만 사용자에게 쓸모있는 무언가를 만들 수 있게 된다. 이 과정은 시장이 PM에게 기대하는 바이기도 하다. 이를 Agent와 함께하면 더 탁월하게 잘해낼 수 있지 않을까?
3. 배휘동 님의 강의자료를 읽으면서, 만들어보고 싶은 프로덕에 대한 생각이 확장된다. 제품의 이름은 'X-Ray'다. Claude Code와 함께 일의 본질을 다루는 제품을, 만들어보고 싶다.
