AI를 동료로 채용했습니다. EP.03 AI 팀을 만들기 전에, ‘나를 아는 팀장’부터 만들기로 했습니다. Little J를 키워가면서 한동안 이런 생각이 들었습니다. “다른 사람들은 에이전트를 여러개 만들던데, 나는 너무 단순하게 만들고 있는 건가?” 리서치 에이전트, 개발 에이전트, 데이터 분석 에이전트, 뉴스 에이전트. 역할별로 나누면 전문성도 분명하고, 일도 더 잘 나뉘는 것처럼 보였습니다. 저도 Claude Code로 다중 에이전트 팀을 만들어본 경험이 있어서 그 장점은 알고 있습니다. 그런데 이번에는 일부러 Little J 하나를 먼저 키우기로 했습니다. 이유는 에이전트를 여러 명 관리하기 불편해서가 아니었습니다. 그 문제는 앞에서 요청을 분류하고 적절한 담당에게 넘겨주는 역할 하나만 두어도 해결할 수 있습니다. 제가 더 중요하게 본 것은 맥락이었습니다. ━━━━━━━━━━━━━ "한 줄로 말이 통하려면" 제가 Little J에게 이렇게 말한다고 해보겠습니다. “다음 주 핵심인재 프로그램 문제 없는지 봐줘.” 이 한 줄로 일이 되려면 단순히 요청을 분류하는 것만으로는 부족합니다. Little J가 핵심인재 프로그램이 무엇인지, 지금 어느 단계인지, 지난번에는 어떤 기준으로 봤는지, 제가 무엇을 중요하게 생각하는지 알고 있어야 합니다. 단순히 요청을 나눠주는 역할과, 저와 일하면서 맥락을 쌓아온 동료는 다릅니다. 리서치 전문 에이전트는 자료를 잘 찾을 수 있고, 개발 전문 에이전트는 코드를 잘 짤 수 있습니다. 하지만 저는 그 전문성보다 먼저 “나를 가장 잘 아는 주체는 누구인가?” 를 정하고 싶었습니다. 그 역할이 Little J입니다. ━━━━━━━━━━━━━ "전문성은 그 뒤에 붙이면 됩니다" 제가 원하는 구조는 단순합니다. Triple J → Little J → 스킬 / 도구 / 전문 에이전트 저는 Little J와 이야기합니다. Little J가 필요한 능력을 판단합니다. 조사가 필요하면 리서치 전문 에이전트를, 분석이 필요하면 데이터 분석 에이전트를, 개발이 필요하면 개발 에이전트를, 검토가 필요하면 검토 에이전트를 부르면 됩니다. 즉, Little J는 앞으로 모든 일을 직접 하는 에이전트가 아니라 여러 전문성을 조율하는 오케스트레이터, 쉽게 말하면 AI 팀장이 되는 겁니다. 지금은 스킬과 도구 중심으로 가고 있지만, 업무가 충분히 복잡해져 맥락을 분리하거나 권한을 나눌 필요가 생기는 순간에는 전문 에이전트로 떼어낼 생각입니다. 다중 에이전트 구조를 하지 않는 것이 아니라, 아직 쪼갤 이유가 없는 겁니다. ━━━━━━━━━━━━━ "팀장이라면 결과까지 책임져야 합니다" 그렇다고 Little J가 다른 에이전트에게 일을 넘기기만 하면 된다는 뜻은 아닙니다. 그건 팀장이 아니라 전달책에 가깝습니다. Little J가 무엇을 확인했고, 왜 그렇게 판단했는지는 제가 볼 수 있어야 합니다. 그리고 결과 검증도 Little J의 감에만 맡기고 싶지는 않습니다. 코드는 테스트로, 데이터는 기준값으로, 중요한 판단은 체크리스트나 별도의 검토 역할로 확인하는 구조가 필요합니다. 결국 원칙은 이겁니다. Little J가 모든 걸 직접 하는 것이 아니라, 모든 걸 책임진다. 그래서 지금은 한 명을 키우고 있습니다. 제가 만들고 싶은 것은 여러 AI 에이전트의 목록이 아닙니다. 저를 가장 잘 아는 한 명의 동료. 그리고 그 동료가 필요할 때 적절한 스킬을 쓰고, 도구를 활용하고, 언젠가는 전문 에이전트들에게 일을 나눠주는 구조입니다. 전문성은 나중에 붙일 수 있습니다. 하지만 나에 대한 맥락은 같이 일하면서 쌓아야 합니다. 그래서 지금은 Little J 한 명을 먼저 키우고 있습니다. 언젠가 Little J가 여러 에이전트에게 일을 나눠주고, 검토까지 마친 뒤 제게 이렇게 말해주는 모습을 기대하면서요. “Triple J님, 제가 확인해봤는데요.”