AI 시대의 개발자: 현업 개발자의 솔직한 이야기

다음 내용은 지난 9월에 진행된 동아대학교에서 진행한 강연을 바탕으로 재구성한 글입니다. 다시 한번 좋은 기회를 주신 관계자 분들에게 감사드립니다.

프롤로그

최근 많은 주니어 개발자나 개발자를 지망하는 분들과 이야기를 나누다 보면 빠짐없이 나오는 주제가 있습니다. "AI가 정말 우리 일을 대체할까요?" "지금 개발 공부를 시작해도 될까요?" "앞으로 개발자의 미래는 어떻게 될까요?" 혹은 "AI로 개발하고 있는데 제대로 하는 건지 모르겠어요" "AI 활용이 중요하다던데, AI 없이는 개발을 못할 것 같아요..."

AI에 대한 불안감, 다들 느끼시나요? 왜 우리는 불안할까요? 인간은 막연하고 모호한 것을 두려워하는 경향이 있다고 합니다. AI 시대를 살아가는 개발자로서 지금이 불안한 이유는, 분명 무언가 달라지고 있는 건 알겠는데 그 미래가 쉽게 예측할 수 없기 때문이겠죠.

게다가 요즘 미디어와 SNS에서 끊임없이 쏟아지는 AI Hype, 그리고 이 흐름에 뒤처지면 안 될 것 같은 FOMO(Fear Of Missing Out)가 불안을 더욱 증폭 시키고 있는 것 같습니다. 예전에는 분명 개발에 깊은 지식들을 공유하고 있던 곳들 마저도 AI소식들도 피드가 채워지고 있는 요즘입니다.

그러다 보니 저도 사실 불안합니다. 특히나 AI에 직접적으로 관련해서 일을 하고 있지 않다보니 더욱 미래에 대해 확신하기 어렵습니다. 그럴 때 저는 실제 현업의 분위기를 파악하기 위해 개발 밈을 자주 봅니다. 밈으로 만들어진 유머는 대중이 보편적으로 공감하는 정서를 담고 있기에 실제 개발자들이 무슨 생각을 하고, 무엇을 두려워하는지를 읽어내기에 좋은 창구라 생각합니다. 그래서 이 글 또한 많은 AI와 관련된 밈들을 바탕으로 적어보았습니다.

AI 전문가는 아니니 AI에 대한 전문적인 시각을 담아낸 글은 아니지만, 현업에서 느끼는 경험들을 바탕으로 AI와 함께 살아가는데 도움이 되길 바라는 마음으로 글을 작성해 보았습니다. 이 글을 통해 여러분도 함께 이 불안을 구체화하고, 실제 현실을 현실적으로 바라보면서 불안하다는 이유로 멈춰서는 게 아니라 불확실함 속에서도 내가 원하는 게 무엇이고 무엇을 해야 할지를 찾아가는데 도움이 되기를 바랍니다.

AI 시대를 살아가는 개발자 - AI가 개발자를 대체할까?

"AI가 정말 개발자를 대체할까?"

AI가 많은 직업을 대체할 거라는 이야기를 계속 듣다 보니, 그리고 특히 개발자 역시 그렇게 될거라고 하니 더욱 불안이 커지는 것 같습니다. 어째서 우리는 AI가 개발자를 대체할 거라고 생각하게 된 걸까요? 그 시작점을 한번 살펴봅시다.

GPT의 등장: 코드를 작성하는 AI

과거에는 단순한 텍스트 에디터에서 코딩을 했습니다. 그러다 알록달록한 에디터가 나왔고, 자동완성과 문법 체크 기능이 생겼습니다. 이제는 너무나 당연한 기능이 되었죠. 'back'을 누르면 자동으로 완성되는 것, 이제 이것 없이는 개발하기 어려울 정도입니다.

그러다 GitHub Copilot이 등장했습니다. 코드 자동완성을 AI 수준으로 확장한 도구였습니다. 기존의 자동완성이 고정된 패턴에서 후보를 찾아주는 것이었다면, Copilot은 문맥을 읽고 다음에 올 코드를 예측해서 제안합니다. 단순한 단어 완성이 아니라, 함수 전체를, 때로는 여러 줄의 로직까지 자동으로 생성해주는 것이죠. 자동완성의 진화였습니다.

"이러한 예측방식의 자동완성을 극한으로 진화시키면 질문에 대한 ‘대답’도 자동완성할 수 있지 않을까?" 이 가설을 검증하려면 막대한 비용이 필요했지만, 누군가 실제로 돈을 태워봤더니 작동했습니다. 그것이 바로 ChatGPT의 등장이고, AI의 패러다임 쉬프트가 일어난 순간이었습니다. AI는 추천 알고리즘이나 머신러닝 등으로 이미 존재했지만, 요즘 AI가 유행하게 된 건 바로 이 '생성형 AI'에 있습니다.

이 새로운 발견, 즉 생성형 AI는 각 도메인에서 다양하게 응용되기 시작했습니다. 개발 영역에서는 Cursor IDE가 나왔습니다. 매번 ChatGPT에 물어보고 복사-붙여넣기 하는 과정이 번거로우니 IDE에 Chat LLM을 통합한 것이죠.

그다음에는 Claude Code 같은 Agent CLI도 등장했습니다. 이제 그마저도 번거롭다며 알아서 해달라는 요구가 나왔고, 이제 요구사항만 적으니 실제로 코드가 자동으로 완성되는 장면을 보게 됩니다. 나아가 스스로 구글 검색도하고 실행하고 버그를 수정하는 모습이 꼭 개발자를 대신하는 것 처럼 보입니다.

AI가 개발자를 대체할거라더라.

이제 자동완성과 개발자 도우미를 넘어, 인간의 언어로 실제 코드까지 생성하는 도구로 진화하면서 사람들은 이것을 단순한 도구가 아닌 개발자를 모방하는 대체품으로 느끼기 시작했습니다. 내가 몇 시간 고민하고 여러 번 틀려가며 작성하던 코드가 몇 초 만에 동작하는 형태로 만들어지는 것을 경험하면서, "이건 완전히 개발자 아닌가? 원하는 거 입력하고 클릭하면 코드를 다 작성해주는데, 앞으로 점점 더 개발자가 할 일이 없어지는 거 아닌가?" 이런 생각이 들 만도 합니다.

그러면서 "AI가 초급 개발자를 대체할 수 있다." "더 이상 개발자 채용 안 할 것" 과 같은 CEO들의 발언이 나오고 실제로 미국에서 대량해고들도 진행이 되었습니다. 실제로 미국 컴퓨터 프로그래머 일자리는 2년 동안 27.5%나 감소했습니다.

실제로 한국에서도 채용 공고가 줄어들고, 면접 기준은 점점 높아지고, "AI 시대에 개발자가 필요할까?"라는 질문이 커뮤니티마다 넘쳐났습니다. 실제로 일부 기업들은 "AI로 개발 효율을 높여 인력을 축소하겠다"고 발표했고, 주변에서는 "지금 개발 공부 시작해도 될까요?"라는 불안한 질문들이 쏟아졌습니다. 실제로 현업에 있는 개발자들들은 어땠을까요? AI가 개발자들을 대체해 나가고 있을까요?

개발자들이 AI를 가장 열심히 쓴다

그런데 재미있는 건, 실제 현업 개발자들이 AI를 바라보는 모습입니다. 나를 대체할지도 모른다는 녀석을 가장 반기고 환영하고 열심히 사용하고 있답니다.

사실 코딩은 힘들어요

맞아요. 여러분도 느끼겠지만 개발은 굉장히 즐거운 창작행위이지만 코딩은 참 어렵습니다. 코딩이란 정신적 시간과 노동력이 많이 소요되는 작업입니다. 특히나 복잡하고 어려운 문제들이 아니라 매우 단순한 작업들일지라도 컴퓨터가 문제없도록 만들어내는 작업은 개발의 난이도와 무관하게 코딩에 품이 많이 들어가는 작업이었습니다.

그래서 과거 IT 산업의 가장 큰 병목은 바로 '코딩 노동력'이었습니다. 기획하고 디자인 끝나고 실제 구현에 들어가는 코딩 작업에는 문제의 난이도와 관계없이 많은 시간과 비용이 소요되었습니다. IT는 첨단 산업이지만 동시에 매우 노동집약적인 구조를 가진 산업이었습니다. 그야말로 사람을 갈아 넣어서 결과를 만들어내야 했죠. 일부는 아주 어려운 문제를 해결해야 했지만 그렇지 않은 다수의 코딩 작업을 필요했습니다.

구로의 등대, 자발적 야근, 포괄 임금제, 마감과 크런치 모드... 라쿠라쿠가 있는 게 복지라고 하고, 40살이 되면 치킨집을 차린다는 전설이 있는 IT업계가 이런 무시무시한 곳이된 이유도 바로 코딩의 생산성 문제였습니다. 모든 것을 0과 1로 된 논리에 맞게 작성하지 않으면 계속해서 에러를 내뱉고 버그를 내뱉는 살벌한 곳이었죠. 개발자에게 야근이란 일상과도 같았습니다.

그래서 개발자는 생산성에 목숨을 건다

