X를 보고 있으면, AI를 개발에 도입해야 할지, 인간의 코딩 능력이 떨어지는 것은 아닌지에 대한 논의가 자주 흘러나온다.

패러다임 시프트(Paradigm Shift)가 일어날 때마다 비슷한 이야기는 나온다. 계산기로 인해 암산 능력이 떨어지고, IDE로 인해 문법을 외우지 않게 되며, 검색으로 인해 기억력이 떨어지는 것——AI에 의한 개발 지원도 큰 틀에서는 같은 구도라고 생각한다.

다만, 이번에는 「편리한 도구가 하나 늘었다」 정도의 이야기가 아니다. 설계, 구현, 리뷰, 테스트 관점의 도출, 문서 정리, 조사까지 개발 공정의 상당히 넓은 범위에 들어올 수 있다.

따라서 논점은 「사용할 것인가 말 것인가」에서 벗어나고 있다. 실무에서 파악해야 할 것은 바로 이런 것이다.

AI를 포함한 개발 라인을 어떻게 설계하고, 어떻게 통제하며, 어떻게 품질을 보증할 것인가.

이 기사에서는 AI 시대에 현실적으로 요구되는 팀 구조와 인물상을 정리한다.

AI 도입이라고 하면 우선 다음과 같은 이야기로 흐르기 쉽다.

• Cursor나 Cline 등의 AI 개발 지원 도구를 사용한다
• ChatGPT나 Claude로 코드를 작성하게 한다
• PR(Pull Request) 리뷰에 AI를 사용한다
• 테스트 관점을 AI에게 도출하게 한다
• 문서를 AI에게 요약하게 한다

이것들 자체는 유효하다. 하지만 그것만으로는 팀으로서의 AI 활용이 되지 않는다. 개인의 기술로만 남게 되면 다음과 같은 문제가 발생한다.

• 사람에 따라 AI에 대한 지시 품질이 제각각이 된다
• 생성된 코드의 품질이 안정되지 않는다
• AI가 건드려도 되는 범위와 건드려서는 안 되는 범위가 모호해진다
• 리뷰 관점이 개인의 역량에 의존하게 된다(属人化)
• 편리함만이 앞서서 품질 보증 메커니즘이 따라가지 못한다
• 「동작은 하지만 위험한 코드」가 늘어난다
• AI가 만든 차이점(diff)을 인간이 설명할 수 없게 된다

문제는 「AI를 사용하는 것」보다 「팀 개발 안에 어떻게組み込む(組み込む, 포함시키다)가」 하는 쪽이다.

「인간 개발자 + AI」라는 덧셈만으로는 부족하다. 현실적으로는 대략 다음과 같은 역할 분담이 필요하게 된다.

AI를 「작업자」로서만 보지 않는 것, 개발 플로우(Flow) 전체 속에 포함시키는 것이 포인트다.

품질 관리는 AI와 상성이 좋다. 인간이 매번 확인하기에는 부하가 높은 확인 작업을 AI가 보조할 수 있다.

• PR 사전 리뷰
• 코딩 규약 위반 검출
• 사양과의 차이 확인
• 테스트 관점 도출
• 기존 구현과의 정합성 확인
• 예외 처리나 로그 출력 부족 체크
• 리스크가 높은 변경 부분 추출
• 문서와 구현의 불일치 확인

다만, 리뷰를 AI에게 통째로 맡겨서는 안 된다. AI는 체크는 해주지만, 「무엇을 좋은 코드로 볼 것인가」, 「무엇을 리스크로 볼 것인가」, 「어디까지를 합격선으로 할 것인가」는 팀 측에서 결정해야 한다.

품질 관리역이 해야 할 일은 AI에게 체크를 시키는 것이 아니라, 기준을 정의하는 것이다.

• 이 프로젝트에서 지켜야 할 설계 원칙은 무엇인가
• 변경 시 반드시 확인해야 할 관점은 무엇인가
• AI 리뷰에서 볼 관점과 인간 리뷰에서 볼 관점을 어떻게 나눌 것인가
• 테스트로 담보할 부분과 리뷰로 담보할 부분을 어떻게 나눌 것인가
• 사양, 설계, 구현, 테스트의 정합성을 어떻게 확인할 것인가

기준이 명문화되어 있을수록 AI는 효과적이다. 반대로 기준이 모호한 채로 AI에게 리뷰를 시키면, 그럴싸한 코멘트는 나오더라도 팀의 품질 보증으로 이어지지는 않는다.

AI 시대에 가치가 올라가는 것은 손을 움직이는 사람이라기보다, AI에게 안전하게 코드를 작성하게 하는 지휘를 할 수 있는 사람이다.

