코딩을 덜 하게 된 우리는 에이전트를 제대로 감독할 수 있을까요?
요즘 이런 말을 자주 듣습니다. 이제 개발자는 코드를 직접 짜기보다 코딩 에이전트를 지휘하고 감독해야 한다고요. 저도 개발자의 역할이 바뀌고 있다는 큰 흐름에는 동의합니다. 다만 여기에는 조심해야 할 역설이 있습니다.
과연 직접 구현을 할 수 없는 개발자가 에이전트를 감독할 수 있을까요?
문법을 빠르게 떠올리고 코드를 입력하는 속도는 조금 느려져도 괜찮습니다. 하지만 요구 사항을 파악하고, 코드의 동작을 예측하고, 실패 원인을 추적하는 능력까지 잃는다면 이야기가 달라집니다. 에이전트가 만든 결과물을 판단할 기반도 함께 사라지기 때문입니다.
실제로 요즘 자신이 올린 PR을 설명하지 못하는 개발자들을 심심치 않게 봅니다. 질문을 하면 AI에게 물어봐야 답할 수 있다고 합니다. 코드를 직접 작성하지 않았을 뿐만 아니라, 많은 경우 읽어보지도 않았기 때문입니다. 본인도 왜 작동하는지 모르는 코드를 동료가 대신 이해해주기 바라는 모양입니다.
에이전트를 감독한다는 것은 단순히 코드가 잘 작성되고 실행되는지 확인하는 일이 아닙니다. 왜 이런 접근을 선택했는지, 어떤 가정을 하고 있는지, 어디에서 실패할 수 있는지 이해하고, 에이전트의 맥락 밖에서 수시로 바뀌는 환경과 제약을 파악하고 통제할 수 있어야 합니다.
이런 감각은 코드를 수동적으로 읽는 것만으로 유지하기 어렵습니다. 직접 코드를 쓰고, 직접 실패하고, 직접 고쳐본 경험 속에서 길러집니다. 아이러니하게도 에이전트를 감독하는 데 가장 필요한 근육이 에이전트에게 구현을 맡기는 과정에서 가장 먼저 약해질 수 있습니다.
컴파일러가 등장했을 때도 어셈블리를 직접 작성하는 능력은 퇴화했습니다. 하지만 아무도 그것을 손실이라고 부르지는 않았죠. 이번도 마찬가지 아니냐고 반문할 수 있습니다.
둘 사이에는 중요한 차이가 있습니다.
컴파일러는 형식 언어로 작성된 명확한 프로그램을 정해진 규칙에 따라 변환합니다. 우리는 생성된 기계어를 매번 직접 읽지 않지만, 소스 코드와 테스트를 통해 프로그램의 의도를 검증합니다. 이해를 포기한 것이 아니라 추상화 계층을 위로 옮긴 것입니다.
컴파일러는 같은 입력에 같은 출력을 냅니다. 우리가 어셈블리를 놓을 수 있었던 건 검증을 포기해서가 아니라, 검증할 필요가 없다는 사실을 수십 년에 걸쳐 확인했기 때문입니다.
생성형 AI는 다릅니다. 불완전한 자연어 요구에서 의도와 구현을 함께 추론합니다. 같은 프롬프트에서 매번 다른 코드가 나온다는 점도 문제지만, 감독자가 애초에 무엇을 만들어야 했는지부터 잘못 이해할 수 있다는 데 더 큰 위험이 있습니다.
따라서 우리가 검증해야 하는 것은 코드의 정확성만이 아닙니다. AI가 어떤 가정을 했는지, 문제를 올바르게 이해했는지, 그 해결책이 시스템 전체와 잘 맞는지까지 확인해야 합니다. 이 판단에는 여전히 사람의 이해가 필요합니다.
물론 사람이 모든 구현 세부를 직접 검토하지 않아도 되도록, 요구 조건을 타입과 계약, 테스트, 형식 명세로 표현하고 도구가 검사하게 하자는 접근도 있습니다. 언젠가는 이런 방식이 검증 부담을 크게 줄여 줄지도 모릅니다.
하지만 무엇을 검증해야 하는지 정의하려면 결국 시스템을 이해해야 합니다. 잘못된 명세를 완벽하게 만족하는 코드는 여전히 잘못된 코드입니다.
이해를 생략하면서 쌓이는 빚을 우리는 인지 부채(cognitive debt)라고 부릅니다. 오늘 내가 생산성을 핑계로 미룬 이해는 눈덩이처럼 불어나 나중에 감당할 수 없는 빚으로 돌아올 수 있습니다.
이 부채가 계속 쌓이면 엔지니어는 단순히 코딩 능력만 잃는 것이 아닙니다. 무엇을 만들고 어떻게 고칠지 판단하는 역할까지 스스로 내주게 됩니다. 역설적으로, AI로 대체될 가능성을 스스로 키우는 것입니다.
코드 리뷰도 단순히 승인과 거부를 결정하는 절차가 아닙니다. 서로의 가정과 맥락을 확인하고, 더 나은 방향을 함께 찾아가는 개발 과정의 일부입니다. 코드를 이해하지 못하면 일의 주도권을 가져가기 어렵습니다. 일의 양은 늘어나는데 정작 본인에게 남는 것은 없습니다.
그렇다고 모든 코드를 반드시 직접 작성해야 한다는 뜻은 아닙니다. 직접 코딩하는 행위 자체가 지켜야 할 성역도 아니고요. 다만 제대로 된 감독을 하려면 구현과 완전히 단절되어서는 안 됩니다. 에이전트가 답을 내놓기 전에 결과를 예측해 보고, 실패했을 때는 원인을 직접 추적해 보고, 선택한 설계와 실패 가능성을 자신의 말로 설명할 수 있어야 합니다.
저는 PR을 올리기 전에 스스로에게 한 가지 질문을 던집니다.
나는 이 코드가 왜 이렇게 만들어졌는지 동료 앞에서 설명할 수 있는가?
설명할 수 없다면 아직 끝난 것이 아닙니다. 테스트가 통과했더라도, 에이전트가 문제가 없다고 말했더라도 마찬가지입니다.
AI에게 구현을 맡기는 것과 판단을 맡기는 것은 본질적으로 다른 일입니다.
전자는 위임이지만, 후자는 포기입니다.
그리고 엔지니어로서 그 포기에 대한 책임 역시 우리의 몫입니다.
This work is licensed under CC BY 4.0
