개발자의 Zemblanity — 스스로 만든 빙판에서 미끄러지는 법

어떤 복서가 있었다. 라이트급. 빠르고 정확한 선수였다. 친구들과 파티를 하고 있었는데, 술에 취한 누군가가 시비를 걸어왔다. 복서는 경계했다. 이 정도 훅은 눈 감고도 피한다. 그런데 바닥이 빙판이었다. 술 취한 남자가 주먹을 휘둘렀고, 복서는 피하려 했고, 둘 다 미끄러졌다. 그리고 우연히 — 정말 우연히 — 그 주먹이 복서의 관자놀이에 적중했다.

 

복서는 의식을 잃었다.

 

실력의 문제가 아니었다. 빙판의 문제였다.

이것을 Zemblanity라고 부른다. Serendipity(뜻밖의 행운)의 정반대 — 뜻밖의 불행. 아무도 의도하지 않았는데, 우연이 최악의 결과를 만들어내는 것. 작가 윌리엄 보이드가 만든 이 단어는 러시아 북극해의 척박한 섬 Zembla에서 따왔다. 춥고 황량하고 아무도 가고 싶지 않은 곳. 그런데 어쩌다 보니 거기 서 있게 되는 것.

 

지금 개발자들이 서 있는 자리가 딱 그렇다.

---

개발자의 본능은 귀찮음을 싫어하는 것이다. 이건 욕이 아니라 찬사다. 같은 코드를 두 번 쓰기 싫어서 함수를 만들었고, 함수를 반복 호출하기 귀찮아서 자동화 스크립트를 짰고, 스크립트를 관리하기 귀찮아서 CI/CD 파이프라인을 만들었다. 인류 문명의 상당 부분은 "이걸 꼭 내가 해야 해?"라는 질문에서 탄생했고, 개발자는 그 질문의 최전선에 서 있었다.

 

훌륭한 전통이다. 문제는 그 논리를 끝까지 밀어붙였다는 것이다.

 

반복 작업을 자동화했다. 자동화를 자동화했다. 테스트를 자동화했다. 배포를 자동화했다. 그리고 마침내 — 코딩 자체를 자동화했다.

기획 문서를 작성하면 AI가 코드를 짠다. 짠 코드를 AI가 테스트한다. 테스트 결과를 AI가 분석하고, 버그를 AI가 고친다. 사람은 문서를 쓰고 결과를 확인한다.

 

잠깐. 그러면 개발자는 뭘 하는 건가?

---

이 질문에 대한 업계의 공식적인 대답은 이렇다. "개발자의 역할이 코드를 짜는 사람에서 AI를 관리하는 사람으로 진화한다." 진화. 좋은 단어다. 공룡이 멸종하는 것도 진화의 일부이긴 하니까.

 

좀 더 솔직하게 말해보자. 지금 일어나고 있는 일의 구조는 이렇다.

 

경영자가 말한다. "개발 비용을 줄이고 싶다."

기획자가 말한다. "문서만 쓰면 앱이 나오면 좋겠다."

개발자가 말한다. "그거 내가 만들어줄게."

 

그리고 만들었다. 정말로.

 

문서를 읽고 코드를 생성하고 테스트까지 돌리는 시스템. 개발자의 귀찮음이 만들어낸 걸작이다. 경영자는 기뻐하고, 기획자는 신나고, 개발자는... 잠깐, 그러면 다음 프로젝트에서 개발자가 필요한가?

 

"아, 그래도 복잡한 건 사람이 해야 하죠."

 

맞다. 지금은.

---

여기서 기획자에게 한마디 하겠다.

 

이건 개발자만의 이야기가 아니다. "이거 자동화할 수 있지?"라고 물었던 그 질문이, 조만간 기획자 자신에게 돌아온다. 요구사항 정리, 화면 설계, 우선순위 판단 — 그것도 결국 패턴이다. 패턴이 있으면 자동화할 수 있다. 우리가 그렇게 배웠으니까.

 

그리고 지금 현장에서 벌어지고 있는 일이 있다.

 

이른바 '바이브 코딩(Vibe Coding)'이라는 것. AI가 생성한 코드를 한 줄도 읽지 않고 그대로 납품한다. 테스트도 AI에게 맡긴다. 돌아가면 됐으니까. 오픈은 된다. 고객도 만족한다. 당장은.

 

문제는 유지보수 단계에서 드러난다. 아무도 읽지 않은 코드는 아무도 고칠 수 없는 코드다. AI에게 다시 물어봐도, 맥락이 사라진 상태에서 돌아오는 답은 또 다른 미지의 코드일 뿐이다. 결국 처음부터 다시 만들거나, 더 큰 비용을 들여 해독해야 한다. 빠르게 만들어서 빠르게 망가지는 구조. 이건 효율이 아니라 부채다.

 