개발자들은 스스로의 환경을 개선하고 생산성을 높이기 위해 온갖 수단을 동원해왔습니다. 개발의 역사는 곧 기술스택의 발전사이고 대부분의 특정한 문제를 해결하기 위한 도구나 패러다임으로 귀결됩니다. 가장 앞선 정보를 얻을 수 있는 개발자 컨퍼런스의 대다수의 주제는 결국 "우리는 이런 문제가 있는데 그래서 이렇게 생산성을 올렸습니다" 입니다. 그러니 AI가 개발자의 생산성을 올려준다면 사용하지 않을 이유가 없었습니다.

실제로 2025년 스택 오버플로우 개발자 설문조사에 따르면, 응답자의 84%가 현재 AI 도구를 사용 중이거나 사용할 계획이라고 답했습니다. 그 누구보다 개발자들이 가장 열심히 AI를 사용하고 있는 것입니다.

누구보다도 열심히 AI를 쓰는 개발자들

ChatGPT 출시 이후 AI 활용에 대한 미디어의 기대는 엄청났습니다. "모든 산업이 AI로 재편된다", "일상이 완전히 바뀔 것이다", "직업의 판도가 달라진다" 같은 거창한 이야기들이 쏟아졌죠.

실제로 많은 사람들이 AI를 다양하게 활용하고 있습니다. 검색을 대신해서 정보를 찾고, 공부를 도와주는 과외 선생님이 되기도 하고, 이야기를 만들며 놀기도 합니다. 특히 심리적으로 힘들 때 대화 상대가 되어주거나 고민을 들어주는 용도로 쓰는 경우도 적지 않습니다. 누군가에게는 실제로 의미 있는 도움이 되고 있는 셈이죠.

그렇지만 미디어가 말하던 그 거창한 변화와 비교하면, 실제 활용의 깊이는 다른 것 같습니다. 일을 대체하거나 삶을 완전히 바꾸는 수준이라기보다는, 필요할 때 찾아가서 쓰는 도구 정도로 자리잡은 느낌입니다.

개발자는 어떨까요? 개발자들은 조금 다른 모습을 보이고 있습니다. 앞서 언급한 84%라는 수치가 말해주듯, 개발자들 사이에서 AI 도구는 이제 업무의 일부로 완전히 자리매김한 모양새입니다. 단순히 "가끔 쓴다"가 아니라 "매일 쓰고 있다"는 점에서, 일반적인 활용 수준과는 확연히 다른 양상입니다.

왜 개발자들이 유독 AI를 업무 도구로 깊숙이 받아들이게 된 걸까요? 답은 간단합니다. 앞서 이야기했듯이 개발자는 생산성에 목숨을 거는 사람들이니까요. 개발자들은 코딩에 들어가는 시간과 노동력을 줄여주는 도구라면, 그것이 완벽하지 않더라도 일단 써보고 활용할 방법을 찾아왔습니다. 생산성을 높이는 도구라면 무엇이든 시도해보는 개발자들의 특성상, AI는 매력적이면서 거부할 이유가 없는 도구입니다.

미디어에서는 AI가 개발자를 대체할 것이라는 뉘앙스를 풍기지만, 실제로는 개발자가 AI를 최대한 부려먹고자 하고 있는 형국입니다. 그럼에도 아직 개발자에게 AI는 성에 차지 않는 존재입니다. (일해라 핫산!) 실제 현업에서 AI는 개발자를 대체하지 못하고 있습니다.

---

현업 개발자들의 진단: 아직은 대체하기 어렵다

기대와 현실의 괴리

많은 사람들이 AI가 "딸깍" 하면 완성품을 만들어줄 거라고 기대했습니다. 하지만 실제 AI를 적용해보면 기대와는 사뭇 다릅니다. 매번 내가 원하는 대로 수행하지 않으며 까닥잘못하면 엉뚱한 일을 저지르고 합니다. 내가 기대했던 것들은 나 대신 알아서 일을 해줄 것 같았지만 현실은 내가 잘하고 있는지 항상 감시를 해야만 하는 것이죠.

심지어 처음에는 원하는대로 잘 수행하다가도 조금만 해야할 것들이 많아지만 그때부터는 말도 제대로 듣지고 않고 자신만의 고집을 부려가며 되려 이걸 수습하는데 훨씬 더 오랜 시간이 필요하곤 합니다.

스택 오버플로우 설문에서 AI 도구의 정확성을 신뢰하는 개발자(33%)보다 불신하는 개발자(46%)가 더 많았으며, 결과물을 '매우 신뢰한다'고 답한 비율은 단 3%에 불과했습니다. 코딩에 들어가는 시간은 분명 절약되었지만, 검수까지 포함하면 전체 개발 시간은 크게 달라지지 않았습니다. 전체 66%에 달하는 개발자들은 AI가 만드는 결과물에 대해서는 신뢰하지 못한다고 대답하고 있습니다.

실제로 코딩을 하는데 들어가는 시간을 줄여주는건 분명하지만, 그걸 수습하는 과정과 시간을 생각하면 사실 극적으로 생산성을 올려주지는 못하고 있는 형국입니다.

그래서 현업 개발자들 사이에서는 "... 미디어를 볼 때는 'AI가 나를 대체하면 어쩌지?'라고 불안한데 막상 현실에서 AI를 쓰다 보면 '아니! 제발 좀 답답하네. 좀 더 해주면 안되나?' 라는 생각이 든다는 것입니다. 아마 대부분 비슷한 감정이라고 생각합니다. 막상 AI를 쓰다보면 "아니!" 라고 말하는 순간을 자주 목도하면서 다들 답답한 순간들을 많이 겪어 봤을 거라고 생각합니다.

언젠가는 나보다 더 뛰어난 결과를 만들지 않을까?

🤔 아직 AI의 성능이 모자라서 그렇지... ChatGPT가 나온지 이제 겨우 3년인데 발전속도를 생각하면 곧 따라 잡지 않을까요?

그렇지만 AI가 성장하는 속도나 최근에 계속해서 새롭게 만들어 지고 있는 서비스나 발전하는 속도를 보면 특히나 초창기에 등장했던 AI의 수준에 비해 그 속도가 너무 가파르다 보니 이대로 가면 대체가 가능한 지점이 올 수도 있겠다 하는 생각이 들기도 합니다. 실제로 AI의 성능은 계속해서 올라가고 있으니까요.

그렇지만 성능이 나아지고 있음에도 AI를 현업에서 사용하면 분명 편리하고 유용한 도구인데 왜 급격한 생산성을 가져오지 못하고 개발자를 대체하지 못하고 있는 걸까를 고민해봤습니다. 그리고 지금 현재의 AI 방식의 패러다임이 바뀌지 않는다면 구조적으로 개발자를 대체하기란 쉽지 않겠다는 결론은 내렸습니다.

현재의 AI방식이 개발자를 왜 대체하기 어려운가에 대한 구조적 고찰

가장 먼저 이해해야 할 것은, 현재의 AI 도구가 기존 개발 도구들과 근본적으로 다른 종류의 도구라는 점입니다. AI가 기존 개발 도구와의 가장 큰 차이점이라고 한다면 바로 "인간의 언어"를 사용하는 "비결정적 도구"라는 점입니다.

AI가 기존 개발 도구와의 가장 큰 차이점
인간의 언어 + 비결정적 도구

이유 1. 인간 언어와 컴퓨터 언어의 본질적 차이 - 언어의 모호성

인간의 언어는 구조적으로 모호성을 내포하고 있습니다. "햄찌씨~ ㅅㅑ~한데 빵!!!! 감동 있게... 뭔 말인지 알지? 부탁해!" 비록 우스개소리이지만 실제로 우리는 대개 이런 감각적으로 소통을 하곤 합니다. 내가 언어로 표현하기는 어렵지만 느껴지는 무언가가 있기에 이걸 전달하다보면 모호해지기 마련이죠.

"햄찌씨~ ㅅㅑ~한데 빵!!!! 감동 있게... 뭔 말인지 알지? 부탁해!"

인간의 언어는 개념적이고 추상적으로 작동하기 때문에 실체가 없고 막연한 단어를 얼마든지 만들어낼 수 있습니다. 또 다른 예를 들어볼까요? 아래 그림을 보고 질문에 답해보세요. "한 무더기의 돌은 몇 개부터일까요?" "이 그림에는 몇 개의 돌 무더기가 있나요?" 무더기라는 말 자체가 모호하고 막연하고 추상적인 단위이기에 몇 개부터 무더기가 되는지는 상황과 맥락과 사람마다 다 다르기 때문입니다. 그렇지만 인간은 이러한 막연하고 추상적인 소통에서 어려움을 겪지는 않습니다.

"한 무더기의 돌은 몇 개부터 인까요?"

또한 현실 세계는 언어 세계보다 훨씬 더 넓은데, 인간은 태생적으로 그것을 언어로 구체적으로 표현하는 데 서툽니다. 그냥 지금 눈앞에 보이는 보고 최대한 구체적인 언어로 말해보려고 시도해보세요. 상당히 어려움을 느낄거에요. 우리는 대충 막연히 이해하고 말하는 능력인 추상화를 잘하도록 진화를 했습니다.

그러나 컴퓨터에게는 "샤하게 빵"이나 "한 무더기"와 같은 단어들로는 실행 가능한 명령이 될 수 없습니다. 0과 1로 이루어진 수를 연산하는 계산기로 시작한 컴퓨터에게 모호함이란 존재할 수 없으며, 모든 것이 명확해야 작동합니다.

"요즘 유행하는 스타일의 버튼을 만들어 줄래?"

