코딩 에이전트의 성능이 폭발적으로 좋아지며, 이제는 코드를 몰라도 자연어로 말만 하면 인공지능(이하 AI)이 코드를 만들어 주는 시대가 왔다. 일찍이 안드레이 카파시(Andrej Karpathy)는 AI 기반 개발 방식을 바이브 코딩(Vibe Coding)이라고 말한 바 있다. 그러나 이제는 바이브 코딩을 넘어 AI가 능동적인 주체로 팀을 구성하고 스스로 목표를 설정해 계획을 세우며 코딩, 테스트, 디버깅까지 수행하는 에이전틱 코딩(Agentic Coding)이 성행하고 있다. 그렇게 AI 기반 개발 방식이 보편화됨에 따라 프롬프트 엔지니어링, 컨텍스트 엔지니어링을 넘어 AI가 만들어 내는 코드를 적극적으로 통제하려는 하네스 엔지니어링도 빠르게 확산되고 있다.

요즘은 우스갯소리로 코딩 에이전트에 장애가 나면 퇴근해야 한다는 말이 있을 정도로 AI 기반 개발 방식이 대중화됐다. 사람이 직접 코드를 작성하지 않는 시대, 누군가는 손 코딩의 종말을 이야기한다.

정말로 손 코딩은 죽었는가?

인지적 부채를 앓거나 호소하는 사람들

1년 전쯤, 나는 어느 바이브 코딩 세미나에 참석한 적이 있다. 당시 행사장에 모인 많은 이들은 그 자체로 바이브 코딩에 대한 높은 관심과 열기를 보여 주는 듯했다. 발표자들 역시 하나같이 손 코딩과의 작별을 고하며, 어떻게 하면 바이브 코딩으로 더 나은 결과물을 잘 만들 수 있을지 말했다.

하지만 정작 내 관심을 끈 것은 바이브 코딩이 아니라 한 청중의 질문이었다.

AI로 코드를 만들고 있지만 코드가 어떻게 동작하는지 잘 모르겠고, 무언가 만들어내지만 내가 성장한다는 느낌이 들지 않는데 어떻게 해야 하나요?

비단 개발자만 이런 현상을 겪는 것이 아니다. 이탈리아 후마니타스대(Humanitas University) 연구진은 내시경에 AI를 적극 사용한 의료진을 분석했다. 그 결과, AI에 지속적으로 의존할 때 숙련된 의사의 독자적인 용종 발견 능력이 저하되는 ‘탈숙련화(deskilling)’ 현상을 발견했다. 결국 이는 AI를 적극적으로 활용하는 업계 전반에서 나타나는 현상인 셈이다.

하버드 비즈니스 리뷰의 한 글은 AI 도입과 그에 대한 과도한 의존으로 발생하는 인간의 심리적 부채를 말하고 있다. 앞서 세미나의 질문자나 AI 내시경을 사용한 의료진이 겪고 있는, 혹은 겪었던 것은 바로 ‘인지적 부채’이며, 이미 나는 ‘당신의 사고까지 AI에 외주화하지 마라’ 글에서 인지적 부채에 대한 문제를 다룬 바 있다. 요즘 내 주위에서는 너무나도 쉽게 (본인이 인지하든 인지하지 못하든) AI에 과도하게 의존하며 생긴 인지적 부채를 앓거나 호소하는 사람들을 만난다.

직접 경험의 종말

AI 기반 개발은 기술로 매개된 매끄러운 간접 경험을 우리에게 선사한다. 원하는 것을 말로 전달하고, 문제를 만나더라도 그 문제를 다시 AI에 전달하면 그만이다. 깊이 생각할 필요도 없다. 그저 원하는 것을 전달할 뿐이다.

이러한 구조에서는 흔히 ‘삽질’이라고 부르는 시행착오를 겪기 어렵다. 앞서 세미나의 질문자는 “성장한다는 느낌이 들지 않는다”라고 말했다. 성장은 학습과 불가분 관계에 있으며, 학습의 원천은 기술로 매개된 간접 경험이 아니라 직접 경험이다. 그래서 무언가를 배울 때 가장 빠르고 확실한 방법은 직접 해보고 실패해 보는 것이다. AI와 같은 기술로 매개된 간접 경험은 이처럼 가장 빠르고 확실한 학습 과정을 방해한다. 그 결과, 원하는 결과물은 만들어 낼 수 있을지 몰라도 만들어낸 것에 대해 명확히 설명하기 어렵다. 결국 스스로 성장하고 있다는 느낌도 들지 않는 것이다.

작년의 바이브 코딩 행사장으로 다시 돌아가 보자. 당시 발표자들은 인지적 부채를 겪지 않았을 가능성이 높다. 적게는 10년, 많게는 20년 가까운 경력으로 직접 개발한 경험도 매우 풍부했기 때문이다. AI 기반 개발이 보편화된 것은 불과 몇 년 전의 일이다. 그전까지 개발자들은 좋든 싫든 직접 코딩했으며, 그 과정에서 수많은 시행착오를 겪었고, 그러한 직접 경험은 ‘사전 지식’으로 쌓여 자신만의 심성 모형(Mental Model)을 만들었다.

