목차05
수정
AI에게 일을 맡기면 결과는 빠르게 나온다.
화면이 생기고, 기능이 붙고, 테스트가 통과했다는 설명도 돌아온다. 다음 작업을 이어가다 보면 프로젝트는 계속 커진다.
그런데 어느 순간 이런 질문을 받으면 멈추게 된다.
“이 기능은 왜 이렇게 동작하나요?”
그 질문에 답하려고 다시 AI를 부른다. 설명을 듣고 나면 이해한 것 같다. 하지만 조금 다른 조건을 물으면 또 설명이 필요하다.
내가 일을 맡긴 걸까. 아니면 내가 판단해야 할 내용까지 함께 넘긴 걸까.
나는 이 문제를 ‘이해의 부채’라는 말로 정리해보고 싶었다.
1. 직접 짜지 않았다는 것이 문제는 아니다
처음에는 내가 코드를 직접 작성하지 않았기 때문에 생긴 문제라고 생각하기 쉽다.
하지만 직접 작성한 코드라고 모든 영향을 이해하는 것은 아니다. 다른 사람이 만든 시스템을 이어받을 때도, 오래전에 정한 이유를 잊었을 때도 비슷한 일이 생긴다.
그러니 사람의 코드와 AI의 코드를 나눠서 볼 문제는 아니다.
내가 이 글에서 말하는 이해의 부채는, 중요한 결정과 동작을 설명하거나 확인할 방법 없이 작업이 쌓여 있는 상태다.
코드뿐만이 아니다. 왜 이 고객을 대상으로 삼았는지 모르는 기획서, 어떤 자료에서 나온 수치인지 모르는 보고서, 무엇을 비교했는지 설명할 수 없는 전략도 여기에 들어간다.
결과물을 가지고 있는 것과, 그 결과물을 믿을 근거가 있는 것은 다르다.
2. 빠르다는 느낌도 확인해야 한다
이 문제를 생각할 때 참고한 자료가 METR의 개발 생산성 연구다.
2025년 공개된 초기 연구에서는, 익숙한 오픈소스 저장소에서 작업하는 개발자 16명이 246개 과제를 수행했다. 그 조건에서는 AI 도구를 사용할 때 작업 시간이 평균 19% 더 길었다. 반면 참가자들은 사용 후에도 자신이 더 빨라졌다고 추정했다.[1]
이 결과를 ‘AI는 개발을 느리게 한다’로 읽으면 안 된다. 대상, 과제, 도구와 측정 시점이 정해진 연구다.
2026년 후속 업데이트에서도 연구진은 더 최근 환경을 측정하는 어려움을 설명했다. AI 없이 작업하려는 참가자가 줄어드는 선택 편향 등으로, 이후의 속도 향상을 신뢰할 만한 하나의 수치로 확정하기 어렵다는 내용이었다.[2]
내가 여기서 가져온 질문은 하나다.
나는 일이 빨라졌다는 느낌을 받고 있는가, 아니면 실제로 끝내는 데 드는 시간이 줄었는가?
작성 시간만 줄고 확인과 재작업이 늘었다면, 그 시간도 함께 봐야 한다. 반대로 실제로 부담이 줄었다면 그것도 인정해야 한다. AI를 의심하기 위해 결과를 낮출 필요는 없다.
3. 그렇다고 모든 코드를 내가 읽어야 할까
나는 그 방향으로 가고 싶지는 않다.
기획하고 설계하고 개발하는 모든 과정을 다시 직접 확인해야만 한다면, 위임의 의미가 너무 작아진다. 특히 비개발자에게 모든 구현을 이해한 뒤에 사용하라고 말하면 결국 개발자가 되라는 요구와 크게 다르지 않다.
내가 남겨야 할 이해와 에이전트에게 맡길 이해를 나눌 필요가 있다.
나는 무엇을 해결하려고 하는지 알아야 한다. 어떤 결과를 원하고, 무엇은 원하지 않는지 설명할 수 있어야 한다. 실제 돈이나 사용자에게 영향을 주는 결정이라면, 어떤 근거로 그 결정을 받아들이는지도 알아야 한다.
반면 기술 선택의 세부 비교, 구현, 테스트 작성과 실행, 오류 분석은 에이전트가 맡을 수 있다. 다만 맡겼다는 이유로 확인 과정까지 없애서는 안 된다.
내가 코드 한 줄씩을 기억하는 대신, 다른 작업자가 이어받아도 확인할 수 있는 설명과 검증 기록이 있어야 한다.
4. 이해를 남기는 방법
저자는 작업을 마칠 때 다음 세 가지를 묻는 방식을 권한다.
무엇이 바뀌었는가. 파일 이름만 나열하지 말고 사용자에게 생기는 차이를 설명하게 한다. 무엇을 요청했고, 실제로 어디까지 구현했는지 분리한다.
무엇으로 확인했는가. 테스트가 있다는 말과 실행했다는 말, 실행이 통과했다는 말은 구분해야 한다. 실행하지 못했다면 그 사실이 남아야 한다. 실제 화면에서 확인해야 하는 문제라면 코드 검사만으로 끝내지 않는다.
아직 무엇을 모르는가. 예외 상황, 운영에서만 확인할 수 있는 조건, 사람이 승인해야 하는 부분을 남긴다. 모르는 부분을 적었다고 작업 전체가 실패한 것은 아니다. 적어두지 않아 다음 사람이 아는 것으로 취급하는 편이 더 곤란하다.
예를 들어 ‘가입 기능 완료’라는 보고보다, 가입·실패·중복 요청을 각각 어떻게 확인했으며 실제 메일 발송은 아직 확인하지 못했다는 보고가 다음 판단에 도움이 된다.
이것은 설명을 길게 쓰라는 뜻이 아니다.
다시 질문해야만 알 수 있는 것을, 다음 작업이 시작되기 전에 남기자는 뜻이다.
완료라는 한마디 대신 남길 설명용 메모.
- 요청한 것
- 사용자가 가입할 수 있게 한다. 원했던 결과와 실제 구현 범위는 나눠 적는다.
- 달라진 동작
- 가입·실패·중복 요청 때 사용자가 무엇을 보게 되는지 설명한다.
- 확인한 방법
- 각 상황을 어떻게 검사했는지, 실제로 실행했는지와 결과를 남긴다.
- 남은 질문
- 실제 메일 발송을 확인하지 못했다면 미확인으로 남긴다. 필요한 승인도 따로 적는다.
5. 내게 필요한 것은 통제가 아니라 위임이다
나는 AI에게 일을 많이 맡기고 싶다. 회사에서 개발과 설계, 마케팅에 활용하며 편리함도 느꼈다.
그렇기에 더 분명하게 나누고 싶다.
반복해서 찾아보고, 만들고, 검사하는 일은 가능한 한 넘긴다. 대신 무엇을 만들 것인지, 어떤 결과를 받아들일 것인지, 어떤 위험은 감수하지 않을 것인지에 대한 판단은 놓지 않는다.
기억해야 할 것을 줄이고 싶은 것이지, 내가 무슨 일을 하는지 모르는 사람이 되고 싶은 것은 아니다.
이해의 부채를 줄인다는 말도 그렇게 쓰고 싶다.
AI를 덜 쓰자는 뜻이 아니다. 맡긴 일이 다음에는 더 잘 이어지도록 만들자는 뜻이다.
출처와 주석
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025-07-10. 해당 실험 조건의 결과이며 모든 개발 업무로 일반화하지 않는다. ↩︎
METR, 후속 생산성 측정 업데이트, 2026-02-24. 2026-09-06 개정 때 함께 확인했다. 연구 결과와 이 글의 개인적인 작업 원칙은 구분한다. ↩︎