에이전트 기반 코딩의 80% 문제: 이해 부채와 개발자의 새로운 역할

핵심 요약

에이전트가 전체 코드의 80% 이상을 대신 쓰는 시대에는 "코드를 더 빨리 쓰는 것"보다 "그 코드의 의미를 끝까지 이해하고 검증하는 것"이 더 큰 문제로 떠오른다.

이 과정에서 이해 부채, 코드 리뷰 병목, 기술 부채 폭증 위험이 커지며, 개발자의 역할은 구현자에서 설계·검증을 주도하는 오케스트레이터로 이동하고 있다.

이 변화를 잘 활용하려면 선언적 사고, 자동 검증 장치, 의도적인 학습 전략을 통해 AI를 "지름길"이 아니라 "경험 가속기"로 사용하는 태도가 필요하다.

80% 문제란 무엇인가

예전에는 "AI가 70%까지 구현해 주고 마지막 30%는 사람이 마무리한다"는 식으로 설명되곤 했다.

이제는 많은 선도 개발자들이 "코드의 80~100%를 에이전트가 쓴다"고 말하지만, 숫자보다 중요한 변화는 문제의 성격이다.

이제 남는 마지막 20%는 단순한 잔손질이 아니라, 요구사항과 설계가 제대로 반영됐는지 확인하고, 보이지 않는 전제와 예외를 다루며, 시스템 전체 일관성을 유지하는 고난도 작업이다.

다시 말해, 구현 자체의 어려움은 줄었지만, "이게 정말 맞는 방향인가?"를 끝까지 책임지는 일이 훨씬 더 어렵고 비싸졌다.

에이전트가 잘못하는 방식: 단순 버그가 아닌 개념적 실패

초기 AI 코딩 도구는 문법 오류나 작은 실수 수준의 문제를 자주 냈지만, 최신 에이전트는 그보다 더 교묘한 문제를 만든다.

대표적인 패턴은 잘못된 전제에서 출발해 전체 기능을 그 전제에 맞게 설계·구현해 버리는 경우다. 처음 이해가 조금 틀렸는데, 그 위에 수많은 파일과 PR이 쌓이면서 나중에는 되돌리기가 어려운 구조적 문제가 된다.

또 다른 문제는 과한 추상화와 구조화다. 함수 하나로 충분한 일을 클래스 계층, 서비스 레이어, 유틸 모듈 등으로 과도하게 쪼개서 1,000줄짜리 코드를 만들고, 겉으로는 "전문적으로 보이는" 복잡한 구조를 생성한다.

여기에 더해 기존 코드를 깨끗이 정리하지 않고, 죽은 코드와 쓰이지 않는 함수, 의미 없는 리팩터링 흔적을 남겨둔 채 새 코드를 덧붙여 전체 코드베이스를 점점 더 난해하게 만든다.

중요한 공통점은, 에이전트가 "당신의 요구를 의심 없이 그대로 따른다"는 점이다. 스스로 질문하지 않고, 모순을 지적하지 않고, 트레이드오프를 드러내지 않는다. 이것이 인간 초년생 개발자보다 위험한 지점이다.

이해 부채: 작성보다 "읽기" 능력이 먼저 무너진다

이 글에서 중요한 개념이 하나 등장한다. 바로 "이해 부채(comprehension debt)"다.

코드를 쓰는 능력과 코드를 읽고 이해하는 능력은 다르다. AI 덕분에 "직접 작성하는 경험"은 줄어들지만, "읽고 검토하는 시간"은 크게 늘어난다.

문제는, 에이전트가 일회에 완성도 높은 코드를 뚝딱 만들어 주면, 사람은 테스트만 통과하는 것을 보고 대충 훑어본 뒤 그대로 병합해 버리기 쉽다는 점이다.

이 과정이 반복되면, 어느 순간 "내가 합친 기능인데 동작 원리를 정확히 설명할 수 없는 코드"가 점점 늘어난다. 표면적으로는 기능이 돌아가고, 에러도 없는데, 머릿속에는 전체 구조가 없는 상태가 된다.

이해 부채는 당장 눈에 잘 보이지 않지만, 나중에 버그를 고치거나 새 기능을 붙일 때 폭발한다. 당시 설계 의도도, 예외 처리 의도도 기억나지 않아 "손대기 두려운 영역"이 늘어나기 때문이다.

생산성 역설: 더 많은 코드, 더 느린 검토

여러 조사에서, AI를 적극 도입한 팀은 PR 수와 코드량이 거의 두 배 가까이 증가했다고 보고한다.

하지만 PR 병합 속도는 빨라지지 않았다. 오히려 코드 리뷰에 걸리는 시간이 크게 늘었고, 평균 PR 크기도 훨씬 커졌다.

즉, "코드 작성"은 싸지고 빨라졌지만, "코드 검토와 이해"는 더 비싸고 느려진 셈이다. 자동차는 빨라졌는데, 도로가 정체된 상황과 비슷하다.

