"90분 만에 기능 하나를 통째로 끝냈는데, 내가 만든 것 같지가 않았어요. 마치 사기꾼이 된 기분이었죠." AI로 코딩해 본 사람이라면 한 번쯤 느껴봤을 거예요. 일은 더 빨리 끝나는데, 이상하게 내 실력이 줄어드는 것 같은 그 불안.
그 불안에 Google Cloud AI 디렉터이자 전 Chrome 엔지니어링 리더인 Addy Osmani가 2026년 JS Nation US에서 던진 진단은 위로가 아니라 직격이었어요. "2026년 시니어 개발자는 고연봉 코드 편집자(highly-paid Code Editor)에 불과하다." 모욕처럼 들리지만, 정작 그는 이걸 살아남는 사람의 정의로 말하고 있어요.
"코드를 잘 짜는 사람 = 좋은 개발자"라는 거짓말
우리는 너무 오래 이 등식을 믿었어요. 그래서 AI가 코드를 대신 써주기 시작하자 정체성이 흔들리는 거예요. "내가 제일 잘하던 걸 기계가 더 빨리 한다면, 나는 뭐지?"
그런데 Osmani의 말을 뒤집어 읽어보세요. 좋은 개발자의 진짜 가치는 원래부터 코드 타이핑이 아니었어요. 아키텍처 판단, 비즈니스 맥락 이해, 무엇을 만들고 무엇을 버릴지 정하는 능력 — 이게 늘 핵심이었는데, 타이핑 실력에 가려 잘 안 보였던 거죠. AI가 타이핑을 가져가면서, 역설적으로 진짜 실력이 드러나기 시작한 거예요.
이게 추상적인 위안이 아니라 이미 벌어진 현실이라는 증거는 숫자에 있어요. 2025 Stack Overflow 설문에서 개발자의 84~90%가 AI 코딩 툴을 쓰고 있고, 51%는 매일 써요. Anthropic의 Claude Code는 출시 6개월 만에 연환산 10억 달러 매출을 찍었고요. AI 페어 프로그래밍은 경쟁 우위가 아니라 그냥 기본값(table stakes)이에요. 안 쓰는 게 선택지가 아니라는 뜻이죠.
그런데 빨리 짠 코드가 정말 더 좋은 코드일까요?
여기서 대부분이 착각해요. "AI 덕에 빨라졌으니 생산성이 올랐다"고요. 데이터는 정반대를 가리켜요.
GitClear의 2025년 분석을 보면, AI 코드 생성이 보편화되면서 코드 중복(copy-paste)이 17.1% 늘었고, 작성 후 2주 안에 다시 고쳐지는 코드 비율이 26% 증가했어요. Annie Vella의 연구에서는 개발자의 77%가 코드를 직접 쓰는 시간이 줄었다고 답했고요. 빨리 뱉어낸 코드가 곧바로 부채로 쌓이고 있다는 얘기예요.
Osmani는 이걸 "이해도 부채(comprehension debt)"라고 불러요. AI가 만든 코드를 실제로 이해하고 책임질 사람이 없으면, 속도는 그대로 빚이 돼요. 그리고 바로 이 지점에서 시니어의 가치가 다시 정의됩니다.
시니어 개발자가 주니어보다 AI 생성 코드를 프로덕션에 배포하는 비율이 2.5배 높아요. 프롬프트를 더 잘 써서가 아니라, 무엇을 믿고 무엇을 버릴지 판단하는 눈이 있기 때문이에요.
그러니까 "고연봉 코드 편집자"는 비하가 아니라 직무기술서예요. 작성자(writer)에서 편집자·감독(editor/director)으로. 무엇이 정확히 달라지는지 한 표로 정리하면 이래요.
| 예전 시니어가 하던 일 | 지금 시니어가 하는 일 | 왜 중요해졌나 |
|---|---|---|
| 코드 직접 작성 | AI 출력 평가·편집 | 속도는 공짜, 판단은 비쌈 |
| 구문·라이브러리 암기 | 컨텍스트 엔지니어링 | AI는 준 만큼만 잘함 |
| PR 직접 구현 | 에이전트 오케스트레이션 | 병렬로 굴려야 배수 효과 |
| 주니어 코드 리뷰 | "AI가 왜 이걸 골랐나" 캐묻기 | 이해도 부채를 막는 방어선 |
| 코드 완성도 = 성과 | 시스템 정합성·아키텍처 = 성과 | 평가 기준 자체가 이동 |
Osmani의 한 문장이 이 전환을 압축해요. "나는 이슈가 아니라 PR을 원한다." 산책하면서 GitHub 앱으로 서너 개 작업을 에이전트에 맡기고, 돌아올 때 완성된 PR을 받아 리뷰하는 방식이에요. 미래 얘기가 아니라 그가 지금 일하는 방식이고요.
그래서 오늘부터 뭘 바꾸면 되는데요
여기가 핵심이에요. "판단력이 중요하다"는 말은 누구나 해요. Osmani가 다른 건, 그 판단력을 매일의 동작으로 바꾸는 구체적 워크플로우를 내놓았다는 점이에요. 그는 이걸 아무거나 시키고 결과를 받는 '바이브 코딩'과 구분해 "AI 보조 엔지니어링"이라고 불러요. 순서대로 6가지예요.
- 코드 전에 스펙 먼저 (15분 워터폴)
막연한 요청으로 시작하지 마세요. AI에게 요구사항을 거꾸로 되묻게 시키고, 합의된 내용을spec.md로 정리해요. 코드 한 줄 짜기 전에 방향부터 못 박는 거예요. 이 15분이 뒤의 몇 시간을 살려줘요. - 한입 크기로 쪼개기
"이거 다 만들어줘"는 일관성 없는 코드를 부릅니다. "Step 1 구현 → 검증 → Step 2" 순서로 가세요. 단계마다 테스트를 돌리고 커밋하는 게 핵심이에요. - 컨텍스트를 아낌없이 주기
AI는 준 맥락만큼만 좋은 결과를 내요. 관련 파일, 제약, 선호 패턴, 피해야 할 함정을 전부 프롬프트에 담으세요.gitingest나repo2txt같은 툴로 코드베이스를 통째로 패키징해 넣는 것도 방법이에요. - 검증은 타협 불가
AI는 자신만만하게 틀려요. 모든 AI 생성 코드를 신입 코드 보듯 대하고 반드시 테스트를 돌리세요. 한 단계 더 나아가, 다른 모델(두 번째 AI)에게 그 코드를 리뷰시키면 사람이 놓친 걸 잡아줘요. - 커밋 = 세이브 포인트
AI와 일할 땐 평소보다 더 자주 커밋하세요. 다음 제안이 산으로 가면 직전 커밋으로 되돌아와야 하니까요. "작업 → 테스트 → 커밋"이 한 사이클의 리듬이에요. - 규칙 파일로 AI 길들이기
CLAUDE.md,.cursorrules같은 규칙 파일을 만들어 코딩 스타일, 금지 패턴, 선호 라이브러리를 명시하세요. 그러면 AI가 매번 헤매지 않고 팀원처럼 맞춰서 작업해요.
눈치챘겠지만 이 6단계는 전부 '판단'을 끼워 넣는 장치예요. 스펙으로 판단하고, 쪼개서 판단하고, 검증으로 판단하고, 커밋으로 되돌릴 여지를 남겨요. 코드 편집자의 일은 바로 이거예요.
Addy의 핵심 조언
"기초(fundamentals)를 이해하는 것은 여전히 초능력(superpower)이에요. AI가 프로그래밍 언어를 무의미하게 만든다는 극단론은 틀렸어요. 오히려 깊은 기술 이해가 있어야 AI의 출력을 제대로 평가하고 통합할 수 있어요." 즉 AI 시대의 안전판은 '프롬프트 잘 쓰기'가 아니라 '판단할 수 있을 만큼 깊이 아는 것'이에요.