그래서 AI 도구를 사용하게 되면 위와 같이 같은 입력을 넣어도 그 결과가 달라집니다. 기존의 컴퓨터로 만든 도구에서는 상상하기가 어려운 방식이죠. 인간의 언어의 모호성과 비결정적론 도구가 결합된 구조는 컴퓨터가 완벽한 결과를 만들어내고 그 결과가 요구사항과 완전히 일치하도록 하는 것은 구조적으로 불가능합니다. 그야말로 코딩가챠인 셈이죠.

이유 2. The Last Mile Problem - 결국 누군가는 명확하게 마무리해야 한다

이러한 이유로 결국 누군가 마지막에는 모호한 인간의 언어가 아니라 구체적이고 명확한 컴퓨터의 언어로 마무리해야 합니다. 그리고 이러한 작업은 여전히 개발자가 해야 하는 역할이죠.

조금 더 생각해보면 다음과 반문을 하게 될지도 모르겠습니다. "인간의 언어로 가능하다면, 컴퓨터 언어를 몰라도 되는 거 아닌가? 인간의 언어중에서 모호하지 않는 언어로 시키면 되는거 아냐?" 그럴지도 모르겠네요. 하지만 그러기 위해서는 자신의 요구사항을 컴퓨터가 실행 가능한 수준으로 매우 구체적이고 명확하게 표현할 수 있어야 합니다. 그러기 위해서는 상당한 전문가적 소양이 필요하겠지요.

그리고 설사 인간의 언어로만 가지고 지시가 가능하다라고 해도 인간은 구체적으로 말하는 것 자체를 매우 어려워하기 때문에 필요하다면 분명 이 일을 누군가에게 위임할 것입니다. 그리고 그 역할을 하는 사람이 개발자가 되겠죠. 더구나 앞서 살펴 봤듯이 구체적으로 표현하는 도구로써 인간의 언어는 썩 효과가 있지 못할테구요. 설령 구체적으로 다 표현했다 하더라도, 그 결과가 좋은지 나쁜지 누가 판단하고 결정할 것인가요?

이유 3. 판단과 책임 - AI는 결정권자가 될 수 없다

정말로 한발 더 나아가 "판단과 결정마저도 AI가 더 잘할 수 있지 않을까요?"라고 물을 수도 있습니다. 사실 현재 AI를 만들고 있는 회사들이 만들어보고자 하는 방향이기도 합니다. 일론머스크는 MacroHard라고 하는 회사를 만들면서 사람이 없는 AI만 존재하여 "문제 정의도 지시도 방향성도 구현도 판단도 다 AI가 하면 되지 않나? 사람 없는 회사를 만들어보자!" 라고 비전을 말하기도 했죠.

하지만 여전히 저는 회의적입니다. 알아서 작동하는 AI가 무엇을 하려고 할지, 그것이 옳은 행동인지 아닌지 판단하고 결정하는 권한을 다시 AI에게 위임할 수 있을까요? 위임을 할 수 있다고 하면 어디까지 가능할까요? 만약 AI가 더 똑똑하고 믿을 수 있다고 해서 핵폭탄 발사 권한을 이양할까요? 혹은 AI를 사용해서 문제가 발생을 하면 AI를 만든 회사에서 책임을 질까요? 현재의 AI는 인간 사회에서 아직 결정에 대한 책임을 질 수 없다는 구조적 한계가 있습니다.

이유 4. 평균지향의 한계와 정답이 없는 열린 세계

현재의 AI는 학습 분포의 통계적 패턴을 따라가는 본질적 특성을 가집니다. 즉, 평균을 지향하며 새로운 기술보다는 익숙함을 선택하는 경향이 있습니다. 새로운 기술은 상대적으로 학습 자료가 부족하기에 AI는 배운 대로만 작성할 수 있어 프론티어나 얼리 어댑터가 되기 어려우며 만들어낸 결과가 최선이 아닐 때가 많습니다.

"하지만 알파고는 스스로 기보를 만들어서 인간을 뛰어넘었잖아요?" 맞습니다. 알파고가 스스로 학습하며 사람보다 더 잘하게 된 것을 보면서, 우리는 그림이나 영상, 음악, 개발마저도 AI가 더 잘하게 될 거라고 쉽게 생각하게 됩니다. 특히나 바둑의 경우의 수는 10^170으로 우주의 원자 수(10^80)보다도 훨씬 많다고 하니 말이죠.

그러나 바둑은 19x19 바둑판이라는 고정된 공간, 흑백 돌이라는 제한된 요소, 승패가 명확히 정의된 목표를 가진 닫힌 시스템(closed system)입니다. 경우의 수가 아무리 많아도 유한한 규칙 내에서 모든 가능성을 탐색할 수 있으며, 승리라는 목표가 명확히 정의되어 자체 평가가 가능합니다. 규모가 큰 영역에서 예측 범위가 인간의 사고를 넘어가는, 그 안에 정답이 있는 분야에서는 AI는 분명 인간보다 탁월합니다.

그렇지만 코딩은 기본적으로 열린 시스템(open system)입니다. 간단한 "Hello World" 프로그램만 해도 수백 가지 방식으로 작성할 수 있습니다. 함수형, 객체지향, 또는 완전히 다른 패턴으로 말이죠. 그리고 이 중 어떤 방식이 "정답"일까요? 정답은 없습니다. 상황과 맥락, 팀의 컨벤션에 따라 "그 당시의 최선"만 존재할 뿐입니다. 더구나 이 최선은 고정되어 있지 않습니다. 어제의 최선이 오늘은 레거시가 되고, 오늘의 혁신이 내일은 당연해집니다.

여기서 알파고와 지금의 생성형 AI는 구조적으로 다릅니다. 알파고는 강화학습을 통해 자신의 수를 스스로 평가하고 개선할 수 있었습니다. 하지만 현재의 생성형 AI는 주로 지도학습에 기반하여 인간이 작성한 기존 코드의 패턴을 학습합니다. 코드의 "좋고 나쁨"을 스스로 판단할 명확한 기준이 없기에, 무엇이 더 나은 코드인지 자체적으로 평가하고 개선하는 메커니즘이 부재합니다.

결국 AI는 가장 많이 봤던 평균적인 해법으로 회귀할 수밖에 없습니다. 새로운 프레임워크 도입, 성능과 가독성 사이의 선택, 이런 트레이드오프의 순간에 AI는 판단 기준을 가지고 있지 않습니다. 맥락을 이해하고 최적해를 선택하며, 때로는 검증되지 않은 새로운 기술을 과감히 도입하는 결정은 여전히 개발자의 몫입니다. 정답이 없는 열린 세계에서 길을 찾아가는 일, 그것이 바로 AI가 넘어설 수 없는 개발자의 영역입니다.

이유 5. 환각(Hallucination) - 신뢰의 문제

또 다른 문제가 있습니다. AI의 환각문제입니다. 지금은 검색 결과를 만들기 전에 신뢰있는 내용들을 인터넷에서 먼저 조사하는 RAG와 같은 방식으로 환각을 많이 줄여가고는 있지만 여전히 환각은 존재합니다. 그리로 환각은 없애야 하는 버그가 아니라 AI가 더 창의적인 결과를 만들기 위한 기능이죠. (버그가 아니라 Feature입니다.)

신뢰성을 말하기 위해 잠시 다른 이야기를 해볼까 합니다. 클라우드 서비스에서는 가용성이라는 개념이 있습니다. 클라우드 서비스를 쓰는 경우 문제가 없을거라고 보장해주는 시간이죠. 그리고 우리는 99.9%의 가용시간을 보장한다고 말합니다.

뭔가 99.9% 가용성이라고 하면 안정적으로 들리지만, 이는 연간 8.76시간의 다운타임을 의미합니다. 만약 여러분이 운영하는 서비스가 하루에 한 번씩 몇 분간 먹통이 된다면? 사용자들은 "이 서비스 믿을 수 없다"고 할 것입니다. AI가 99% 정확하다면? 100번 중 1번은 완전히 잘못된 답을 줍니다. 그리고 이러한 내용은 심각한 문제를 만들어 낼 수도 있습니다.

"그렇지만 사람은 더더욱 100%가 아니지 않나요? 오히려 사람이 더 많이 실수 할텐데요?" 맞습니다. 그러나 사람은 상식안에서 활동합니다. 사람의 실수는 대개 예측 가능한 범주에 있고, 누군가는 혹은 모두가 함께 책임을 집니다. 사람은 "이 문제를 해결하기 위해 우선 운영 DB를 초기화하겠습니다"와 같은 맥락 없는 결정을 하지는 않습니다. 그렇기에 사람의 실수는 인간의 시스템이라는 범주 내에서 통제 가능합니다.

그러나 AI의 환각은 다릅니다. 환각은 현재로서는 엄연히 AI 기능의 일부이며, 주어진 데이터의 통계적 패턴에 따라 그럴듯한 답을 생성할 뿐입니다. 따라서 기술적으로는 말이 되지만 맥락적으로는 재앙인 코드를 아무렇지 않게 제안할 수 있습니다. 누군가는 최종 결정권자로서 코드와 실행에 대한 책임을 져야 합니다.

실제로 AI가 사고하는 과정에서 특정 문제를 해결하기 위해서 "... 이 문제를 해결하기 위해 우선 운영 DB를 초기화가 필요합니다." 라는 말도 안되는 판단을 했고 이를 실행함으로써 운영하는 데이터베이스가 삭제되는 사건이 있었습니다.