많은 개발자가 "AI 덕분에 주당 10시간 이상 절약했다"고 느끼지만, 조직 전체의 속도는 그대로거나 오히려 떨어지는 경우도 있다. 코드는 쏟아지는데, 이를 소화하고 조직적 일관성을 맞추는 일이 뒤늦게 병목으로 떠오른다.

언제 80/20 모델이 잘 작동하는가

에이전트가 80% 이상을 구현해 주는 방식이 진짜로 빛을 발하는 환경이 있다. 주로 새로 시작하는, 규모가 작고 의존성이 적은 프로젝트다.

개인 사이드 프로젝트나 MVP 단계의 제품, 초기 스타트업의 그린필드(기존 시스템 없이 새로 짓는) 개발에서는 "완벽하지 않아도 빨리 돌려보는 것"이 훨씬 중요하다. 이런 상황에서는 에이전트의 과감한 생성과 빠른 리팩터링이 큰 가치를 준다.

팀 규모가 작을수록, 구성원이 코드베이스 전체를 머릿속에 그려둘 수 있어 이해 부채도 상대적으로 낮게 유지된다. 잘못된 방향으로 갔을 때 코드 전체를 갈아엎는 결정도 비교적 쉽게 내릴 수 있다.

반대로, 복잡한 도메인 규칙과 암묵적 관행이 많은 레거시 시스템에서는 AI가 "모르는 걸 모르는 상태"로 자신감 있게 코드를 덧붙인다. 이때는 80%까지는 빨리 가지만, 남은 20%를 맞추기 위해 훨씬 많은 인력과 시간이 들어간다.

개발자의 양극화: 구현자에서 오케스트레이터로

동일한 도구를 두고도 개발자 집단은 크게 둘로 갈리고 있다.

한쪽은 에이전트를 활용해 하루 수십 개의 PR을 받아내며 "나는 거의 영어로만 프로그래밍한다"고 말하는 그룹이다. 이들은 업무 방식을 근본적으로 바꿔, 스스로를 "라인 코더"가 아니라 "오케스트레이터"로 인식한다.

다른 쪽은 과거의 연장선에서 에디터 자동 완성이나 한두 줄 제안을 받는 수준에 머물며, 전체 워크플로를 AI 중심으로 재설계하지 않는다. 이들에게 AI는 단지 "조금 더 똑똑한 IDE"일 뿐이다.

이 양극화는 단순히 나이 차가 아니라, "역할 인식"의 차이에서 생긴다. 에이전트와 함께 일하는 사람들은 문제 정의, 아키텍처, 품질 기준을 스스로 세우고, 그 기준에 맞게 에이전트를 지휘하는 데 시간을 쓴다.

반면, AI를 빠른 타자기로 쓰는 사람들은 여전히 직접 코딩이 핵심이라고 느끼며, 에이전트가 만든 큰 덩어리의 변화를 다루는 것을 부담스러워한다. 시간이 지날수록 두 그룹의 생산성과 경험치 차이는 더 벌어질 가능성이 크다.

선언적 개발: "어떻게"보다 "무엇을 만족해야 하는지"에 집중하기

에이전트 기반 개발에서 레버리지가 가장 크게 생기는 지점은 사고방식의 전환이다.

예전에는 "이 함수에서 무엇을 하고, 어떤 라이브러리를 쓰고, 어떤 로직을 짜야 하는지"를 세세히 지시하는 방식이었다. 이는 명령형(절차 중심) 접근이다.

이제는 "요구사항, 제약조건, 성공 기준, 반드시 통과해야 하는 테스트와 시나리오"를 정의해 주고, 구현 방법은 에이전트가 탐색하게 하는 선언적 방식이 더 잘 맞는다.

에이전트는 지치지 않고 수십 번의 시도와 수정, 리팩터링을 반복할 수 있다. 이 능력을 활용하려면 "도착점과 평가 기준"을 분명히 주는 것이 중요하다. 예를 들면, 테스트를 먼저 작성하고 "이 테스트가 모두 통과할 때까지 반복하라"고 지시하는 식이다.

다만, 이 전략이 효과를 내기 위해서는 처음에 정의하는 요구사항과 테스트가 제대로 된 것이어야 한다. 잘못된 성공 기준을 주면, 에이전트는 잘못된 방향으로 완벽하게 수렴해 버린다. Garbage in, garbage out이 더 강력해진다.

슬롭칼립스 우려와 품질 관리 전략

누구나 순식간에 수천 줄의 그럴듯한 코드를 만들 수 있게 되면, 저품질 코드가 세상을 덮어버리는 "슬롭칼립스(저품질 폭증)"가 올 것이라는 우려가 나온다.

반대 의견도 있다. 모델 자체가 점점 더 나은 코드 스타일과 정리 방식, 자체 수정 능력을 갖추면서 오히려 전체적인 품질이 개선될 수 있다는 주장이다.

실제로 두 가지가 동시에 일어날 가능성이 크다. "빠르게만 만드는 팀"은 슬롭을 양산하고, "검증과 제약을 잘 거는 팀"은 AI를 이용해 품질까지 끌어올린다.

