AI가 코드를 써도 손을 떼면 판단이 무뎌진다

AI가 코드를 많이 쓰기 시작하면, 사람의 일은 코드를 치는 것보다 공장을 돌리는 쪽으로 옮겨가. 프롬프트와 지식 베이스로 방향을 잡고, 테스트와 린트와 타입 시스템으로 결과를 막아 세우는 일 말이야.¹

그럼 이런 질문이 생겨. 공장이 잘 돌아가면, 사람은 코드에서 손을 떼도 될까?

이 글이 말하는 답은 아니야. 코드를 직접 쓰는 일은 생산량 때문이 아니라 판단력 때문에 남는다. 에이전트가 만든 diff를 읽는 것과, 내가 직접 코드를 지우고 돌려보는 것은 시스템을 이해하는 깊이가 다르다.

공장을 돌리는 일은 늘었다

소프트웨어 엔지니어의 일은 이제 코드 한 줄을 직접 생산하는 데서 끝나지 않아. 누구나 변경을 프롬프트로 요청하고, 에이전트가 그 변경을 만들고, 결과가 바로 배포될 수 있는 조립 라인을 유지해야 해.¹

그 조립 라인에는 여러 장치가 붙는다. 프롬프트, 스킬, 지식 베이스가 에이전트의 작업 범위를 좁힌다. 테스트, 린팅, 타입 시스템, 평가, 다른 AI를 쓴 자동 평가가 결과를 뒤에서 막는다.¹

이 구조가 잘 갖춰지면 낮은 성능의 모델도 꽤 쓸 만한 변경을 만들 수 있다. 충분한 제약과 최신 맥락을 주면 모델이 경로를 크게 벗어나지 않는다는 얘기야.¹

여기까지는 agentic workflow의 이야기와 닿아 있어. 모델 하나가 똑똑한지보다, 모델이 어떤 지시를 받고 어떤 검증을 통과하며 어떤 권한으로 움직이는지가 중요해진다.

그런데 코드는 영어보다 정밀하다

문제는 코드가 단순한 산출물이 아니라 사고 도구라는 점이야. 글쓴이는 Fable 수준의 지능을 가진 에이전트가 있더라도, 직접 코딩은 영어라는 중간 계층 없이 실행 환경에서 생각하게 해준다고 말한다.¹

영어로 “이렇게 고쳐줘”라고 지시하면 요구는 느슨해질 수밖에 없어. 반대로 코드는 실행 가능한 단계로 생각하게 만든다. 알고리듬 작업에서는 특히 그래. 어떤 자료구조를 고르고, 어느 경계 조건에서 실패하고, 어떤 테스트가 빈틈을 남기는지는 코드를 만질 때 더 빨리 드러난다.¹

그래서 수동 리뷰만으로는 부족해질 수 있다. 에이전트가 만든 패치와 diff를 읽는 일은 중요하지만, 그것만으로는 시스템 아키텍처와 깊게 연결되기 어렵다. 직접 코드를 다루면 그 위에 기능을 얹을 때 무엇이 깨지는지 몸으로 알게 된다.¹

이건 reflection과도 이어져. 테스트 실패, 정적 분석, 실행 결과를 보고 다음 수정을 고르는 루프가 생기려면, 사람도 그 피드백이 무엇을 뜻하는지 충분히 감각으로 알아야 한다.

에이전트는 컴파일러가 아니라 인턴에 가깝다

글에서 가장 중요한 비유는 이거야. 코딩 에이전트는 컴파일러보다 새로 합류한 인턴에 가깝다.¹

컴파일러는 명확한 입력을 정해진 규칙으로 처리한다. 하지만 에이전트는 품질이 들쭉날쭉한 기존 코드를 읽고, 부정확한 변경 설명을 바탕으로 새 변경을 만든다. 그러니 사람의 사고와 취향을 그대로 넘겨받는다고 보면 안 된다.¹

특히 에이전트는 기존 결정을 보수적으로 보존하려는 쪽으로 기울 수 있다. 한 코드베이스에서 사람이 일부 상태를 브라우저 로컬 스토리지에 둔 적이 있었는데, 나머지 상태는 백엔드 데이터베이스에 저장하고 있었는데도 에이전트가 그 결정을 유지하려고 래핑과 간접 계층을 추가했다. 결과적으로 코드 줄 수가 약 3배로 늘었다는 사례가 나온다.¹

여기서 확인되는 건 에이전트가 나쁘다는 말이 아니야. 사람의 일회성 실수도 패턴처럼 보이면, 에이전트는 그 실수를 더 크게 만들 수 있다는 말이야.

직접 만지는 일은 줄어도 사라지지 않는다

직접 코딩만이 소프트웨어를 이해하는 유일한 방법은 아니야. 실제 코드 대부분을 AI가 생성하더라도 직접 코딩은 여전히 유용한 도구로 남는다는 게 글의 균형 잡힌 결론이다.¹

핵심은 사람이 모든 줄을 손으로 써야 한다는 낭만이 아니야. 사람이 먼저 접근법을 시험하고, 일관된 아키텍처 원칙을 만들고, 에이전트가 그 패턴을 반복하게 해야 한다는 쪽에 가깝다.¹

테스트 전략도 여기서 중요해진다. 디버깅 과정에서 테스트의 약점을 찾아 고치면 새로운 종류의 버그 전체를 막을 수 있다. 에이전트가 많아질수록 평가와 측정, 보호 장치는 더 필요해지고, 개인 프로젝트에서도 CI를 초기에 붙이게 된다는 관찰도 나온다.¹

그러니까 2026년에 코드를 작성한다는 건 “AI와 경쟁해서 타자를 더 빨리 친다”는 뜻이 아니야. 조립 라인을 분해해 보고, 브레이크 패드를 하루 종일 관찰하듯이, 세부 사항과 전체 구조가 어디서 맞물리는지 확인하는 일에 가깝다.¹

다음에 볼 것

앞으로 볼 것은 코드 생산량이 아니라 검증 구조야. 에이전트가 만든 변경을 사람이 어디서 직접 만지고, 어떤 테스트가 실패를 빨리 드러내고, 어떤 아키텍처 원칙이 반복 가능한 패턴으로 남는지가 중요해진다.

또 하나는 에이전트가 기존 결정을 얼마나 보수적으로 확대하는지야. 좋은 패턴을 반복하면 생산성이 된다. 나쁜 우연을 반복하면 부채가 된다. 이 차이를 가르는 일은 아직 사람의 손에 많이 남아 있어.

각주

1. GeekNews/GN, 「2026년에 왜 코드를 작성하는가」 GeekNews. ↩︎ ↩︎² ↩︎³ ↩︎⁴ ↩︎⁵ ↩︎⁶ ↩︎⁷ ↩︎⁸ ↩︎⁹ ↩︎¹⁰ ↩︎¹¹ ↩︎¹² ↩︎¹³ ↩︎¹⁴