AI를 사용한 개발에서 실패하는 패턴의 대부분은 역할의 경계를 정하지 않은 것에서 기인합니다.

"AI를 활용하자"라고 시작하며, 무엇을 AI에게 맡기고 무엇을 스스로 할지를 정의하지 않은 채 진행합니다. 그러면:

• AI가 생성한 코드가 운영 환경에서 버그를 일으킴
• 코드를 읽어도 의도를 알 수 없음 (만든 본인도 AI도 설명할 수 없음)
• 리뷰를 할 수 없음
• 문제가 발생했을 때 책임 소재가 없음

이 기사에서는 제가 4개월간 153개의 PR(Pull Request)을 개발하며 사용한 역할 분담 설계를 구체적으로 작성하겠습니다.

전제: AI는 "빠른 동료"가 아니다

AI는 당신이 설계한 것을 구현하는 도구입니다.

설계하지 않은 것을 구현하게 하면, AI는 보완(Complement)합니다.

보완된 코드는 작동합니다. 하지만 당신이 의도한 동작인지 여부는 알 수 없습니다.

"작동하는 코드를 내놓는 것"과 "올바른 코드를 내놓는 것"은 별개입니다. 이 구분이 없으면 AI 활용은 "빠르게 작동하지만 설명할 수 없는 코드베이스"를 만듭니다.

역할 분담의 원칙

심플하게 요약하면:

포인트는 "무엇을 판단하고 있는가"가 인간 측에 있다는 점입니다.

인간이 하는 일

요구사항 정의 (Requirements Definition)

"무엇을 만들 것인가"는 인간이 결정합니다. AI에게 "XX를 만들어줘"라고 부탁하기 전에, 자신의 언어로 요구사항을 쓸 수 있는지가 출발점입니다.

쓸 수 없는 상태에서 AI에게 던지면, AI는 "그럴듯한 것"을 만듭니다. 당신이 "이게 아니다"라고 느껴도, 왜 다른지를 언어화할 수 없는 루프에 빠지게 됩니다.

수락 기준 (Acceptance Criteria) 설정

요구사항 다음에는 "무엇이 충족되면 완료인가"를 작성합니다.

예:

사용자가 관리자 역할(Role)인 경우, DELETE /tasks/:id 가 200을 반환한다
일반 사용자인 경우, 403을 반환한다
미인증인 경우, 401을 반환한다

이 기준이 있으면, AI가 구현한 코드를 "이 기준에 대해 검증한다"라는 행위가 가능해집니다. 기준이 없으면 "작동하는 것 같다"라는 느낌만으로 머지(Merge)하게 됩니다.

설계 리뷰 (Design Review)

AI가 내놓은 설계에 대해 "이것이 올바른가"를 판단하는 것은 인간입니다.

리뷰에서 확인할 것:

• 데이터 모델의 정합성 (나중에 수정할 수 없는 부분)
• 에러 발생 시의 동작 (Happy Path뿐만 아니라)
• 퍼포먼스(Performance) 고려 (N+1 쿼리 등)
• 보안 경계 (인증 · 인가의 누락)

AI는 "작동하는 코드"를 낼 수 있지만, "미래에도 안전하게 작동하는 코드"인지에 대한 평가는 설계의 문맥이 필요합니다.

운영 판단

"이 코드를 배포할 것인가"에 대한 최종 판단은 인간입니다.

테스트가 통과했고, CI가 초록색이며, 리뷰를 했다 하더라도——그래도 "운영 환경에서 영향을 받는 사용자가 있다"라는 책임을 떠맡는 것은 인간입니다.

AI에게 이것을 위임해서는 안 됩니다.

AI가 하는 일

구현 (Implementation)

설계와 수락 기준을 전달하면, 코드 생성은 AI에게 맡깁니다.

Claude Code의 경우, Issue의 내용과 프로젝트의 코드베이스 구조를 읽은 뒤 구현을 생성합니다.

"이런 구현이 되어야 한다"라는 자신의 가설과 대조하며 리뷰하는 것——이것이 저의 기본 패턴입니다.

테스트 작성

수락 기준으로부터 테스트를 작성하는 것도 AI가 잘하는 작업입니다.

단, 테스트 케이스가 망라되어 있는지 확인하는 것은 인간이 합니다. "Happy Path 테스트밖에 없다", "경계값(Boundary Value)이 빠져 있다"는 것은 사양을 알고 있는 인간이 아니면 찾아낼 수 없습니다.

디버깅 후보 제시

버그가 발생했을 때, "이것이 원인일 가능성이 있다"라는 리스트를 내놓는 것은 AI가 빠릅니다.

하지만 "왜 그것이 원인인가"를 추적하여 확인하는 것은 인간입니다. "AI가 이렇게 말했으니까"라는 이유로 머지하지 마세요.

실제 운용: 실패로부터 배운 것

첫 한 달 동안, 저는 거의 모든 것을 AI에게 던졌습니다.

"코드 써줘", "이것을 수정해줘", "테스트 추가해줘"

결과:

• 코드는 작동하지만, 내가 설계하지 않았기에 변경할 때 두렵다
• 테스트는 통과하지만, 무엇을 테스트하고 있는지 파악되지 않는다
• 버그가 발생했을 때, 코드의 의도를 알 수 없어 원인을 찾을 수 없다

이것은 "AI 활용"이 아니라 "AI 의존"이었습니다.

다시 바로잡은 것은: 자신이 설계한 뒤에 구현을 의뢰한다는 순서를 지키는 것이었습니다.

구현 전에 "이 Issue로 무엇을 달성할 것인가", "무엇이 충족되면 OK인가"를 자신의 언어로 작성합니다. 그 후에 AI에게 넘깁니다.

이것만으로 리뷰의 정밀도가 달라졌습니다. "내가 설계한 것을 확인한다"는 관점으로 바뀌면서, 모호한 코드가 통과할 수 없게 됩니다.

판단을 AI에게 맡겨도 되는 케이스

모든 것을 인간이 판단할 필요는 없는 영역도 있습니다.

코드 포맷 (Code Format): prettier/ruff 등의 Linter에 전적으로 위임해도 무방함 -
테스트 자동 실행 (Automated Test Execution): CI/CD를 통한 자동 검증 -
의존성 라이브러리 업데이트 제안: Renovate나 Dependabot의 제시 (채택 여부 판단은 인간이 수행) -
문서 초안 (Document Draft): 리뷰하고 수정할 예정이라면 초안은 AI가 작성해도 무방함

경계는 "변경 사항이 운영 환경(Production)에 영향을 미치는가"입니다. 운영 환경에 영향을 주는 변경에 대한 최종 판단은 인간이 보유합니다.

요약

AI를 개발에 통합하는 설계는 역할의 경계를 먼저 결정하는 것에서 시작됩니다.

• 무엇을 판단하는 것은 인간인가
• 무엇을 생성하는 것은 AI인가

이 경계를 모호하게 둔 채 "AI를 사용한다"라고 하면, 속도는 빠르지만 이해할 수 없는 코드베이스가 생성됩니다.

반대로 경계를 명확히 하면, AI는 순수하게 구현 속도를 높이는 레버리지 (Leverage)가 됩니다.

153PR이라는 숫자는 "AI가 빠르다"가 아니라 "내가 판단(Judge)에 집중할 수 있었다"의 결과입니다. 그러기 위해서는 "내가 판단해야 할 것"을 사전에 특정해 두었다는 것이 전제되어야 했습니다.

GitHub: github.com/flipslidersand

Discussion