클로드 코드에 프로젝트를 통째로 맡겨본 분이라면 비슷한 기억이 있으실 겁니다. 처음엔 그럴듯하게 진행되다가 어느 순간 산으로 간 결과물을 받아 들고, AI는 아직 멀었다며 창을 닫는 경험입니다. 그런데 이런 실패의 원인은 대부분 AI의 성능이 아니라 일을 넘기는 단위에 있습니다. 이 글은 클로드 코드 잘 쓰는 법의 핵심인 '위임의 단위' 설계를 다룹니다. 직무를 어떻게 쪼개고, 어떤 업무를 넘기며, 비워진 자리에 무엇을 채울지 순서대로 정리해 드립니다.
왜 통째로 맡기면 산으로 갈까요
직무와 업무는 다릅니다. 개발자의 직무는 요구사항 해석, 설계 판단, 코드 작성, 테스트, 배포 결정 같은 수십 개 업무가 얽힌 묶음입니다. AI는 이 묶음 전체, 즉 직무를 대체하는 것이 아니라 그 안의 개별 업무를 대체합니다. 직무 단위로 통째로 넘기면 AI가 잘하는 업무와 못하는 업무가 뒤섞인 채 실행되고, 못하는 업무에서 생긴 오류가 잘하는 업무의 결과까지 오염시킵니다. 통째 위임의 실패는 도구의 한계 이전에 단위 설계의 실패입니다.
클로드 코드 잘 쓰는 법 1단계: 직무를 업무 목록으로 분해하기
내 일을 업무 단위로 적어 내려가는 것이 출발점입니다. 이번 주에 한 일을 돌아보며 반복 구현, 레거시 코드 파악, 테스트 작성, 설계 결정, 이해관계자 설득처럼 동사가 하나만 남는 수준까지 쪼개 보시기 바랍니다. 이 목록이 없으면 위임은 감으로 이뤄지고, 감으로 넘긴 일은 범위가 흐려져 다시 산으로 갑니다. 목록이 있어야 무엇을 넘기고 무엇을 남길지 판단할 기준이 생깁니다.
2단계: 위임할 업무를 고르는 세 가지 기준
첫째, 완료 조건을 문장으로 쓸 수 있는 업무입니다. 테스트가 통과하면 끝, 이 입력에 이 출력이 나오면 끝처럼 검증 가능한 업무는 클로드 코드가 안정적으로 처리합니다. 둘째, 실패해도 되돌리기 쉬운 업무입니다. 브랜치 하나 버리면 그만인 일부터 넘기고, 운영 데이터베이스를 건드리는 일은 남겨 두십시오. 셋째, 판단에 필요한 맥락이 코드 안에 있는 업무입니다. 근거가 회의록과 조직 사정에 흩어져 있는 일은 아직 사람 몫입니다. 세 기준을 통과한 업무만 넘기면 결과물을 검수하는 비용이 크게 줄어듭니다.
3단계: 비워진 자리에 새 업무를 채우기
위임의 목적은 일을 줄이는 데서 끝나지 않습니다. 반복 구현을 넘기고 확보한 시간에 설계 검토, 요구사항 정제, AI 결과물 검증 같은 업무를 더하면, 내 직무는 AI가 대체하지 못한 업무를 중심으로 확장됩니다. 형태만 바뀔 뿐 일은 계속됩니다. 코드를 치는 시간이 줄어든 자리에 무엇을 채우느냐가 같은 도구를 쓰는 사람들 사이의 격차를 만듭니다.
바로 적용하는 체크리스트
오늘 실행할 수 있는 순서로 정리하면 이렇습니다.
첫째, 이번 주 업무를 동사 하나 단위로 목록화합니다.
둘째, 완료 조건·되돌리기·맥락 세 기준으로 위임 가능한 업무에 표시합니다.
셋째, 그중 가장 작은 것 하나를 완료 조건과 함께 클로드 코드에 넘기고 결과를 직접 검증합니다.
넷째, 성공하면 다음 업무로 범위를 넓히고, 확보한 시간에 더할 새 업무를 정합니다. 이 사이클이 자리 잡으면 클로드 코드 잘 쓰는 법을 다시 검색할 일은 줄고, 무엇을 넘길지 판단하는 속도만 남습니다.
지금 내 앞에 있는 것은 통째로 넘길 직무가 아니라, 쪼개서 다시 설계할 업무 목록입니다.