물론 이러한 이유들은 어디까지나 지금 방식의 AI라는 전제입니다. 언젠가 완전히 새로운 방식의 혁신이 등장한다면 이야기는 달라질 수 있겠죠. 하지만 적어도 현재 AI의 구조—인간의 언어로 작동하는 비결정적 도구, 평균을 지향하는 통계적 패턴, 자체 평가 메커니즘의 부재—를 가진 이상, 모호한 언어를 명확한 코드로 번역하고, 수많은 최선 중 맥락에 맞는 선택을 하며, 그 결과에 대한 판단과 책임을 지는 일에는 반드시 최종 결정권자가 필요합니다. AI는 분명 개발자의 강력한 도구가 될테지만, 적어도 현재의 AI 방식이라면 개발자는 여전히 최종 단계의 코드를 결정하고 실행에 대한 책임을 지는 역할로 남을 것입니다.

AI 시대 개발자의 역할

지금까지 우리는 AI가 개발자를 대체할 수 없는 구조적 이유를 살펴봤습니다. 인간 언어의 모호성과 비결정적 도구라는 AI의 본질, 그래서 누군가는 명확하게 마무리해야 한다는 마지막 마일의 문제, 판단과 책임을 질 수 없는 AI의 한계, 정답이 없는 열린 세계에서 평균으로 회귀할 수밖에 없는 구조, 그리고 환각으로 인한 신뢰의 문제까지요.

이 다섯 가지를 관통하는 핵심을 정리하면 결국 세 가지 근본적인 문제로 수렴됩니다.

첫째, 인간 언어의 모호성과 컴퓨터의 엄밀함 사이의 간극을 누가 메울 것인가.
둘째, 정답이 없는 문제에서 어떤 선택이 최선인지 누가 판단하고 결정할 것인가.
셋째, 그 결과에 대해 누가 신뢰를 담보하고 책임을 질 것인가.

그렇다면 개발자의 역할은 무엇일까요? 저는 이렇게 정의를 한번 해보았습니다. 인간의 모호하고 막연한 요구사항을 컴퓨터가 해결할 수 있는 문제로 재정의하고, 이를 컴퓨터 언어로 구현하며, 그 결과가 올바른지 판단하고 책임지는 것. 이것이 바로 개발자가 하는 일입니다. AI는 이 과정에서 강력한 도구가 될 수 있지만, 최종적으로 이 역할을 수행하는 주체는 여전히 개발자입니다.

하지만 여기서 또 다른 질문이 생깁니다. "그렇다고 한들 AI가 발전하면 그런 역할은 소수의 사람들에게만 기회가 생기는 게 아닐까요?" 실제로 많은 사람들이 이런 우려를 합니다. AI가 개발자를 완전히 대체하지는 못하더라도, 개발 생산성이 10배, 100배 높아지면 필요한 개발자의 수 자체가 급격히 줄어들 수밖에 없지 않겠냐는 거죠. 그렇다면 결국 소수의 엘리트 개발자만 살아남고, 나머지는 설 자리를 잃게 되는 건 아닐까요?

이 질문에 답하기 위해 잠시 다른 산업을 살펴볼 필요가 있습니다. 역사를 보면 자동화는 늘 있어왔고, 그 결과는 산업마다 완전히 달랐습니다. 대표적으로 농업과 자동차 산업을 비교해볼까요? 둘 다 매우 노동집약적 산업이었고 20세기에 극적인 자동화를 겪었던 산업입니다.

농업은 어떻게 됐나요? 트랙터와 콤바인이 등장하면서 생산성이 비약적으로 증가했고, 실제로 농업 종사자는 급격히 줄어들었습니다. 100년 전만 해도 인구의 대다수가 농업에 종사했지만, 지금은 전체 인구의 몇 퍼센트에 불과합니다. 왜 그랬을까요? 농업은 근본적으로 닫힌 시장이었기 때문입니다. 경작할 수 있는 토지는 한정되어 있고, 사람들이 먹을 수 있는 식량의 양도 한계가 있습니다. 생산성이 높아져도 시장이 그만큼 커지지 않으니, 필요한 사람의 수는 줄어들 수밖에 없었죠.

그런데 자동차 산업은 어떨까요? 자동화된 공장 라인이 도입되고 로봇이 용접을 하고 조립을 하게 됐지만, 자동차 산업 종사자는 오히려 늘어났습니다. 왜 그럴까요? 자동차는 열린 시장이었기 때문입니다. 생산성이 높아지면서 자동차 가격이 내려갔고, 더 많은 사람들이 자동차를 살 수 있게 됐으며, 시장 자체가 폭발적으로 성장했습니다. 더 다양한 종류의 자동차가 만들어지고, SUV도 나오고, 전기차도 나오고, 자율주행차도 개발되면서 해결할 수 있는 문제의 영역이 계속 확장됐죠. 자동화가 산업을 축소시킨 게 아니라 확장시킨 경우입니다.

그렇다면 IT는 어떨까요? AI라는 자동화의 물결로 인한 변화는 농업처럼 될까요, 아니면 자동차처럼 될까요? 솔직히 아직은 알 수 없습니다. 어쩌면 둘 다 아닌, 완전히 새로운 방식으로 흘러갈 수도 있겠죠. 소프트웨어가 해결할 수 있는 문제의 영역이 계속 확장되고 있는지, 아니면 어느 순간 한계에 부딪힐지 한번 생각해보면 좋겠습니다.

---

정말 대체되지 않고 있을까? - AI가 가져다 준 변화

AI가 생산성을 극대화하지는 못했고, 여전히 개발자는 필요하며 구조적으로 보면 AI가 개발자를 대체하기는 어렵습니다. 그렇다면 정말 안심해도 되는 걸까요? 최근 몇 년간 개발 현장에서는 묘한 변화들이 감지되고 있습니다. 특히 주목해야 할 점은 AI로 인해 시장이 요구하는 수준은 계속 올라가는데, 정작 개발자의 실제 수준은 AI로 인해 떨어지고 있다는 점입니다.

변화 1. 채용 시장의 변화 - 공급은 늘었고 경쟁은 심해졌다

코딩 노동력은 늘 부족했기에 개발을 더 쉽게 하려고 노력했더니 실무에 필요한 코딩은 점점 더 쉬워졌습니다. 어느 순간 IT는 상당히 돈이 되는 시장이 되었고 코딩 노동력의 수요가 커지자 공급을 늘리자는 움직임이 있었습니다. 전공을 해도 현장에 필요한 실무 능력이 부족하다며, 전문성과 기본기보다 실무 능력 위주로 가르치고 공부했고, 일부는 실제로 그것만으로도 밥값을 할 수 있었습니다.

"누구나 입문할 수 있어요! 비전공자들도 할 수 있어요!" 코로나 시기 IT의 흥행을 발판으로 채용을 늘렸고, 몰린 자본으로 개발자의 몸값과 복지가 올라가며 코딩 노동력을 공급하기 위해 학원들이 생겨났습니다. 그리고 수많은 코딩 노동력을 공급되었습니다.

그러나 모바일/인터넷 IT 성장 동력의 한계가 왔고, 어느덧 AI로의 관심이 전환되었습니다. 이제 사업과 투자는 축소가 되었는데 이미 너무 많이 뽑아둔 노동력은 잉여가 되었습니다. 예전 같지 않은 상황에 눈치를 보며 채용 동결을 하고 싶었고, 때마침 좋은 핑계거리인 AI가 있었죠. "AI로 대체하겠다. AI로 인력을 대체할 수 있는 방안을 찾아봐라."

개발자 채용 시장은 예전과 같은 호황은 더 이상 아니게 되었습니다. 어찌보면 그때가 비정상적이었고 지금은 원래의 자리로 돌아온 것일 수 있습니다. 그렇지만 이미 많은 공급은 이루어졌고 황금기는 막을 내리면서 자리는 없기에 경쟁이 더 심화되었습니다. 주니어들이 AI로 인해 직접적으로 대체되지는 않았지만, 성장이 정체된 IT 생태계와 변화하고 있는 산업 구조에서 코딩 노동력을 확보해야 한다는 생각에는 제동이 걸린 상태입니다.

그런데 AI는 평균 수준은 한다는 게 문제입니다. 이제 신입 개발자에게는 "최소한 AI보다는 잘해야" 하는 새로운 기준이 생겼습니다. AI 덕분에 개발이 쉬워졌다고 들어왔는데, 막상 취업 시장에 나와보니 문턱이 더 높아진 역설적 상황입니다. AI로 누구나 코드를 작성할 수 있게 되면서 공급은 늘고 있지만 정작 기업들이 원하는 건 "AI를 부려먹을 수 있는" 수준의 개발자입니다.

단순히 AI가 만든 코드를 복붙하는 수준이 아니라, 개발 기본기가 확실하면서도 즉각적인 실무 능력을 갖추고, AI를 효과적으로 활용할 줄 알며, 사람들과 소통과 협업을 잘하는 사람을 원하고 있습니다. 결국 "개발 잘하고, 일 잘하고, 소통 잘하는 사람"을 원한다는 겁니다. 사실 이런 사람은 예전에도 선호했습니다. 다만 예전에는 개발자 공급이 부족해서 그 기준을 낮춰서라도 뽑았다면, 이제는 공급이 많아진 시장에서 본래의 기준, 아니 그 이상의 기준을 원하게 되었습니다.

