Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 질문을 바로 세우기
메커니즘 — 병목은 사라지지 않고 이동한다
감가하는 기술 — 원래 가치가 아니라 대리 지표였던 것들
절상하는 기술 (1) — 검증: 훑어보는 눈이 아니라 정답을 공급하는 능력
절상하는 기술 (2) — 프로덕션 디버깅: 맥락이 암묵적일 때
절상하는 기술 (3) — 시스템 설계와 트레이드오프 취향
절상하는 기술 (4) — 요구사항 고고학: 무엇을 만들지 아는 일
절상하는 기술 (5) — 오너십: 호출기를 찰 수 있다는 것
반론 — "검증도 결국 AI가 하지 않나"
마치며
참고 자료

들어가며 — 질문을 바로 세우기

"AI가 개발자를 대체할까"는 잘못 세운 질문입니다. 이 질문은 개발자를 하나의 기술로 취급합니다. 실제로 개발자는 열댓 가지 기술의 묶음이고, 그 묶음의 항목들은 지금 서로 다른 속도로 재가격되는 중 입니다. 어떤 항목은 0에 수렴하고, 어떤 항목은 오릅니다.

그래서 제대로 된 질문은 이것입니다 — 묶음에서 싸지는 항목은 무엇이고, 그 값은 어디로 가는가. 이건 취향의 문제가 아니라 꽤 지루한 경제학의 문제이고, 답의 뼈대는 이미 나와 있습니다.

메커니즘 — 병목은 사라지지 않고 이동한다

공정 하나가 싸지고 흔해지면 병목은 소멸하지 않습니다. 다음 공정으로 이동 합니다. 그리고 값은 병목이 있는 곳에 붙습니다. 생성이 싸지면 값은 생성 다음 단계로 갑니다 — 그것이 맞는지 확인하는 일, 무엇을 만들지 정하는 일, 남의 시스템에 끼워 넣는 일로.

