현대 소프트웨어 엔지니어의 느리고 조용한 인지 위축 — AI에 생각을 맡기는 대가

본문

AI 도구가 소프트웨어 개발의 기본 워크플로가 된 지금, 엔지니어들은 문제를 보자마자 스스로 해법을 떠올리는 대신 본능적으로 AI에게 먼저 묻는 습관에 빠지고 있습니다. 저자는 이를 Pieter Bruegel의 그림 'The Blind Leading the Blind(1568)'에 빗대어, 다만 현대의 차이점은 우리가 '스스로 눈을 멀게 하고 있다'는 점이라고 말합니다.

리뷰가 사라진 워크플로의 위험

작은 변경이라며 AI가 생성한 코드를 검토 없이 커밋하는 과정이 반복되면, 그 '작은 변경들'이 누적되어 어느 순간 AI 없이는 코딩을 못 하는 상태가 됩니다. AI가 만든 코드는 깔끔하고, UI도 보기 좋고, (AI가 함께 생성한) 테스트도 통과하기 때문에 엔지니어는 검토 없이 변경을 수용하고 넘어가기 쉽습니다. 하지만 숙련 기술은 사용하지 않으면 반드시 퇴화하며, '지시하는 것'과 '직접 구현하는 것'은 완전히 다른 일이라고 저자는 강조합니다. 직접 실행해야만 엣지 케이스를 발견하고, UX를 고민하고, 어떤 테스트가 의미 있는지 판단할 수 있습니다.

사람이 작성했다는 것 자체의 가치

인간이 작성한 코드가 완벽하지 않다는 것이 오히려 가치의 근거라고 말합니다. 사람이 쓴 코드에는 책임 주체가 있고, 맥락을 가진 사람이 있으며, 문제가 생겼을 때 처음부터 시작하지 않아도 될 기반이 있습니다. 잘못된 가정을 하고 고생하며 결국 해법을 찾는 과정 자체가 진짜 이해를 만듭니다. 반면 리뷰 없이 AI 코드가 PR로 올라가면 '주니어는 AI를 믿고, 시니어는 주니어를 믿고, 코드는 프로덕션에 도달하는' 도미노가 시작됩니다. 1000줄이 넘는 AI 생성 코드를 읽는 것은 리뷰어조차 게을리 하게 만들고, 심하면 AI 리뷰 에이전트에 다시 맡기게 되어 불확실성이 더 커집니다.

실천법 — PR을 '내 것'으로 만들기

저자가 제시하는 기준은 단순합니다. 보내기 전에 읽고, PR을 이해하고, 의도를 갖고 푸시하는 것입니다. PR이 완벽할 필요는 없지만 리뷰어가 물었을 때 '왜?'라는 질문에 즉시 답하고 코드의 이면을 설명할 수 있어야 합니다. 변경에 대한 토론이 이뤄져야 맥락이 팀원에게 자연스럽게 전달됩니다.

또한 저자는 매일 최소 하나의 코딩 챌린지를 풀면서 자신의 풀이 과정을 화면과 함께 녹화하고, 마치 누군가에게 가르치듯 단계별로 설명한다고 밝힙니다. 녹화를 다시 보며 버벅이는 부분과 설명 중 멈칫하는 부분을 체크하면 자신의 현재 실력이 객관적으로 드러나고, 첫 녹화와 지금을 비교하면 실력 향상이 눈에 보여 동기부여가 된다고 합니다. 아울러 작업할 때는 먼저 문서와 여러 접근법을 스스로 조사해 자기 생각을 형성한 뒤 AI를 보조 수단으로 사용하는데, 실제로 AI가 deprecated된 메서드를 제안하는 것을 자기 조사 덕분에 잡아낸 경험을 공유합니다. 지적하자 AI는 'You're absolutely right!'라고만 답했고, 이를 통해 AI가 복불복이며 배경 지식이 없으면 오류를 놓치기 쉽다는 것을 깨달았다고 말합니다.

직접 해본 경험과 훈육

저자도 AI 생성 코드를 써봤지만 localhost에서 여러 버그를 만났고, 코드를 자신이 만들지 않아 어디를 봐야 할지 모르는 무력감이 더 컸다고 회상합니다. AI가 제시하는 사전 점검 목록을 따라가는 워크플로가 자신에게 맞지 않았고, 결국 직접 디버깅·학습·수정을 반복해 15~30분 만에 필요한 컴포넌트를 만들었다고 합니다. 그 고생은 '사다리를 오르는 것처럼' 실감나는 진전이었고, 얻은 이해는 남았다고 말합니다. 마지막으로 저자는 '훈육은 자기 존중의 궁극적 형태'라는 인용을 들며, 코드 생성이 쉬워질수록 지름길 없이 배우는 훈육이 슈퍼파워가 된다고 결론 내립니다. AI는 그것을 다루는 엔지니어의 좋은 습관과 나쁜 습관 모두를 증폭시키므로, 생각을 통째로 아웃소싱하지 말고 책임지고 설명하고 고칠 수 있는 코드를 만들어야 한다고 당부합니다.

원문: dev.to / 번역·요약: Trawling