그 결과 채용 과정은 훨씬 더 까다로워졌습니다. 코딩 테스트, 과제 테스트, 라이브 코딩, 기술 면접, 실무 면접, 컬쳐핏 면접, 인성 검사까지... AI 시대가 되면서 채용은 줄었는데 기대 수준은 더 높아지면서 개발 취업 허들은 훨씬 더 높아졌습니다. 공급이 많아진 시장에서 기업들은 더 신중하게, 더 꼼꼼하게 개발자를 선별하고 있습니다. AI가 평균이 되어버리니, 이제 평균적으로 하는 정도로는 변별력이 생기지 않는 시대가 되었습니다.

변화 2. 가장 위험한 부작용 - 본질의 퇴화

시장은 더 까다로워졌는데, 정작 개발자들의 실력은 어떻게 되고 있을까요? 여전히 잘하는 개발자는 찾기가 어렵습니다. 코딩이 쉬워지고 공급자를 늘리는 교육을 주로 하다 보니 기초보다는 당장 실습 가능한 실무 위주의 교육이 되었고, 거기에 물어보면 대답해주는 AI의 등장으로 우리는 AI에게 너무나 쉽게 "해줘~"라고 하게 되었습니다.

뇌의 가혹한 진실이 있습니다. 쓸 필요가 없으면 퇴화시켜버립니다. 근손실처럼요. 그래서 특히 요즘은 문제를 마주했을 때 '고민이 길어지는 것' 자체를 견디지 못하고 너무 쉽게 AI에게 즉각적인 답을 요구하는 모습을 자주 봅니다. 마치 우리가 쇼츠의 즉각적인 자극에 익숙해져 긴 호흡의 영상을 견디기 힘들어하듯 말이죠.

AI가 나 대신 공부하고, 나 대신 고민하고, 나 대신 코딩하게 두는 순간, 우리는 막막한 문제를 붙들고 씨름하며 얻어내는 개발자 고유의 문제 해결 능력을 잃게 됩니다. 자칫 AI 의존성이 생기고 기본 코딩 능력이 저하될 수 있습니다. 코딩이 쉬워지면서 오히려 코딩을 더 잘할 수 있게 하는 기회와 환경을 AI에게 빼앗기고 있는 중입니다.

변화 3. 개발 현장의 부작용 - 평균으로의 수렴

"AI가 10배의 생산성을 가져다줄 거예요!" 하지만 현실은 어떤가요? 분명 코드를 작성하는 건 더 쉬워졌지만, 실제로 생산성이 올라가지는 않았습니다. 왜일까요? AI로 인해 개발 현장에도 새로운 부작용이 생겼습니다. AI는 분명 편리하기는 하지만 항상 정답은 아니기에 그걸 확인하고 걸러내는 데 시간이 쓰이기 때문입니다.

또한 AI로 인해 개발 현장 자체에도 구조적인 변화가 일어나고 있습니다. 가장 눈에 띄는 건 기술의 표준화가 급격히 가속화되고 있다는 점입니다. AI는 학습 데이터가 많은, 즉 가장 대중적으로 사용되는 기술일수록 압도적으로 더 나은 답변을 내놓습니다. 문제는 AI를 사용하다 보면 자연스럽게 AI가 계속해서 특정 기술 스택을 제안한다는 겁니다. 예를 들어 최신 라이브러리를 쓰려고 하면 AI는 자기가 잘 아는 보편적인 라이브러리로 대체하는 답변을 내놓습니다. 매번 "아니야, 이게 아니라 저걸로 해줘"라고 설명하는 것도 귀찮고, 결국 AI가 제안하는 대중적인 기술을 따라가는 게 편해집니다.

특히 개발을 AI를 통해 배우는 경우라면 이 문제는 더 심각합니다. AI가 제시하는 기술 스택과 패턴이 표준이고 정답인 줄 알게 됩니다. AI가 계속 React를 제안하면 React가 정답이고, AI가 계속 특정 패턴으로 코드를 작성하면 그게 베스트 프랙티스라고 생각하게 되면서 다른 선택지에 대한 고민을 해보기 보다는 AI가 제시하는 평균적인 기술 생태계 안에서 개발을 배우게 됩니다.

그 결과 새로운 프레임워크나 라이브러리를 도입하려고 할 때도 "AI 지원이 잘 되나?"하는 우려가 생기고, 팀 내에서 급진적인 기술 스택을 제안하면 "그거 AI한테 물어보면 제대로 답 나와?"라는 질문이 나옵니다. 성능이나 개발자 경험 측면에서 객관적으로 더 나은 기술이어도, AI와 계속 씨름하며 개발하느니 AI가 편하게 서포트해주는 익숙한 기술을 쓰는 게 낫다는 판단을 하게 되는 것이죠. 결국 신규 기술의 정체 현상이 나타나게 됩니다. 새로운 기술을 만들고 도입해야 할 동기는 약해지고, 대신 AI가 코드를 잘 생성해주는 소수의 검증된 기술로만 생태계가 고착되고 있습니다.

기술 스택 뿐만 아니라 코드의 관점에서도 마찬가지입니다. AI를 통해 코딩을 하다보면 나중에 AI가 이해하기 쉬운 평균적인 패턴으로 수렴하게 되는 경향을 보입니다. AI를 통해 코드를 수정하다보면 더 좋은 코드를 만들기 위해서 노력을 하더라도 AI가 다시 평균적인 코드로 만들어 버리는 악순환을 경험하게 됩니다.

특히 주니어 개발자들 사이에서 이 문제가 더 두드러집니다. 경험이 부족한 상태에서 AI가 제시하는 코드를 보면 문법적으로 완벽하고 구조도 깔끔해 보이기에, "AI가 만든 게 내가 고민해서 짠 것보다 더 나을 거야"라고 생각하기 쉽습니다. 그래서 AI가 제안한 범용적인 패턴을 그대로 받아들이고, 프로젝트의 특수한 상황이나 성능 요구사항을 고려한 최적화에 대해서도 AI의 의견을 더 중시하게 됩니다. 심지어 스스로 더 나은 방법을 떠올렸을 때도 "근데 AI는 왜 이렇게 안 했을까? 내가 뭘 놓친 건 아닐까?"하며 자신을 의심하고 결국 AI의 평균적인 답으로 돌아가곤 합니다.

결국 개발 생태계 전체가 혁신보다는 안전을, 최적화보다는 평균을 선택하게 되는 구조적 변화가 일어나고 있습니다.

---

그래서 AI를 안 써야 할까?

당연히 그렇지 않겠죠. AI에는 부작용이 있지만 여전히 긍정적인 측면이 많습니다. 또한 AI시대로의 전환은 거스를 수 없는 시대의 변화가 되어 가고 있습니다. 미디어에서 말하는 것처럼 AI가 개발자를 막 대체할 전문가 수준은 아니라서 내 일을 온전히 대신 해주지는 못하지만, 확실히 예전보다 편리한 도구입니다. 변화에 적응하는 것 또한 개발자에게 요구되는 중요한 덕목이죠.

AI는 이미 문화가 되었다

인간은 편리함을 경험하면 역행하지 않습니다. 계산기가 등장했을 때도, 자동차가 나왔을 때도, 스마트폰이 나왔을 때도 마찬가지였습니다. 처음엔 "이게 우리를 나태하게 만들 거야", "기본기가 사라질 거야"라는 우려가 있었지만, 결국 모두가 사용하게 되었죠. 이미 진화와 변화는 시작되었습니다.

AI를 개발의 도구로 사용하는 것은 이미 문화가 되어버린 것 같습니다. 제가 한 비공식적인 사내 설문조사에서는 이제 첫 검색은 구글이 아니라 LLM으로 한다고 모두가 대답했습니다.

여전히 생각하고 언어를 만드는 일은 어렵기에 조금 서툴러도 없는 것보단 낫습니다. 이미 만들어진 진화를 되돌리지는 못합니다. "옛날에는 말이야, ChatGPT 없이 코딩을 했대!" 이런 세상은 이미 와버렸습니다. 이제 AI 없이 개발하는 건 마치 자동완성 없이 코딩하는 것처럼 불편하게 느껴질 정도입니다.

결과적으로 전체 생산성이 극적으로 올라가지 않더라도, 내가 쓰는 에너지가 덜 든다면 그것이 편리이기에 만족합니다. 그리고 AI가 생산성을 낼 수 있도록 하는 게 개발자의 몫이기에 인지하고 잘 쓰려고 해야 합니다.

AI 없이 개발하는 능력이 아니라 그렇기에 AI를 더 잘 쓰는 기본기

문제는 "AI를 쓰느냐 마느냐"가 아닙니다. "어떻게 쓰느냐"입니다. 앞서 살펴본 것처럼 AI 의존으로 인한 기본기 퇴화는 분명 심각한 문제입니다. 그렇다고 "AI를 쓰지 말고 순수하게 직접 코딩하자"는 게 현실적인 답일까요? 이미 AI는 개발 문화의 일부가 되었고, 실제로 채용 시장을 보면 기업들이 원하는 것도 달라지고 있는 것 같습니다.

기업에서는 채용에서는 "AI 없이도 개발할 수 있나요?"가 아니라 "AI를 얼마나 효과적으로 활용할 수 있나요?"를 질문합니다. AI를 억지로 안 쓰는 방식으로 훈련하는 것도, AI에게 모든 것을 맡기는 것도 답이 아닙니다.

