AI가 코드를 쏟아내는데, 왜 개발자는 더 지칠까요

AI 에이전트가 알아서 코드를 짜는 시대입니다. 그런데 이상하게도 개발자들 사이에서 “예전보다 더 피곤하다"는 말이 나옵니다. 자동화가 됐는데 왜 더 힘들어졌을까요. 오늘은 이 역설의 정체를 파헤쳐 보겠습니다.

먼저 솔직하게 말씀드릴 게 있습니다. 이 주제로 최근 한 달간의 커뮤니티 반응을 뒤져봤지만, 딱 떨어지는 최신 논의는 거의 잡히지 않았습니다. 그래서 오늘 글은 실시간 여론 정리라기보다, 업계에서 반복적으로 관찰되는 구조적 문제에 대한 제 해석에 가깝습니다. 이 점 감안하고 읽어주시면 좋겠습니다.

‘휴먼 인 더 루프’는 원래 사람을 위한 장치였습니다

휴먼 인 더 루프(Human-in-the-loop)는 자동화 시스템에 사람의 판단을 끼워 넣는 설계입니다. AI가 결정을 내리기 전에, 혹은 내린 뒤에 사람이 확인하는 구조죠.

취지는 명확합니다. AI는 틀릴 수 있으니까요. 그러니 최종 책임은 사람이 진다. 안전벨트 같은 개념입니다.

문제는 이 안전벨트가 몇 번 채우느냐에 있습니다. 하루에 한 번 채우는 안전벨트는 안전장치입니다. 1분에 한 번 채웠다 풀었다 해야 하는 안전벨트는 고문 도구입니다.

생산성의 비대칭이 만드는 병목

여기서 핵심은 비대칭입니다.

AI 에이전트는 코드를 생성하는 속도가 사람의 수십 배입니다. 하지만 그 코드를 읽고 이해하고 판단하는 속도는 여전히 사람의 속도입니다. 생성은 기계 속도로, 검증은 인간 속도로 돌아갑니다.

결과가 뭘까요. 병목이 사람에게 몰립니다. 예전에는 “코드를 짜는 시간"이 대부분이었다면, 이제는 “남이 짠 코드를 읽는 시간"이 대부분이 됩니다.

그런데 코드 리뷰는 코드 작성보다 인지 부담이 큽니다. 내가 짠 코드는 머릿속에 맥락이 있지만, 남이 짠 코드는 맥락부터 재구성해야 하니까요. 하물며 그게 사람도 아닌 에이전트가 짠 코드라면요.

자동화 안주 편향, 그리고 러버스탬프

인간공학 분야에는 자동화 안주 편향(automation complacency)이라는 오래된 개념이 있습니다. 자동화 시스템이 대체로 잘 작동하면, 감시자는 점점 감시를 게을리한다는 겁니다.

항공 자율비행 연구에서 수십 년간 반복 확인된 현상입니다. 조종사가 오토파일럿을 오래 신뢰하면, 정작 오토파일럿이 이상해졌을 때 알아채는 게 늦어집니다.

AI 코딩 에이전트도 똑같습니다. 처음엔 한 줄 한 줄 꼼꼼히 봅니다. 그런데 스무 번 연속으로 멀쩡한 코드가 나오면? 스물한 번째부터는 스크롤을 내리며 승인 버튼을 누르게 됩니다.

이게 바로 러버스탬프(rubber stamp), 도장 찍기입니다. 형식적으로는 사람이 검토했습니다. 실질적으로는 아무도 안 본 겁니다.

여기서 잔인한 부분이 나옵니다. 안전장치는 무너졌는데, 책임은 그대로 사람에게 남아 있다는 것. 사고가 나면 “왜 승인했느냐"는 질문이 돌아옵니다. 실질적 감시는 불가능한 속도로 밀어넣어 놓고, 책임만 지우는 구조입니다.

진짜 문제는 ‘결정 피로’입니다

지치는 이유가 단순히 일이 많아서만은 아닙니다.

검토는 결정의 연속입니다. 이 코드 승인할까 말까. 이 접근이 맞나 틀리나. 이 에러 핸들링 빠진 게 의도인가 실수인가. 하나하나가 판단입니다.

심리학에서 말하는 결정 피로(decision fatigue)가 여기서 터집니다. 판단을 반복하면 판단력 자체가 고갈됩니다. 그리고 판단력이 고갈된 사람이 선택하는 기본값은? 대개 “그냥 승인"입니다.

그러니까 이건 순환 구조입니다. 검토가 많아진다 → 피로해진다 → 대충 본다 → 문제가 생긴다 → 검토를 더 강화한다 → 더 피로해진다.

여기에 하나 더 있습니다. 만드는 즐거움이 사라진다는 점이요. 개발자가 개발자가 된 이유는 대개 뭔가를 만드는 게 재밌어서입니다. 그런데 온종일 남의 결과물을 검사만 하고 있으면요. 직업이 창작에서 감사(audit)로 바뀝니다. 번아웃은 일이 많을 때보다 의미를 못 느낄 때 더 빨리 옵니다.

그래서 어떻게 해야 할까요

정답은 없지만 방향은 몇 가지 보입니다.

첫째, 검토 지점을 줄이는 것입니다. 모든 단계에 사람을 넣지 말고, 되돌릴 수 없는 지점에만 넣는 겁니다. 배포, 마이그레이션, 결제 로직처럼요. 나머지는 그냥 놔두고 테스트와 롤백으로 잡는 게 낫습니다. 실수해도 되돌릴 수 있으면 그건 검토할 대상이 아니라 실행할 대상입니다.

둘째, 검토를 검토답게 만드는 것입니다. 500줄 diff를 통째로 던지면 아무도 못 봅니다. 에이전트가 “내가 뭘 왜 바꿨는지, 어디가 위험한지"를 먼저 요약하게 만들어야 합니다. 사람이 볼 곳을 좁혀주는 거죠.

셋째, 신뢰 구간을 나누는 것입니다. 모든 작업을 같은 강도로 볼 이유가 없습니다. 테스트 코드 추가와 인증 로직 수정은 다른 무게를 가져야 합니다.

넷째, 이게 사람 문제가 아니라 설계 문제라는 인식입니다. “집중력을 더 발휘하세요"는 해법이 아닙니다. 인간의 지속적 주의력에는 물리적 한계가 있고, 그건 정신력으로 뚫는 게 아니라 시스템으로 우회하는 겁니다.

마무리

휴먼 인 더 루프는 좋은 개념이었습니다. 다만 AI가 초당 몇 개씩 결과물을 뱉어내는 세상을 전제하고 만든 개념은 아니었습니다. 루프 안에 사람을 넣는 것만으로 안전해진다는 믿음은, 그 사람이 실제로 볼 수 있을 때만 유효합니다.

지금 우리가 마주한 질문은 이겁니다. 사람이 모든 것을 보게 할 것인가, 아니면 봐야 할 것만 보게 할 것인가.

여러분의 팀은 어느 쪽인가요. 혹시 승인 버튼을 누르면서, 정작 화면은 안 보고 계시지는 않은가요.