AI 시대, 개발팀은 어떻게 일해야 할까? 사람과 AI의 역할 재정립

AI가 개발 프로세스에 깊숙이 들어오면서 개발팀의 풍경이 바뀌고 있다. 코딩 속도는 빨라졌지만, PR(Pull Request)이 늘고, AI가 만든 코드를 사람이 다시 리뷰하는 시간도 만만치 않다. 과연 AI 시대의 개발팀은 어떻게 일해야 할까? 여러 커뮤니티와 기업 블로그에서 이 질문에 대한 고민과 해법을 엿볼 수 있다.

AI, 마법 지팡이인가 길들여야 할 야수인가

요즘IT의 글에서 한 주니어 개발자는 AI를 ‘어떤 마법이 나올지 모르는 지팡이’에 비유한다. 같은 요청에도 매번 다른 결과를 내놓는 비결정론적인 도구 앞에서 개발자들은 혼란을 겪는다는 것이다. “깊은 지식이 있어야 AI를 제대로 쓴다”거나 “사람이 만들었기 때문에 더 낫다”는 말도 더 이상 충분한 방어선이 되지 못한다.

실제로 네이버 D2의 AI 해커톤 후기를 보면, AI가 무엇을 해줄 수 있을까’에서 ‘AI에게 맡기지 않을 것은 무엇인가’로 질문이 바뀌었다고 한다. AI는 계획(planning)에는 강했지만, 전체적인 방향과 핵심을 잡는 전략(strategy)은 여전히 사람의 몫이었다는 것이다. Reddit r/webdev에서도 Claude Code가 Django 기능을 거의 완벽하게 구현했지만, 결국 개발자의 판단과 검토가 중요했다는 경험담이 공유된다.

AI를 길들이는 ‘하네스 엔지니어링’

그렇다면 AI를 어떻게 활용해야 할까? 요즘IT의 다른 글에서는 ‘팀 하네스 엔지니어링’이라는 개념을 제시한다. 8개월 만에 170만 줄의 코드를 쌓은 스타트업 바이버스 AI의 사례인데, Claude Code의 플랜 모드에만 의존하자 엉뚱한 작업이 늘고 출시 속도가 느려지는 문제를 겪었다고 한다. 여기서 찾은 해법은 다음과 같다.

• AI의 결정 금지 원칙: 스펙 하나라도 AI가 결정하면 결국 기술 부채로 돌아온다.
• 시니어의 암묵지 형식지화: 시니어 개발자의 경험과 노하우를 ‘스킬’ 형태로 만들어 AI가 활용하도록 한다.
• 메인 에이전트는 오케스트레이터: AI를 모든 것을 결정하는 주체가 아닌, 정해진 스킬과 계획에 따라 작업을 조율하는 오케스트레이터로 둔다.
• 4단계 워크플로우: 플랜-구현-E2E 테스트-PR의 명확한 단계를 통해 AI 작업을 관리한다.

이런 접근 방식은 AI가 빠르게 코드를 생성하더라도, 최종 결과물의 품질과 일관성은 사람이 책임지고 제어해야 한다는 점을 강조한다. 비개발자가 400페이지 서명 검사를 AI로 자동화하려다 겪은 시행착오도 같은 맥락이다. AI가 모든 것을 해결해 줄 것이라는 환상에서 벗어나, ‘어디까지 도구에 맡기고 어디부터 사람이 봐야 하는가’를 명확히 하는 것이 중요하다.