Back to Code | Ep 01: 환상의 청구서와 블랙 프라이데이의 충돌

LogiFlow의 15주간의 기술적 사투 — 인공지능 (AI)이 만들어낸 환상에서 깨어나 실제 엔지니어링 (Engineering)으로 돌아가는 기업의 이야기.

이야기 (The Story)

LogiFlow의 유리 벽으로 된 메인 회의실의 공기는 에어컨 소리조차 들리지 않을 정도로 긴장감이 감돌았습니다. 테이블 중앙의 프로젝터에는 이사회를 위한 단 하나의 슬라이드가 표시되어 있었습니다: 11월 인프라 및 AI API 비용.

금액: $114,500.

CTO Kerem은 넥타이를 느슨하게 풀며 침을 삼켰습니다. "보시다시피, 우리의 'AI-First' 전략은 개발 속도를 400% 향상시켰습니다. 자율 AI 에이전트 (Autonomous AI agents)를 사용하여 단 3주 만에 라우팅 (Routing) 마이크로서비스 (microservice)를 처음부터 구축했습니다..."

상석에 서 있던 CFO가 그의 말을 끊었습니다: "Kerem, 속도는 이해했습니다. 하지만 이 청구서는 자동차 한 대 값과 맞먹습니다. 그리고 어젯밤 블랙 프라이데이 (Black Friday) 부하 시뮬레이션 (load simulation)은 시스템을 다운시켰습니다. 당신의 그 '결점 없는' AI가 왜 4시간의 서비스 중단 (outage)을 초래했습니까?"

테이블 끝에 앉아 있던 스태프 엔지니어 (Staff Engineer) Defne는 천천히 노트북 덮개를 닫았습니다. '혁신 반대'라는 낙인이 찍힐까 두려워 수개월 동안 참아왔던 말을 해야 할 때가 왔습니다.

"그건 Kerem 때문이에요," Defne가 차분하게 말했습니다. "AI가 우리에게 코드를 작성해 준 것이 아니에요. AI는 우리에게 _작동하는 것처럼 보이는 환상_을 팔았습니다. 그리고 그 환상은 동시성 (concurrency)에 대해 아무것도 이해하지 못합니다."

기술적 부검 (Technical Autopsy)

화면의 Datadog 로그가 빨간색으로 깜빡이고 있었습니다. 문제는 AI가 자랑스럽게 작성한 서비스인 route-optimizer-v2에 있었습니다. 이 서비스는 실시간 교통 데이터를 기반으로 트럭 경로를 재계산하고 이를 PostgreSQL 데이터베이스 (database)에 기록하는 역할을 했습니다.

AI가 생성한 TypeScript 코드는 그야말로 시 (poetry) 같았습니다. 변수 이름은 완벽했고, JSDoc 주석은 결점이 없었으며, 단 하나의 ESLint 에러도 발생하지 않았습니다.

// AI가 생성한 "결점 없는" 코드
export async function assignRoutesInParallel(
  truckIds: string[], region: string
...

Kerem은 화면을 바라보았습니다. "이게 뭐가 문제라는 거죠? Promise.all을 사용해서 작업을 병렬로 실행하잖아요. 시뮬레이션에서는 50,000대의 트럭을 2초 만에 처리했다고요."

Defne는 씁쓸하게 미소 지었습니다. "네, 2초 만에 처리했죠. 하지만 데이터베이스에 무슨 일이 일어났는지는 아무도 묻지 않았어요." 그녀는 Datadog 로그를 필터링했습니다.

{
  "timestamp": "2026-11-24T23:45:12.114Z",
  "level": "ERROR",
...

기계가 이해할 수 없는 것: 물리적 한계 (Physical Limits)

"**데드락 (Deadlock)**이에요." Defne가 말했습니다. "경쟁 상태 (Race condition)와 커넥션 풀 고갈 (Connection pool exhaustion) 때문이죠."

1. AI가 50,000대의 트럭을 위해 Promise.all을 사용했을 때, Node.js는 즉시 50,000개의 비동기 (async) 작업을 생성했습니다.
2. 각 작업은 SELECT를 통해 데이터베이스로 접근한 뒤, UPDATE로 경로를 수정했습니다.
3. PostgreSQL의 max_connections 제한은 100이었습니다. PgBouncer의 풀 크기 (pool size)는 50이었고요.
4. 50,000개의 요청이 50개의 풀로 몰려들었습니다.
5. 설상가상으로, AI는 UPDATE 쿼리를 작성할 때 **트랜잭션 블록 (Transaction block)**을 사용하지 않았습니다.

"AI는 코드 구문 (syntax)과 해피 패스 (happy path)를 알고 있습니다. 하지만 AI는 PostgreSQL의 MVCC 아키텍처, RAM 내의 커넥션 풀 제한, 또는 디스크 I/O 병목 현상을 느끼지 못합니다. 우리의 기술은 이러한 물리적 한계를 관리하는 것입니다."

에피소드 1의 교훈

1. AI의 동시성 맹점 (Concurrency Blindness): LLM은 비동기 (async) 코드를 작성할 때 시스템 리소스의 물리적 한계를 고려하지 않습니다. 속도 제한 (Rate-limiting) 및 배치 (Batching) 메커니즘은 반드시 인간이 추가해야 합니다.

2. 트랜잭션 경계 (Transaction Boundaries): AI는 "해피 패스"에 집중하여 데이터베이스 작업을 작성합니다. BEGIN, COMMIT, ROLLBACK, 그리고 SELECT ... FOR UPDATE와 같은 잠금 (lock) 메커니즘을 AI에게 맡기면 운영 환경에서 데드락 (deadlock)이 발생합니다.

3. 허영 지표 (Vanity Metrics): AI를 사용하여 하루에 1,000줄의 코드를 작성하는 것은, 하루에 1,000줄의 기술 부채 (technical debt)를 작성하는 것과 같을 수 있습니다.

이것은 "Back to Code" 시리즈의 에피소드 1입니다. 다음 편: 에피소드 2 — 부검: 결점 없어 보였던 거짓말.

Series: back.to.code · 2026