AI가 코딩의 속도를 바꾸고 있지만, 책임 있는 소프트웨어 개발의 핵심은 여전히 인간의 판단과 리뷰에 있다는 주장.
URL: https://adventures.nodeland.dev/archive/the-human-in-the-loop/
Title: The Human in the Loop
Mike Arnaldi는 "The Death of Software Development"라는 생각할 거리를 던지는 글을 썼다. 나는 Mike를 매우 존중한다. Effect는 훌륭한 작업이고, 지금 AI 국면에 대한 그의 분석은 대부분보다 날카롭다. 하지만 그는 중요한 무언가를 놓치고 있다고 생각한다.
분명히 하자. 나는 AI가 우리 업계를 변혁하고 있지 않다고 주장하려는 게 아니다. 변혁하고 있다. 내 워크플로 역시 극적으로 바뀌었다.
요즘 내 큐에 이슈가 들어오면, 첫 반응은 AI에 던지는 것이다. Node.js나 Undici의 보안 취약점. Fastify의 버그. Platformatic를 위한 신규 기능. AI가 구현을 맡는다. 지난 몇 달 동안 이런 식으로 수십 개의 수정 사항을 배포했다.
하지만 Mike가 대수롭지 않게 넘기는 핵심이 있다. 나는 바뀐 모든 것을 검토한다. 모든 동작 변경을. 배포되는 모든 줄을.
Mike는 2시간 만에 Polymarket 분석 도구를 만들었고, 코드 한 줄도 쓰지 않았으며, 코드 한 줄도 검토하지 않았다고 쓴다. 그는 이를 승리로 제시한다.
나는 다르게 본다.
내가 배포할 수 있는 능력은 더 이상 얼마나 빨리 코딩하느냐에 의해 제한되지 않는다. 얼마나 잘 리뷰하느냐에 의해 제한된다. 그리고 나는 이것이 정확히 그래야 한다고 생각한다.
보안 취약점을 고칠 때 나는 단지 테스트가 통과하는지 확인하는 게 아니다. 나는 묻는다. 이게 실제로 공격 벡터를 닫는가? AI가 놓친 엣지 케이스는 없는가? 이게 ‘맞는’ 수정인가, 아니면 그냥 ‘어떤’ 수정인가? 새 기능을 배포할 때는 이것이 아키텍처에 맞는지, 하위 호환성을 유지하는지, 내가 책임지고 지지할 수 있는 것인지 이해해야 한다.
내가 리뷰를 멈추는 순간, 내가 배포하는 것에 대해 책임지는 것도 멈추는 순간이다.
Mike는 이렇게 묻는다. “나 같은 바보가 월 3만 달러짜리 제품을 2시간 만에 복제할 수 있다면, 소프트웨어 개발이란 대체 뭐지?”
나는 다른 질문을 던지고 싶다. 그 복제품에 버그가 있어서 누군가 잘못된 거래를 하게 되면 누가 책임지는가? 누가 엣지 케이스를 이해하는가? 새벽 3시에 운영 환경에서 깨졌을 때 누가 디버깅할 수 있는가?
블룸버그 터미널이 비싼 이유는 코드가 쓰기 어려워서가 아니다. 그 뒤에 금융 시장, 규제 요건, 데이터 무결성, 시스템 신뢰성을 이해하는 사람들이 서 있기 때문이다. 무엇이 잘못될 수 있는지에 대한 정신적 모델을 수년 동안 쌓아온 사람들 말이다.
Mike가 абсолютно(절대적으로) 맞는 게 한 가지 있다. 40년의 모범 사례는 이제 구식이다. 우리가 의지해온 패턴, 우리가 만든 팀 구조, 우리가 따르던 프로세스. 전부 재고되어야 한다.
인간이 작성한 코드를 전제로 설계된 코드 리뷰 프로세스? 다시 생각해야 한다. 인간의 타이핑 속도를 기준으로 한 스프린트 계획? 구식이다. 개발자가 더 많으면 산출물이 더 많다는 가정? 의심스럽다.
나는 Node.js 생태계에 충분히 오래 있었기에 “모범 사례”가 생겼다가 사라지는 것을 봐왔다. 하지만 이번은 다르다. 새 프레임워크나 새 패러다임이 아니다. 코드가 생산되는 방식 자체의 근본적 변화다. 우리가 예전 방식대로 계속할 수 있다고 가장하는 사람은 현실을 부정하고 있다.
Mike는 소프트웨어 개발은 죽었지만 소프트웨어 엔지니어링은 살아 있다고 주장한다. 나는 전적으로 동의한다. 이제 엔지니어는 “더 고차원의 시스템을 설계”하고 “기법을 구축”한다. 소프트웨어 엔지니어와 아키텍트의 역할은 그 어느 때보다 중요하다.
사라진 것은 Jira에서 작업을 받아 처리하고 하루 일과를 마치는 프로그래머의 역할이다. 그 일은 사라졌다. AI가 이제 더 빠르고 더 싸게 할 수 있다.
하지만 나는 여기서 더 나아가고 싶다. 다른 사람이 한 코드를 리뷰하고 평가하는 일은 오픈 소스에서 예전부터 해오던 일이다. Node.js, Fastify, Pino, Undici의 메인테이너로서, 그리고 Node.js 기술 운영 위원회(Technical Steering Committee) 의장으로서, 나는 대부분의 시간을 한 번도 만난 적 없는 기여자들의 PR을 리뷰하는 데 쓴다. 배포되는 코드의 대부분을 내가 직접 쓰지 않는다. 나는 그것을 리뷰하고, 평가하고, 충분히 좋은지 결정한다. 이것은 나에게 새롭지 않다. AI는 이제 또 다른 기여자일 뿐이다.
나 또한 완전히 이해하지 못한 기여를 배포한 적이 있다. 나는 그것들을 애틋하게 후회한다. 모든 메인테이너는 언젠가 이런 일을 해본다. 그리고 매번 그것은 결국 너를 물어뜯는다. 버그는 고치기 더 어렵고, 동작은 설명하기 더 어렵고, 기술 부채는 누적된다. 그래서 리뷰가 중요하다. 그래서 이해가 중요하다.
그래, 나는 시스템을 설계한다. 하지만 더 중요한 것은 판단을 제공한다는 점이다. 무엇을 만들어야 하는지, 어떻게 동작해야 하는지, 구현이 의도와 일치하는지 결정한다. AI가 그럴듯해 보이지만 사실은 아닌 것을 자신만만하게 만들어낼 때, 나는 그 케이스를 잡아낸다. 어떤 프롬프트도 완전히 담아낼 수 없는 맥락을 나는 이해한다.
이건 새로운 기술이 아니다. 시니어 엔지니어가 늘 가져왔던 기술과 같다. 차이는 이제 이것이 여러 기술 중 하나가 아니라, 핵심 기술이 되었다는 점이다.
Mike는 “평균적인 소프트웨어 개발자는 이 변화의 규모를 이해하기에 턱없이 부족하다”고 말한다. 동의한다. 하지만 오해는 양쪽 모두에 있다고 생각한다.
일부 개발자는 AI를 과소평가한다. AI가 실수하니 내 일자리는 안전하다고 생각한다. 틀렸다. AI는 이미 일상적인 코딩 작업의 상당 부분을 처리하기에 충분히 좋다.
반대로 일부 AI 애호가는 변화를 과대평가한다. 그들은 루프 안의 인간을 일시적 한계, 최적화로 제거해야 할 병목이라고 생각한다. 나는 그 또한 틀렸다고 본다.
루프 안의 인간은 한계가 아니다. 요점이다.
내가 코드를 배포하면 내 이름이 걸린다. Undici에 보안 취약점이 생기거나 Fastify에 버그가 나면 그것은 내 책임이다. AI를 써서 더 빠르게 움직일 수는 있지만, 내 판단을 외주 줄 수는 없다. 내 책임을 외주 줄 수는 없다.
내 걱정은 소프트웨어 개발이 죽는다는 게 아니다. “내가 리뷰 안 했어, AI가 썼어”가 용인되는 변명으로 자리 잡는 문화를 우리가 만들까 봐 걱정하는 것이다.
나는 10년 넘게 오픈 소스 프로젝트를 유지보수해 왔다. 사람들이 이해하지 못한 코드를 배포할 때 어떤 일이 벌어지는지 봐왔다. 보기 좋지 않다. 그리고 AI 속도로 코드를 생성할 수 있을 때 가능한 피해 규모는, 타이핑 속도에 제한되던 때보다 훨씬 크다.
산업혁명 비유는 적절하지만, Mike가 제시하는 방식으로는 아니다. 산업혁명은 물건을 풍부하게 만들었을 뿐 아니라, 산업 재해의 새로운 범주, 새로운 형태의 오염, 대규모로 일이 잘못될 수 있는 새로운 방식도 만들어냈다. 산업 규모 생산을 책임 있게 다루기 위한 안전 관행, 규제, 문화적 규범을 개발하는 데에는 수십 년이 걸렸다.
우리는 AI가 생성하는 소프트웨어에 대해 그 과정의 시작점에 있다. 그리고 답은 인간을 루프에서 제거하는 게 아니다. 리뷰 파트를 훨씬 더 잘하게 되는 것이다.
나는 AI 사용에 반대하는 게 아니다. 나는 매일 쓴다. 나는 그 어느 때보다 생산적이다.
하지만 이제 내 병목이 코딩이 아니라 리뷰라는 사실을 받아들였다. 그리고 거기에 더 능숙해지려고 노력하고 있다. 더 빠른 패턴 인식. 흔한 실패 모드에 대한 더 나은 정신적 모델. 동작을 검증하는 더 효율적인 방법.
2026년에 중요한 기술은 이것이다. 프롬프팅이 아니다. “에이전틱 인프라스트럭처”도 아니다. 판단이다.
Mike가 말한 것처럼 변화는 빠르다. 하지만 루프 안의 인간은 고쳐야 할 버그가 아니다. 지켜야 할 기능이다.
