이 글은 원저자의 허가 하에 The 80% Problem in Agentic Coding 아티클을 한국어로 번역한 글입니다. 약간의 의역 및 오역이 포함될 수 있습니다.
앤드레이 카파시가 이번 주에 한 말 덕분에 많은 생각을 하게 됐습니다.
"저는 80%의 수동 코딩과 20%의 자동완성 및 에이전트 코딩에서, 80%의 에이전트 코딩과 20%의 수정 코딩으로 넘어갔습니다. 이제 대부분 영어로만 프로그래밍하고 있습니다."
이런 전환이 2025년 말 몇 주 만에 일어났습니다. 기존 레거시 앱보단 새로 시작하는 개인 프로젝트에선 확실히 더 빠르게 전환이 이루어질 것이고, AI가 우리를 데려다주는 수준은 1년 전보다 더 올라갔을 거라고 생각합니다. 모델, 스펙, 스킬, MCP, 그리고 우리 워크플로가 나아진 덕분입니다.
최근 클로드 코드를 만든 보리스 체르니도 비슷한 얘기를 했습니다.
"저희 코드는 거의 100%, 클로드 코드와 오퍼스 4.5로 작성됩니다. 저 개인적으로는 2개월 넘게 100% 그렇게 개발했고, 작은 수정도 직접 하지 않습니다. 어제 PR 22개, 그저께 27개를 올렸는데, 전부 클로드가 쓴 겁니다. 몇 달 안에 업계 대부분도 비슷한 수치를 보게 될 것 같아요. 그 전환이 얼마나 빨리 이루어지는 정도의 차이일 뿐입니다."
저는 예전에 "70% 문제"에 대해 쓴 적이 있습니다. AI 코딩이 70%를 차지하고, 마지막 30% 구간만 사람이 채우는 구도에 대한 내용이었습니다. 하지만 문제의 틀이 바뀌고 있는 것 같습니다. AI가 차지하는 숫자는 80% 혹은 그 이상이 될 수 있지만, 그것보단 문제 자체가 크게 달라졌습니다.
아르민 로나허의 개발자 5,000명을 대상으로 한 설문이 제 가설을 뒷받침합니다. 답변자 44%가 직접 작성하는 코드는 10% 미만에 불과하며, 그 외 26%는 10~50% 정도를 직접 작성한다고 합니다. 한계선을 넘어버린 것입니다. 그런데 에이전트 만능 담론에서 놓치고 있는 게 있습니다. 문제는 사라진 것이 아니라 옮겨갔을 뿐이고, 어떤 건 더 나빠졌다는 사실입니다.
한 가지 짚어보자면, 새 사이드 프로젝트에서는 80% 이상 에이전트 코딩으로 넘어가는 걸 확실히 느꼈습니다. 하지만 대형·기존 앱, 특히 팀 프로젝트의 상황은 많이 다릅니다. 기대치도 다를 뿐더러, 에이전트 코딩으로의 전환은 앞으로 우리가 갈 방향의 맛보기일 뿐입니다.
실수의 형태가 바뀌었습니다
AI 오류는 문법 오류에서 개념 오류로 옮겨갔습니다. 시간에 쫓기는 주니어 개발자가 할 법한 실수입니다.
카파시가 여전히 발생하는 문제들을 정리했습니다.
"AI 모델이 당신을 대신해 잘못된 가정을 세우고 확인 절차 없이 그대로 밀고 나갑니다. 혼란이 있어도 정리하지 않고, 애매한 점은 묻지 않고, 불일치를 드러내지 않고, 트레이드오프를 제시하지 않고, 반박해야 할 때도 반박하지 않습니다. 여전히 과하게 우리의 편을 들고 있습니다."
가정 전파(Assumption propagation): 모델이 초반에 잘못 이해한 전제 위에 전체 기능을 쌓습니다. PR 다섯 개쯤 들어가고 아키텍처가 굳어져서야 개발자가 눈치챕니다. 일종의 두 걸음 뒤로 가는 패턴입니다.
추상화 비대화(Abstraction bloat): 에이전트에게 제약을 주지 않으면 끝없이 과하게 복잡하게 만들 수도 있습니다. 100줄이면 충분한 코드를 1,000줄 짜리로 만들고, 함수 하나면 될 곳에 클래스 계층을 늘어 놓습니다. 적극적으로 "그냥 이렇게만 하면 안 돼?"라고 말해야 합니다. 에이전트는 항상 "물론이죠!"라고 답하고 바로 단순화 작업을 진행합니다. 유지보수성보다는 다 갖춘 것처럼 보이게 하는 작업에 최적화되어 있습니다.
죽은 코드의 축적(Dead code accumulation): 스스로 정리를 하지 않습니다. 예전 구현이 그대로 남기도 하고, 주석이 부수 효과로 사라지기도 하고, 잘 이해하지 못한 코드도 작업 범위에 가깝다는 이유로 수정해 버립니다.
아부성 동의(Sycophantic agreement): 반박을 잘 하지 않습니다. "정말 그런가요?", "다른 접근도 고려해 보셨나요?" 같은 말은 하지 않습니다. 여러분의 설명이 불완전하거나 모순돼 있어도 그저 열심히 실행할 뿐입니다.
무엇을 경계해야 할지 안다면 스킬과 같은 방법으로 문제를 어느 정도 완화할 수 있습니다.
시스템 프롬프트, CLAUDE.md 지시, 플랜 모드만으로 문제가 다 고쳐지는 건 아닙니다. 수정해야 할 버그가 아니라, 시스템이 동작하는 방식 자체에서 기인하는 경우가 있습니다.
에이전트는 입력받은 전제에 의문을 품기보단, 일관되게 출력하도록 최적화되어 있습니다.
저도 팀에서 비슷한 문제를 본 적이 있습니다. 리뷰할 땐 멀쩡해 보이던 코드가, 세 커밋 뒤에 누군가 인접 시스템을 건드리면 깨져버리는 경우였습니다.
데이터 관점에서 보자면, 최근 설문조사에서는 이른바 "검증 병목" 현상이 나타났다고 합니다. 개발자의 48%만이 AI 보조 코드를 커밋 전에 반드시 확인하고 있으며, 38%는 사람이 쓴 코드보다 AI가 만든 코드를 리뷰하는 게 더 힘들다고 답했습니다. 우리는 더 빠르게 "정답처럼 보이는 코드"를 만들어 내고 있지만, 동시에 기술 부채도 더 빠르게 쌓고 있을지 모릅니다.
이해 부채 - 우리가 따로 세지 않는 숨은 비용
코드 생성과 판별은 서로 다른 인지 능력입니다. 코드를 작성하는 능력이 퇴화하더라도, 리뷰하는 능력은 비교적 유지될 수 있습니다. 하지만 "리뷰"가 "형식적 승인"으로 변모하기도 합니다.
제레미 트웨이가 이런 현상을 "이해 부채" 라는 용어로 정확하게 표현했습니다. LLM이 한 번에 그럴듯하게 동작하는 코드를 만들면 그냥 넘어가고 싶어지는 유혹은 꽤 큽니다. 문제는 그다음입니다. 에이전트는 지치지 않습니다. 본인의 확신을 잃지 않고 구현 위에 구현을 쌓아 올립니다. 코드는 그럴듯해 보이고, 테스트는 통과합니다(또는 그렇게 보입니다). 출시 압박이 있는 우리는 그냥 다음 단계로 넘어가게 됩니다.
그렇게 시간이 지나면서 개발자는 코드베이스를 점점 덜 이해하지 못하게 될 수 있습니다.
저도 지난주에 이런 경험을 했습니다. 클로드가 제가 며칠 미뤄두던 기능을 구현해줬습니다. 테스트는 통과했고, 대충 훑고 고개 끄덕인 다음 병합했습니다. 그리고 사흘 뒤, 저는 동작 방식을 설명할 수 없었습니다.
요코 리는 이 중독 루프를 잘 포착했습니다.
"에이전트가 대단한 기능을 구현해 줬는데 딱 10%쯤 틀려 있습니다. '5분만 더 프롬프트를 다듬으면 고칠 수 있겠다' 생각하지만, 5시간이 흘러 버립니다."
우리는 항상 거의 다 온 것처럼 느낍니다. 마지막 10%는 손에 잡힐 듯 가깝게 느껴집니다. 프롬프트 한 번만 더 다듬고 반복하면 될 것 같습니다.
누군가 이렇게 말했습니다.
"저는 대부분의 시간을 에이전트를 돌보는 데 씁니다. 거의 만능 비서를 쓰는 듯한 느낌은 드는데, 일일이 관리하는 비용도 만만치 않습니다. 이제 코딩을 하는 게 아니라 감독하고 있습니다. 지켜보고, 방향 잡아 주고. 또 다른 종류의 피로감이 듭니다."
위험은 바로 이 지점에 있습니다. 직접 다시 짤 수 없는 코드를 리뷰하는 건 너무 쉽습니다. "읽는" 능력이 에이전트의 "출력" 능력만큼 커지지 않으면, 더 이상 엔지니어링이 아닙니다. 코드가 잘 구현되길 바라고 있을 뿐입니다.
생산성 역설 - 더 많은 코드, 비슷한 처리량
에이전트 도입이 많은 팀에서는 개인 산출량이 98% 늘었지만, PR 리뷰 시간 또한 최대 91%까지 늘었습니다.
Faros AI와 구글 DORA 리포트 데이터가 흥미로운 결과를 보여줍니다.
- 에이전트 도입이 높은 팀은 머지한 PR이 98% 더 많았습니다.
- 동시에 해당 팀들의 리뷰 시간은 91%까지 늘어났습니다.
- PR 크기는 평균 154% 증가했습니다.
- 코드 리뷰가 새로운 병목이 됐습니다.
아틀라시안 2025 설문은 이 역설을 뚜렷하게 보여 줍니다. AI를 사용하는 개발자 99%가 주당 10시간 이상 절약했다고 했는데, 그럼에도 대부분은 업무량이 줄었다고 느끼지 않았습니다. 코드 작성에서 아낀 시간은 조직적 마찰로 소모됐습니다. 잦은 컨텍스트 스위칭, 더 큰 협업 비용, 더 많은 변경 사항을 관리하는 부담이 아낀 시간을 잠식해 버렸습니다.
우리는 더 빠른 차를 얻었지만, 도로는 더 막혀가고 있습니다.
더 많은 코드가 작성되는 동시에 그것을 검토하는 데 더 많은 시간을 쓰고 있습니다. 병목은 사라지지 않았습니다. 위치만 옮겨갔을 뿐입니다. 어떤 자원이 더 저렴해지면(여기선 코드 생성의 비용), 소비는 효율 개선 속도보다 더 빠르게 증가하고, 결국 전체 자원 사용량은 오히려 늘어납니다.
우리는 코드를 덜 쓰고 있는 게 아닙니다. 훨씬 더 많은 코드를 쓰고 있고, 여전히 누군가는 그 대부분을 이해해야 합니다. 물론, AI가 그 역할까지 대신할 수 있다면 더 이상 그럴 필요가 없다고 느끼는 개발자들도 존재합니다.
8:2 비율이 통하는 경우
새로 시작하는 프로젝트라면, 에이전트 코딩이 8할을 차지해도 괜찮습니다. 전체 스택을 직접 통제할 수 있고, 팀 규모가 작아 이해 부채가 관리 가능한 수준에 머물기 때문입니다.
실제로 이런 경우에선 잘 맞습니다.
- 전부 직접 통제하는 개인 프로젝트
- "충분히 괜찮은 정도"가 진짜 충분한 MVP
- 레거시 제약 없는 스타트업
- 이해 부채가 감당 가능할 만큼 작은 팀
이런 환경에서는 에이전트의 약점이 치명적이지 않습니다. 빠르게 스캐폴딩하고, 과감히 리팩터링하고, 정치적 마찰 없이 코드를 버릴 수 있습니다. 가끔의 잘못된 판단보단 빠르게 반복하는 게 더 큰 가치를 가집니다.
하지만 복잡한 로직이 얽혀 있고, 오래된 코드베이스에서는 그렇지 않습니다. 에이전트는 자기가 무엇을 모르는지 모릅니다. 문서화되지 않은 규칙을 직관적으로 파악하지 못합니다. 맥락 이해도가 낮을수록 자신감은 오히려 더 커집니다.
누군가 제가 살짝 돌려 말하던 걸 정확히 짚었습니다. 처음 90%는 쉬운데, 마지막 10%가 오래 걸릴 수 있습니다. 90% 정확도는 임무에 치명적이지 않은 부분에는 충분할 순 있지만 정말 중요한 부분에는 한참 모자랍니다. 자율주행차는 잘 달리다가도 가끔 잘못 동작하기 때문에 L2는 어디에나 있지만 L4는 아직 어려운 것입니다.
비개발자에게는 벽이 낮지만 여전히 있습니다. AI 스튜디오, v0, 볼트 같은 도구로 스케치를 곧바로 동작하는 프로토타입으로 만들 수 있습니다. 하지만 그 프로토타입을 실제 사용자 데이터를 스케일로 다룬다거나, 보안과 규정을 맞추는 등의 실제 운영 환경에서 동작시키려면 여전히 엔지니어링 기본기가 필요합니다. AI는 MVP의 80% 지점까지 빠르게 데려다줍니다. 마지막 20%는 인내, 깊이 있는 학습, 또는 숙련된 엔지니어가 필요합니다.
서로 다른 두 집단
채택 곡선은 부드럽지 않습니다. 어느 순간 임계점을 넘어선 사람들과, 그렇지 않은 사람들 사이의 분리가 명확히 있습니다. 초기 적응자와 나머지 사이의 격차는 오히려 벌어지고 있습니다.
아르민의 설문조사는 단순한 채택률 숫자가 가리는 현실을 드러냈습니다. 개발자의 44%는 여전히 코드의 90% 이상을 직접 작성한다고 답했습니다. 이는 종 모양 곡선이라기보단 양봉 분포에 가깝습니다. 한쪽에는 카파시와 클로드 코드 팀처럼, 하루에도 수십 개의 PR을 배포하며 코드의 100%를 AI로 작성하고, 이전보다 훨씬 빠르게 반복하는 사람들이 있습니다. 다른 한쪽에는 대다수의 개발자들이 있습니다. 코파일럿 스타일의 도구를 점진적으로 도입하고는 있지만, 워크플로 자체를 근본적으로 바꾸지는 않은 상태입니다.
세대 차이도 담론 속에서 보입니다. 젊은 개발자들은 워크플로를 급진적으로 바꾸는 데 더 개방적인 경향이 있습니다.
나이가 더 많은 개발자들은 더 회의적입니다. 도구를 못 써서가 아니라, 일시적인 생산성 상승과 지속 가능한 실천을 구분할 만큼 많은 사이클을 겪어왔기 때문입니다. 어쩌면 둘 다 맞을지도 모릅니다.
스택 오버플로 2025 설문에 따르면, "생산성이 크게 향상되었다"고 답한 사람은 16%에 불과했습니다. 절반은 소폭의 개선만을 경험했다고 답했습니다. 불만 사항은 "AI 솔루션이 거의 맞지만, 완전히 맞지는 않음"(66%), “AI 코드 디버깅이 직접 쓰는 것보다 오래 걸림”(45%)순으로 답변했습니다.
2026년에 잘 적응한 엔지니어들은 단순히 더 좋은 도구를 쓰는 사람들이 아닙니다. 역할을 구현자에서 오케스트레이터로 재정의하고, 명령형이 아니라 선언형으로 생각하는 법을 익힌 것입니다. 이제 자신의 일이 한 줄 한 줄 코드를 작성하는 것이 아니라, 아키텍처를 감독하고 품질을 통제하는 것임을 받아들였습니다.
반면 어려움을 겪는 사람들은 AI를 더 빠른 타자기처럼 사용하려 할 뿐, 워크플로를 바꾸지 않았습니다. 에이전트의 접근 방식을 활용하기보다, 그 방식과 싸우고 있습니다. 효과적으로 프롬프트를 작성하는 법을 배우는 데 충분히 투자하지 않았습니다. 하지만 이제는 과거에 좋은 문서나 설계 명세를 작성하는 것만큼이나 중요한 역량이 되었습니다.
여기에는 불편한 진실이 있습니다.
에이전트를 오케스트레이션하는 일은 업무를 위임하고, 결과를 검토하고, 일이 엇나가면 방향을 재설정하는 일입니다. 관리자와 매우 닮아 있습니다. 관리하고 싶지 않아서 엔지니어가 된 사람이라면, 이런 변화는 배신처럼 느껴질 수 있습니다. 역할이 당신 모르게 바뀌어버린 것이니까요.
격차는 계속 벌어지고 있는 듯합니다. 이 도구들과 함께 일하는 법을 터득한 사람들은 제가 따라가기 벅찰 정도로 빠르게 결과물을 내고 있습니다. 나머지는… 아직 적응하는 중입니다.
이 분리는 누군가에게는 불편할 수 있습니다. 저는 항상 스스로를 빌더라고 생각해왔지만, 동시에 프로그래밍 자체도 즐겼습니다. 이 두 길이 이제 갈라져서 하나를 선택해야 하는 것처럼 느껴진다면, 그것은 지나치게 단순화된 해석일지도 모릅니다. 복잡한 현실을 이분법으로 밀어 넣는 것 같으니까요. 댓글 중 누군가가 이렇게 말했습니다. '두 관점 모두 타당하다. 단지 서로 다른 두뇌 회로를 가졌을 뿐이다. 어느 쪽도 틀리지 않았다.'
명령형에서 선언형으로 - 진짜 레버리지
AI에게 무엇을 할지 일일이 지시하지 마세요. 대신 성공 기준을 주고 기준을 만족할 때까지 반복시키세요. 마법은 에이전트의 코드 "작성"에 있는 게 아니라, 여러분이 정한 조건을 만족할 때까지 반복하는 데 있습니다.
카파시의 관찰은 이 핵심을 정확히 짚습니다.
"LLM은 특정 목표를 만족할 때까지 반복하는 데 매우 뛰어납니다. "인공지능의 마법"은 바로 여기서 나옵니다."
명령형에서 선언형 개발으로의 전환
- 기존 모델(명령형): “X를 받아 Y를 반환하는 함수를 작성해. 이 라이브러리 사용하고. 이 엣지 케이스 처리해. 그리고…”
- 새로운 모델(선언형): "요구사항은 이거고, 통과해야 할 테스트는 이거고, 성공 기준은 이거야. 방법은 네가 찾아."
에이전트는 좌절하지 않기 때문에 새로운 모델이 통합니다. 사람이라면 인내심이 바닥나겠지만 에이전트는 계속 시도합니다. 끊임없이 반복합니다. 목적지를 명확히 지정하면, 30번 실패하더라도 결국 거기에 도달합니다.
잘 작동하는 패턴
- 먼저 테스트를 쓰고, 에이전트가 통과할 때까지 반복시킵니다.
- MCP로 브라우저에 붙여서 동작을 시각적으로 검증하게 합니다.
- 단순하지만 올바른 버전을 먼저 구현한 뒤, 정확성을 유지하면서 최적화합니다.
- API 규격을 정의하고, 스펙에 맞게 구현하게 합니다.
단, 이 모든 것은 성공 기준이 실제로 올바를 때만 통합니다. 입력이 잘못되면 출력도 잘못됩니다. 그리고 모델의 능력이 높아질수록, 그 잘못은 더 크게 증폭됩니다.
이 접근으로 성공하는 개발자는 시간의 70%를 문제 정의와 검증 전략에 쓰고, 30%만 실행에 씁니다. 비율이 기존 개발 패턴과 뒤집혔지만, 총 시간은 크게 줄었습니다.
슬로파칼립스는 올 것인가
역자주*: 슬로파칼립스(slopacolypse)란 slop(엉성한 결과물)과 apocalypse(대재앙)를 합친 단어로, AI가 만들어 내는 질 낮은 콘텐츠가 넘쳐나는 사태를 의미합니다.
누구나 몇 분 만에 수천 줄을 생성할 수 있게 되면, "이건 필요 없어"라고 말할 수 있는 능력이 더 가치 있게 됩니다.
카파시는 이렇게 경고했습니다.
"2026년을 GitHub, 서브스택, arxiv, X/인스타, 전반적인 디지털 미디어 전반에 걸친 슬로파칼립스의 해가 될 것에 대비하고 있습니다."
걱정은 단순합니다. 누구나 그럴듯해 보이는 코드, 콘텐츠, 논문, 포스트를 마음대로 대량 생성할 수 있는 세상에서 신호 대비 잡음을 어떻게 유지할 수 있을까?
보리스 체르니는 반론을 제기합니다. “저는 슬로파칼립스는 오지 않을 것으로 예상합니다. 모델이 점점 덜 엉성한 코드를 쓰고 기존 코드 이슈도 잘 수정하게 될 겁니다. 그동안에는 모델이 새 컨텍스트 창에서 자신의 코드를 리뷰하게 하는 게 도움이 됩니다.”
둘 다 맞을 수 있습니다. 엉성한 결과물을 대량으로 생산하는 능력은 전례 없이 커졌고, 이를 방지하는 도구도 나오고 있습니다. 문제는 어느 쪽이 더 빨리 확장되느냐입니다.
슬로파칼립스는 속도를 생산성으로 착각하는 사람들에 의해 가속될 것입니다. 에이전트는 방향 감각이 없는 마라톤 러너와 같습니다. 방향을 주지 않으면, 벽을 향해 10마일을 전력 질주할 수도 있습니다. 필요한 지점에서 "코드 액션"을 감독하지 않으면 그렇게 됩니다.
이를 잘 처리하는 팀들은
- 새로운 컨텍스트에서의 코드 리뷰: 같은 모델에게 자기 코드를 비판하게 하는 것이 어색하게 느껴질 수 있습니다 하지만 효과는 있습니다. 깨끗한 상태에서 다시 읽게 하면, 스스로의 실수를 꽤 잘 찾아냅니다.
- 모든 단계에서의 자동 검증: CI/CD, 린터, 타입 체커, 테스트를 가드레일로 사용합니다.
- 에이전트 자율성에 대한 의도적인 제약: 작업 범위를 한정하고, 성공 기준을 명확히 합니다.
- 중요한 결정에 사람이 반드시 개입하는 구조: 구조의 결정은 여전히 사람이 중심에 있어야 합니다.
모델이 발전함에 따라, 카파시가 말한 코드 품질 문제, 과한 복잡화, 추상화 비대, 죽은 코드 축적의 문제는 같이 나아집니다. 하지만 완전히 사라지지는 않습니다. 그 문제들은 단순한 버그가 아니라, 시스템이 문제에 접근하는 방식에서 자연스럽게 발생하기 때문입니다.
실제로 통하는 실전 패턴
미래는 거시적 관점에 대한 일관된 정신 모델을 유지하면서, 미시적 전술 작업은 에이전트에게 맡길 수 있는 사람들이 쟁취하게 될 것입니다.
지난 1년간 팀들이 적응하는 모습을 지켜보며, 효과적인 패턴들이 점점 분명해졌습니다.
1. 에이전트 우선 초안과 짧은 반복 루프
AI를 단발성 제안 도구로 쓰지 마세요. 전체 초안을 생성하게 한 뒤, 그 위에서 다듬으세요. 클로드 코드 팀은 모델이 작성한 코드를 새로운 컨텍스트 창에서 스스로 리뷰하게 합니다. 이렇게 하면 사람이 리뷰하기 전에 상당수의 문제를 걸러낼 수 있습니다.
2. 선언형 소통
노력의 70%는 문제 정의에, 30%는 실행에 씁니다. 포괄적인 명세를 작성하고, 명확한 성공 기준를 정의하고, 테스트 케이스를 미리 제공하세요. 에이전트에게 방법을 지시하지 말고, 목표를 안내하세요.
3. 자동 검증
같은 종류의 실수를 반복해서 고치고 있다면, 미리 테스트나 린트 규칙을 작성하세요. 에이전트가 코드를 설명하고 잠재 문제를 표시하게 한 뒤 사람이 리뷰해야 합니다.
4. 단순 생산 집착이 아닌, 의도적인 학습
이미 여러 번 들었겠지만, AI를 지름길이 아니라 학습 도구로 사용하세요. 에이전트가 작성한 코드 중 이해되지 않는 부분이 있다면, 그건 더 깊이 파고들어야 한다는 신호입니다. AI가 생성한 코드를 멘토의 코드처럼 대하세요. 그저 배포하기 위해서가 아니라 배우기 위해 리뷰하세요.
5. 아키텍처 위생
더 강한 모듈화, 더 명확한 API 경계, 프롬프트에 포함시킬 잘 문서화된 스타일 가이드, 구현 전에 제공할 고수준 아키텍처 설명이 필요합니다. 기획 단계가 늘고, 코딩 단계는 줄고, 리뷰 단계는 문법이 아니라 설계 중심으로 이동합니다.
잘 하는 개발자는 코드를 가장 많이 생성하는 사람이 아니라, 어떤 코드를 언제 생성할지, 출력을 언제 의심할지, 키보드에서 손을 떼도 이해력을 유지할 줄 아는 사람입니다.
불편한 진실 - 스킬 개발에 대하여
여러분의 "읽는" 능력이 에이전트의 "출력" 능력만큼 성장하지 않으면, 더 이상 엔지니어링을 하는 게 아닙니다. 형식적으로 승인하고 있을 뿐입니다.
"저한텐 끓는 개구리 같았어요. ChatGPT에 더 많이 복붙하기 시작했고, 그다음 IDE 프롬프팅이 늘었고, 그다음 에이전트 도구를 쓰게 됐습니다. 어느새 손으로 코딩을 거의 안 하고 있더라고요. 전환이 너무 점진적이라 이미 그 지점에 도달하기 전까지 눈치채지 못했습니다.” [HN]
에이전트를 과도하게 쓰는 사용자에게 기술 퇴화의 초기 징후가 나타나고 있습니다. 모든 걸 AI에 의존하는 주니어 개발자들은 시간이 지나면서 문제 해결에 대한 확신이 줄었다고 보고합니다. 이는 일종의 구글 효과가 코딩에 적용된 것입니다. 계속 아웃소싱하면 뇌는 저장하지 않습니다.
이 문제의 해답은 알 수 없지만, 저는 이런 걸 해보고 있습니다.
- TDD(테스트 주도 개발): AI가 구현하게 하기 전에 테스트(또는 테스트 케이스)를 쓰거나 생각합니다.
- 시니어와 페어링: AI 제안을 실시간으로 논의해서 의사결정 과정을 배웁니다.
- 설명 요청: AI가 해결책만 만들지 말고 접근을 정당화하게 합니다.
- 번갈아 하기: 감각을 유지하기 위해 일부 기능은 직접 구현합니다.
위험은 분명합니다. 직접 다시 짤 수 없는 코드를 리뷰하는 건 위험할 정도로 쉽습니다. 그 지점에 도달하면, 여러분은 성장을 제한하는 방식으로 도구에 의존하게 됩니다.
장기적으로 잘 나갈 엔지니어는 AI로 경험을 빨리 쌓되, 건너뛰지는 않는 사람일 것입니다. 기초를 유지하면서 AI로 더 넓은 영역을 더 빨리 탐색합니다.
우리는 지금 어디에 서 있는가
70%에서 80%로의 전환은 단순히 숫자의 문제가 아닙니다. 프로토타입과 운영 환경의 소프트웨어 사이의 간극에 관한 이야기입니다. 그 간극은 좁아지고 있지만, 아직 사라지지는 않았습니다.
카파시가 핵심적인 질문을 던집니다.
"‘10X 엔지니어’는 어떻게 될까? 평균과 최고 엔지니어 사이의 생산성 격차는? LLM을 장착한 제너럴리스트가 점점 전문가를 능가하게 될까?"
이 질문들이 앞으로 몇 년을 정의할 것입니다.
한 가지는 확실합니다. 2025년 말 초기 적응자들 사이에서 AI가 코드의 80%를 작성했습니다. 여러분도 이에 비해 비율이 훨씬 낮더라도, 1년 전보다는 높을 가능성이 큽니다. 그래서 결과에 대한 책임, 품질 기준 유지, 테스트가 실제로 동작을 검증하는지 확인하는 등의 인간의 역할에 더 큰 책임을 부여합니다.
위험한 건 에이전트가 실패하는 게 아닙니다. 오히려 잘못된 방향으로 너무 확신에 차서, 여러분이 방향을 확인하지 않게 되는 데에 있습니다.
DORA 2025 리포트가 현실을 명확히 합니다. AI는 개발 프로세스를 증폭기처럼 작동시킵니다. 좋은 프로세스는 더 좋아지고(고성과 팀은 55~70% 더 빠르게 전달합니다), 나쁜 프로세스는 더 나빠집니다(전례 없이 빠르게 부채가 쌓입니다). 만능 해결책은 없습니다.
카파시의 마지막 관찰이 가장 공감됩니다.
“에이전트와 함께 프로그래밍 하면 더 재밌을 거라고 예상 못 했어요. 빈칸 채우는 잡무가 많이 사라지고 창의적인 부분만 남아서 더 재밌습니다. 막히는 느낌도 덜하고, 함께 손잡고 조금이라도 진전을 만들 방법이 있다는 용기를 느낍니다."
그는 또 이렇게도 말합니다.
"LLM 코딩은 코딩 자체를 좋아한 사람과 만드는 걸 좋아한 사람으로 엔지니어를 나눌 겁니다."
앞으로의 방향에 대한 예측 중 가장 통찰력 있는 예측일지도 모릅니다.
수공예와 명상 같이 코드 쓰는 행위 자체를 이 전환이 상실처럼 느껴질 수 있습니다. 하지만 만드는 걸 좋아하고 코드가 수단이었던 사람에게는 해방처럼 느껴질 것입니다.
어느 쪽도 틀린 건 아닙니다. 하지만 요즘의 도구는 후자에 맞춰 최적화되고 있습니다.
회의론자에게(회의적인 건 맞다)
생산성에 대한 주장들은 종종 과장되어 있습니다. AI는 여전히 유능한 주니어 개발자라면 하지 않을 실수를 합니다. 이해 부채는 실제로 존재하며, 아직 충분히 이해되지도 않았습니다. 슬로파칼립스의 위험도 현실적입니다.
그럼에도 전환은 이뤄지고 있음은 분명합니다. 카파시가 이제 직접 거의 코드를 쓰지 않는다고 했고, 클로드 코드 팀이 100% AI 작성 코드로 매일 20개 이상 PR 올리고 있다면, 과장으로 치부할 단계는 지났습니다.
소프트웨어 엔지니어로서 우리 정체성은 "코드를 쓸 수 있는 사람"이 아니라 "소프트웨어로 문제를 해결할 수 있는 사람"이었습니다.
AI가 엔지니어를 대체하는 게 아닙니다. 좋든 나쁘든 증폭하고 있을 뿐입니다.
제 조언은 이렇습니다. 도구는 받아들이되, 결과의 책임은 스스로 지세요. AI를 학습을 가속하는 도구로 사용하되, 학습을 건너뛰는 수단으로 쓰지 마세요. 그리고 그 어느 때보다 중요한 기본기에 집중하세요. 견고한 아키텍처, 읽기 쉬운 코드, 꼼꼼한 테스트, 사려 깊은 UX 등 이것들은 여전히 중요합니다. 어쩌면 구현이 더 이상 병목이 아닌 지금, 오히려 더 중요해졌을지도 모릅니다.
이게 어디로 향할지는 저도 모릅니다. 코딩을 좋아한 사람과 만드는 걸 좋아한 사람으로 나뉠 거라는 카파시 말이 맞을지도 모릅니다. 우리는 그저 PR 하나씩 쌓아가면서 개방된 공간에서 이 변화를 직접 느끼고 있습니다.
