AI 코딩 도구가 빠르게 진화하면서 소프트웨어 개발 현장이 유례없는 격변기를 맞고 있습니다. 이제는 단순히 AI를 “쓰는 법”을 익히는 단계를 넘어, 팀의 구성과 개발자의 역할 자체가 뿌리째 흔들리는 중입니다. 최근 몇 달간 현장에서 느낀 기이한 변화와, 앞으로 개발자들이 향해야 할 방향을 정리해봤습니다.
1. 지금 개발 현장에서 벌어지고 있는 기이한 현상들
AI 열풍 속에서 많은 기업이 효율성을 잡겠다며 다소 극단적인 실험을 벌이고 있습니다. 하지만 그 방향이 맞는지는 다시 한번 따져봐야 합니다.
토큰 맥싱(Token Maxing)이라는 함정
일부 조직은 직원이 AI 토큰을 얼마나 썼는지 리더보드로 경쟁시킵니다. 많이 쓰는 사람이 “잘하는 사람”이라는 논리인데, 이건 과거 “코드 줄 수(LOC)”로 생산성을 측정하던 시절의 오류가 다시 재현된 것에 불과합니다. 의미 없는 프롬프트를 쏟아내 양만 늘리는 이른바 바이브 코딩(vibe coding)은 시스템의 복잡도만 끌어올릴 뿐, 실제 가치에는 기여하지 못합니다.
폭발하는 코드, 그리고 병목의 이동
AI가 수만 줄의 코드를 순식간에 뽑아내기 시작하면서, 이제 병목은 “코드 작성”이 아니라 인간의 코드 리뷰로 옮겨갔습니다. 시니어 개발자들은 AI가 쏟아낸 PR을 검증하느라, 정작 자신이 해야 할 아키텍처 설계를 못 하는 교통 관제사가 되어가고 있습니다.
| 과거 | 지금 |
|---|---|
| 코드 작성이 느림 → 개발자 수 늘림 | 코드 작성은 빠름 → 리뷰/검증이 병목 |
| 생산성 지표: LOC, 커밋 수 | 생산성 지표: 명세 품질, 리뷰 품질 |
| 주니어는 “코드를 많이 짜는 사람” | 주니어는 “AI 결과를 검증할 수 있는 사람” |
2. 중심축의 이동: “사후 리뷰”에서 “사전 명세(Spec)”로
요즘 현장에서 가장 뚜렷하게 느껴지는 변화는 품질 관리의 시점이 앞당겨지고 있다는 점입니다. 예전엔 다 짜고 나서 리뷰했지만, 이제는 짜기 전에 명세를 잡는 것이 더 중요해졌습니다.
코드의 소모품화
코드는 이제 언제든 AI로 다시 짤 수 있는 소모품이 됐습니다. “어떤 언어로 짰는가”는 중요하지 않고, “어떤 의도(Spec)를 담아 설계했는가”가 자산이 됩니다. 명세만 제대로 있다면, 파이썬으로 짰던 백엔드를 고(Go)로 다시 짜는 것도 몇 분이면 됩니다.
명세 기반 개발(Spec-Driven Development)의 귀환
AI는 맥락을 스스로 판단하지 못합니다. 그래서 상태 머신(State Machine), 결정 테이블(Decision Table), 엣지케이스를 망라하는 테스트 세트 같은 정밀한 설계 문서가 다시 중요해졌습니다. 과거엔 “문서가 코드를 따라간다”였다면, 이제는 “문서(명세)가 먼저고, 코드는 그 산출물”이 되는 흐름입니다.
- 완벽한 명세 + 테스트 세트 = AI가 언제든 구현을 재생성할 수 있는 원본
- 명세가 빈약하면 AI는 그럴듯하지만 틀린 코드를 자신감 있게 뽑아낸다
- “내가 뭘 만들고 싶은가”를 언어화하는 능력이 곧 설계력이다
3. 인간 개발자만이 할 수 있는 마지막 영역
AI가 매뉴얼화된 코딩은 압도하지만, 실제 장애 상황에서는 인간의 경험적 지식(Tribal Knowledge)이 여전히 결정적입니다.
AI의 한계: 매뉴얼 그 너머
서버가 터졌을 때 AI는 매뉴얼대로 “재시작하라”는 답을 반복할 수 있습니다. 하지만 숙련된 시니어는 로그 한 줄에서 “이건 지난주 마이그레이션 때 바꾼 커넥션 풀 설정이 원인이겠구나”를 직관적으로 읽어냅니다. 이 맥락은 공식 문서 어디에도 적혀 있지 않습니다.
암묵지의 자산화 — 하네스 엔지니어링
팀 내 시니어들의 머릿속에만 있던 비정형 지식을 AI가 참조할 수 있는 배경지식 그래프(Context Graph)로 구축하는 작업 — 이것이 최근 주목받는 하네스 엔지니어링(Harness Engineering)입니다. 장애 히스토리, 장비별 특이사항, 팀의 의사결정 근거 같은 것들을 데이터화해두면 AI가 훨씬 똑똑하게 움직입니다. 앞으로는 이 암묵지 레이어를 얼마나 잘 구축했는가가 조직의 핵심 자산이 될 것입니다.
4. 우리는 어떤 개발자가 되어야 하는가
그래픽 엔지니어가 폴리곤을 하나하나 찍던 시대에서 게임 엔진을 다루는 시대로 넘어왔듯, 소프트웨어 엔지니어링도 “구현”에서 “감독”으로 진화하고 있습니다.
| 역할 | 과거 개발자 | AI 시대 개발자 |
|---|---|---|
| 핵심 역량 | 빠르고 정확한 구현 | 명확한 설계와 의도의 언어화 |
| 주 업무 | 코드 작성 | 명세 작성 + AI 결과 감독 |
| 성과 지표 | 얼마나 빨리 짰는가 | 얼마나 견고하게 설계했는가 |
| 비유 | 폴리곤 찍는 손 | 빛을 조절하는 눈 |
- 코더가 아닌 아키텍트: 빨리 짜는 기술은 변별력이 없다. AI가 오해하지 않도록 설계를 명확히 할 수 있어야 한다.
- AI 감독관(Supervisor): AI의 의사결정 논리를 이해하고, 비판적으로 검토해 시스템에 안착시키는 능력.
- 도구를 지배하는 태도: “가장 많이 쓴 사람(Most AI)”이 아니라 “가장 잘 뽑아낸 사람(Most out of AI)”이 되어야 한다.
정리하며
AI 시대에 개발자가 사라지는 것이 아니라, 개발자의 무게 중심이 옮겨가고 있다고 보는 것이 정확합니다. 우리는 이제 코드를 “쓰는 사람”이 아니라 의도를 설계하고, 그 결과를 감독하는 사람이 되어야 합니다.
- 병목의 이동: 구현(Coding) → 검증 및 감독(Supervision)
- 명세의 힘: 설계 문서(Spec)가 곧 제품이 되는 SDD 시대
- 경험의 자산화: AI가 모르는 우리 팀만의 암묵지를 데이터화
- 역할의 진화: 폴리곤을 그리던 손에서 빛을 조절하는 눈으로
코드는 소모품이 됐지만, 좋은 설계와 경험은 여전히 희소합니다. 다음 글에서는 이 변화의 핵심축인 Spec-Driven Development와 Harness Engineering을 실제 업무에 어떻게 접목할지 좀 더 구체적으로 풀어보겠습니다.