따라서 이들은 AI 기반 개발 환경에서도 이미 머릿속에 자신만의 구현 방향이 존재하며, AI가 실제로 만들어 낸 코드를 보고 차이점을 쉽게 인지해 이를 취사 선택해 원하는 방향으로 만들 수 있다. 반면 AI 기반 개발 방식이 보편화된 시기에 개발을 시작한 사람들은 다르다. 이들은 압도적으로 기술에 의해 매개된 간접 경험이 많기에 인지적 부채에 더욱 취약한 것이다.

인지적 장애물

인지적 부채를 해결하는 방법 중 하나는 인지적 장애물(Cognitive friction)을 두는 것이다. 인지적 장애물의 핵심은 AI를 사용하기 전에 내 생각을 구체화하는 데 있다. 스스로 문제를 정의하고 가설을 세우거나, 내 생각에 대한 근거를 찾고, 그것을 바탕으로 AI와 대화하며 결과물을 만드는 것이다. 여기서 중요한 것은 단순히 AI에게 완성형 프롬프트로 “~을 만들어줘”라고 지시하는 것이 아니라, 사고의 주도권을 내가 쥔 채 AI와 협업한다는 점이다.

인지적 장애물에 대한 구체적인 사례가 있다면 이해하기 수월할 것이다. 나는 동작하는 코드를 만들기 전에 테스트 코드를 먼저 작성한다. 켄트 벡이 테스트 주도 개발(Test Driven Development, TDD)이라고 명명한 개발 방식이다. 이때 작성하는 테스트 코드는 AI에게 맡기지 않고 손으로 직접 만든다. 이 과정에서 풀어야 할 문제를 스스로 정의하고 가설을 세운다. 그리고 테스트 코드를 기준으로 AI와 대화하며 구체적인 코드를 함께 작성해 나간다.

AI와 함께 코드를 만들 때 나는 주로 AI에게 문제의 맥락(사용자 스토리, 데이터 크기 등)을 설명한다. 그리고 AI가 만든 코드를 보고 의도를 질문하거나 다시 내 생각을 제안한다. 내게 있어 테스트 코드를 직접 작성하는 것은 인지적 장애물을 두는 것과 같다.

또 다른 사례로는 얼마 전부터 나와 함께 일하게 된 동료와의 협업 방식을 들 수 있다. 동료는 AI가 대중화되던 시기에 개발을 시작했다. 주로 프론트엔드 개발을 해왔지만 백엔드 개발로 전환해야 했고, 심지어 처음 접하는 언어를 사용해야 했다. 나는 동료가 인지적 부채를 최소화하면서도 빠르게 새로운 것을 학습할 수 있을지 고민했고, 이렇게 제안했다.

세 번 작성하라.

구체적으로 우리(나와 동료)가 한 방식은 아래와 같다.

스스로 어떻게 구현할지 방안을 만든다.
함께 짝 프로그래밍하며 직접 코딩을 경험한다.
코드를 모두 지우고 AI에게 시킨다.

1번 과정에서 그는 자신의 생각을 구체화하며 시뮬레이션한다. 2번 과정에서는 직접 경험을 쌓는 동시에 짝 프로그래밍을 거치며 다른 사람의 문제 해결 방식을 경험한다. 1번과 2번 과정(인지적 장애물)을 거치면서 자신만의 동작하는 코드를 갖게 되고, 3번 과정에서 AI가 생성한 코드를 볼 때 선택지가 생긴다. AI가 만든 것을 받아들일지, 내가 만들었던 것을 선택할지, 그 순간의 선택이 나를 능동적인 존재로 만든다.

문제 푸는 방법을 보기 전에 풀어보라는 요청을 받고 문제와 씨름하고 난 후에는 해법을 더욱 잘 배우고 그 지식을 더 오래 기억할 수 있다.-<어떻게 공부할 것인가?>

코드는 꼭 보아야 하는 것인가

오픈클로 개발자는 코드를 읽지 않는다고 하는데, AI 기반 개발 환경에서 코드를 꼭 보고 이해할 필요가 있을까? AI가 생성한 코드를 볼지 말지는 각자가 처한 맥락에 따라 다르다.

예를 들어 내가 기획자나 디자이너라면 바이브 코딩으로 동작하는 소프트웨어를 만든 다음, 굳이 익숙하지 않은 코드를 보고 이해할 필요는 없을 것이다. 마찬가지로 아이디어가 시장에서 통할지 확인하기 위한 MVP(Minimum Viable Product)를 만들 때도 코드를 보고 이해할 필요는 없을 수 있다. 결국 각자가 처한 맥락에서 일의 목적과 목표에 따라 판단이 달라진다.

