더이상 (인간) 프로그래머는 필요 없다고?

초등학교 미술 시간에 장래 희망을 그려서 교실 뒤에 붙여 놓았던 기억이 납니다. 학교 끝나고 컴키드 라는 학원에 가서 PPT나 나모 웹에디터를 가지고 놀던(?) 저는 "프로그래머"라는 직업을 그려 넣었었습니다. 그리고 그 아이는 지금은 그렇게 프로그래머가 되었습니다.

어쩌면 이 글은 프로그래머를 꿈꾸는 학생 또는 개발팀을 모두 해고하고 LLM 코딩 에이전트로 대체할 수 있다고 생각이 스멀스멀 올라온 경영진들을 위한 글일 수도 있겠네요.

2023년에는 LLM 세계에는 NLP 엔지니어는 뭘 할까? 라는 글도 썼었는데, LLM이 정말 빠르게 이 산업을 바꾸고 있는게 새삼 느껴집니다.

최근에 금융업계에서 일하는 개발 팀 매니저인 친구가 고민을 털어 놓더군요. 회사 내 클라이언트가 ChatGPT로 바이브 코딩한 결과물을 들고 와서 왜 니네 팀은 우리의 요청을 더 빨리 처리하지 못하냐고 질책했더랍니다.

친구 머릿속에는 바이브 코딩과의 현실에 대한 간극을 설명하는 여러 이유가 떠올랐죠. 기존 프로덕션 코드와 통합하는 것, 여러 기술 부채, 인력 문제 등등. 하지만 결국 별 말을 하지 않고 잘 보채서 돌려 보냈다고 합니다. 클라이언트에게는 그게 모두 변명처럼 들리고 그저 자신이 무능하게 비춰질 것 같을 뿐이라고. 이런 이유들은 이해도가 적은 비기술적인 사람에게 정말 설명하기 어렵습니다.

이런 일화처럼, 현재 LLM 코딩 에이전트들의 바이브 코딩 결과물은 우리 소프트웨어 엔지니어의 일이 너무 쉽게 대체 가능해 보이게 만듭니다. 특히 NVIDIA CEO Jensen Huang 같은 사람들이 이제 프로그래밍을 배우지 않아도 된다 같은 말을 하며, 비즈니스 뉴스에 매일 같이 등장하죠. (개발자를 해고하고 전부 GPU를 사는데 돈을 넣으세요!)

그렇다면 현재 프로그래밍에 관심이 있는 학생들이나 이제 커리어를 시작한 주니어들은 어떻게 해야할까요? 이 길을 포기해야 할까요? 이미 이 길에 접어든 경력자들은 중년의 위기처럼 여기고 다른 직업을 찾아야 할까요? 아니, AI 소프트웨어 엔지니어 Devin보다 잘할 자신이 없다고요?

하지만 저는 모든 소프트웨어 엔지니어가 대체되지는 않을 것이라 믿습니다. 하지만, 언제나 그렇듯이, 제가 틀릴 수도 있으니 제 말만 믿고 커리어 결정을 하지는 마세요...

코딩과 프로그래밍

이 두 단어 사이에는 많은 혼란이 있습니다. 특히 비개발자인 사람들 사이에서요. 소프트웨어 엔지니어의 실존적 위기를 고민하기 위해서는 이 두 용어들을 명확히 정의해야 합니다.

프로그래밍은 근본적으로 컴퓨터가 우리를 위해 작업을 수행하도록 하는 것입니다. 이런 작업들은 우리가 하고 싶지 않은 것들인데, 지루하거나 시간이 많이 걸리거나 너무 복잡하기 때문이죠."자동화"라고도 생각할 수 있습니다.

코딩은 이런 작업들에 대해 컴퓨터에 지시를 내리는 것입니다. 소통의 한 방식이죠. 우리는 펀치 카드에 구멍을 뚫는 것부터 시작했죠. C++이나 Python 같은 프로그래밍 언어가 주로 쓰이는데, 이들은 우리의 공통 언어인 영어 또는 수학적 표현로 소통한다고 생각하면 쉽습니다.