중요한 건 AI를 도구로서 제대로 부릴 줄 아는 능력입니다. 개발자는 생산성에 목숨 거는 사람들이니 AI를 잘 써야죠. 다만 "잘" 쓴다는 게 무엇인지, 활용과 의존의 경계가 어디인지를 분명히 인지하고 있어야 합니다.

어쩌면 기회일 수도

한편으로 생각해보면, 이건 기회일 수도 있습니다. 과거에는 개발을 시작하는 게 꽤 어려웠습니다. 개념을 이해하고, 문법을 익히고, 에러를 해결하는 법을 터득하기까지 상당한 시간과 노력이 필요했죠. 그 과정에서 "나는 이게 안 맞나봐"하고 포기하는 경우도 많았을 겁니다.

그런데 AI는 이 초기 진입 장벽을 낮춰줍니다. "로그인 기능을 만들고 싶어"라는 막연한 생각만 있어도, AI의 도움을 받아 실제로 작동하는 코드를 만들어볼 수 있습니다. 물론 그것만으로는 진짜 개발자가 될 수 없습니다. 하지만 적어도 시도해볼 수 있는 길이 생겼다는 것, 그리고 그 과정에서 "이게 재미있네, 더 알고 싶다"는 동기를 얻을 수 있다는 건 분명 의미가 있습니다.

이미 경험이 있는 개발자들에게도 마찬가지입니다. 백엔드 개발자가 프론트엔드를 시도해보거나, 웹 개발자가 모바일을 경험해보는 것이 예전보다 훨씬 쉬워졌습니다. AI가 초기 학습 곡선을 완화시켜주기 때문이죠.

결국 이 "시도할 수 있는 기회"를 어떻게 활용하느냐입니다. AI가 만들어준 코드를 복붙만 하고 끝낸다면 그건 기회를 낭비하는 것입니다. 하지만 AI가 만든 코드를 이해하려 노력하고, 왜 이렇게 작성했는지 분석하고, 더 나은 방법을 고민한다면 그건 훌륭한 학습 도구가 됩니다.

결국 AI를 잘못 쓰면 우리를 퇴화시키지만, 잘 쓰면 더 멀리 갈 수 있게 해주는 도구입니다. 그리고 그 선택 또한 AI 시대를 살아가는 우리의 몫이 되었습니다.

---

AI 시대 개발자의 생존 전략

그럼 AI를 어떻게 잘 사용할 수 있을까요? AI를 잘 활용한다는 건 결국 업의 본질을 제대로 이해해서 적절한 질문을 만들고, 업무 파이프라인 중에서 AI가 대체할 수 있는 부분을 찾아내는 안목, 그리고 그 결과를 평가하고 판단하는 능력을 의미합니다.

AI를 잘 사용한다는 것은 무엇일까?

첫째, AI로 무엇이 가능하고 무엇이 불가능한지를 알아야 합니다. 앞서 살펴본 Last Mile 문제를 기억하세요. AI는 막연한 지시는 이해하지 못하고, 정답이 없는 문제에서 최선을 판단하지 못하며, 환각으로 인해 완전히 신뢰할 수 없습니다. 이런 한계를 알고 있어야 AI에게 무엇을 시킬 수 있고 무엇을 시킬 수 없는지가 보입니다. 동시에 이 한계 안에서 AI가 할 수 있는 것들을 상상할 수 있는 경험과 지식이 필요합니다.

둘째, 내가 하고 있는 일을 AI에게 효과적으로 시킬 수 있는 능력이 있어야 합니다. 이를 위해서는 내가 일하는 도메인에 대한 깊은 이해가 필요합니다. 내 업무의 흐름을 정확히 파악하고 있어야 "이 부분은 AI에게 맡겨도 되겠다", "이 부분은 내가 직접 해야겠다"를 구분할 수 있습니다. 그리고 그것을 AI에게 명확하게 전달할 수 있는 소통 능력이 필요합니다. 앞서 봤듯이 구체적이고 명확하게 말할 수 있어야 AI가 제대로 된 결과를 만들어낼 수 있습니다.

셋째, 실제로 업무 흐름의 일부를 AI가 대체하게 만들 수 있는 기술적 능력이 필요합니다. Agent를 활용해 자동화 워크플로우를 만들거나, RAG로 회사의 내부 문서를 학습시켜 맥락 있는 답변을 받거나, MCP나 n8n 같은 도구로 AI를 기존 시스템과 통합하는 등 AI를 실제 업무에 녹여낼 수 있는 지식과 활용 능력이 있어야 합니다. 단순히 ChatGPT에 물어보는 수준을 넘어서, AI를 내 업무 파이프라인의 일부로 만들 수 있어야 진짜 생산성이 나옵니다.

AI 시대에 필요한 능력

AI의 한계는 개발자의 기회입니다. AI는 인간의 모호한 언어를 완벽하게 이해할 수 없습니다. 맥락과 의도를 파악하지 못하고, 학습 데이터의 평균적인 답변만 할 뿐 새롭고 혁신적인 해결책을 제시하지 못합니다. 이것은 현재의 LLM 구조에서 오는 인간 언어와 컴퓨터 언어 사이의 본질적 차이에서 오는 구조적 한계입니다. 그리고 이 격차를 메우는 것이 개발자의 존재 이유입니다. (만약 이를 해결하는 새로운 혁신이 찾아온다면 그때는 또 새로운 살길을 찾아보기로 해요 ^^;)

그래서 지금의 AI 시대에 개발자에게 훨씬 더 중요해 질 거라 생각하는 능력들을 제 나름대로 한번 추려보았습니다. 어디까지나 개인적인 생각이지만 충분히 생각해볼 만한 부분일거라 생각합니다.

첫째, 추상적 요구사항을 구체적 명세로 표현할 수 있는 능력

"로그인 기능 만들어줘"가 아니라 "Node.js Express로 이메일/비밀번호 입력받아서 bcrypt로 암호화 검증하고, JWT 토큰 발급하는 POST /api/login API 만들어줘. 로그인 실패 시 401 에러 리턴하고, 성공 시 토큰이랑 사용자 정보 리턴해줘"처럼 AI에게 말할 수 있어야 합니다. 그리고 이러한 구체적인 설명을 잘 하기 위해서는 인간의 요구사항에 대한 문제 인식과 함께 컴퓨터에 관한 전공 지식이 확보되어 있어야 합니다.

둘째, 맥락과 의도를 명확히 전달하는 소통 능력

"이 코드 리뷰해줘"가 아니라 "결제 API 수정했는데 동시 결제 요청 시 중복 처리되는 문제 때문에 트랜잭션 추가했어. 특히 결제 상태 업데이트 부분에서 race condition 안 생기는지 확인해줘"처럼 말할 수 있어야 합니다. AI가 더 정확하고 유용한 답변을 줄 수 있도록 충분한 정보와 명확한 방향성을 제공하는 능력이 필요합니다. 이는 사람에게도 동일합니다. 사람에게 이야기할 때도 "이거 나가도 되는지 다음 주까지 확인 부탁드려요"가 아니라 "결제 모듈 리팩토링했는데 기존 결제 로직이랑 동일하게 동작하는지 확인 부탁드려요. 특히 부분 환불 처리 부분이 복잡해서 테스트 케이스 추가로 검증해주시면 감사하겠습니다. 다음 주 배포 예정입니다"처럼 인간 언어의 모호성을 최대한 제거할 수 있게 충분한 맥락과 정확한 의도를 분명하게 말할 수 있어야 합니다.

셋째, 프로젝트를 처음부터 끝까지 완주하는 경험

"나는 프론트엔드 개발자가 될 거니까 React만 해야겠다"가 아니라 "로그인 화면 만들려니 JWT 토큰도 해야 되고, 회원가입 만들려니 비밀번호 암호화도 해야 되고, 배포하려니 서버도 해야 되고, 사용자가 버그 신고하니까 로그 분석도 해야 되고, 트래픽 늘어나니까 DB 최적화도 해야 되고... 서비스를 완성하려면 이런 것들이 다 필요하구나"를 깨달아야 합니다.

서비스를 위한 한 바퀴를 모두 직접 개발해보는 경험이 반드시 필요합니다. AI 도구 없이도 개발할 수 있어야 한다는 뜻이 아니라, 한 번은 개발 과정의 전체 흐름과 각 단계별 어려움을 체감해야 한다는 뜻입니다. 경험이 있어야 AI에게 무엇을 어떻게 요청해야 할지, 어떤 부분에서 인간의 개입이 필요한지 정확히 판단할 수 있습니다. 코딩을 직접 해본 적이 없으면 AI에게 제대로 된 코딩 지시를 할 수 없습니다.

넷째, 목적을 우선하는 개발 경험과 마인드셋

"AI 써서 뭔가 해봐야지"가 아니라 "우리 팀 배포 과정이 너무 번거로운데... 매번 환경별 설정 파일 바꾸고 빌드 명령어 치고 서버 접속해서 파일 업로드하고, 이 문제 AI로 스크립트 생성해서 한 번에 처리하는 워크플로우로 만들어볼까?"처럼 생각해야 합니다.

기술은 문제를 해결하기 위한 수단입니다. AI든 개발의 새로운 기술을 써보고 싶어서 프로젝트를 시작하는 게 아니라, 내가 해결하고 싶은 문제가 먼저 있고 그 문제를 해결하기 위해 적절한 기술을 선택하는 경험이 중요합니다. AI 또한 하나의 기술이자 도구일 뿐이며, 도구에는 그 쓰임의 목적성이 존재합니다.