이 직관을 AI 쪽에서 가장 날카롭게 벼려 놓은 사람이 Jason Wei입니다. 그의 검증의 비대칭성(asymmetry of verification) 은 간단합니다 — 어떤 과제는 푸는 것보다 확인하는 게 훨씬 쉽습니다. 스도쿠를 푸는 데는 오래 걸리지만 다 푼 답이 맞는지는 즉시 압니다. 여기서 그는 검증자의 법칙(verifier's law) 을 끌어냅니다 — "AI에게 어떤 과제를 가르치는 난이도는 그 과제의 검증 가능성에 비례한다." 더 날 선 표현으로는, 풀 수 있고 검증하기 쉬운 과제는 결국 전부 AI가 풀게 된다 는 것입니다.

대부분은 이 법칙을 "AI가 잘하게 될 일" 목록으로 읽습니다. 그런데 뒤집어 읽는 쪽이 훨씬 중요합니다. 검증하기 쉬운 일이 자동화된다면, 사람에게 남는 일은 정확히 검증이 비싸거나 느리거나 주관적이거나, 애초에 정답지가 없는 일 입니다. 이건 위안이 아니라 예측입니다.

그리고 병목은 실제로 이미 움직였습니다.

DORA 2025 는 기술 인력의 약 90%가 AI를 쓴다고 보고합니다. 그런데 결론이 묘합니다 — AI 도입은 처리량과 양의 관계로 돌아섰지만, 배포 불안정성은 계속 오릅니다. DORA의 요약은 AI가 조직의 기존 강점과 약점을 함께 증폭하는 증폭기 라는 것입니다. 속도만 올리고 품질 통제를 안 하면 병목은 그저 하류로 밀려납니다.
LinearB의 2026 벤치마크 는 그 하류가 어디인지 숫자로 보여 줍니다. 4,800여 개 조직의 PR 810만 건을 분석했더니, AI가 만든 PR은 리뷰를 4.6배 오래 기다립니다. 에이전트가 연 PR은 픽업 시간이 5.3배 깁니다. 병합률은 32.7% 대 84.4% 로 사람이 쓴 코드에 한참 못 미칩니다. 생성이 폭증한 자리에서 리뷰 앞에 줄이 생긴 것입니다.
그 줄이 왜 안 줄어드는지는 Stack Overflow 2025 가 설명합니다. 개발자의 84%가 AI 도구를 쓰거나 쓸 계획이고 절반 이상이 매일 씁니다. 그런데 최대 불만 1위가 "거의 맞지만 정확히는 아닌 코드"(66%) 이고, 2위가 "AI가 만든 코드를 디버깅하는 데 시간이 더 든다"(45.2%) 입니다. 정확성을 높게 신뢰한다는 응답은 3.1%뿐입니다.

마지막 항목이 이 글 전체의 핵심입니다. 거의 맞는 코드는 틀린 코드보다 비쌉니다. 틀린 코드는 즉시 걸러집니다. 거의 맞는 코드는 훑어보기를 통과하고, 리뷰를 통과하고, 스테이징을 통과한 다음, 프로덕션에서 터집니다. 생성이 싸질수록 이런 코드가 더 많이, 더 빨리 쏟아집니다. 검증 비용은 생성량에 비례해서 늘어나는데, 검증 역량은 그렇지 않습니다.

감가하는 기술 — 원래 가치가 아니라 대리 지표였던 것들

솔직하게 이름을 붙이겠습니다.

암기한 프레임워크 API. 모델은 문서를 당신보다 정확히, 전부 읽었습니다. 시그니처를 외우는 능력에 붙어 있던 프리미엄은 사라졌습니다.
보일러플레이트 처리량. CRUD 스캐폴딩, DTO 변환, 설정 파일, 테스트 픽스처 — 분당 생산량으로 경쟁하던 영역입니다.
"나는 빨리 친다" 식 생산성. 타이핑 속도가 병목이었던 적은 사실 한 번도 없었지만, 그래도 값이 매겨지던 시절은 있었습니다.

중요한 건 이겁니다 — 이 기술들은 원래부터 가치 그 자체가 아니라 가치의 대리 지표(proxy) 였습니다. 생성이 병목이던 시절에는 희소했기 때문에 값이 붙었을 뿐입니다. 희소성이 사라지면 값도 사라집니다.

다만 감가와 무용은 다릅니다. 읽지 못하는 코드는 리뷰할 수 없습니다. 문법도 모르고 프레임워크도 모르면 아래에서 말할 절상 기술은 하나도 시작되지 않습니다. 바닥은 여전히 필요합니다. 다만 바닥은 이제 입장료지 경쟁 우위가 아닙니다.

절상하는 기술 (1) — 검증: 훑어보는 눈이 아니라 정답을 공급하는 능력

먼저 오해를 걷어냅시다. 절상하는 검증 능력은 "디프를 꼼꼼히 읽는 성실함"이 아닙니다. 그건 기계가 이미 상당 부분 합니다. 린터, 타입 체커, 정적 분석, AI 리뷰 봇 — 널 체크 누락과 명백한 경쟁 조건은 검증하기 쉬운 축에 속하고, 검증자의 법칙에 따라 그쪽은 계속 자동화됩니다.

값이 오르는 건 기계가 공급할 수 없는 쪽입니다 — 정답지(ground truth) 자체. 이 시스템에서, 이 사업에서, 이 규모에서 "맞다"가 무엇을 뜻하는지 결정하는 일 입니다. 모델은 테스트를 통과시킬 수 있지만, 무엇을 테스트해야 하는지는 결정하지 못합니다. 그건 사업의 사실이지 코드의 사실이 아니기 때문입니다.

의도적으로 기르는 법:

모델이 코드를 쓰기 전에 통과 조건을 먼저 쓰세요. 통과 조건을 문장으로 못 쓰면 그건 요구사항이 아니라 소망입니다.
가설을 갖고 리뷰하세요. 디프를 열기 전에 "이 변경이 프로덕션을 깨뜨릴 수 있는 경로 세 가지"를 적고, 그것들을 찾으러 들어가세요. 가설 없는 리뷰는 오타 검사입니다.
버그 장부를 쓰세요. 프로덕션 버그마다 "어떤 검증이 있었다면 이걸 잡았을까"를 한 줄로 적으세요. 그 목록이 당신에게 없는 테스트입니다.
"테스트 통과"와 "정확함"을 구분하는 훈련을 하세요. 평가 설계는 그 자체로 하나의 기술이고, 이건 AI 코딩 모델 평가에서 신호와 잡음 가려내기에서 다룬 문제와 정확히 같은 문제입니다 — 잡음보다 큰 차이만 신호입니다.

절상하는 기술 (2) — 프로덕션 디버깅: 맥락이 암묵적일 때

METR의 무작위 대조 실험이 이 대목에서 가장 유용합니다. 숙련 오픈소스 개발자 16명이 자기 저장소(평균 별 2만 개 이상, 코드 100만 줄 이상)에서 실제 이슈 246건을 처리했습니다. 이들은 시작 전 24% 빨라질 거라 예상했고, 끝난 뒤엔 20% 빨라졌다고 느꼈습니다. 실제로는 19% 느려졌습니다.

이유가 결정적입니다. 오래 다뤄 온 성숙한 저장소는 AI에게 최악에 가까운 조건입니다 — 요구사항이 저장소 바깥의 맥락에 얽혀 있고, 사람 쪽에는 문서에 없는 방대한 로컬 지식 이 쌓여 있기 때문입니다. 모델에게는 그 지식이 없습니다.

이게 해자의 모양입니다. AI는 맥락이 암묵적이고 실패가 창발적인 곳에서 가장 약합니다. 프로덕션이 정확히 그런 곳입니다. 버그는 디프 안에 없습니다. 디프와, 아무도 적어 두지 않은 6년치 결정들 사이의 상호작용 안에 있습니다.

제 경험으로 말하자면 — KubeVirt GPU 패스스루 VM이 112일간 스케줄되지 못한 부검에서 원인은 저장소 안에 없었습니다. 저장소만 읽는 무엇도 그걸 찾아낼 수 없었습니다. CloudNativePG로 Postgres를 띄우고 죽여본 기록도 같습니다 — 페일오버가 실제로 무엇을 하는지는 읽어서 아는 게 아니라 프라이머리를 죽여 보고 23초를 재서 압니다.

의도적으로 기르는 법:

장애를 끝까지 소유하고 부검을 직접 쓰세요. 배움은 대응이 아니라 글쓰기에서 생깁니다.
안전한 곳에서 일부러 부수세요. 프라이머리를 죽이고, 디스크를 채우고, 네트워크를 끊으세요. 먼저 결과를 예측하고, 그다음 측정하세요. 예측과 측정의 간극이 곧 당신이 가진 시스템 모델의 오차이고, 회사가 돈을 내는 대상이 바로 그 모델입니다.
코드가 아니라 시스템을 읽는 훈련. 메트릭, 트레이스, 커널 로그, 이벤트. 관찰 → 가설 → 실험의 루프를 몸에 붙이세요.
내가 안 쓴 코드를 디버깅하세요. 이게 앞으로의 기본값입니다. 코드는 모델이 썼고, 책임은 당신에게 있습니다.

절상하는 기술 (3) — 시스템 설계와 트레이드오프 취향

모델은 어떤 설계 질문에도 그럴듯한 답을 내놓습니다. 못 하는 건 당신의 조직이 5년간 감당할 수 있는 트레이드오프가 어느 쪽인지 고르는 일입니다. 그 판단은 저장소에 없는 사실들에 달려 있기 때문입니다 — 팀 규모, 온콜 성숙도, 감당 못 할 마이그레이션, 만료를 앞둔 벤더 계약, 6개월 뒤 나갈 사람.

취향은 신비한 게 아닙니다. 지난번에 무엇이 터졌는지에 대한 압축된 기억 입니다. 결과를 겪고 만든 사전 확률이죠.

의도적으로 기르는 법: 남의 부검을 읽으세요(공개된 것이 많습니다). 설계 문서마다 무엇을 포기하는지 를 명시적으로 쓰세요. 기각한 대안을 최소 두 개 적고 왜 기각했는지 쓰세요. 그리고 12개월 뒤 자기 결정을 다시 열어 채점하세요 — 이 되먹임이 없으면 취향은 자라지 않고 고집만 자랍니다.

규칙 하나 — 기각된 대안이 없는 설계 문서는 설계가 아니라 선호입니다.

절상하는 기술 (4) — 요구사항 고고학: 무엇을 만들지 아는 일

가장 비싼 버그는 완벽하게 구현된 엉뚱한 것 입니다. AI는 만드는 비용을 떨어뜨립니다. 그 말은 엉뚱한 것을 훨씬 빠르게, 훨씬 대량으로 만들 수 있게 됐다 는 뜻이기도 합니다. 그래서 무엇을 만들지 아는 능력은 만드는 비용이 싸지는 만큼 정확히 비례해서 절상됩니다.

요구사항 고고학은 사람들이 말한 것에서 실제로 필요한 것을 발굴하는 일입니다. 대부분의 진짜 요구사항은 문서에 없습니다. 아무도 지우지 못하는 2019년의 if 문 안에, 이상한 예외 처리 안에, 옛 시스템의 기본값 안에 화석처럼 박혀 있습니다.

이 모호함을 다루는 일이 직무 자체인 자리도 있습니다 — Forward Deployed Engineer 준비 글에서 정리했듯, 거기서는 모호함이 부작용이 아니라 업무입니다.

의도적으로 기르는 법: 사용자 옆에 앉아 실제로 하는 걸 보세요(말하는 것과 다릅니다). "이게 실패하면 그다음에 뭘 하세요?"를 물으세요 — 진짜 요구사항은 대개 그 답에 있습니다. 코드베이스에서 가장 흉한 분기를 골라 왜 존재하는지 끝까지 파세요(대개 실수가 아니라 요구사항입니다). 설계 문서 이전에 한 장짜리 문제 정의 를 쓰세요. 그리고 틀리려면 일찍, 싸게, 소리 내어 틀리세요.

절상하는 기술 (5) — 오너십: 호출기를 찰 수 있다는 것

모델에게 호출기를 채울 수는 없습니다. 똑똑함이 모자라서가 아닙니다. 책임은 결과를 감당하는 주체를 요구하기 때문 입니다. 조직은 결정에 이름이 붙기를 원합니다. 새벽 3시에 깨어나 "이건 내가 롤백한다"고 말할 사람이 필요합니다.

여기서 정직할 필요가 있습니다. 이건 역량의 사실이라기보다 사회적·법적 사실 입니다. 언젠가 제도가 바뀔 수도 있습니다. 다만 사회적 사실은 끈질기고, 노동의 값을 실제로 매깁니다.

커뮤니케이션도 여기 속합니다. 코드를 못 읽는 사람에게 트레이드오프를 설명하지 못하면 결정을 통과시킬 수 없습니다. 생성이 싸질수록 희소해지는 행위는 결정 이고, 결정은 본질적으로 사회적 행위입니다.

의도적으로 기르는 법: 호출기를 받으세요. 아무도 하기 싫어하는 마이그레이션에 손을 드세요. 무언가를 출시하고 1년간 그것에 붙어 있으세요. 결과가 나에게까지 도달하는 되먹임 고리 — 판단력은 오직 거기서만 자랍니다.

반론 — "검증도 결국 AI가 하지 않나"

이 반론은 진지하게 다뤄야 합니다. 약하게 만들어 놓고 이기면 자기기만입니다.

가장 강한 형태는 이렇습니다. 검증자의 법칙은 검증하기 쉬운 일은 전부 AI가 가져간다 고 말하는데, 리뷰의 상당 부분은 검증하기 쉽습니다. 타입 오류, 널 참조, 명백한 경쟁 조건, 스타일 — AI 리뷰 도구는 이미 이걸 잘합니다. 테스트 생성, 퍼징, 코드를 실제로 실행해 보고 관찰하는 에이전트까지 붙으면 검증의 상당 부분은 자동화됩니다. 여기에 더해, 위에서 인용한 METR 결과조차 METR 자신이 단서를 달았습니다 — 2026년 2월 업데이트에서 이들은 실험 설계를 바꾸겠다고 밝히면서, 2026년 초 시점에는 개발자들이 초기 추정보다 더 빨라졌을 가능성이 높다 고 봅니다(다만 그 크기에 대한 증거는 약하다고 인정합니다). 그러니 "19% 느려진다"를 영구 법칙처럼 들고 다니면 안 됩니다. 그건 한 시점의 측정입니다.

여기까지는 인정합니다. 기계적 검증은 자동화될 것이고, 대체로 자동화되는 편이 낫습니다. 당신의 "검증 능력"이 널 체크 누락을 잡아내는 것이라면, 그것도 함께 감가합니다.

그럼에도 남는 경계가 있습니다. 정확성 검증은 대조할 정답지 를 필요로 합니다. 그 정답지는 어디서 옵니까? 수학과 알고리즘 문제에는 답안지가 있습니다. 당신 회사의 정산 시스템에는 없습니다. 누군가 무엇이 맞는지를 결정해야 합니다.

이 경계가 실재한다는 가장 깨끗한 증거가 DeepMind 팀의 결과입니다 — 외부 피드백 없이 모델이 스스로 답을 고치게 하는 내재적 자기교정 은 정확도를 올리지 못했고, 오히려 떨어뜨리기도 했습니다. 정답 레이블(오라클)을 쥐여 줬을 때만 개선이 나타났습니다. 이 결과는 2023년 모델 기준이고 그 사이 모델은 크게 좋아졌습니다 — 구체적 수치를 오늘에 그대로 적용하면 안 됩니다. 그런데 구조적 논점은 모델 성능의 함수가 아닙니다. 자기 믿음을 자기 믿음으로 검사하는 시스템은, 갖고 있지 않은 정답지를 만들어 낼 수 없습니다.

여기서 정직하게 불확실성을 표시하겠습니다. 저는 이 경계가 어디까지 밀릴지 모릅니다. 만약 모델이 당신의 사업에서 "맞다"가 무엇인지 당신보다 잘 결정하게 된다면, 이 글의 조언은 만료됩니다. 저는 그게 가깝다고 보지 않습니다 — 제약은 지능이 아니라 결과에 대한 접근 이라고 보기 때문입니다. 하지만 "그렇게 보지 않는다"는 증거가 아니라 믿음입니다. 느슨하게 쥐십시오.

제가 걸겠다면 이쪽에 겁니다 — AI가 대부분을 검증하는 세계에서도 그 판정에 책임지는 누군가는 여전히 필요하고, 책임이야말로 직업의 정의 입니다.

마치며

양쪽 극단을 모두 거부합시다.

"개발자는 끝났다"는 틀렸습니다. 묶음 전체가 0으로 재가격됐다고 가정하지만, 실제로는 불균등하게 재가격됐을 뿐입니다. "달라진 건 없다"도 틀렸습니다. 많은 사람이 커리어를 세운 바로 그 항목들이 정확히 싸진 항목이기 때문입니다.

불편한 대목도 남겨 두겠습니다. 이 재가격은 주니어에게 특히 가혹합니다. 감가하는 기술들은 그동안 사다리의 아래 칸 이었기 때문입니다 — 보일러플레이트를 치면서 코드베이스를 익히는 길이 막히고 있습니다. 저는 여기에 깔끔한 답이 없습니다. 그나마 최선은 결과에 더 빨리 닿는 것 입니다. 작더라도 프로덕션에서 무언가를 소유하고, 그것이 깨질 때 호출당하는 자리에 일찍 서는 것.

절상하는 기술들은 하나의 공통 성질을 갖습니다. 전부 결과와의 접촉 을 요구합니다. 검증은 무엇이 터지는지 알아야 하고, 디버깅은 호출을 당해 봐야 하고, 취향은 틀려 봐야 생깁니다. 그래서 이것들은 다운로드할 수 없습니다. 그리고 같은 이유로, 한 번도 호출당해 본 적 없는 모델에게 아직은 학습시키기 어렵습니다.

한 줄로 줄이면 이렇습니다 — 코드를 짜는 값은 떨어졌고, 코드가 맞는지 아는 값은 올랐습니다.