AI 기반 개발의 허와실 — 'AI가 다 짜준다'는 말이 빠뜨린 것

"이제 AI가 코드를 다 짜준다"는 문장은 절반만 맞다. 맞는 절반은 생성(generation)이다. AI는 함수 하나, 컴포넌트 하나, CRUD 한 벌을 몇 초 만에 만들어낸다. 빠뜨린 절반은 나머지 전부다. 그 코드가 실제로 의도대로 동작하는지, 기존 시스템과 충돌하지 않는지, 엣지 케이스에서 무너지지 않는지, 6개월 뒤에도 유지되는지.

소프트웨어의 비용은 원래 "타이핑"에 있지 않았다. 코드를 쓰는 시간보다 그 코드가 맞는지 확인하고, 통합하고, 고장 났을 때 고치는 시간이 훨씬 길다. AI는 가장 싼 부분을 더 싸게 만들었고, 가장 비싼 부분은 거의 그대로 두었다. 그래서 병목은 사라진 게 아니라 옮겨갔다.

이 글은 AI 개발을 둘러싼 세 가지 허(虛)와 세 가지 실(實)을 가른다. 마케팅이 아니라 실제로 AI-native 방식으로 결과물을 출하해본 운영 관점에서.

허 ①: "AI가 알아서 다 해준다"

데모는 5분이다. 프로덕션은 다르다.

AI에게 "쇼핑몰 장바구니 만들어줘"라고 하면 작동하는 것처럼 보이는 화면이 나온다. 문제는 그 다음부터다. 동시에 두 명이 같은 상품의 마지막 재고를 담으면? 결제 중 네트워크가 끊기면? 쿠폰과 적립금을 같이 쓰면 계산이 맞나? 이런 질문은 AI가 먼저 던지지 않는다. 물어보면 답하지만, 물어볼 목록 자체를 만드는 일은 여전히 사람의 몫이다.

"알아서 다 해준다"는 환상은 생성과 사양(specification)을 혼동한 데서 온다. AI는 주어진 사양을 코드로 옮기는 데 강하다. 그러나 무엇을 만들어야 하는지, 무엇이 "맞다"의 기준인지를 정하는 일은 생성이 아니다. 그 기준이 비어 있으면 AI는 그럴듯한 기본값으로 빈칸을 채우고, 그 기본값이 당신의 비즈니스 규칙과 일치할 확률은 높지 않다.

허 ②: "검증 없이 바로 출시할 수 있다"

AI 코드의 진짜 위험은 못 짜는 게 아니다. 그럴듯하게 틀리는 것이다.

컴파일은 통과하고, 화면은 뜨고, 해피 패스는 동작한다. 코드 리뷰에서도 멀쩡해 보인다. 그런데 특정 조건에서 음수 재고를 허용하거나, 권한 체크를 한 군데 빠뜨리거나, 환율 계산에서 소수점을 잘못 처리한다. 사람이 짠 버그는 대개 "어색해서" 눈에 걸린다. AI가 짠 버그는 주변 코드와 톤이 똑같아서 더 잘 숨는다.

이건 인상비평이 아니다. 개바리가 결과물을 만드는 데 쓰는 것과 같은 생성-검증 파이프라인으로 작업 크기를 바꿔가며 내부 측정을 해봤다. AI가 단일 프롬프트로 만든 코드가 검증 게이트(테스트)를 첫 시도에 통과하는 비율은 규모가 커질수록 가파르게 무너졌다. 300 LOC 이하 단일 파일은 93–100%, 약 800 LOC 단일 파일은 평균 48.7%, 그리고 파일이 2개 이상으로 쪼개지는 순간 0%였다. 온도(temperature) 0으로 고정해도 매번 같은 지점에서 결정론적으로 붕괴했다.

"AI가 만들었으니 빠르다"와 "AI가 만들었으니 믿는다"는 다른 명제다. 빠른 생성은 검증을 면제해주지 않는다. 오히려 생성이 싸지면서 검증해야 할 산출물의 양이 늘었기 때문에, 검증이 자동화되지 않으면 전체 속도는 더 느려진다. 사람이 일일이 눈으로 확인하는 방식은 생성 속도를 따라잡지 못한다.

허 ③: "개발 비용이 0이 된다"

비용은 사라지지 않았다. 이동했다.

소프트웨어 한 줄의 총비용을 분해하면 대략 이렇게 나뉜다. 작성, 검증, 통합, 운영·유지보수. 통념과 달리 작성은 이 중 가장 작은 조각이고, 유지보수가 가장 크다. AI는 가장 작은 조각을 0에 가깝게 만들었다. 나머지 조각들은?

"AI로 개발하면 공짜"라는 기대로 들어온 프로젝트가 실패하는 이유가 여기 있다. 생성 비용이 0이 됐다고 전체 비용이 0이 된 게 아닌데, 견적과 일정을 생성 비용 기준으로 잡으면 검증·통합·운영 단계에서 예산이 터진다. 비용이 어디로 갔는지 모르면 그 비용을 관리할 수도 없다.

실 ①: 진짜 레버리지는 "검증 게이트"

생성이 싸진 시대에 차별화는 "얼마나 빨리 짜느냐"가 아니라 "작동을 어떻게 증명하느냐"에서 나온다.

개바리가 결과물을 출하하는 방식의 핵심은 verify-gate다. AI가 만든 산출물은 자동으로 출하되지 않는다. 사전에 정의된 검증을 통과한 것만 통과한다. 통과하지 못하면 다시 생성 루프로 돌아간다. 사람이 보기에 그럴듯한지가 아니라, 정의된 기준을 실제로 만족하는지가 통과 조건이다.

