필사 모드: 무엇이 비싸게 남는가 — 생성이 싸질 때 값이 오르는 네 가지

• 도구 목록으로 답하면 그 답은 곧 낡습니다
• 두 축으로 네 칸을 그리면 보이는 것
• 위험한 칸은 오른쪽 위입니다
• 검증 비용을 비싸게 만드는 것들
• 반전 — 비싼 검증을 싸게 만드는 것이 일입니다
• 체감을 근거로 쓰지 않기
• 직접 해보기
• 이어서 읽기
• 참고 자료

도구 목록으로 답하면 그 답은 곧 낡습니다

앞으로 무엇을 준비해야 하느냐는 질문에 가장 흔히 돌아오는 답은 배울 것의 목록입니다. 목록은 읽기 편하고, 편한 만큼 빨리 낡습니다. 5년 전 목록을 지금 꺼내 보면 절반은 이름조차 사라졌고, 남은 절반은 다른 것에 흡수됐습니다.

목록이 낡는 이유는 항목을 잘못 골라서가 아니라 축을 잘못 잡아서입니다. 도구는 축이 될 수 없습니다. 도구는 변수입니다. 필요한 것은 도구가 바뀌어도 유지되는 판별식입니다.

이 시리즈가 쓰는 판별식은 하나입니다. 값이 남는 기술은 검증 비용이 비싼 기술이다. 코드를 쓰는 일은 싸졌지만, 그 코드가 맞는지 판정하는 일과 애초에 그것이 만들 값어치가 있었는지 판정하는 일은 싸지지 않았습니다. 앞으로 아홉 편에서 다룰 능력은 전부 이 문장에서 도출됩니다.

두 축으로 네 칸을 그리면 보이는 것

한 가지 일을 두 개의 비용으로 나눠 봅시다. 결과물을 만드는 데 드는 생성 비용, 그리고 그 결과물이 맞는지 확인하는 데 드는 검증 비용입니다.

왼쪽 위는 형식 변환, 보일러플레이트, 정형화된 이관 작업입니다. 여기에 실력을 쌓아 온 사람은 이미 값이 떨어지는 것을 겪었습니다.

왼쪽 아래가 흥미롭습니다. 만들기는 어려운데 맞았는지 판정하기는 쉬운 일입니다. 정답이 정해진 알고리즘 문제, 컴파일 통과 여부로 갈리는 변환, 벤치마크 점수가 있는 최적화가 여기 있습니다. 판정 기준이 존재하면 시행착오를 기계가 대신 반복할 수 있기 때문에, 이 칸은 생성이 아무리 어려워도 오래 버티지 못합니다. 자동화의 진짜 조건은 문제가 쉬운 것이 아니라 채점이 가능한 것입니다.

오른쪽 아래는 만들기도 어렵고 판정도 어려운 일입니다. 10년 된 시스템의 마이그레이션 경로를 정하는 일, 규제와 계약과 성능이 동시에 걸린 설계를 고르는 일이 여기 있습니다.

위험한 칸은 오른쪽 위입니다

가장 주목할 곳은 오른쪽 위입니다. 만들기는 싸졌는데 판정은 여전히 비싼 칸이고, 오늘 소프트웨어 작업의 상당 부분이 이 칸으로 이사했습니다.

이 칸이 위험한 이유는 결과물이 그럴듯해 보이기 때문입니다. 틀린 결과가 눈에 띄게 틀려 보이면 비용은 작습니다. 문제는 거의 맞는 결과입니다. Stack Overflow가 2025년에 공개한 개발자 설문에서, AI 도구 사용 시 가장 큰 불만으로 "거의 맞지만 정확히는 맞지 않은 해답"을 꼽은 응답이 66퍼센트였습니다. 이어서 45퍼센트가 AI가 만든 코드를 디버깅하는 데 시간이 더 든다고 답했습니다. 같은 조사에서 도구 정확성을 신뢰하지 않는다는 응답이 46퍼센트로, 신뢰한다는 33퍼센트보다 많았습니다.

설문은 체감의 기록이지 성과의 측정이 아닙니다. 그래서 이 숫자를 생산성 결론으로 옮기면 안 됩니다. 다만 한 가지는 분명하게 읽힙니다. 병목이 만드는 쪽에서 판정하는 쪽으로 옮겨갔다는 것을 사용자들이 스스로 보고하고 있다는 사실입니다.

검증 비용을 비싸게 만드는 것들

그러면 무엇이 판정을 비싸게 만드느냐가 다음 질문입니다. 대체로 네 가지입니다.

첫째는 암묵적 맥락입니다. 판정에 필요한 정보가 코드에도 문서에도 없고 사람의 기억과 조직의 관행에만 있을 때, 그 정보를 가진 사람만이 판정할 수 있습니다.

둘째는 지연된 결과입니다. 지금 초록불이어도 6개월 뒤 운영에서 무너지는 설계가 있습니다. 결과가 늦게 오는 일일수록 지금 판정하려면 경험에서 온 예측이 필요합니다.