요즘에는 "노코드" 플랫폼도 있어서 UI를 통해 컴퓨터에 지시하는 것이 더 쉬워졌습니다. 프로그래밍 언어는 아니지만 여전히 "코딩"으로 간주될 수 있습니다. 작동하려면 어떤 구문/구조가 있어야 하니까요 (Scratch, UI 기반 프로그래밍 언어나 Zapier, 또는 최근의 n8n 워크플로우 같이).

이와 같이 프로그래밍은 코딩보다 더 포괄적인 개념입니다. 아이는 알파벳을 쓰는 법을 배울 수 있지만, 곧바로 문장을 쓰기에는 충분하지 않습니다. 문장을 쓸 수 있더라도, 문단으로, 산문으로 발전시켜 책을 쓰기에는 더 많은 노력이 필요합니다.

프로그래밍은 소프트웨어 개발에 들어가는 모든 과정을 포함합니다. 문제 정의, 계획, 아이디어 구상, 설계, 테스팅, 그리고 훨씬 더 많은 것들. 코딩은 그 중 작은 한 부분일 뿐입니다.

프로그래밍 vs. 소프트웨어 엔지니어링

하나 더 큰 그림을 봅까요. 소프트웨어 엔지니어링은 단순히 프로그래밍에 관한 것이 아닙니다. 소프트웨어 엔지니어들은 토목 엔지니어들처럼 다리나 터널 같은 실제 물리적인 것을 만들지 않지만, 우리는 여전히 "엔지니어"라고 불립니다. 왜일까요?

왜냐하면 우리는 단순히 작업을 자동화하기 위해 "코드"를 작성하는 것이 아니라, 수천 번이 아니라 아마 수백만 번, 어쩌면 수조 번 작업을 수행하는 "프로그램"을 만들기 때문입니다. 이런 반복은 안정성이 있게 결과가 신뢰할 수 있게 나와야 하고, 꽤 오랜 시간 동안 지속되어야 하며, 많은 고객에게 서비스를 제공해야 합니다.

그리고 또한 새로운 기능을 계속 추가해야 합니다. 이것은 종종 프로그램의 내부 구조를 변경을 필요로 하는데, 이는 지속적인 리팩토링(refactoring)과 마이그레이션(migration)을 하면서 가야하죠. 이 작업을 하며 서비스의 안정성을 유지하며 지속적으로 운영하는 것은, 마치 기차가 300km/h로 달리는 동안 기차 부품을 교체하는 것과 같은거라 보면 됩니다. 생각해보면 인터넷이 처음 나왔을 때는 밤에 몇시간씩 점검 또는 업그레이드로 접속이 안되던 때도 있었죠.

그보다도 먼저, 우리는 무엇을 만들어야 할지 결정해야 합니다. 이것이 제품 관리자(Product Manager), 디자이너, 또는 비즈니스 개발자의 역할이라고 생각할 수 있지만, 소프트웨어 엔지니어의 입력 없이는 어떠한 제안에도 현실성을 부여하기 힘듭니다. 규모에 따라 어떤 회사들은 그러한 직종을 가진 팀원조차 없어서, 엔지니어들이 스스로 그런 역할을 하고는 합니다.

마지막으로, 소프트웨어 엔지니어링은 보통 팀 스포츠입니다. 독립 개발자가 아니라면, 다른 소프트웨어 엔지니어들과 비기술 직종 팀원들과 함께 팀으로 일할 가능성이 높습니다. 그렇기에 일은 단순히 코딩을 하는 것을 넘어서 팀워크와 매니지먼트 같은 사회적인 측면을 무시할 수 없어집니다. 쉽지 않지만 큰 프로젝트를 성공적으로 해내기 위해서는 필요합니다. 코드 리뷰, 버그 추적, 프로젝트 관리 도구 등이 이런 이유로 존재합니다.

소프트웨어 엔지니어링은 LLM으로 대체될 수 있을까?

이제 이 세 용어를 정의했으니, 질문으로 돌아가봅시다: "(인간) 소프트웨어 엔지니어는 LLM으로 대체될 수 있을까?"

LLM 및 AI 모델 또는 에이전트들이 여태까지 어떤 산업에서 충분한 가치를 가져왔거나 미래에 가져올 것인지는 논쟁의 여지가 많습니다만, 한 가지 확실한 것은 소프트웨어 엔지니어의 생산성을 높였다는 것입니다 (이조차도 토론의 여지가 있지만요).

