제1장: AI 시대의 시스템 개발과 품질 관리: 왜 AI 코드는 3인 체제의 리뷰 없이는 붕괴하는가

이번부터 6회에 걸쳐 AI 주도 개발(AI-driven development)의 실태에 대해, 그 문제점과 해결책을 포함하여 해설해 나가고자 한다.

제1장: AI 시대의 시스템 개발과 품질 관리: 왜 AI 코드는 3인 체제의 리뷰 없이는 붕괴하는가 ← 현재 여기

제2장: AI 주도 개발의 불편한 진실: 생성된 코드의 질이 「인간 뇌의 스펙」을 넘을 수 없는 이유

제3장: AI 개발의 추론 교착과 할루시네이션(Hallucination) 연쇄: LLM이 막다른 길에 다다르는 구조적 한계의 메커니즘

제4장: 최신 추론형 AI의 진화와 변하지 않는 현실: Reasoning 모델의 뇌내 리뷰와 구조적 한계

제5장: AI 주도 개발에서의 자동화의 기만: LangChain이나 API 에이전트가 할루시네이션 루프(Hallucination loop)로 파탄 나는 이유

제6장: AI 주도 개발의 최종 대책안 | YAML을 통한 세계 모델(World Model)의 통치와 물리적 리셋을 통한 오염 퍼지(Purge) 수법

기존의 시스템 개발, 즉 AI를 활용하지 않고 개발을 진행할 때에는 '리뷰'라는 작업이 있는데, 그 작업은 「3인 체제의 로직 평가(리뷰)」이다. 이것이야말로 과거 일본의 고품질 시스템 개발을 지탱하고 유지해 온 최고봉의 방어선(질서)이라고 생각한다.

프로그램이 작성한 코드를 단순히 훑어보는 것이 아니라, 서로 다른 역할을 가진 3명의 역할로 모든 각도에서 로직을 검증하고 버그를 찾아낸다. 이 프로세스를 거치고 있었기에 「운영 환경에서의 결함」 같은 것은 나올 수가 없었던 것이다.

이 3인 체제는 대부분의 경우 역할이 다음과 같이 구성된다.

1: 본인 (구현 의도와 상세 내용을 설명한다)

2: 상급 프로그래머 (OS, 메모리, 데이터 구조 레이어에서 로직의 효율성이나 예외, 리소스 해제 누락 여부를 냉철하게 꿰뚫어 본다)

3: 프로그램을 짤 수 있는 SE (업무 사양이나 데이터의 흐름, 시스템 전체의 아키텍처 관점에서 값의 체크 위치나 에러 핸들링(Error handling), 로그 출력 방식이 적절한지를 조망한다)

사양과 프로그램 양쪽을 모두 아는 SE와 저수준(Low-level)까지 내다볼 수 있는 상급 프로그래머가 본인(프로그래머)의 코드를 사이에 두고 「로그 타이밍」, 「값의 유효성 검사(Validation) 위치」, 「예외 처리의 망라성」을 모두 리뷰한다. 이 정도로 철저하게 로직을 평가하고 있다면, 릴리스 시점에 누락이나 빠진 부분이 「거의 없는」 상태가 되는 것은 필연이다.

• 「미래를 위해 여기는 인터페이스(Interface)를 사이에 두고 추상화해 두자」라며 과도하게 고려하다가 코드가 복잡 기괴해져 자멸한다.
• 반대로 「지금은 이걸로 충분해」라며 너무 딱딱하게 만들어 버려서, 3년 후에 사양이 바뀌었을 때 복사 붙여넣기(Copy-paste) 투성이인 스파게티 코드(Spaghetti code)를 강제로 덧붙일 수밖에 없게 되어 결함이 발생한다.

이 「미래의 예측과 허용의 밸런스」를 어디서 담보할 것인가는 기업의 기술력이나 사상에 따라 완전히 갈리며, 이 부분이 흔들리는 순간 아무리 견고했던 시스템도 서서히 부패하여 붕괴를 향해 나아간다.

「나, 도대체 언제쯤 단체 시험(Unit test)을 할 수 있는 거야!」라며 책상을 치고 싶을 정도의 그 엄청난 리뷰 횟수. 그렇게까지 철저하게 로직을 검증하고 있기 때문에, 그 이후의 공정이 「완전한 단순 작업」과 다를 바 없게 되는 것이다.

현대의 복사 붙여넣기 세대나 1분짜리 PM, 코드를 쓰지 못하고 아키텍처도 모르는 PM은 단체 시험(테스트)이라는 것을 「프로그램이 다 작성된 후에 화면을 클릭하며 버그가 나오지 않는지 확인하는 작업」이라고 오해하고 있다.

하지만 진짜 개발 프로세스는 전혀 다르다.

제조 리뷰에서 「로직, 에러 핸들링, 예외, 값의 체크 위치」를 상급 프로그래머와 SE 3명이 밀리미터 단위로 검증하고 있는 그 시점에, 「뇌내에서의 단체 시험」은 이미 끝나 있는 것이다.

• 리뷰 현장에서 「이 값이 NULL이라면?」, 「경계값인 -1이라면 어떻게 동작할까?」라며 논쟁한다.
• 그 자리에서 통과해야 할 경로(시험 항목)가 모두 도출된다.
• 필연적으로 그것을 증명하기 위한 「테스트 방법」과 「테스트 데이터」까지도 로직의 확정과 세트로 그 자리에서 100% 만들어진다.

