모든 개발자가 느껴본 적이 있을 겁니다. 복잡한 버그를 만났고, AI 에이전트를 찾았더니 몇 초 만에 수정된 코드를 작성하는 것을 지켜봅니다. 노력은 사라지고, 문제는 해결됩니다. 그리고 당신은 그 과정에서 거의 아무것도 배우지 못합니다.

당신이 얻는 결과물과 스스로 쌓아 올리는 기술 사이의 간극이야말로 AI를 활용하여 소프트웨어를 구축할 때 핵심적인 긴장점입니다. 중요한 것은 코드가 정확한지 여부가 아닙니다. 기계 없이 다음 코드를 직접 작성할 수 있을지가 중요합니다.

부담(Strain)이 메커니즘이다

런던 택시 운전사들은 25,000개의 거리를 암기하는 데 3~4년을 보냅니다. 이 과정을 '지식 (Knowledge)'이라고 합니다. 신경과학자들은 공간 지도를 담는 뇌의 후방 해마(posterior hippocampus)가 다른 사람보다 측정 가능하게 크다는 것을 발견했으며, 운전 기간이 길수록 더 크다는 것을 확인했습니다. 여기에는 상충 관계가 있었습니다. 같은 운전자들은 전방 해마(anterior hippocampus)가 작았고 새로운 공간 배치를 따라 하는 데는 오히려 취약했습니다. 뇌는 요구되는 부하를 감당하기 위해 전문화되었고, 이는 힘든 과정이었습니다.

London cabbie brain study

GPS가 그 노력을 대체했을 때, 그 능력은 위축되었습니다. 연구원들은 습관적으로 GPS를 사용하는 사람들이 도움 없이 길을 찾을 때 가장 나쁜 공간 기억력을 가지고 있으며, 시간이 지날수록 사용량이 많을수록 그 감소 폭이 더 크다는 것을 발견했습니다. 이 기술은 기계에게 넘겨졌고 조용히 사라져 갔습니다.

AI가 당신의 코드를 작성할 때도 똑같은 일이 벌어집니다. 디버깅하는 노력, 호출 스택(call stack)을 추적하는 노력, 아키텍처를 머릿속에 유지하려는 그 노력이 바로 시스템 수준의 이해를 쌓는 반복적인 과정입니다. 이 과정을 제거하면 결과물만 남게 됩니다. 당신은 직접 수행함으로써 얻어야 할 적응력을 잃게 되는 것입니다.

기억에서 스스로 테스트하는 것이 증명하는 것

기억에서 스스로 테스트하는 것이 증명하는 것

심리학자들은 이를 직접 측정했습니다. 한 그룹에게는 지문을 반복해서 읽게 하고, 다른 그룹에게는 그 내용을 기억에 의존하여 테스트하게 했습니다. 반복해서 읽은 그룹이 더 자신감을 느꼈습니다. 일주일 후 시험에서는, 기억 속에서 스스로 끄집어내야 했던, 확신도가 낮았던 그룹이 훨씬 더 많은 것을 기억해냈습니다.

편안한 방법은 진전처럼 느껴졌지만 실질적인 성과는 거의 없었습니다. 불편한 방법은 실패처럼 느껴졌지만 실제로 학습을 시켰습니다.

AI 에이전트가 모든 버그를 고쳐주도록 내버려 두는 것은 당신이 반복해서 읽는 사람과 같습니다. 생산적이라고 느낍니다. 하지만 AI가 존재하지 않거나 문제가 진정으로 새로운 경우에 필요할 정신 모델(mental model)을 구축하고 있지는 않습니다.

개발자를 위한 자동화의 아이러니

엔지니어들은 40년 전에 이 현상을 지적했습니다. 즉, 기계에 작업을 맡기면 사람에게 남는 일은 그 기계를 감시하며 실패를 잡아내는 것이지만, 사실 작업을 넘기는 행위 자체가 감시에 필요한 기술을 소모시킨다는 것입니다. 대부분의 경우, 무언가를 확인하는 것이 그것을 만드는 것보다 저렴합니다. 산술 계산은 외부화하고도 총합이 터무니없는지 판단할 수 있는 충분한 수 감각(number sense)은 유지할 수 있습니다.