---

🔥 무엇을 하면 좋을까? - 회고와 구조적 말하기

개발자는 인간과 컴퓨터 사이를 번역하는 번역가 역할을 해왔습니다. 기획서에 적힌 "사용자 목록을 보여주세요" 라는 요구사항을 컴퓨터가 이해할 수 있는 언어로 바꿉니다. 반대로 "지금 이 화면이 백지로 보이는 이 이유는.. "이라며 컴퓨터의 상태를 사람들이 이해할 수 있는 언어로 전달합니다. 전자를 우리는 오랫동안 하드 스킬이라 불렀고, 후자는 소프트 스킬이라 불렀습니다. 전통적으로는 전자가 훨씬 더 중요했습니다. 컴퓨터에게 정확한 명령을 내릴 수 없다면 개발자로서 존재 가치가 없었으니까요.

그런데 AI 시대가 오면서, 물론 완벽하지는 않지만, 인간의 요구를 컴퓨터 언어로 번역하는 일, 즉 하드 스킬을 AI가 상당 부분 대신할 수 있게 되었습니다. 이에 따라 내가 작업한 내용을, 내가 마주한 기술적 선택의 순간을, 내가 해결한 문제를 다른 사람에게 설명하는 능력. 바로 소프트 스킬이 상대적으로 중요해지게 되었습니다.

개발자에게 소프트 스킬이란 여러가지가 있지만 개인적으로 중요하게 여기는 것은 '기술적 기반 위에서 자신의 맥락을 담아 구체적인 이야기를 구조적으로 할 수 있는 능력'이라고 생각합니다. 이건 단순히 "접근성 문제를 해결했습니다."로 끝내는게 아니라 "키보드 사용자가 모달에 갇히는 이슈가 있었기에, 포커스 트랩을 추가하고 ESC 키 핸들러를 추가했으며, aria-modal 속성을 부였습니다."와 같이 공학적 근거가 되어줄 기술적 기반 위에서, "우리 팀은 가변 높이 카드를 쓰고 있어서 가상 스크롤 구현이 복잡했다"와 같은 자신만의 맥락을 담아, 이 모든 사실 조각들을 "문제 → 원인 → 트레이드오프 → 해결"처럼 논리적인 인과관계의 구조로 엮어내는 능력을 말합니다.

이러한 능력은 AI가 대신 해줄 수 없습니다. AI는 React에서 디자인 시스템을 작성하는 베스트 프랙티스를 알려줄 수 있지만 우리 프로젝트가 레거시 jQuery 코드와 공존해야 하고, 디자이너가 Figma 컴포넌트를 어떻게 구조화했는지, 다음 분기에 디자인 시스템 개편이 예정되어 있다는 맥락까지는 알 수 없습니다. 반대로 이러한 맥락을 대신 설명해 줄 수도 없습니다. AI는 나 대신 경험할 수도 말해줄 수도 없으니까요. 나의 구체적인 맥락을 구조화해서 표현하는 능력은 온전히 나의 몫이며, AI가 대체할 수 없는 개발자의 실력을 보여주는 지표입니다.

더욱이 AI를 '잘' 활용하기 위해서도 이 능력이 중요합니다. '컴포넌트 만들어줘'라는 막연한 지시는 평범한 결과만 낳지만, '모달 컴포넌트인데, 포커스 트랩이 필요하고... ESC키를 통해 닫히는 기능이 필요하고 aria 속성도 이렇게 넣어줘'처럼, 나의 기술적 요구사항과 맥락을 구체적인 언어로 번역해 지시하면 AI는 더 나은 결과물을 줍니다. 결국 소프트 스킬은 하드 스킬을 포함한 총체적인 개발자의 역량입니다.

사실 이전에는 없던 특별한 건 아닙니다. 이러한 소프트 스킬은 연차가 쌓이면서 자연스럽게 축적되는 스킬이었죠. 시니어 개발자들은 끊임없이 기술 문서를 작성하고, 아키텍처 결정을 설명하며, 트레이드오프를 설득하는 과정을 통해 이 능력을 단련해왔습니다. 그리고 실제 평가도 대부분 코드 자체를 보고 이루어지는 게 아니라, '내가 한 일을 얼마나 잘 설명하는가'로 이루어집니다. 이력서나 면접도 결국 마찬가지입니다.

그런데 AI 시대에는 이걸 의도적으로, 그리고 더 일찍부터 단련할 필요가 있습니다. AI가 하드 스킬의 격차를 줄여가는 상황에서, 이것이 AI의 도움을 받지 못하고 오롯이 내가 해내야 하는, '중요한 역량'이 되었기 때문입니다. 면접에서 '가장 어려웠던 점이 뭐였나요?'라고 묻는 것도, 결국 지원자가 자신의 경험을 기술적 기반을 바탕으로 얼마나 잘 '구조화'하는지를 보려는 것입니다.

그렇다면 이 '구조화 능력'을 어떻게 키울 수 있을까요? 저는 회고를 통한 구조적 글쓰기를 추천합니다. 회고는 내가 마주한 문제가 무엇이었는지, 왜 그게 문제였는지, 어떤 시도를 했고 왜 실패했는지, 결국 어떻게 해결했고 그 과정에서 무엇을 배웠는지를 인과관계를 명확히 하며 풀어내는 연습입니다.

어떻게 하면 구조적으로 잘 말하거나 글을 쓸 수 있을까요? 힌트는 우리가 하는 소프트웨어 설계에 있습니다. 소프트웨어 설계란 '적절한 이름을 붙이고, 있어야 할 자리에 두는 것'입니다. 그리고 적절한 추상화 계층에 맞게 배치하고 데이터의 흐름을 연결하는 것이죠. 개발자의 말하기도 글쓰기도 마찬가지입니다.

연습은 이렇습니다. 먼저, 최대한 구체적으로 '사실'들을 나열해 보세요. '오늘 스크롤 버그 고쳤다'가 아니라, '특정 브라우저(IE11)에서만 position: sticky가 작동하지 않았다', '개발자 도구로 디버깅해보니 상위 DOM의 transform 속성과 충돌했다', '애니메이션 때문에 transform을 제거할 수는 없었다'처럼, 막연한 표현이 아닌 구체적인 표현을 꺼내놓는 겁니다. "Lighthouse 점수가 65점이었다", "서버 상태와 클라이언트 상태가 분리되지 않아 코드가 복잡했다", "팀원들이 Recoil 경험이 없었다" 같은 것들이 모두 '사실' 조각입니다.

그다음, 이 사실들에 '이름(범주)'을 붙여보세요. 이 범주는 정해져 있지 않습니다. 내 경험을 설명하기에 가장 적절한 이름을 붙여보는 겁니다.

• 'sticky가 작동 안 함' → [문제 정의]
• 'transform과 충돌함' → [기술적 원인]
• 'Lighthouse 점수가 65점' → [측정된 데이터] or [성능 현황]
• '애니메이션 때문에 transform을 제거할 수 없음' → [제약 조건]
• '서버 상태와 클라이언트 상태가 분리되지 않음' → [설계상의 문제]
• '팀원들이 Recoil 경험이 없음' → [팀의 맥락] or [기술 선택의 배경]
• 'DOM 구조를 변경함' → [최종 해결책]
• '가상 스크롤 대신 페이지네이션을 도입함' → [고민한 트레이드오프]

이렇게 내 경험의 조각들에 이름표를 붙이고 나면, 이것들을 어떤 순서로 놓아야 가장 논리적일지 '나만의 좋은 구조(설계)'가 보이기 시작합니다. "저는 [문제 정의]가 있었는데, [기술적 원인]을 찾아보니 이랬습니다. [제약 조건] 때문에 [최종 해결책]을 선택했습니다."처럼 말이죠. 그러면 다음 번에는 그 범주를 떠올리며 구체적으로 말하는 것이 더 쉬워 집니다.

그리고 이 구조적 글쓰기를 말하기로 자연스럽게 이어 연습을 해보세요. 회고를 통해 내 경험을 정리했다면, 이제 그것을 다른 사람에게 설명해보는 것입니다. 그러면 글로 정리할 때는 보이지 않았던 논리의 구멍들이, 말로 설명하려고 하면 확연히 드러납니다. '어... 왜 이 방법을 썼더라?' 하고 설명이 막히는 지점이, 내가 아직 정확히 이해하지 못했다는 증거입니다. 그 구멍을 다시 글로 메우고 설명하는 과정을 반복하면서, 글쓰는 내용과 말하는 방식의 수준이 점점 비슷해질 거예요.

이 내용은 제가 AI 시대에 개발자가 조금 더 집중했으면 하는 역량이자 실천적 방법론입니다. AI는 코드를 작성해줄 수 있습니다. 하지만 내가 왜 이 프로젝트를 시작했는지, 어떤 고민을 했는지, 무엇을 배웠는지는 AI가 대신해줄 수 없습니다. 회고를 통해 경험을 구조화하고, 그것을 말로 설명하는 연습을 반복해보세요. 그렇게 쌓인 "내 맥락을 담아 구체적인 내용을 구조적으로 표현하는 능력"이야말로 AI가 모방할 수 없고, 채용 시장이 진짜로 원하는, 개발자의 핵심 역량이 되어줄 것입니다.

AI 시대에도 변하지 않는 것