AI는 지시가 모호해도 그럴싸한 구현을 내놓는다. 그것이 편리한 반면 무섭기도 하다. 구현 속도는 올라가지만, 지시가 나쁘면 기술적 부채(Technical Debt)를 빠르게 쌓게 된다.

설계·구현 지휘에서는 대략 다음과 같은 것이 요구된다.

• 요구사항을 구현 가능한 단위로 분해한다
• 변경 범위를 명확히 한다
• 건드려도 되는 파일과 건드려서는 안 되는 파일을 지정한다
• 계층 구조나 책임 분담을 명시한다
• 명명 규칙, 예외 처리, 로그 방침을 지정한다
• 기존 코드와의 정합성을 확인한다
• AI에게 한 번에 맡기는 범위를 작게 한다
• 생성 결과를 차이점(diff) 단위로 확인한다
• 「동작하지만 위험한 구현」을 간파한다

특히 큰 작업을 한꺼번에 맡기지 말 것. AI는 큰 지시에도 「완료된 것처럼 보이게」 할 때가 있다. 실제로는 사양 누락, 기존 설계와의 불일치, 예외 시의 고려 부족, 테스트 부족 등이 섞이기 쉽다.

현실적인 진행 방식은 다음과 같다.

• 사양을 정리한다
• 변경 범위를 한정한다
• 구현 방침을 결정한다
• AI에게 작은 단위로 구현하게 한다
• 차이점(diff)을 확인한다
• 테스트를 추가한다
• 리뷰한다
• 필요하다면 규칙이나 체크리스트를 업데이트한다

이 흐름을 돌릴 수 있는 사람이 AI 시대의 구현 지휘자가 된다.

AI로 리뷰나 테스트 관점의 도출은 강화할 수 있다. 다만, 최종적인 보증을 모두 AI에게 맡길 수는 없다. 특히 다음은 인간이 확인해야 할 영역이다.

• 업무로서 올바른가
• 사용자에게 자연스러운가
• 현장 운용을 견딜 수 있는가
• 사양(Specification) 해석에 어긋남이 없는가
• 예외 상황 대응이 현실적인가
• 릴리스(Release)해도 문제가 없는가
• 장애 발생 시 설명 책임(Accountability)을 다할 수 있는가
• 고객이나 관계자가 납득할 수 있는 동작인가

코드 리뷰와는 별개다. 코드로써 올바른가가 아니라, 업무로서 올바른가를 본다.

AI는 사양서에 적힌 내용이나 코드상의 정합성을 보는 데는 능숙하다. 현장의 암묵지(Tacit knowledge), 업무상의 위화감, 사용자의 수용 방식, 운용상의 위험성까지는 아직 인간의 판단이 필요하다.

AI 시대에 인간이 담당해야 할 역할은 '스스로 전부 만드는 것'보다 '보증해야 할 곳을 보증하는 것'으로 시프트(Shift)되어 간다.

AI 개발 오케스트레이터(Orchestrator)적인 역할——개발 플로우와 규칙을 정의하고, 지속적으로 업데이트·공유하는 사람——이 AI 시대에는 특히 중요해진다.

• AI에게 맡겨도 좋은 작업 범위를 결정한다
• AI에게 맡겨서는 안 되는 작업 범위를 결정한다
• 인간이 반드시 확인하는 품질 게이트(Quality Gate)를 결정한다
• PR(Pull Request) 규칙을 정비한다
• ADR(Architecture Decision Record) 등으로 설계 판단을 기록한다
• AI용 프롬프트(Prompt), 규칙, 체크리스트를 정비한다
• 실패 사례를 재발 방지 규칙으로 변환한다
• Linter, 테스트, CI/CD, AI 리뷰를 조합한다
• 팀 멤버에게 운용 규칙을 공유한다
• 정기적으로 규칙을 재검토한다

이 역할이 없으면 AI 활용은 개인의 역량에 의존하는 속인화(Personalization) 현상이 발생한다. 잘 사용하는 사람과 그렇지 못한 사람, 품질 높은 생성 코드와 위험한 생성 코드, 출력을 의심할 수 있는 사람과 그대로 믿는 사람——재현성이 나오지 않는다.

조직의 힘으로 만들기 위해서는 개인의 스킬뿐만 아니라 플로우, 규칙, 체크리스트, 템플릿, 리뷰 관점으로 정비할 필요가 있다.

"AI로 코딩 능력이 떨어진다"는 우려는 절반은 맞다. AI에게 맡김으로써 직접 손으로 쓰는 양은 줄어든다. 정형적인 구현, 보일러플레이트(Boilerplate), 간단한 변환 처리, 테스트 초안 작성 등, 처음부터 직접 쓸 기회는 확실히 줄어든다. 예전 방식의 "아무것도 보지 않고 전부 쓸 수 있는 능력"은 떨어질지도 모른다.

