우리 회사는 업무용 소프트웨어를 만들고 있는데, 솔직히 엔지니어 수가 전혀 부족한 상황입니다. 소규모 팀이 사내 도구부터 제품 코드까지 전부 보고 있다 보니, 잡무적인 태스크는 아무래도 뒤로 밀리기 일쑤였습니다.

그러던 차에 Claude Code가 화제가 되어, "그럼 시험 삼아 실무 태스크를 통째로 맡겨볼까"라고 생각한 것이 계기였습니다. 처음에는 단순히 코드를 쓰게 하는 정도라고 생각했는데, 상상 이상으로 다양한 작업을 맡길 수 있다는 것을 깨달았습니다.

솔직히, 처음에는 완전히 얕보고 있었습니다.

"AI니까 대충 부탁하면 알아서 잘 해주겠지"라고 생각하며, 이런 식으로 던졌었습니다.

이 기능의 테스트 데이터 만들어줘

이게 전부였습니다. 결과는 예상대로 미묘한 데이터가 돌아왔습니다. 경계값(Boundary value)도 제대로 고려되지 않았고, 파일 형식도 예상과 달랐으며, 결국 제가 전부 직접 수정해야 하는 상황이 되어 "AI에게 부탁한 의미가 있었나?" 싶은 결과가 되었습니다.

그리고 가장 해서는 안 될 실수는, 생성된 코드나 문서를 리뷰하지 않고 그대로 커밋(Commit)한 것이었습니다. 어느 날 사내용 스크립트를 통째로 맡겨서 나온 코드를 거의 체크 없이 머지(Merge)했더니, 며칠 뒤 다른 멤버로부터 "이 에러 핸들링(Error handling), 예상하는 케이스와 다르다"라는 지적을 받았습니다. 결국 제 이해 부족인 상태로 타인에게 넘겨버리게 되어, 은근히 신뢰를 잃게 되었습니다.

대충 던지는 지시 → 대충 나오는 결과 → 수정하느라 오히려 시간이 더 걸리는, 악순환에 빠져 있었습니다.

여기서부터 시행착오를 거치며 나름대로 터득한 요령을 정리합니다.

태스크를 전달할 때, 무엇을 판단해도 되는지와 무엇을 판단해서는 안 되는지를 처음에 전달하도록 했습니다.

이 테스트 데이터 생성에서는 정상계(Normal case) 패턴은 자유롭게 늘려도 OK.
단, 경계값·이상계(Abnormal case) 케이스는 반드시 목록화한 뒤에 구현에 착수할 것.
구현 후에는 생성한 데이터의 타당성을 스스로 검증한 뒤에 제출할 것.

이것만으로도 재작업(Rework)이 상당히 줄었습니다. AI에게 "어디까지 재량권이 있는지"를 전달하는 것은, 사람에게 일을 의뢰할 때와 완전히 똑같다는 것을 실감했습니다.

이것이 가장 효과가 있었던 포인트입니다. 통째로 맡긴다는 것이 검증하지 않는다는 의미는 절대 아닙니다.

# 생성된 코드에 대해 반드시 리뷰를 실행할 것
# 코드 리뷰 관점에서 불일치·버그·간략화 여지를 체크할 것

실제로 제 팀에서 운용하는 중에는, 코드 생성 후에 반드시 다른 관점에서의 리뷰를 1회 거치는 플로우(Flow)로 하고 있습니다. 인간의 리뷰와 마찬가지로, 생성시킨 본인(동일한 세션)에게만 판단하게 하지 않고, 한 번 거리를 두고 검증하게 함으로써 명백한 실수의 대부분은 사전에 없앨 수 있게 되었습니다.

이것도 쓴맛을 보고 배운 것입니다. 아무 말도 하지 않으면, 기존의 클래스나 데이터 구조를 무시하고 새로 코드를 쓰기 시작할 때가 있거든요. 사내의 기존 데이터 관리 클래스가 있는데도 그것을 쓰지 않고 새로운 로직을 처음부터 생성해서, 나중에 "이건 기존 클래스로 충분하잖아"라고 된 적이 몇 번 있었습니다.

그래서 지금은 처음에 한마디,

신규 구현 전에, 기존의 관련 클래스·데이터 구조를 확인하고,
유용할 수 있는 부분은 유용하는 방침으로 진행해줘

라고 전달하는 것을 철저히 하고 있습니다. 이 한 수 덕분에 무의미한 코드량이 상당히 줄었습니다.

처음부터 복잡한 사양서 작성이나 대규모 리팩터링(Refactoring)을 통째로 맡기는 것이 아니라,

• 우선은 작은 단발성 태스크 (테스트 데이터 생성, 간단한 스크립트)
• 다음은 리뷰·검증을 포함한 태스크
• 마지막으로 사양서 작성과 같이 구조화된 결과물을 요구하는 태스크

라는 순서로 맡기는 범위를 넓혀갔습니다. 인간 신입 멤버에게 일을 가르칠 때의 단계와 거의 비슷한 감각입니다. 갑자기 큰 재량을 주는 것이 아니라, 작은 성공 경험을 쌓게 한 뒤에 범위를 넓히는 것이 요령이었습니다.

결국, "통째로 맡긴다(丸投げ)"라는 말의 이미지와 실태는 상당히 달랐습니다. 던져놓고 방치하는 것이 아니라, 지시 방식·검증 프로세스·기존 자산의 취급 방법을 제대로 설계하지 않으면 오히려 불필요한 수고가 들 수도 있는 것이었습니다.

한편으로, 경계를 명시하고 리뷰를 거치는 운용으로 전환한 이후에는, 사소한 잡무계 태스크(테스트 데이터 작성, 간단한 문서 정비, 코드 리뷰의 1차 체크)를 상당히 가져올 수 있게 되어, 팀의 실동 시간이 확실히 확보되고 있습니다. 5명뿐인 팀에게 이 차이는 꽤 큽니다.

통째로 맡기는 것은 만능 마법이 아니라, "전달 방식"을 궁리함으로써 비로소 힘을 발휘하는 도구라는 것이 이번에 얻은 가장 큰 배움이었습니다.