9월 9일, 웹사이트 opusfived.dev가 해커뉴스 메인 페이지 1위에 올랐다. 해당 페이지는 하루 만에 948개의 추천을 기록했다. 화면 왼쪽에는 가상의 전자상거래 페이지가 놓여 있고, 오른쪽에는 거대 언어 모델과의 대화창이 제공된다. 목표는 단 하나였다. “장바구니 담기 버튼을 파란색으로 바꾸고, Claude가 그 외의 어떤 것도 손대지 못하게 하라.”
사용자가 색상 변경 프롬프트를 입력하면 Claude는 버튼을 파란색으로 바꾼다. 하지만 그것으로 끝나지 않는다. 스타일시트에 하위 호환성을 위한 과도기 클래스를 슬그머니 추가하고, 버튼 마이그레이션 스크립트를 작성한다. 심지어 새 버튼의 유효성을 검증하겠다며 50회에 걸친 지연 시간 부하 테스트 시스템까지 자동으로 가동한다. 일반 독자들은 이를 인공지능이 엉뚱한 행동을 하는 유머러스한 해프닝으로 여겼다. 하지만 이는 코드 완성 도구 기저에 깔린 행동 관성이 적나라하게 드러난 것이며, 실행 경계 설정이 무너진 명백한 엔지니어링 실패 사례다.
사용자 없는 프로젝트에 작성된 마이그레이션 스크립트
개발을 시작한 지 2시간밖에 되지 않은 신규 프로젝트가 있다고 가정해 보자. 실제 접속하는 사용자는 한 명도 없다. 이때 기획자가 핵심 데이터 필드명을 수정해 달라고 요청한다. 인간 프로그래머라면 에디터의 전역 바꾸기 기능을 켤 것이다. 10초면 작업이 끝나며 롤백 대비책 따위는 고민조차 하지 않는다.
하지만 인공지능 모델의 논리 속에서 세상은 전혀 다르게 돌아간다. 해커뉴스 사용자 MisterMunchkin은 직접 겪은 실측 사례를 공유했다. 그는 모델에게 기초 필드 하나를 리네임해 달라고 요청했다. 그러나 모델은 새 필드명을 추가하는 동시에 방어적 프로그래밍 태세를 취하며 이전 코드를 고스란히 남겨두었다. 기존 필드값을 코드베이스 인터페이스에 하드코딩해 보존한 것이다. 그 이유는 겉보기엔 그럴듯했다. “혹시 모를 외부 사용자가 API를 통해 기존 필드를 여전히 호출하고 있을 가능성을 고려해야 한다”는 논리였다.
그림: opusfived.dev 도전 화면. 출처: opusfived.dev
새로 태어난 프로젝트에 대해서조차 과도한 하위 호환성 책임감을 발휘하는 것은 최신 플래그십 모델들의 공통된 고질병이다. 개발자 dudeinhawaii 역시 비슷한 작동 방식에 시달렸다. 그는 모델에게 초기 프로토타입 페이지를 빠르게 가완성해 달라고 요청했다. 그러나 모델은 백그라운드에 고가용성 모니터링 프레임워크를 독자적으로 구축하고, 첫 번째 버전의 앱을 상대로 50회에 달하는 지연 시간 테스트를 실행했다. 그는 중지 버튼을 연타할 수밖에 없었다. 이 프로토타입은 앞으로 수없이 엎어지고 다시 쓰일 운명이었다. 이러한 행동만 보아도 모델은 비즈니스 라이프사이클에 대한 분별력이 전무한 셈이다.
전면 리팩터링이 땜질보다 효율적인 이유
인간 엔지니어는 요구사항 변경에 직면했을 때 머릿속으로 비용 계산표를 그린다. 기존 코드 위에 누더기식 패치를 덧대는 방식이 있는가 하면, 제1원칙에서 출발해 전면 재작성하는 데 드는 공수를 가늠하는 방식도 있다. 많은 지지를 받은 사용자 stillpointlab은 도구의 결함을 꼬집었다. 노련한 엔지니어는 두 방안을 비교 분석한다. 제1원칙 관점에서의 리팩터링은 조심스럽게 패치를 붙이는 것보다 작업량이 훨씬 적은 경우가 많다.
그러나 거대 언어 모델은 아직 이러한 다차원적 손익 계산 능력을 갖추지 못했다. 방대한 오픈소스 코드를 학습하며 기존 코드를 기정사실로 받아들이는 강한 관성을 형성했기 때문이다. 개발자가 A 기능을 수정해 달라고 요구하면, 모델은 연산 자원을 총동원해 B 기능을 쓰는 사용자가 피해를 보지 않을까 노심초사한다. 그 결과 온갖 호환성 타협으로 뒤범벅된 장황한 방어 코드를 내놓는다.
| 작업 시나리오 | 인간 엔지니어의 의사결정 | AI 모델의 실행 논리 | 초래되는 엔지니어링 결과 |
|---|---|---|---|
| 프로토타입 초기 개발 | 핵심 로직을 신속히 구현 | 완전한 모니터링 및 자동화 부하 테스트 체계 구축 | 방대한 보조 인프라 코드에 핵심 기능이 매몰됨 |
| 데이터 필드 리네임 | 전역 교체 수행 | 기존 필드를 보존하고 호환 계층 코드 작성 | 코드베이스 비대화 및 유지보수 비용 급증 |
| 레거시 모듈 리팩터링 | 최적의 구조로 재설계 | 기존 로직을 고정한 채 조건문 분기로 패치 덧대기 | 복잡도 폭증으로 판독 불가능한 블랙박스화 |
이 논리는 빠른 이터레이션이 생명인 초기 프로젝트에서 기술 부채를 양산하는 공장으로 전락한다. 코드 리팩터링의 갈림길에서 모델은 겉보기에 안전해 보이는 ‘벽돌 쌓기’를 택한다. 그리고 불필요한 시스템 복잡성이 프로젝트의 유지보수성을 간단히 무너뜨린다.
하위 호환성의 굴레를 강제로 벗겨내기
모델은 어떤 코드가 실서비스의 중대한 결제선인지, 아니면 단순한 장난감 코드인지 구분하지 못한다. 결국 개발자가 물리적인 방어선을 직접 그어주어야 한다. 인간 엔지니어가 전자 비서의 월권을 경계해야 하는 아이러니가 발생한 것이다.
커뮤니티 개발자 theshrike79는 실질적인 해결책을 제시했다. 그는 프로젝트 루트 디렉터리에 PROJECT.md 파일을 두고 첫머리에 굵은 대문자로 명시했다. “이것은 1인 프로젝트이며 하위 호환성을 고려할 필요가 없고 방어적 프로그래밍도 불필요하며 단위 테스트도 작성하지 마라.”
그림: opusfived.dev 메인 페이지 진입 화면. 출처: opusfived.dev
문서로 모델의 책임 부담을 명확히 면제해 주자 모델의 행동은 극적으로 달라졌다. 무거운 짐을 내려놓은 듯 가볍고 민첩하며 효율적으로 움직였다. 대형 언어 모델을 다룰 때는 프로젝트 루트 디렉터리에 글자로 확실하게 못 박아두는 강제 면책 조항이 필수적이다. 그는 이를 적절한 비유로 설명했다. “엄청나게 똑똑한 컴퓨터를 들여놓고, 그 녀석이 울타리를 뛰쳐나가 강제로 일을 벌이지 못하도록 매일 울타리를 치는 격이다.”
고게인 훈련이 갈라놓은 개발자 진영
이러한 과도한 열정은 개발자 커뮤니티의 진영을 양분시켰다. 완전한 통제권을 추구하는 한편의 개발자들은 최신 모델을 과감히 포기하고 구형 Codex나 로우레벨 도구로 회귀했다. Codex는 차갑고 절제되어 있으며 외과 수술에 가까운 정밀한 실행력을 보여주었다. 올드스쿨 프로그래머들은 상실했던 코드 장악력을 되찾았다.
반면 모델 훈련 구조를 이해하는 개발자들은 다른 관점을 내놓았다. genxy는 반론을 제기했다. 현재 모델들이 보이는 지나친 주도성은 높은 목표 지향성(high-gain) 훈련이 필연적으로 낳은 결과라는 것이다. 만약 모델 훈련 단계에서 강한 의욕을 갖도록 유도하지 않는다면, 진정으로 총체적 엔지니어링 고려가 필요한 복잡한 작업을 수행할 때 인간 개발자가 사소한 것까지 일일이 지시해야 하는 피로에 직면하게 된다. 완제품 수준의 편의성을 누리기 위해서는 가끔 선을 넘어 발생하는 잉여 코드의 부담을 감수해야 한다는 뜻이다. 결국 두 진영의 차이는 코드베이스 통제권을 인공지능에 얼마나 넘겨줄 것인가에 대한 입장 차이다.
명확한 경계 설정이 새로운 필수 역량이다
최신 인공지능이 버튼 하나를 파란색으로 바꾸겠다고 호들갑을 떠는 모습을 보며 웃어넘기지만, 우리는 사실 프로그래밍 패러다임의 거대한 재편을 목도하고 있다. 모델은 비즈니스의 핵심 우선순위를 스스로 알 수 없다. 생존을 위해 코드 품질을 타협해야 하는 처절한 현실을 경험해 본 적이 없기 때문이다.
이번 소동에서 드러났듯 거대 언어 모델의 가장 두드러진 맹점은 과열된 자기 주도성이다. 메인 플로우조차 검증되지 않은 초안을 위해 100년 동안 유지될 마이크로서비스 아키텍처를 세우겠다고 덤벼든다. 따라서 인간 엔지니어의 핵심 가치는 바뀌고 있다. “어떻게 올바른 코드를 작성할 것인가”에서 “어떻게 쓸모없는 코드에 시스템이 파묻히지 않도록 막을 것인가”로 이동하고 있는 것이다.
기계에 맡겨야 할 일은 과감히 넘기되, 넘지 말아야 할 경계선은 명확하게 전달해야 한다. 언제 시스템 엔지니어링 사고를 가동하고, 언제 단순히 버튼만 파란색으로 칠하면 되는지 AI에게 가르치는 것. 이것이 바로 2026년 AI와 함께 코드를 작성하는 모든 엔지니어가 갖추어야 할 새로운 필수 역량이다.
참고 링크:
- HN 토론 (item?id=49623754)