이 정도로 전 단계에서 리뷰 관점이 만들어져 있다면, 막상 「단체 시험 페이즈」에 들어갔을 때는 이미 합격할 것이 약속된 테스트 데이터를 담담하게 흘려보내고 결과를 기록하는 작업이 된다. 말 그대로 「단순 작업」이며, 그곳에 미지의 버그가 끼어들 여지 따위는 없다.

리뷰 작업은 2회, 3회 리뷰를 거듭하며 「언제쯤 시험을 할 수 있냐」고 현장이 한계를 느낄 정도로 전 공정에서 대응한다. 이 투박하면서도 압도적으로 강직한 프로세스야말로 재작업(Rework)이 가장 적고, 결과적으로 스케줄이 가장 짧으며, 그리고 「절대로 아무도 병들지 않고, 망가지지 않는」 최강의 시스템을 만드는 유일한 정답이다.

인풋 (Input)과 아웃풋 (Output)의 표면만 보고, 중간의 프로세스 (뇌내 OS)를 스킵하고 있는 현대의 「겉핥기식 개발」의 현상.

AI가 코드를 생성할 때, AI는 「왜 그 코드가 필요한가」를 엔지니어링으로서 이해하고 쓰는 것이 아닙니다. 인터넷의 바다에 있는 방대한 코드를 확률론적으로 출력하고 있을 뿐입니다.

그렇기 때문에, 생성된 코드에는,

• 한 번만 호출하면 될 시스템 콜 (System Call)을 루프를 돌 때마다 무의미하게 발행하거나
• 가상 메모리 (Virtual Memory)를 낭비하며 커밋 (Commit)하고 해제를 잊어버리거나
• 이미 언어의 내부에서 동기화되고 있음에도, 추가로 이중의 무거운 뮤텍스 (Mutex)를 걸고 있는

이와 같이, 저수준 (Low-level)을 아는 사람이 보면 「이게 뭐야!?」라고 할 만한 「수수께끼의 낭비되는 코드」가 산더미처럼 섞여 들어갑니다.

하지만, 인풋과 아웃풋의 화면 클릭만 하는 「겉핥기 세대」에게는 그 낭비가 보이지 않습니다. 「에러가 나지 않고, 일단 기대한 대로의 값 (Output)이 돌아왔으니까 OK!」라며 그대로 통과시켜 운영 환경에 던져 넣습니다.

그 아름답고도 엄격했던 3인 체제의 리뷰 체제.

• 본인 (프로그래머)
• 상급 프로그래머
• 프로그램을 짤 수 있는 SE (System Engineer)

이 세 사람이 모여 로직 (Logic), 에러 핸들링 (Error Handling), 로그 (Log), 예외 (Exception), 값의 체크 위치를 「시점을 바꾸어 평가」했기에, 빈틈없고 완벽한 시스템을 만들 수 있었습니다.

하지만 AI가 생성한 코드, 즉 「수수께끼의 낭비되는 코드가 포함된 상태」를 마주했을 때, 지금의 현장에는 그것을 평가할 수 있는 「상급 프로그래머」도 「프로그램을 짤 수 있는 SE」도 없습니다. 3명의 시점은커녕, **「AI가 만든 블랙박스를 아무도 제대로 읽지 못한 채, 아무도 책임을 지지 않는 시점 제로의 무법지대」**가 만들어지고 있는 것입니다.

평가를 할 수 없습니다. 그렇기에 향후의 사양 변경을 어디까지 허용·고려할 것인가 하는, 시스템 개편을 위한 설계 판단 (Architecture) 따위는 고려될 리가 없습니다. 사양이 바뀌는 순간, 그 AI제 왜곡된 모래성 위의 성은 순식간에 붕괴합니다.

기존의 개발 작업이나 리뷰 작업은 이러한 「완벽한 흐름 작업」이었으며, 지금의 IT 업계 현장이 얼마나 파탄 나 있는지가 더욱 선명하게 드러나고 있다고 생각합니다. 무지의 연쇄가 기업의 업무 시스템을, IT 전략을 좀먹고 있는 것입니다.

당신이 해온 흐름 작업:

3명에 의한 리뷰로 로직, 항목, 데이터까지 「완벽하게 확정한 후」였기에, 뒷공정이 자동으로 흘러갔다. -
현대의 복사·붙여넣기·AI 개발의 흐름 작업:

리뷰를 한 번도 하지 않고, 로직의 평가도 제로, 예외도 로그도 체크 위치도 엉망인 채로, AI가 뱉어낸 코드를 「일단 돌아가니까」라며 단체 시험 담당자 (혹은 하청)에게 통째로 떠넘기는 작업.

당연히 시험 항목도 테스트 데이터도 엉망진창이기에, 단체, 결합, 종합 시험을 시작하는 순간 버그가 대폭발합니다. 게다가 내부 구조 (OS나 메모리, 아키텍처)를 아무도 리뷰하지 않았기 때문에, 왜 그 버그가 발생하는지를 추적 (Trace)할 수 있는 인간조차 아무도 없는 상태인 것입니다.

결과적으로 결합 시험이나 운영 환경에까지 그 시한폭탄이 그대로 흘러 들어가, 대형 SIer의 PM이 얼어붙고, 현장이 말 그대로 「불타는 프로젝트 (炎上案件)」로 변해가는 것입니다.