발표에서 확인된 핵심 사실

AI 에이전트가 코드 전체를 자동으로 짜준다는 유튜브 영상이나 마케팅 문구를 보면 누구나 개발의 완전 자동화를 꿈꾼다. 하지만 실제 현장에서는 AI에게 모든 권한을 넘기기보다 인간이 촘촘하게 감시하는 방식이 더 효과적이다. okTurtles는 보안이 매우 중요한 시스템에서 고품질 소프트웨어를 만들기 위해 AI를 짧은 목줄로 묶어 관리하는 숏리쉬(short leash method, AI의 작업 범위를 좁게 제한하고 인간이 즉시 검토하는 방식) 기법을 적용한다. 이들은 단순히 도구를 쓰는 수준을 넘어 조직 차원에서 공식적인 AI 사용 정책을 세워 운영하며 개발 공정을 통제한다.

오케스트레이터(전체 작업을 지휘하고 분배하는 관리 도구)가 여러 개의 AI 에이전트를 병렬로 돌리는 바이브(Vibe) 방식은 겉보기에 매우 빠르고 효율적으로 보인다. 하지만 이 방식은 개발자가 코드베이스(전체 소스 코드의 집합)를 스스로 이해하고 파악하는 과정을 방해한다. AI가 작업 도중 궤도를 벗어나 엉뚱한 코드를 작성하더라도, 개발자는 이를 즉시 알지 못하고 나중에 소프트웨어를 실제로 실행해 본 뒤에야 오류를 발견하게 된다. 품질을 최우선으로 생각하는 고신뢰 시스템에서는 이러한 지연된 발견이 치명적인 결함으로 이어질 수 있어 적절하지 않은 접근법이다.

AI 도입의 성패는 자동화율을 얼마나 높이느냐가 아니라 인간의 검토 깊이를 어떻게 설계하느냐에 달려 있다. okTurtles가 숏리쉬 방식을 채택한 것은 AI의 생성 능력보다 인간의 검증 능력을 시스템의 중심에 두기 위해서다. AI를 단순한 보조 도구로 활용하며 인간이 모든 라인을 통제하는 프로세스를 구축해야 보안과 품질을 동시에 확보할 수 있다.

AI 코딩 에이전트를 활용하는 'short leash'

최신 유료 모델을 쓰지 않고도 수준 높은 결과물을 뽑아내는 개발자들이 있다. 전문 소프트웨어 개발자만 구사할 수 있는 숏리쉬(Short Leash, AI의 권한을 제한해 짧은 목줄을 쥐듯 관리하는 방식) 기법이 그 핵심이다. 이 방식은 프론티어 모델(가장 앞선 성능을 가진 거대 AI 모델)을 사용하지 않아도 Fable(AI 코딩 도구)보다 뛰어난 성과를 낸다. AI에게 모든 것을 맡기지 않고 인간과 AI가 함께 리뷰에 참여하는 구조를 지향함으로써 결과물의 완성도를 높인다.

AI의 도움을 받아 PR(Pull Request, 작성한 코드를 메인 저장소에 반영해달라고 요청하는 절차)을 올리는 개발자는 AI가 짠 코드를 한 줄씩 직접 읽고 분석해야 한다. 제출자는 자신의 PR을 마치 타인이 작성한 코드를 검토하는 리뷰어의 관점에서 다루어야 한다. AI가 작성한 내용을 그대로 복사해 붙이는 것이 아니라, 모든 라인을 직접 검토하며 완전히 이해하는 과정이 필수다. AI가 짠 코드의 논리적 허점을 찾아내고 수정하는 과정이 이 방법의 핵심이다.

이런 엄격한 검토 과정은 개발자가 전체 코드베이스(프로젝트를 구성하는 모든 소스 코드의 집합)에 대한 이해도를 구축하는 실질적인 수단이 된다. 한 줄씩 뜯어보는 행위를 통해 AI가 제안한 논리가 프로젝트 전체 맥락과 맞는지 확인하고 이를 스스로 증명한다. AI가 생성한 코드를 완전히 내 것으로 만드는 과정을 통해 소프트웨어의 안정성을 확보한다. AI를 도구로 쓰면서도 코드의 주도권은 인간이 쥐는 방식으로 고품질 소프트웨어를 완성한다.

확인해야 할 핵심 지점

리뷰어 한 명이 놓친 사소한 오타 하나가 서비스 전체를 멈추게 하고 개발자의 주말을 앗아간다. 코드 변경 사항을 반영해달라고 요청하는 PR(Pull Request)을 인간과 AI가 함께 검토하면, 어느 한쪽만 확인했을 때보다 실수가 눈에 띄게 줄어든다. AI는 문법 오류나 스타일 위반을 자동으로 잡아내는 린터(linter) 역할을 수행하며 단순 반복 실수를 빠르게 걸러낸다. AI가 1차적으로 잡음 제거를 마치면 인간은 더 복잡한 설계 결함을 찾는 데 시간을 쓸 수 있다. 인간은 AI가 훑고 지나간 자리에서 전체적인 방향성이나 상위 수준의 논리적 문제를 포착하는 데 집중한다. 서로 다른 층위의 오류를 교차 검증할 때 비로소 결함 없는 코드가 완성된다.

Fable 5 같은 고성능 모델이 작성하거나 검토한 코드라도 효율성이 떨어지거나 구조가 엉망인 경우가 발생한다. 특히 학습 데이터가 부족한 니치(niche) 영역, 즉 소수의 전문가만 다루는 특수 분야에서 이런 현상이 자주 나타난다. AI는 자신이 배운 데이터의 범위를 넘어서 스스로 생각하거나 추론할 수 없다는 한계가 명확하다. 코드는 일단 돌아가지만 내부적으로는 끔찍하게 비효율적이고 추한 상태가 될 가능성이 높다. 고품질 소프트웨어를 만들려면 AI의 자동화율을 높이는 것보다 인간이 얼마나 깊게 검토하느냐를 기준으로 품질 관리 프로세스를 설계해야 한다.

유튜브 영상 속 AI 에이전트가 모든 코드를 짜주는 마법 같은 모습은 현실과 거리가 있다. 학습 데이터가 부족한 틈새 영역에서 AI는 여전히 비효율적이고 투박한 결과물을 내놓기 때문이다.

이제는 AI가 얼마나 많은 코드를 생성했는지가 아니라, 인간이 그 코드를 얼마나 깊게 파고들었는지가 실력을 가르는 기준이 된다. 도구의 자동화율이 아닌 검토의 밀도가 소프트웨어의 생존을 결정한다.