<개발자의 핵심역할>
인간의 모호하고 막연한 요구사항을 컴퓨터가 해결할 수 있는 문제로 재정의하여 이를 컴퓨터 언어로 구현하고 그 결과가 올바른지 판단하며 책임지는 역할

본질에 집중하자.

불확실한 시대일수록 본질적 역량에 집중하세요. 전공 지식, 개발 경험, 태도, 글쓰기, 말하기... 잘하는 개발자의 역량에 대한 기준은 아직 변하지 않았습니다.

개발자의 핵심 역할은 인간의 모호하고 막연한 요구사항을 컴퓨터가 해결할 수 있는 문제로 재정의하여 이를 컴퓨터 언어로 구현하고, 그 결과가 올바른지 판단하며 책임지는 역할입니다. 앞으로는 인간의 모호하고 막연한 요구사항을 AI를 통해 컴퓨터가 해결할 수 있는 문제로 재정의하여, 이를 컴퓨터 언어로 구현하고, 그 결과가 올바른지 판단하며 책임지는 역할이 될 것입니다.

AI 기술을 이해하기 위한 전공 지식에 충실하세요. AI 기술을 써야 하는 목적이 될 수 있도록 제품을 끝까지 완성해보세요. AI는 결국 인간의 문제를 해결하고자 하는 도구입니다. AI의 능력보다 현실의 문제가 훨씬 더 큽니다. 사람과 어울리고 소통하는 경험을 늘려갑시다.

그래도 불안하다면

여기까지 읽고도 여전히 불안할 수 있습니다. "그래... 개발자는 대체되지 않을 수도 있고, 잘 활용하면 되겠지... 근데 한국에서 미래 개발자가 과연 전망이 있을까? AI 시대에?" "AI가 너무 빠르게 발전하고 있는데, 내가 지금 배우고 있는 것들이 의미가 있을까? 몇 년 후면 AI가 다 대신하게 되는 거 아닐까? 그럼 내가 쌓은 실력은 다 쓸모없어지는 거 아닐까?"

솔직히 이 질문에는 답이 없습니다. IT가 농업처럼 될 수도 있고, 자동차 산업처럼 될 수도 있습니다. 닷컴 버블부터 스마트폰, 블록체인, 클라우드, 메타버스... 그리고 지금은 AI까지. 이 산업은 계속 변해왔고, 앞으로도 변할 겁니다. 개발자의 대우는 결국 한국과 전 세계 개발자 생태계가 만들어가는 것이지, 제가 어찌 할 수 있는 것도, 여러분 혼자 어찌 할 수 있는 것도 아닙니다.

다만 이것만은 말할 수 있습니다. 현재 모든 자본이 AI로 모이고 있고, 저는 소프트웨어의 가능성이 농업의 한계와는 다를 거라고 생각합니다. 그리고 분명한 건, 이 흐름 속에서 누군가는 여전히 뛰어난 대우를 받을 거라는 사실입니다. 그리고 그 '누군가'는 단순히 AI보다 코딩을 빨리하는 사람이 아닐 것입니다. 그들은 AI에게 '왜' 이 코드가 필요한지 설명하고, AI가 내놓은 결과물의 '맥락'을 판단하며, AI를 '설계'의 도구로 부릴 줄 아는 사람일 것입니다.

AI가 코드 작성의 가치는 떨어뜨릴 수 있어도, 그 코드를 쓰면서 배운 '문제 해결 능력', '설계 능력', 그리고 '자신의 맥락을 설명하는 능력'의 가치는 떨어뜨릴 수 없습니다. 이 '메타 스킬'은 기술 스택이 바뀌어도, AI가 대체할 수 없는, 그대로 이전되는 핵심 역량이 되어 줄거라 생각합니다.

그러니 내가 개발을 좋아한다면, 하고 싶다면, 일단 해보세요. 계속 변화에 관심을 가지면서요. 불안하다는 핑계로, 신중함과 효율성을 내세우며 멈춰서지 마세요. 불확실함 속에서도 내가 원하는 것이 무엇이고 무엇을 해야 할지를 찾아가 보기로 해요. 오늘 겪은 경험은 사라지지 않을거라고 믿고 일단 지금 할 수 있는 것들을 해보자구요!

끝으로...

우리 스스로가 AI에게 대체당하지는 말기로 해요.

지금까지 AI의 한계와 개발자의 역할에 대해 긴 이야기를 했습니다. 하지만 솔직히 말하면, 이 모든 기술적인 분석보다 제가 더 근본적으로 걱정하는 것이 하나 있습니다. 제가 현업에서 개발을 하고, 특히 후배 개발자들을 가르치면서 요즘 자주 목격하는 AI의 가장 위험한 부작용처럼 느껴지는 장면입니다. 마치 우리가 쇼츠의 즉각적인 자극에 익숙해져 긴 호흡의 영상을 견디기 힘들어하듯, 문제를 마주했을 때 '고민이 길어지는 것' 자체를 견디지 못하고 너무 쉽게 AI에게 즉각적인 답을 요구하는 모습입니다.

저는 "AI가 개발자를 대체할까?"라는 질문보다, "사람이 먼저 스스로를 AI에게 대체하고 있는 건 아닌가?"라는 질문이 더 중요하다고 생각합니다. 우리의 뇌는 극단적으로 효율을 추구하기에 쓸 필요가 없으면 더 이상 쓰지 않으려 합니다. AI가 나 대신 공부하고, 나 대신 고민하고, 나 대신 코딩하게 두는 순간, 우리는 막막한 문제를 붙들고 씨름하며 얻어내는 개발자 고유의 문제 해결 능력을 잃게 됩니다. 기술적으로 대체되는 것이 아니라, 스스로 생각하기를 포기함으로써 대체당하는 것, 그것이 정말로 AI에게 대체되는 순간입니다.

AI를 '잘' 활용하기 위해서는 역설적이게도 AI가 아닌 것들을 더 '잘'해야 합니다. 현재의 생성형 AI는 결국 방대한 인간의 지식과 언어를 모방한 결과물입니다. 그렇기에 AI가 아무리 편리하고 빠른 답을 준다 한들, 가장 깊이 있는 통찰이나 특정 맥락에 맞는 최적의 해답은 여전히 '사람'과 '원본'에 있습니다. AI가 편리한 첫 번째 답을 줄 수는 있지만, 우리는 그 답을 검증하고 더 깊이 파고들기 위해 주변의 동료에게 물어보고, 공식 문서를 파고들며, 원리와 근본을 다루는 책을 읽고 상식을 가져야 합니다.

나아가, 현재의 AI는 '인간의 언어'로 작동하는 도구입니다. 이는 AI를 잘 다룬다는 것이 곧 '언어'를 잘 다룬다는 의미이기도 합니다. 내가 무엇을 원하는지, 어떤 맥락인지, 무엇이 문제인지를 명확하고 구체적인 언어로 표현할 수 있는 능력, 즉 언어적 소양과 인문학적 소양이 AI 활용 능력과 직결되는 시대입니다. AI를 더 잘 쓰기 위해, 오히려 우리는 더 깊이 인간의 지식을 탐구하고, 더 정확하게 표현하는 법을 연마해야 하는 것입니다.

AI는 강력한 도구입니다. 당연히 써야 하고, 잘 써야 합니다. 하지만 '나 대신' 일하게 두는 것과, '내가' AI를 가지고 일하는 것은 근본적으로 다릅니다. 그 둘을 구분하는 기준은 명확합니다. 내가 원하는 구체적인 목표와 그림이 머릿속에 있고, 그것을 달성하기 위한 수단으로 AI에게 명확히 '지시'하고 그 결과를 비판적으로 검토한다면, 그건 탁월한 '활용'입니다. AI를 쓰다가 비록 헤매고, 답답하고, 원하는 대로 동작하지 않는 시행착오를 겪더라도 그 과정에서 '내가' 무언가를 배우고 있다면, 그것도 훌륭한 '활용'입니다.

그러니 활용과 의존의 경계를 항상 의식해보세요. 스스로에게 물어보세요. "지금 내가 하고 있나? AI가 하고 있나?" AI에게 묻기 전에, 먼저 스스로 기억하려고, 기록해두려고, 그리고 나의 모호한 생각을 구체적인 언어로 표현하려고 노력해주세요. 그 막막하고 때로는 답답하게 느껴지는 '고민의 과정'이야말로 AI가 가질 수 없는, 개발자로서의 가장 강력하고 본질적인 무기가 되어줄거라 생각합니다.

AI 시대를 함께 살아가는 현업 개발자로서 이 글을 준비하면서, 저 또한 AI에 대한 그 막연한 불안감을 여러분과 함께 들여다보고 우리가 마주한 현실을 조금 더 냉정하게 바라보고 싶었습니다.

정리를 하다 보니 사실 내가 어렴풋이 알고 있던, 그리고 어쩌면 당연했던 이야기들이더라고요. 그런데 이렇게 구체적으로 정리하고 나니 신기하게도 막연했던 불안이 조금은 옅어지고, AI 시대의 개발자로서 어떻게 살아가야 할지 조금은 더 선명해진 기분입니다.

이 글이 여러분에게도 지금의 AI 시대를 자신만의 시각으로 현실적이고 구체적으로 고민해보는 '계기'가 되어 각자의 방향을 찾아가는 데 조금이나마 도움이 되기를 진심으로 바랍니다. 긴 글 읽어주셔서 감사합니다.