셋째는 판정 기준의 부재입니다. 랭킹의 품질, 인터페이스의 좋고 나쁨, 모델 출력의 적절함처럼 정답표가 없는 영역에서는 판정 자체를 설계해야 합니다.

넷째는 책임 귀속입니다. 누군가는 이 결정에 이름을 걸어야 하고, 서명은 위임되지 않습니다. 서명하려면 이해해야 하므로, 책임은 이해를 강제하는 장치이기도 합니다.

반전 — 비싼 검증을 싸게 만드는 것이 일입니다

여기까지만 읽으면 결론이 이상해집니다. 검증이 비쌀수록 내 값이 오른다면, 검증을 비싸게 유지하는 것이 이득이라는 말이 되기 때문입니다. 그건 틀렸고, 그 지점에서 이 틀이 실무와 연결됩니다.

엔지니어의 일은 정확히 반대입니다. 비싼 판정을 싼 판정으로 바꾸는 장치를 만드는 것입니다. 사람이 매번 읽어야 알던 것을 타입으로 못 박고, 운영에서 6개월 뒤에 드러나던 것을 배포 시점의 지표로 당겨오고, 정답표가 없던 영역에 대리 지표와 표본 검토 절차를 세웁니다.

그래서 정리하면 이렇습니다. 판정을 수행하는 일은 자동화되고, 판정을 설계하는 일은 남습니다. 좋은 테스트를 짜는 것은 비싸고 그 테스트를 돌리는 것은 공짜인 것과 같은 구조입니다. 이 시리즈에서 다루는 능력은 전부 이 설계 쪽에 있습니다.

체감을 근거로 쓰지 않기

마지막으로 하나 짚어야 할 것이 있습니다. 이 영역에서 자기 체감은 믿을 만한 근거가 아닙니다.

METR이 2025년 7월에 공개한 무작위 대조 실험이 이를 잘 보여 줍니다. 자기 오픈소스 저장소에 익숙한 숙련 개발자 16명이 246개 작업을 수행했고, 작업마다 AI 도구 사용 허용 여부가 무작위로 배정됐습니다. 결과는 도구 사용이 허용된 작업이 19퍼센트 더 오래 걸린 것이었습니다. 참가자들은 실험 전 24퍼센트 빨라질 것이라 예상했고, 실험이 끝난 뒤에도 20퍼센트 빨라졌다고 믿고 있었습니다.

이 결과를 일반화하면 안 됩니다. 연구진 스스로 표본이 16명이고, 참가자가 자기 코드베이스에 매우 익숙했으며, 품질 기준이 엄격한 저장소였고, 도구 숙련이 더 쌓이면 결과가 달라질 수 있다고 밝히고 있습니다. 이 실험이 말해 주는 것은 도구가 나쁘다는 것이 아니라, 빨라졌다는 느낌과 실제로 빨라진 것 사이에 방향이 반대인 간극이 존재할 수 있다는 사실입니다.

그래서 이 시리즈의 조언은 전부 기록으로 확인하라는 단서를 달고 갑니다. 느낌은 가설이고, 가설은 재야 합니다.

직접 해보기

이번 주에 할 수 있는 것 하나만 고른다면 이것입니다. 지난 2주 동안 한 작업을 열 개쯤 적고, 각각을 위 네 칸 중 하나에 넣어 보세요. 넣기 애매한 작업이 있다면 그것이 가장 중요한 신호입니다. 판정 기준을 아직 못 정한 일이라는 뜻이기 때문입니다.

• 엔지니어 스킬 코스 — 리눅스, 네트워크, DB, 쿠버네티스, AI/LLM 트랙을 유닛 단위로 따라가며 자기 위치를 확인할 수 있습니다.
• 사고력 훈련소 — 처음 보는 문제 앞에서 쓸 수 있는 아홉 개의 수를 연습합니다. 판정 기준을 세우는 연습에 가장 가깝습니다.

이 틀이 안 맞는 경우도 적어 둡니다. 사람 수가 적고 실패 비용이 낮은 초기 제품에서는 판정 장치를 먼저 깔다가 제품을 못 내는 쪽이 더 큰 손해입니다. 검증 설계는 걸린 것이 있을 때 값어치가 생깁니다.

이어서 읽기

• 이 블로그의 관련 글: 코드가 어려운 부분이 아니었다는 말이 왜 그렇게 화를 돋우는가

비싸게 남는 기술 시리즈

• 다음 글: 디버깅은 왜 대체가 어려운가 — 배제의 기술과 가설의 문장

참고 자료

• Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR, 2025-07-10 — 16명, 246개 작업의 무작위 대조 실험. 19퍼센트 지연과 체감의 역전이 여기서 나옵니다. 2026-08-15 확인.
• Stack Overflow Developer Survey 2025 — AI — 거의 맞는 해답 66퍼센트, 디버깅 시간 증가 45퍼센트, 정확성 불신 46퍼센트 대 신뢰 33퍼센트. 2026-08-15 확인.
• 네 칸 표와 검증 비용 판별식은 위 자료에 나오는 것이 아니라 이 글에서 정리한 틀입니다.