현실적인 방어 전략은 비교적 분명하다. 새로운 컨텍스트에서 같은 모델로 코드 리뷰를 시켜 스스로의 실수를 잡게 하고, 강력한 CI/CD, 테스트, 린터, 타입 체크 등을 필수로 돌리며, 에이전트에게 맡기는 작업 범위와 권한을 의도적으로 제한하는 것이다.

특히, 아키텍처 수준의 구조 변경이나 핵심 도메인 로직 결정은 여전히 사람이 주도하고, 에이전트는 그 아래의 구현과 반복 작업을 처리하도록 역할을 나누는 것이 안전하다.

효과적인 활용 패턴: 어떻게 써야 "덜 위험하게" 잘 쓰는가

성공적으로 에이전트 기반 개발을 굴리는 팀들의 공통 패턴에는 몇 가지 특징이 있다.

첫째, 작은 제안보다는 전체 기능이나 모듈을 통째로 초안으로 생성하게 하고, 그 결과를 다시 모델과 사람이 차례로 리뷰하며 점점 다듬어 간다. 이때 "새 컨텍스트로 자기 코드 리뷰"를 시키는 전략이 자주 쓰인다.

둘째, 문제 정의와 사양 작성에 시간을 훨씬 많이 쓴다. 요구사항 문서, API 계약, 데이터 흐름, 엣지 케이스를 명확히 적어두고, 이를 프롬프트의 중심으로 삼는다. 개발자는 "어떻게 짤지"가 아니라 "무엇을 만족해야 할지"를 설계하는 데 집중한다.

셋째, 반복해서 발생하는 오류 유형을 발견하면, 그때그때 수동으로 고치지 않고 테스트, 린트 규칙, 정적 분석 등 자동 검증 장치로 승격시킨다. 이후에는 에이전트에게도 이 규칙을 인지시키고, 코드 생성 전에 스스로 점검하게 한다.

넷째, AI를 단지 생산성 도구가 아니라 "학습 파트너"로 활용한다. 이해되지 않는 코드가 나오면 그냥 넘어가지 않고, "이 부분을 단계별로 설명해 달라", "다른 접근법과 비교해 달라"고 요구하며 스스로 개념을 흡수한다.

마지막으로, 아키텍처와 모듈 경계를 더 명확히 설계하고 문서화한다. 큰 그림의 설계는 사람 손에서, 세부 구현과 반복 수정은 에이전트에게 맡기는 구조를 의도적으로 만든다.

스킬 약화 위험과 의도적인 학습 전략

AI를 많이 쓸수록 "손이 줄어들고 머리가 줄어들 수 있다"는 우려는 이미 현실에서 감지되고 있다.

특히 주니어 개발자들 중에는, 거의 모든 과제를 AI에 맡기다 보니 문제를 처음부터 스스로 쪼개고 설계하는 경험이 부족해지고, 시간이 지날수록 자신감이 떨어지는 경우가 보고되고 있다.

이 위험을 줄이려면 "일부러 불편함을 유지하는 구간"을 만들어야 한다. 예를 들어, 중요한 기능은 테스트 코드를 직접 먼저 쓰고, 구현은 AI에 맡기더라도 나중에 테스트를 기준으로 설계 의도를 다시 복기해본다.

또한 일정 비율의 작업은 의도적으로 직접 구현해 보고, 이후에 "만약 에이전트에게 맡겼다면 어떤 코드가 나왔을지"를 비교해 보는 방식도 도움이 된다. 이는 단순 속도 경쟁이 아니라 사고 과정 자체를 점검하는 훈련이 된다.

AI에게 "해결만 시키지 말고", "왜 이런 설계를 택했는지", "어떤 대안이 있었는지"를 설명하게 하는 것도 좋다. 이렇게 하면, 에이전트가 경험으로 압축해 둔 패턴을 인간이 언어로 재획득하는 효과가 생긴다.

인사이트

에이전트가 코드를 잘 쓰는지보다 더 중요한 질문은, "나는 이 코드의 의미와 영향을 충분히 이해하고 있는가?"이다.

코드 생성 능력은 이미 인간을 넘어가는 영역으로 가고 있다. 앞으로 차이를 만드는 것은 코드 양이 아니라 문제 정의 능력, 설계 품질, 검증 체계, 그리고 이해 부채를 의식적으로 관리하는 습관이다.

AI를 거부하는 것도, 무비판적으로 맡기는 것도 둘 다 위험하다. 좋은 전략은 "AI를 통해 더 빨리 경험을 쌓되, 근본적인 이해와 책임은 절대 넘기지 않는 것"이다.

결국 남는 질문은 단순하다. "나는 코드를 좋아하는가, 아니면 제품과 시스템을 만드는 걸 좋아하는가?"

어느 쪽이든 괜찮지만, 에이전트 기반 코딩 환경에서는 후자, 즉 "빌더로서의 정체성"을 가진 사람이 더 큰 레버리지를 얻기 쉽다. 그 사실을 알고, 스스로 어느 쪽에 서고 싶은지 선택하는 것이 지금 시점에서 가장 중요한 의사결정일 수 있다.

출처 및 참고 : The 80% Problem in Agentic Coding - by Addy Osmani