Automation irony

가장 위험한 능력은 스스로 검증할 수 있는 능력입니다. 아키텍처가 건전한지, 코드 리뷰가 철저한지, 디자인이 예외 케이스(edge cases)를 처리하는지는 그것을 직접 구축해 본 부분만이 느낄 수 있는 판단입니다. 이 중 하나라도 외부화하면, 실패를 잡아내는 데 필요한 가장 저렴한 것마저 잃게 됩니다. 손실하고 있다는 사실을 알기 위해서는 바로 그 것을 필요로 합니다.

개인적인 예시:
저는 첫 번째 모델이 생성한 결과물을 완전히 신뢰하지 못했기 때문에 제 글을 평가할 AI 심사위원 패널을 만들었습니다. 그들은 훌륭했습니다. 제가 놓친 부분을 잡아냈습니다. 하지만 그들의 판결을 실제 독자들로 가득 찬 방 옆에 두었을 때, 기계는 사람들이 점수한 것보다 거의 만점 가까이 높은 점수를 매겼습니다. 저는 더 높은 숫자를 믿었습니다. 제가 넘겨준 판단은 그 결과물이 실제보다 낫다고 확신했고, 달리 알 방법이 없었습니다. 오직 제가 물어봤기 때문에 비로소 알게 되었습니다.

모든 어려움이 신성한 것은 아니다

Difficulty trade-off

많은 어려움이 아무것도 만들지 못합니다. 고장 난 인터페이스, 상용구(boilerplate), 유효성 검사를 거부하는 설정 파일에 낭비된 20분 같은 것들 말입니다. 그런 종류는 순수한 낭비이며, 이것을 기계에게 맡기는 것은 이 시대의 진정한 선물 중 하나입니다. 그 선물을 받아들이세요.

다른 종류는 무언가를 만듭니다. 그것은 실제적인 노력을 필요로 하며, 과제가 끝난 후에도 남아 있는 변화된 당신 자신, 즉 역량을 남깁니다. 두 가지는 같은 얼굴을 하고 있으며, 내부적으로는 동일하게 느껴집니다. 둘 다 그저 저항일 뿐입니다. 하나의 테스트가 대부분의 구분을 해줍니다. 과제가 끝났을 때, 무엇이 뒤에 남아 있는지 살펴보세요. 만약 남은 것이 완성된 과제뿐이라면, 그 어려움은 단지 당신에게서 빼앗아 간 것일 뿐이었습니다. 만약 당신 안에 무언가 다른 것이 있다면, 그것은 당신을 만들어 온 것이며, 이것이야말로 보호해야 할 것입니다.

어떤 어려움을 계속해서 어렵게 처리할 것인가?

택시 기사들은 그들이 받게 된 어려움에 의해 만들어졌습니다. 그들은 선택하지 않았고, 도시가 그것을 의무화했습니다. 우리의 것을 강요하는 기관은 없습니다. 모든 것이 자동화될 수 있는 세상에서 끝나는 것은 기본값으로서의 형성입니다. 당신이 계속 유지하기로 선택하지 않는 한, 외부의 어떤 것도 더 이상 당신을 만들어주지 않을 것입니다.

Choose your difficulty

개발자에게 이 질문은 구체적인 문제가 됩니다. 에이전트(agent)가 아키텍처를 작성하게 하고 검토할 것인가, 아니면 직접 스케치하고 에이전트를 사용해 부족한 부분을 찾아낼 것인가? 오류 메시지를 채팅창에 붙여넣을 것인가, 아니면 10분 동안 추적하며 시간을 보낼 것인가? 기계에게 당신이 유지하려고 하는 정확한 행위를 수행하도록 요청할 것인가?

그 대답은 오늘 무엇을 배포(ship)할지뿐만 아니라, 5년 후에 무엇을 배포할 수 있을지를 결정합니다.

본 글은 "The Difficulty You're Escaping Was Making You"에서 각색되었습니다. 모든 참고 자료와 주석이 포함된 전체 버전은 Substack에 있습니다.