Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Claude Code를 실무에 도입하며 겪은 시행착오와 효율적인 활용 노하우를 공유합니다. 단순 지시의 한계를 극복하기 위해 AI의 재량권을 설정하고, 반드시 검증 과정을 거치며, 기존 코드 구조를 존중하도록 지시하는 구체적인 방법론을 제시합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기우리 회사는 업무용 소프트웨어를 만들고 있는데, 솔직히 엔지니어 수가 전혀 부족한 상황입니다. 소규모 팀이 사내 도구부터 제품 코드까지 전부 보고 있다 보니, 잡무적인 태스크는 아무래도 뒤로 밀리기 일쑤였습니다.
그러던 차에 Claude Code가 화제가 되어, "그럼 시험 삼아 실무 태스크를 통째로 맡겨볼까"라고 생각한 것이 계기였습니다. 처음에는 단순히 코드를 쓰게 하는 정도라고 생각했는데, 상상 이상으로 다양한 작업을 맡길 수 있다는 것을 깨달았습니다.
솔직히, 처음에는 완전히 얕보고 있었습니다.
"AI니까 대충 부탁하면 알아서 잘 해주겠지"라고 생각하며, 이런 식으로 던졌었습니다.
이 기능의 테스트 데이터 만들어줘
이게 전부였습니다. 결과는 예상대로 미묘한 데이터가 돌아왔습니다. 경계값(Boundary value)도 제대로 고려되지 않았고, 파일 형식도 예상과 달랐으며, 결국 제가 전부 직접 수정해야 하는 상황이 되어 "AI에게 부탁한 의미가 있었나?" 싶은 결과가 되었습니다.
그리고 가장 해서는 안 될 실수는, 생성된 코드나 문서를 리뷰하지 않고 그대로 커밋(Commit)한 것이었습니다. 어느 날 사내용 스크립트를 통째로 맡겨서 나온 코드를 거의 체크 없이 머지(Merge)했더니, 며칠 뒤 다른 멤버로부터 "이 에러 핸들링(Error handling), 예상하는 케이스와 다르다"라는 지적을 받았습니다. 결국 제 이해 부족인 상태로 타인에게 넘겨버리게 되어, 은근히 신뢰를 잃게 되었습니다.
대충 던지는 지시 → 대충 나오는 결과 → 수정하느라 오히려 시간이 더 걸리는, 악순환에 빠져 있었습니다.
여기서부터 시행착오를 거치며 나름대로 터득한 요령을 정리합니다.
태스크를 전달할 때, 무엇을 판단해도 되는지와 무엇을 판단해서는 안 되는지를 처음에 전달하도록 했습니다.
이 테스트 데이터 생성에서는 정상계(Normal case) 패턴은 자유롭게 늘려도 OK.
단, 경계값·이상계(Abnormal case) 케이스는 반드시 목록화한 뒤에 구현에 착수할 것.
구현 후에는 생성한 데이터의 타당성을 스스로 검증한 뒤에 제출할 것.
이것만으로도 재작업(Rework)이 상당히 줄었습니다. AI에게 "어디까지 재량권이 있는지"를 전달하는 것은, 사람에게 일을 의뢰할 때와 완전히 똑같다는 것을 실감했습니다.
이것이 가장 효과가 있었던 포인트입니다. 통째로 맡긴다는 것이 검증하지 않는다는 의미는 절대 아닙니다.
# 생성된 코드에 대해 반드시 리뷰를 실행할 것
# 코드 리뷰 관점에서 불일치·버그·간략화 여지를 체크할 것
실제로 제 팀에서 운용하는 중에는, 코드 생성 후에 반드시 다른 관점에서의 리뷰를 1회 거치는 플로우(Flow)로 하고 있습니다. 인간의 리뷰와 마찬가지로, 생성시킨 본인(동일한 세션)에게만 판단하게 하지 않고, 한 번 거리를 두고 검증하게 함으로써 명백한 실수의 대부분은 사전에 없앨 수 있게 되었습니다.
이것도 쓴맛을 보고 배운 것입니다. 아무 말도 하지 않으면, 기존의 클래스나 데이터 구조를 무시하고 새로 코드를 쓰기 시작할 때가 있거든요. 사내의 기존 데이터 관리 클래스가 있는데도 그것을 쓰지 않고 새로운 로직을 처음부터 생성해서, 나중에 "이건 기존 클래스로 충분하잖아"라고 된 적이 몇 번 있었습니다.
그래서 지금은 처음에 한마디,
신규 구현 전에, 기존의 관련 클래스·데이터 구조를 확인하고,
유용할 수 있는 부분은 유용하는 방침으로 진행해줘
라고 전달하는 것을 철저히 하고 있습니다. 이 한 수 덕분에 무의미한 코드량이 상당히 줄었습니다.
처음부터 복잡한 사양서 작성이나 대규모 리팩터링(Refactoring)을 통째로 맡기는 것이 아니라,
라는 순서로 맡기는 범위를 넓혀갔습니다. 인간 신입 멤버에게 일을 가르칠 때의 단계와 거의 비슷한 감각입니다. 갑자기 큰 재량을 주는 것이 아니라, 작은 성공 경험을 쌓게 한 뒤에 범위를 넓히는 것이 요령이었습니다.
결국, "통째로 맡긴다(丸投げ)"라는 말의 이미지와 실태는 상당히 달랐습니다. 던져놓고 방치하는 것이 아니라, 지시 방식·검증 프로세스·기존 자산의 취급 방법을 제대로 설계하지 않으면 오히려 불필요한 수고가 들 수도 있는 것이었습니다.
한편으로, 경계를 명시하고 리뷰를 거치는 운용으로 전환한 이후에는, 사소한 잡무계 태스크(테스트 데이터 작성, 간단한 문서 정비, 코드 리뷰의 1차 체크)를 상당히 가져올 수 있게 되어, 팀의 실동 시간이 확실히 확보되고 있습니다. 5명뿐인 팀에게 이 차이는 꽤 큽니다.
통째로 맡기는 것은 만능 마법이 아니라, "전달 방식"을 궁리함으로써 비로소 힘을 발휘하는 도구라는 것이 이번에 얻은 가장 큰 배움이었습니다.