클로드 코드 팀 도입 가이드: MCP·스킬·훅으로 코딩 에이전트 하네스를 설계하는 법

핵심 메시지

• 발표자는 개발자의 핵심 질문이 '이걸 어떻게 구현하지'에서 '코딩 에이전트가 이걸 제대로 구현하게 하려면 무엇을 줘야 하지'로 옮겨갔다고 본다.
• 최신 AI 연구소 밖의 평범한 개발팀이 겪는 병목은 세 가지다. 도구가 없거나, 도구를 잘 쓸 줄 모르거나, 개인의 생산성이 팀의 생산성으로 이어지지 않는다.
• 하네스 엔지니어링의 세 가지 기본 요소는 도구를 연결하는 MCP, 맥락을 담는 스킬, 경계를 만드는 훅이다.
• 스킬은 '할 수 있음'이 아니라 '잘함'을 준다. 에이전트가 30분 헤매며 저지른 실수를 스킬 파일로 압축해 두면 다음 세션에서 같은 실수를 반복하지 않는다.
• 슬랙·지라처럼 팀이 함께 쓰는 것은 팀 단위로 공유하고, 개인 취향에 가까운 설정은 개인 단위로 두는 것이 발표자의 기준이다.

쉽게 이해하기

물리학 박사 출신으로 데이터 과학자를 거쳐 지금은 AI 교육·컨설팅을 하는 샤힌 탈레비는, 소프트웨어 엔지니어링이 이미 다른 일이 됐다는 전제에서 발표를 시작한다. 그는 선도 AI 연구소의 엔지니어들이 자사 코드의 거의 전부를 모델이 쓰고 있다고 밝힌 보도를 인용하며, 이 변화가 '하네스 엔지니어링'이라는 새로운 기술을 요구한다고 말한다. 하네스 엔지니어링은 모델 자체를 만드는 일이 아니라, 모델 주변의 도구와 맥락과 경계를 설계해 쓸모 있는 결과를 내게 만드는 일이다.

그는 발표를 준비하며 지인 개발자들을 대상으로 조사한 결과 세 가지 병목이 반복해서 나타났다고 소개한다. 첫째는 도구 부재다. 사내에서 만든 챗봇이나 웹 채팅 화면만 쓸 수 있어서 코드를 실제로 다루는 에이전트를 아예 못 쓰는 경우다. 둘째는 숙련도 문제로, 도구는 있지만 결과물이 오히려 일을 늘려서 '처음부터 내가 짜는 게 빨랐겠다'는 상황이 반복된다. 셋째는 협업의 문제다. 구성원 각자가 10배 빨라져도 소통 방식과 업무가 들어오는 경로가 그대로면 팀 전체 산출은 늘지 않는다.

발표의 본론은 클로드 코드를 예로 든 세 가지 기본 요소다. MCP는 슬랙·지라·노션·깃허브·관측 도구 같은 업무 시스템에 에이전트를 연결하는 통로다. 그는 새로 합류한 동료에게 슬랙 계정도, 지라 접근 권한도 주지 않는 상황을 상상해 보라며, 코딩 에이전트를 팀에 온보딩시키는 것과 같은 일이라고 설명한다. 설치는 클로드 코드 안에서 플러그인 목록을 열어 공식 마켓플레이스에서 받는 방식이 가장 안전하고, 출처가 불분명한 서버를 내려받을 때는 주의가 필요하다고 덧붙인다.

두 번째 요소인 스킬은 마크다운 파일 하나를 중심으로 참고 자료·이미지·실행 스크립트를 담은 폴더다. 핵심 동작은 점진적 공개다. 세션이 시작될 때는 스킬의 설명만 컨텍스트에 올라가고, 지금 하는 일과 관련이 있다고 판단될 때 비로소 본문이, 더 필요하면 하위 파일이 불려 온다. 덕분에 컨텍스트 창을 부풀리지 않으면서도 필요한 정보를 다 줄 수 있고, 여러 스킬을 상황에 맞게 조합할 수도 있다. 자료가 적은 신생 프레임워크, 팀의 코딩 표준, 도메인 지식처럼 모델이 자주 틀리는 영역이 좋은 후보다.

세 번째 요소인 훅은 도구 호출 전후에 자동으로 실행되는 코드다. 발표자는 브라우저를 닫을 때 쌓인 스크린샷을 지우는 정리 작업, 환경 변수 파일 접근을 아예 차단하는 보호 장치, 코드 생성 뒤 검증 단계를 자동으로 돌리는 절차를 예로 든다. 훅의 진짜 효과는 자동화 자체보다 신뢰에 있다. 위험한 행동이 구조적으로 막혀 있으면 에이전트를 더 독립적으로 굴릴 수 있기 때문이다. 이렇게 만든 MCP·스킬·훅 묶음은 플러그인으로 포장해 깃허브에 올려 팀 전체가 같은 설정을 공유할 수 있다.

주요 인사이트

• 도구를 붙이는 것과 도구를 잘 쓰는 것은 다른 문제다. MCP로 연결만 해 두면 에이전트가 불필요한 호출을 반복하거나 오류를 받아 오는 일이 잦아, 그 도구 전용 스킬을 따로 만들어 두는 편이 효율적이다.
• 에이전트가 헤맨 시간은 버려지는 비용이 아니라 스킬의 재료다. 실수와 해결 과정을 그때그때 문서로 압축해 두는 팀이 시간이 갈수록 유리해진다.
• 개인의 속도가 아니라 팀과 조직의 처리 능력이 상한을 정한다. 개발팀만 10배 빨라지고 요구사항이 들어오고 검증되는 경로가 그대로면 그 속도는 어디선가 막힌다.
• 무엇을 팀 공용으로 만들지 정하는 기준은 단순하다. 모두가 같은 계정과 같은 규칙을 쓰는 영역은 하나로 통일하고, 취향과 개인 작업 습관에 속한 것은 굳이 팀에 강요하지 않는다.
• 발표자는 여기서 설명한 원리가 클로드 코드에만 해당하지 않는다고 못 박는다. 다른 코딩 에이전트를 쓰더라도 도구·맥락·경계를 설계한다는 접근은 그대로 적용된다.

자주 묻는 질문

관련 AI 소식