LLM 코딩 에이전트들은 놀라운 속도로 코딩을 합니다. 분명히 우리가 쓰는 시간 중 많은 부분은 반복적이고 지루한 코드를 쓰는 것이 많았는데 (Boilterplate라고 합니다) LLM은 이 부분을 효과적으로 자동화 해준다는 것은 의심의 여지가 없습니다.
제가 이전 글에서 언급했듯이, 그것들은 거의 Stack Overflow와 많은 API 문서 읽기를 대체했습니다. 예를 들어, 저는 파이썬 라이브러리인 Pandas와 Matplotlib을 많이 사용하는데, API가 그렇게 직관적이지 않아 혼자서 쓰려면 한참 걸리지만, Gemini Coding Agent를 사용해서 수초면 제가 원하는 결과를 출력할 수 있습니다.

좋은 원칙들과 함께, LLM 코딩 도구를 사용한다면 생산적으로 사용할 수 있습니다.
하지만 생산성은 속도와 같다고 생각합니다. 더 중요한건 어떤 방향으로 갈지에 대한 결정이죠.

좋은 결정을 위한 맥락, 컨텍스트

Claude와 Gemini가 수백만 토큰의 컨텍스트 윈도우를 내놓았을 때, 많은 사람들이 생각했습니다: "이제 전체 코드베이스에 Attention을 걸 수 있으니 모든 컨텍스트를 가지고 있어!"

"음 그래.. 하지만 아직 충분하지 않을 수 있어"

불행하게도 일의 모든 컨텍스트는 문서화되어 있지는 않습니다. 어떤 것은 2년 전에 일어난 회의에서 나왔을 수도 있고, 3분 전에 일어난 사무실 복도에서 한 잡담에서 나왔을 수도 있습니다. 현실적으로 우리의 코드베이스는 정말 지저분하고 문서화는 거의 되어 있지 않을 수도 있습니다. 많은 업무의 컨텍스트는 LLM이 항상 접근할 수 있는 것이 아니라고 생각됩니다.

인간은 언제나 컨텍스트 (맥락) 속에서 살아갑니다. 우리는 하늘에서 뚝 떨어진 게 아닙니다. 더 시니어일수록 더 많은 컨텍스트를 흡수해야 합니다. 그래서 그들이 그렇게 많은 회의, 컨퍼런스, 팀 이벤트 등을 참석하는 거죠. 그렇기에 유능하고 오래 근무한 엔지니어가 팀을 떠나면 몇 년의 엄청난 모든 컨텍스트를 모두 가지고 나가기 때문에 팀에 큰 타격이 되고는 하죠.

그래서 현재 LLM의 소위 "긴" 컨텍스트 윈도우는 무엇을 어떻게 구축할지 결정하는 엔지니어를 대체하기에는 충분히 길지 않다고 생각합니다.

LLM 코딩 에이전트가 소프트웨어 엔지니어를 대체할 수 있을까요? 답은 간단하지 않습니다. LLM은 보일러플레이트를 처리하고, API 질문에 답하고, 개발 속도를 높이는 강력한 생산성 도구가 되었습니다. 하지만 소프트웨어 엔지니어링은 코딩보다 훨씬 더 많은 것을 포함합니다. 문서화되지 않은 컨텍스트를 이해하고, 아키텍처 결정을 내리고, 기술 부채를 탐색하고, 사람 간 협업하고, 실제 시스템과 조직에서 경쟁하는 우선순위를 균형 있게 조정하는 것이 요구됩니다.

앞서 말한 제 친구의 클라이언트는 ChatGPT에서 나온 작동하는 코드를 보고 개발 팀이 왜 더 빨리 일 을 할 수 없는지 궁금해했습니다. 그들이 보지 못한 것은 보이지 않는 작업, 컨텍스트, 여러 상충관계에 대한 이해, 유지보수 부담 등에 대한 인간 엔지니어가 고민하는 것들이 아니었나 싶습니다.

근데 솔직히 2026년에는 LLM이 얼마나 발전할지 저는 모르겠습니다. 연말에는 이 글의 의견이 우스운 소리가 될지도.. 그저 우리가 계속 성장해서 AI에 의해 실업자가 되지 않기를 기원하며 하루하루 화이팅해야겠습니다!