이 게이트가 허 ②에서 말한 "그럴듯하게 틀리는" 문제를 막는 장치다. 생성은 값싸고 불완전하다는 것을 전제로 받아들이고, 대신 통과 기준을 단단하게 만든다. 빠르게 많이 만들되, 증명된 것만 내보낸다.

“Testing shows the presence, not the absence of bugs.”

검증 게이트는 만능이 아니다. 다익스트라의 말대로 테스트는 버그의 부재를 증명하지 못한다. 그러나 게이트의 가치는 완벽함이 아니라 일관성이다. 사람의 컨디션이나 마감 압박에 따라 검증 강도가 들쭉날쭉하지 않고, 정의된 기준이 매번 동일하게 적용된다. AI가 생성을 무한히 반복할 수 있는 만큼, 검증도 무한히 반복 가능한 형태여야 짝이 맞는다.

실 ②: oracle-author 루프 — 사람은 "정답 기준"을 쓴다

검증 게이트가 작동하려면 "무엇이 맞는가"의 기준이 있어야 한다. 그 기준을 만드는 일이 oracle(오라클, 정답 판정 기준) 작성이다.

AI-native 운영에서 사람의 시간이 가장 크게 들어가는 곳이 여기다. 코드를 타이핑하는 대신, "이 기능이 맞다는 것은 무엇으로 증명되는가"를 정의한다. 어떤 입력에 어떤 출력이 나와야 하는지, 어떤 엣지 케이스가 막혀야 하는지, 어떤 불변식이 깨지면 안 되는지. 이 오라클이 생성 루프의 통과 조건이 된다.

루프는 단순하다. 사람이 오라클을 쓴다 → AI가 산출물을 생성한다 → 게이트가 오라클로 검증한다 → 실패하면 다시 생성, 통과하면 출하. 생성은 값싸니까 여러 번 돌려도 되고, 검증은 오라클로 자동화돼 있으니 사람이 매번 들여다볼 필요가 없다. 사람의 비싼 시간은 "기준을 정하는 일"에 집중된다.

이게 "AI가 개발자를 대체한다"가 틀린 이유다. 대체된 것은 타이핑이고, 사람에게 남은 것은 더 어려운 일 — 무엇이 맞는지를 정의하는 일 — 이다.

실 ③: 사람의 역할은 사라진 게 아니라 이동했다

AI 이전의 개발자 시간은 대부분 구현에 들어갔다. AI 이후 그 시간은 세 곳으로 재배치된다. 사양(무엇을 만들 것인가), 오라클(무엇이 맞는가), 판단(게이트가 잡지 못한 것을 잡고, 트레이드오프를 결정하는가).

이 셋은 전부 생성이 아니다. 맥락, 도메인 지식, 비즈니스 판단이 필요한 일이다. 커머스로 좁히면 더 분명하다. "정산 주기를 어떻게 잡을 것인가", "반품 정책이 적립금과 어떻게 상호작용하는가", "채널별 재고를 어느 시점에 동기화하는가" — 이런 결정은 AI가 대신 내려주지 않는다. AI는 결정된 것을 빠르게 구현할 뿐이다.

그래서 AI-native 개발은 "사람이 적게 일한다"가 아니라 "사람이 다른 일을 한다"에 가깝다. 더 정확히는, 가장 레버리지가 높은 일 — 기준을 정하고 판단하는 일 — 만 남기고 나머지를 기계에 넘기는 것이다.

정리: 허와실 한 표로

AI는 도구다. 강력하지만, 무엇을 만들지와 무엇이 맞는지를 정하는 일까지 대신해주지는 않는다. AI 개발을 잘 쓴다는 것은 "사람을 빼는 것"이 아니라, 값싸진 생성을 단단한 검증 게이트와 짝지어, 작동이 증명된 결과물만 내보내는 시스템을 만드는 것이다. 생성이 공짜가 된 시대의 경쟁력은 거기에서 갈린다.

FAQ

자주 묻는 질문

AI가 개발자를 대체하나요?

코드를 타이핑하는 일은 상당 부분 자동화됩니다. 그러나 무엇을 만들지(사양), 무엇이 맞는지(오라클), 게이트가 놓친 것을 잡는 판단은 여전히 사람의 일입니다. 역할이 사라지는 게 아니라 더 어려운 쪽으로 이동합니다.

AI가 만든 코드, 검증 없이 바로 써도 되나요?

위험합니다. AI 코드의 특징은 '못 짜는 것'이 아니라 '그럴듯하게 틀리는 것'입니다. 컴파일되고 화면도 뜨지만 특정 조건에서 비즈니스 규칙을 위반할 수 있습니다. 정의된 기준으로 작동을 증명하는 검증 게이트를 거쳐야 합니다.

AI로 개발하면 비용이 0이 되나요?

코드 생성 비용은 0에 가까워집니다. 하지만 소프트웨어 비용의 대부분은 원래 생성이 아니라 검증·통합·운영·유지보수에 있었고, 이 부분은 그대로 남습니다. 비용은 사라진 게 아니라 이동했습니다.

---

개바리는 이 방식으로 커머스 결과물을 출하합니다 — 값싸진 생성을 검증 게이트와 짝지어, 작동이 증명된 것만 내보냅니다. 문의: gaebari.com/apply