한편, 프리랜서나 소규모 팀에서는 AI로 며칠 만에 끝낼 수 있는 일을 기존 공수 기준으로 청구하기도 한다. 고객은 결과물만 보니까 모른다. 단기적으로는 수익성이 좋다. 하지만 고객도 바보가 아니다. 언젠가 알게 된다. "이거 AI로 만들 수 있는 거였어?" 그 순간 고객은 직접 AI에게 시키거나, 더 투명한 곳을 찾는다.

 

더 조용한 문제도 있다. AI로 주니어를 대체하면 당장의 비용은 줄어든다. 하지만 주니어가 성장하지 않으면 시니어가 될 사람이 없다. AI의 결과물을 판단하고 설계할 수 있는 사람이 사라진다. 지금 벌어들이는 이익은 다음 세대의 역량을 담보로 한 것일 수 있다.

 

가끔 링크드인에서 보인다. 개발도 자동화했고 테스트도 자동화했다고 자랑하는 글들. 효율을 이야기하고, 생산성을 이야기한다. 틀린 말은 아니다. 다만 그 자동화가 누군가의 첫 번째 기회를 대체했을 수 있다는 것까지 생각이 닿았는지는 모르겠다.

 

"그러면 주니어도 자동화를 배우면 되는 거 아닌가?" 물론이다. 다만 '자동화를 배운다'는 말이 두 갈래로 갈린다. AI 도구 사용법을 익히는 것과, 자동화의 원리를 이해하는 것. 전자는 파워유저가 되는 길이고, 후자는 개발자가 되는 길이다.

 

원리를 이해하려면 한 번은 수동으로 해봐야 한다. 직접 삽질해봐야 뭘 자동화하고 있는지 안다. 그런데 삽질할 자리가 이미 자동화로 사라졌다면, 주니어는 도구 사용법만 배우게 되고, 도구가 바뀌면 같이 쓸려나간다. 수영을 안 가르치고 구명조끼 사용법만 알려주는 거다.

 

경영자에게도 한마디.

원했던 건 비용 절감이었다. 개발자 줄이고, 기획자 줄이고, 요구사항 넣으면 앱이 나오는 파이프라인. 거의 다 왔다. 그런데 그 파이프라인이 완성되는 날, 경쟁사도 똑같은 파이프라인을 갖게 된다. 같은 AI, 같은 도구, 같은 자동화. 차별화는 결국 "무엇을 만들 것인가"를 결정하는 사람에게 달리게 된다.

---

빌 게이츠는 오래전부터 소수의 핵심 개발자가 플랫폼을 만들고, 나머지 대다수는 그 위에서 조립하는 세상을 그렸다. 1%의 개발자와 99%의 파워유저. 노코드, 로코드, 시티즌 디벨로퍼 — 이 모든 트렌드가 그 방향을 가리키고 있었다.

 

아이러니한 건, 게이츠가 최근 인터뷰에서 "코딩은 100년 뒤에도 100% 인간의 영역"이라고 말했다는 거다. 하지만 지금 현장에서는 이미 다른 일이 벌어지고 있다. AI가 생성한 코드를 읽지도 않고, 테스트도 AI에게 맡기는 사람들. 그들은 스스로를 개발자라고 부르지만, 실질적으로는 파워유저다.

 

게이츠의 예언이 이루어지고 있다. 다만 그가 예상한 방식은 아니다. 1%의 자리마저 AI가 채우기 시작하면, 남는 건 0%의 개발자와 100%의 소비자다.

---

다시 복서 이야기로 돌아가자.

 

복서의 실력이 문제가 아니었다. 빙판이 문제였다. 그런데 이번에는 좀 다르다. 개발자는 실력이 있었기 때문에 빙판을 직접 만들었다. 자기가 서 있는 바닥을 자기 손으로 얼려버린 것이다.

그리고 그 옆에서 기획자가 물을 부었고, 경영자가 온도를 낮췄다.

셋 다 미끄러질 것이다. 순서의 차이만 있을 뿐.

---

"그래도 AI가 못 하는 게 있잖아. 창의성, 공감, 판단력..."

 

맞다. 지금은.

 

"결국 사람만이 할 수 있는 영역이 남을 거야."

아마도. 그런데 그 말, 10년 전에 바둑 기사들도 했다.

---

이 글의 결론은 "그러니까 AI를 멈춰라"가 아니다. 멈출 수 없고, 멈출 이유도 없다.

 

다만 정직해야 할 것은 있다. 지금 나는 개발자인가, 파워유저인가. AI가 생성한 코드를 읽지 않고, 테스트도 AI에게 맡기고 있다면 — 그것은 개발이 아니라 조립이다. 조립이 나쁜 것이 아니다. 다만 조립하면서 개발자인 척하면, 결국 자기 발밑을 파는 일이 된다.

 

빙판 위에 서 있다는 걸 아는 사람은 넘어져도 준비할 수 있다. 모르는 사람은 넘어지면서 남까지 다치게 한다.

 

자동화를 멈출 필요는 없다. 다만, 바닥이 점점 미끄러워지고 있다면 — 누가 물을 붓고 있는지 정도는 확인해봐도 좋겠다. 거울이면 충분하다.