AI 코딩 에이전트가 일상 개발 도구로 자리 잡으면서, 겉으로는 잘 드러나지 않는 변화 하나가 진행되고 있다. 예전이라면 반사적으로 내렸을 결정, 즉 "이 부분은 더 이상 손댈 수 없을 만큼 복잡해졌으니 계속 기능을 붙이기 전에 구조를 다시 짜자"는 판단이 점점 사라지고 있다는 것이다. 이는 에이전트가 만들어내는 코드의 품질 문제가 아니다. 경험 많은 엔지니어조차 시스템에서 가장 지저분한 부분을 다시 손보자고 밀어붙이던 습관을 조용히 접고 있다는 데 문제의 핵심이 있다.
모듈화는 취향이 아니라 인간의 한계에 대한 타협이었다
왜 우리는 시스템을 잘게 쪼개 왔는가. 컴퓨터와 달리 사람은 수십 갈래로 분기하고 서로 얽힌 복잡한 시스템 전체를 한 번에 머릿속에 담고 추론할 수 없다. 그래서 개발자들은 유일하게 가능한 방법을 택했다. 각 조각이 한 사람의 머리에 들어올 만큼 시스템을 작은 모듈로 나누고, 그 사이를 이해 가능한 인터페이스로 연결하는 것이다. 모듈화, 캡슐화, 계층화는 미적 취향이 아니라 인간 작업 기억의 크기라는 제약에 대한 타협이었다. 조각이 한 사람의 머리에 담겨야만 사람이 그것을 추론하고, 안전하게 바꾸고, 남의 변경을 리뷰할 수 있기 때문이다.
대개 코드는 처음부터 복잡하지 않다. 요구사항이 단순할 때 깔끔하게 작성되지만, 요구사항이 바뀌면서 새로운 경우를 위한 분기가 하나 붙고, 예외가 하나 더 붙고, 그 예외 위에 또 특수 케이스가 얹힌다. 반복이 충분히 쌓이면 원래 코드가 표현하던 '규칙'은 예외들에 파묻히고, 심하면 규칙은 사라진 채 예외만 남는다. 그리고 어느 순간 개발자는 버그를 쫓아 코드를 따라가다 길을 잃는다. 분기들이 더 이상 머릿속에 그려지는 하나의 그림을 이루지 못하는 그 순간, 그것이 바로 신호였다.
'길을 잃는 감각'이 유지보수를 지탱해 왔다
숙련된 엔지니어는 코드에서 길을 잃으면 멈춰 서서 말했다. 여기 무언가를 더 붙이기 전에, 이해 가능한 상태로 다시 쓰거나 리팩터링해야겠다고. 우아함을 위해서가 아니라 자신과 이후의 모든 사람이 이 코드를 추론하고 안전하게 리뷰할 수 있게 하기 위해서였다. "내가 길을 잃었다, 그러니 리팩터링할 때다"라는 이 반사 신경은 오래 살아남는 시스템을 유지 가능하게 지켜온 가장 중요한 힘 중 하나였고, 그 방아쇠는 인간의 한계, 즉 더 이상 코드를 따라갈 수 없게 된 순간이었다.
사실 이 반사 신경은 AI 이전부터 마감, 로드맵, 그리고 "멀쩡히 돌아가는 걸 왜 다시 쓰느냐"고 묻는 관리자의 압박에 시달려 왔다. 리팩터링은 대체로 가장 먼저 뒤로 밀리는 작업이었고, 시니어들도 예전만큼 강하게 밀어붙이지 못하게 된 지 오래다. 에이전트가 이 약점을 만든 것은 아니다. 다만 에이전트는 그런 압박에도 불구하고 작동하던 마지막 내적 방아쇠, 즉 사람이 직접 길을 잃는 생생한 경험을 제거해 버렸다.
문제는 여기서 시작된다. AI 에이전트는 인간과 같은 방식으로 맥락의 한계에 묶이지 않는다. 뒤엉킨 함수를 읽고, 모든 호출자를 추적하고, 사람이라면 손을 놓았을 난장판을 이해해낸다. 아무도 온전히 이해하지 못하는 코드 안에서도 다음 분기를 정확히 추가하고, 그 다음 것도 붙인다. 단기적으로 이는 분명한 강점이다. 그러나 결정적인 것이 빠졌다. 에이전트는 길을 잃지 않으므로 신호가 발생하지 않는다. "이건 감당이 안 되니 멈추고 리팩터링하자"는 반사 신경 자체가 에이전트에게는 없다. 하니스나 프롬프트, 명시적 리뷰 기준으로 구조를 되묻도록 지시받지 않는 한, 에이전트는 난장판을 무한정 유지하며 분기만 계속 쌓아 올린다. 그 난장판이 에이전트에게는 아무 문제도 아니기 때문이다.
실패 양상은 '나쁜 코드'가 아니라 '사라진 체크포인트'다
실패는 에이전트가 형편없는 코드를 쓴다는 데 있지 않다. 자연스러운 점검 지점이 사라지고, 인간이 코드가 자신의 이해 범위를 벗어났다는 사실조차 눈치채지 못하게 된다는 데 있다. 경보를 울리던 순간, 즉 사람이 길을 잃는 순간이 조용히 루프에서 빠져나갔기 때문에, 어떤 극적인 계기도 없이 서서히 우리는 에이전트라는 중개자 없이는 자기 시스템을 스스로 추론할 수 없는 상태에 도달한다.
이를 순전히 원칙의 문제로만 볼 수도 있지만, 냉정하게 실용적인 이유도 있다. 길을 잃지 않는 에이전트도 난장판에는 대가를 치른다. 코드가 뒤엉켜 서로 얽힐수록 올바른 변경을 위해 읽어야 할 파일과 추적해야 할 분기가 늘고, 매 수정마다 태우는 토큰도 늘어난다. 작고 자기완결적인 모듈로 이뤄진 시스템은 사람에게만 친절한 것이 아니라, 모든 미래 변경의 이해 비용이 낮아 운영이 더 저렴하다. 게다가 관련 로직이 경계가 분명한 하나의 조각에 담기지 않으면 에이전트는 실마리를 놓치고 환각을 일으키기 쉽다. 분기가 실제로 하지 않는 일을 한다고 가정하거나, 세 단계 깊이에 묻힌 예외를 놓치는 식이다. 시스템을 사람 머릿속에 담아 두던 바로 그 모듈화가, 변경을 에이전트가 안정적으로 추론할 수 있는 경계 안에 가둔다.
결국 소스를 잘 정리해 두는 일은 에이전트를 희생시켜 사람에게 베푸는 호의가 아니다. 사람에게 이롭고, 에이전트의 정확도를 높이며, 앞으로 그 코드에 가할 모든 변경의 토큰 비용을 낮춘다. 저자가 강조하는 답은 에이전트를 일부러 무력화하는 것이 아니라, 더 이상 저절로 발생하지 않는 체크포인트를 우리가 의식적으로 되살리는 것이다. 하니스에 모듈이 적정 크기나 분기 복잡도를 넘으면 표시하고, 확장만이 아니라 리팩터링을 제안하며, 변경이 추론하기 어려워질 때 알리도록 지시할 수도 있다. 그러나 최종 책임은 여전히 사람에게 있다. 자기 시스템을 이해해야 하는 것도, 방심하면 그 능력을 잃는 것도 우리 자신이기 때문이다. "에이전트가 여전히 이해할 수 있다"는 것과 "시스템이 건강하다"는 것은 다르다. 길을 잃어 신호를 보내주던 도구가 이제 길을 잃지 않으니, 리팩터링할 때가 됐는지는 우리가 계속 물어야 한다.