11명의 비개발자가 AI와 채팅하며 사내 플랫폼을 함께 만들었다. 전자결재, 근태관리, 평가 관리—각자 자기 업무 도구를 직접 만드는 장면은, 겉으로는 생산성 성공 사례처럼 보인다. 하지만 요즘IT에 소개된 이 사례를 자세히 들여다보면, 정작 흥미로운 이야기는 AI가 뭘 만들었는가가 아니라 개발자가 뭘 설계했는가에 있다.
사람이 한두 명일 때는 보이지 않던 문제가 열 명이 넘자 한꺼번에 터졌다. AI가 '결재'라는 단어를 보고 근태관리의 결재 정책을 전자결재 화면에 끌어다 쓰는 일이 벌어졌다. 컨텍스트가 뒤섞였고, 결과물은 엉망이 됐다. 개발자가 내린 처방은 AI를 더 똑똑한 모델로 교체하는 게 아니었다. 대신 AI가 매번 읽어야 할 문서를 만들었다. 디자인 시스템, 스키마 명세, 네이밍 규칙, 프로젝트별 기능 명세. 컬럼명 하나에도 '이 필드는 이런 의미이고, 이런 상황에 쓰며, 값은 이 타입으로 들어온다'는 맥락을 붙였다. 그러자 API 에러가 거의 사라졌다. AI에게 진짜 중요한 건 모델의 크기가 아니라 맥락의 품질이었다.
이 통찰은 최근 dev.to에 공개된 소형 코딩 모델 하네스 최적화 연구에서도 정확히 같은 방향으로 검증된다. GPT-5.1-Codex-Mini—플래그십 대비 한두 티어 아래인 소형 모델—에 정교한 하네스를 씌웠더니 Terminal-Bench 2.0에서 61.6%를 기록했다. 같은 벤치마크에서 Claude Opus 4.6, GPT-5.2 같은 대형 모델의 기본 하네스와 동일한 점수 대역이다. 비용은 단 27달러. 연구자의 결론은 명확하다. "모델이 클수록 하네스 실수를 근육으로 때운다. 작은 모델을 쓸 때만 설계 실수가 즉각 드러난다." 즉, 하네스—시스템 프롬프트 구조, 툴 설계, 컨텍스트 관리, 에러 복구 전략—가 모델 선택보다 더 결정적인 변수라는 것이다.
두 사례가 수렴하는 지점이 있다. AI 코딩의 품질은 모델 스펙이 아니라 AI가 일하는 환경의 설계 수준에서 갈린다. 어떤 맥락을 제공하느냐, 어떤 툴을 어떤 순서로 노출하느냐, 실패했을 때 어떻게 복구하느냐—이 구조를 짜는 것이 이제 개발자의 핵심 작업이 되고 있다. 사내 플랫폼 사례의 개발자는 이걸 "AI가 일할 수 있는 환경을 설계하는 것"이라 표현했다. 하네스 연구자는 "래퍼가 모델보다 더 많은 일을 한다"고 썼다. 같은 말이다.
여기에 한 가지 불편한 현실을 더해야 한다. GitHub Copilot의 새 요금제 공개 이후 dev.to에 올라온 분석 글은, AI 도구 의존성의 숨겨진 비용을 정면으로 꺼낸다. Copilot이 월별 예상 비용 미리보기 기능을 도입하자, V2EX 중국 개발자 커뮤니티에서 "이제 못 쓰겠다"는 반응이 쏟아졌다. 저자는 이를 '구독 의존성 부채'라 부른다. AI 도구를 도입하면 생산성이 오른다. 워크플로우가 도구에 최적화된다. 그러다 가격이 오르면—프롬프트로 문제를 푸는 데 익숙해진 뇌는 원래 속도로 돌아가지 못한다. 기술 부채처럼, 스킬 부채가 쌓인다.
이 세 흐름을 함께 놓으면 하나의 질문이 선명해진다. AI 도구를 '쓰는' 것과, AI가 '일할 환경'을 만드는 것—당신은 지금 어디에 서 있는가? 전자는 도구의 성능에 기대는 포지션이다. 가격이 오르면 취약해지고, 모델이 바뀌면 흔들린다. 후자는 맥락을 설계하고, 가드레일을 깔고, 실패 시나리오를 미리 구조화하는 포지션이다. 도구가 바뀌어도, 모델이 교체되어도, 설계 원칙은 남는다.
나는 AI-First 팀 리빌딩을 주도하면서 팀원들에게 늘 같은 질문을 던진다. "AI한테 무엇을 시키고 있는가"가 아니라 "AI가 제대로 일하려면 우리가 무엇을 먼저 만들어야 하는가." 스키마에 의미를 붙이는 일, 컴포넌트 경계를 명확히 문서화하는 일, 테스트 스펙을 AI가 읽을 수 있는 형태로 선행 작성하는 일—이건 전통적인 시스템 설계 역량이 AI-First 워크플로우에서 재소환되는 장면이다. 달라진 건 대상이다. 예전엔 사람 개발자를 위해 설계했다면, 지금은 AI 에이전트와 비개발자 모두를 위해 설계한다.
앞으로의 방향은 이미 보인다. 모델은 계속 바뀌고, 요금제도 계속 바뀐다. 소형 모델이 정교한 하네스를 만나 대형 모델을 따라잡는 속도는 점점 빨라질 것이다. 그 흐름 속에서 '어떤 모델을 쓰느냐'는 팀 경쟁력의 핵심 변수에서 점점 멀어진다. 남는 것은 맥락을 얼마나 잘 설계했는가, AI 실패를 얼마나 구조적으로 막았는가, 그 환경 위에서 팀원이 얼마나 자유롭게 만들 수 있는가다. 마인크래프트 서버를 여는 사람의 역할—뭘 짓는지는 다른 사람들이 정하고, 개발자는 그들이 신나게 지을 수 있는 땅을 설계한다. 그 비유가 지금 개발자 역할의 이동을 가장 정확하게 포착하고 있다.