다만, 그것만으로 개발자의 능력이 떨어졌다고 말하기는 어렵다. 변하는 것은 요구되는 능력의 비중이다.

떨어뜨려서는 안 되는 것은 오히려 이쪽이다.

• 사양을 읽는 능력
• 요구사항을 분해하는 능력
• 설계 의도를 이해하는 능력
• 코드의 위험한 징후(Code Smell)를 간파하는 능력
• AI의 출력을 의심하는 능력
• 차이점(Diff)을 평가하는 능력
• 테스트 관점을 생각하는 능력
• 사양, 설계, 구현, 테스트의 연결 고리를 보는 능력
• 팀의 개발 플로우에 녹여내는 능력
• 설명 책임을 다하는 능력

AI 시대에 정말 무서운 것은 코딩력의 저하가 아니라, 판단력·검품력·설계 독해력·품질 보증력의 저하다.

AI의 등장으로 개발자의 역할은 더욱 세밀하게 분해되어 간다. 기존에 한 명의 개발자가 통틀어 담당했던 작업——사양 이해, 설계, 구현, 테스트, 리뷰, 조사, 문서 작성, 릴리스 판단의 일부——중 일부는 고속화·자동화할 수 있다.

그 대신, 인간 측에는 상류(Upstream)·횡단(Cross-cutting)·보증 중심의 능력이 요구된다. AI 시대의 개발자는 "손을 움직이는 사람"에서 대략 다음과 같은 방향으로 확장되어 간다.

• AI에게 작업을 시키는 사람
• AI의 작업을 검사하는 사람
• AI에게 맡길 범위를 설계하는 사람
• AI가 내놓은 결과를 업무에 비추어 판단하는 사람
• AI를 포함한 개발 플로우를 개선하는 사람

여기서 차이가 나는 것은 "AI를 쓸 수 있는가"보다 "AI를 포함한 개발 프로세스를 설계할 수 있는가"이다.

AI를 개발에 도입할 경우, 공정마다 "AI가 보는 부분"과 "인간이 보는 부분"을 나눈다. 예를 들어 다음과 같은 플로우가 있다.

1. 요구사항 정리
- 인간이 업무 목적·제약·수락 조건(Acceptance Criteria)을 정리한다
- AI에게 논점 누락이나 확인 사항을 도출하게 한다
...

AI 도입으로 강해지는 팀과 약해지는 팀이 있다.

• 요구사항이나 설계를 명문화하고 있다

• 코딩 컨벤션(Coding Convention)이 있다

• 리뷰 관점이 정리되어 있다

• 테스트가 있다

• CI/CD가 정비되어 있다

• ADR 등으로 판단을 기록하고 있다

• AI에게 맡길 범위를 제어할 수 있다

• AI의 실패를 규칙에 반영할 수 있다

• 팀에서 사용법을 공유한다

• 사양이 모호하다

• 설계 판단이 남아 있지 않다

• 리뷰가 개인의 역량에 의존한다

• 테스트가 취약하다

• AI의 출력을 그대로 신용한다

• 큰 작업을 한꺼번에 AI에게 던진다

• 차이점(Diff)을 확인하지 않는다

• 실패 사례를 축적하지 않는다

• 사용법이 개인에게 맡겨져 있다

AI는 잘 정돈된 개발 프로세스를 더욱 강력하게 만든다. 반대로, 모호한 프로세스에 AI를 투입하면 모호함을 고속으로 증폭시킨다. 도입은 단순한 툴(Tool) 도입이 아니라, 개발 프로세스의 정비와 세트로 생각해야 한다.

"AI를 사용해야 하는가", "코딩 능력이 떨어지는 것이 아닌가" —— 이 두 가지만으로는 논의가 부족하다. 실무에서 효과를 발휘하는 것은 AI를 포함한 개발 라인의 설계다.

품질 관리자, 설계·구현 지휘자, 검수자, 플로우(Flow) 관리자 —— 이 4가지 역할에 가까운 구조로 AI의 위치 설정과 인간의 확인 포인트를 결정해 나간다.

인간의 일이 없어진다기보다, 보아야 할 곳이 바뀐다. 놓쳐서는 안 되는 것은 코드를 쓰는 능력뿐만 아니라, 사양(Specification)을 읽고, 설계를 분해하며, AI의 출력을 의심하고, 차분(Diff)을 평가하며, 팀의 품질 보증(QA) 플로우에 녹여내는 능력이다.

강한 것은 "AI를 사용하는 팀"이 아니라, "AI를 포함한 개발 프로세스를 설계하고, 통제하며, 개선할 수 있는 팀"이다.