다만 내가 관찰한 인지적 부채를 겪는 개발자들은 주로 기술로 매개된 매끄러운 간접 경험에 원인이 있었다. 이러한 경험은 개발자와 코드 사이의 거리를 벌려 놓고, 그 사이를 스스로 메우지 못하는 데서 나온다. 켄트 벡은 Augmented Coding: Beyond the Vibes란 글에서 ‘증강 코딩(Augmented Coding)’을 말하며, 깔끔하고 제대로 동작하는 코드를 만들기 위해서는 코드 자체는 물론 코드의 복잡성, 테스트, 그리고 테스트 커버리지까지 신경 써야 한다고 주장한다.

<출처: Kent Beck, https://tidyfirst.substack.com/p/augmented-coding-beyond-the-vibes>

정체성이란 내가 나 자신에 대해, 내게 들려주는 이야기다. 나는 어떤 사람인가, 나는 무엇을 상징하는가, 나는 무엇을 잘하는가, 나는 무엇을 할 수 있는가에 관한 이야기다. 당신이 개발자라면, 그리고 깔끔하고 제대로 동작하는 코드를 만들고 싶다면, 그 코드가 내가 직접 만든 것이든 AI가 생성한 것이든 상관없이 보고 이해해야 한다.

학습을 위한 손 코딩

내가 어릴 적 무척 좋아했던 <신세기 사이버 포뮬러>는 미래의 레이싱을 다룬 만화영화로, 주인공 하야토는 AI인 아스라다와 함께 레이싱을 하며 성장한다. 어느 날 주인공은 한계에 부딪히고, 그 벽을 넘기 위해 AI의 지원을 모두 끄고 직접 레이싱 테크닉을 연습하는 장면이 나온다. 문제의 본질에 다가가기 위해 기술이 매개된 경험이 아니라 직접 경험을 쌓으려 했던 것이다.

만화영화의 상상력은 현실에서도 충분히 벌어질 수 있다. 나는 ‘안전한 패스워드 없는(Passwordless) 시스템을 향해’라는 글을 쓴 적이 있다. 그보다 앞서 나는 패스키(Passkey) 개념을 정확하게 이해하기 어려웠고, 아무리 문서를 읽어도 다른 사람에게 명확하게 설명하기 힘들어했다. 그래서 개념과 동작 방식을 학습하기 위해 직접 코딩을 했고, 글에 삽입한 순차도를 직접 그렸다. 그 결과 머릿속이 명확해졌을 뿐만 아니라 다른 사람에게도 정확하게 설명할 수 있었다. 이후 AI와 함께 운영하고 있던 서비스에 패스키를 적용했고, 그 과정에서 나오는 문제들 역시 어렵지 않게 해결할 수 있었다.

학습을 위한 글쓰기(Writing to Learn, WTL)라는 개념은 우리에게 직접 무언가를 생성하는 행위가 학습에 매우 효과적이라는 사실을 알려 준다. 그건 AI도 사람도 마찬가지다. AI도 동일한 문제를 다양하게 여러 번 생성하면 더 나은 결과를 만들어낸다.

누구나 직접 경험을 통한 학습이 필요한 이유다.

마치며

현대 소프트웨어 생태계는 과거와 비교할 수 없을 정도로 복잡해졌다. 따라서 모든 것을 세 번 작성하거나 손 코딩하며, 전부 이해하고 만든다는 것은 현실적이지 않다. 또한 AI가 폭발적으로 늘어난 복잡성을 소화할 수 있게 해주는 매개체라는 것도 엄연한 사실이다. 다만 특별히 중요해 보이는 것이 있다면, 그것과 관련된 직접 경험을 쌓아 인지적 부채를 줄이고 이해도를 높이는 것이 중요하다는 것 역시 엄연한 사실이다.

우리는 본능적으로 선형적 사고를 한다. 프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 하네스 엔지니어링, 이런 식으로 말이다. 하지만 현실은 복잡계이기에 선형적 사고는 오해를 만든다. 현실에서는 하네스 엔지니어링만 하지 않는다. 프롬프트 엔지니어링과 컨텍스트 엔지니어링이 공존한다. 마찬가지로 바이브 코딩이나 에이전틱 코딩이 대세라고 해서 손 코딩이 사라지거나 그 가치가 없어지는 것은 아니다.

손 코딩은 과거의 위상 같지는 않겠지만, 앞으로도 그 고유의 역할을 가지고 공존할 것이다.

감사의 말

누군가는 글 제목을 보고 눈치챘을지 모르겠다. 이번 글의 제목은 ‘Is TDD Dead?’의 오마주다. 인연은 없지만 여전히 활발한 활동으로 영감으로 주는 켄트 벡에게 감사를 표한다. 마지막으로 실험(?)에 동참해 준 동료에게 감사를 전한다.