요즘 AI와 관련하여 LinkedIn과 Thread를 보다 보면 자꾸 뭔가가 죽는다.
"이제 개발자는 죽었다." "이제 MCP는 죽었다." "이제 Skill은 죽었다."
자극적인 워딩을 통한 마케팅을 선호하지 않지만, 한편으로는 왜 이런 마케팅이 성공하는지에 대한 이유를 알 것도 같다. 혁신이 레거시가 되기까지의 라이프사이클 기간이 극도로 줄어들면서, 기술 변화에서 오는 피로감과 불안감이 이런 극단적인 표현들로 나타나는 듯하다.
그럼에도 많은 사람들이 "결국 좋은 개발자는 살아남는다"는 이야기를 하고 나 역시 그 말에 동의한다. 하지만 정작 그 '좋은 개발자'가 구체적으로 어떤 모습이며 무엇을 준비해야 하는지에 대해서는 명쾌한 해답을 찾기 어렵다.
이 시리즈에서는 개발자가 어떤 시선으로 AI를 바라봐야 하는지, 단순히 '어떤 AI 툴이 좋은가'를 넘어 개발자의 역할이 어떻게 바뀌고 있는지, 그리고 개인과 팀의 관점에서 어떤 워크플로우에 집중해야 하는지를 써보려 한다.
첫번째 글은 뻔하지만 그동안의 나의 생각을 정리할 수 있는 글로 시작한다.
이 글은 AI 시대의 개발 시리즈입니다.
- AI 시대, 개발자의 역할은 어떻게 재정의되는가 ← 현재 글
- 개인 편: AI 시대, 개발자의 판단 기준
- 이론 편: CoALA로 이해하는 AI 에이전트의 사고 구조
- 팀 편: 팀 전원이 AI 에이전트를 돌릴 때
AI가 개발자의 역할을 어디까지 대체할 수 있을까?
일론 머스크가 젠슨 황의 자율주행 관련 발표를 보고 이런 글을 남긴 적이 있다.
99%에 도달하는 것은 쉽지만, 마지막 1%의 예외(Long Tail)를 해결하는 데는 엄청난 리소스가 들어간다
이는 자율주행 연구에 관한 이야기였지만, 코드 레벨에서 LLM을 다루는 우리 역시 이러한 경험을 공유하고 있다.
실제로 LLM을 활용해 개발해 보면, Zero-base에서 그럴듯한 프로토타입을 뽑아내는 속도는 가히 압도적이다. 실제로 온갖 커뮤니티에서 매일 수백개의 새로운 프로젝트가 쏟아지고 있고 모두 입을 모아 LLM의 퍼포먼스를 찬양한다. 하지만 어떤 개발자도 그 프로젝트가 당장 프로덕션 레벨에 투입될 수 있다고 믿지는 않는다. 결국 우리는 소프트웨어의 수준을 일관되고 신뢰성이 있는 결과가 확보되는 수준까지 끌어올려야만 한다.
복잡한 비즈니스 로직과, 의도한 아키텍처 구조나 패턴을 강제하기 위해 우리는 정확한 결과가 나올때까지 LLM에게 끝없이 마이크로 매니징을 시도하게 된다. 그리고 그 구간(Long Tail)에서, 우리는 "그럴듯한" 결과를 위해 사용한 비용의 몇배에 해당하는 비용을 지불한다. 비용 대비 유의미한 결과물의 산출 비율은 급격하게 하락하고 어느 순간 AI가 뱉어낸 코드를 수습하는 시간이 내가 직접 코드를 짜는 시간을 역전해버리는 상황에 직면한다.
결론적으로 AI 모델의 퍼포먼스 향상이 소프트웨어 프로덕트의 완성을 보장하지는 않는다.
살아남는 개발자는 누구인가
그렇다면 프로덕트의 완성도를 보장할 수 있는 개발자는 어떤 역량을 갖춰야 하는가 라는 질문이 자연스레 따라온다.
"좋은 개발자란 무엇인가"는 업계에서 참 많이 나오는 질문이다. 기존에 개발자의 성장 방향은 보통 크게 두가지 트랙으로 나뉘었다.
-
Manager 트랙: 일정 수준 이상의 개발 실력에 커뮤니케이션 및 조율 능력을 무기로 매니징의 영역으로 넘어가는 케이스
-
Specialist 트랙: 특정 기술 하나를 끝까지 파고들어 전문성을 갖춘, 흔히 말하는 스타 개발자가 되는 케이스
하지만 앞으로 AI의 모자란 기술적 역량을 대신 채워주는 폴리필(Polyfill) 역할의 개발자는 점차 설 자리를 잃을 것이다. 단순히 코딩 레벨에서의 기술적 간극을 메꿔주길 기대하는 기업 역시 줄어들 수밖에 없다.
결국 살아남는 것은 1번, 그중에서도 기존 매니징의 영역을 인간에서 AI 영역까지 확장시키는 관리자다.
기존의 매니저는 본인의 머릿속에 있는 명확한 설계를 기반으로 여러 명의 주니어 개발자에게 작업을 지시한다. 만약 이때 명확하고 엄격한 오더가 없다면, 각자의 코드가 충돌(Conflict)하고 컨벤션이 무너지는 상황을 우리는 이미 숱하게 경험하고 있다.
실제 운영 환경에서 경험한 LLM도 정확히 이런 모습이다. 개발자에게 AI란 "기술적 지식은 풍부하지만, 눈앞의 모든 코드를 뜯어고치고 싶어 하는 열정이 넘치는 주니어 개발자"와 같다.
이 열정 넘치는 동료를 통제하고 그 속에서 최고의 퍼포먼스를 이끌어 내는 것. 명확한 아키텍처 기준을 세우고, 유지보수가 가능한 비즈니스 로직을 설계하여 이를 바탕으로 AI에게 정확한 제약과 방향성을 부여하는 컨텍스트 엔지니어링(Context Engineering) 능력이 필수적으로 요구된다.
요새 유행하는 하네스(Harness) 엔지니어링의 개념처럼 이를 통제하고 지휘하는 "오케스트레이터(Orchestrator)"만이 이 시장에서 살아남을 수 있지 않을까 생각해본다.
개발자에만 해당되는가?
미디어에서 "개발자의 인력 대폭 감소" 라는 키워드 아래 많은 기사를 쏟아낸다. 그렇다면 이 현상은 개발자 커뮤니티에서 유독 심하게 일어나는 현상일까. 이에 대해 나는 "비싼 인력일수록 대체되는 속도가 가속화될 것이다"라는 명제가 현실에 가깝다고 생각한다. 이는 AI를 도입하는 수요 기업과 기술을 제공하는 공급 기업, 양쪽의 측면에서 바라볼 필요가 있다.
AI를 활용하는 수요 기업의 경우 AI는 결국 효율을 높이는 도구에 불과하다. 아무리 좋은 모델, 좋은 기술이 나와도 이는 결국 기업에게 더 나은 퍼포먼스를 제공하고 퍼포먼스 대비 비용을 절감시켜주는 도구인 것이다. 따라서 ROI를 극대화하기 위해서는, 지출에서 가장 높은 비중을 차지하는 고연봉 지식 노동을 대체시키는 것이 자연스러운 수순이다.
이번엔 공급 기업의 측면에서 바라보자. AI 기술을 주도하는 기업들의 입장에서 기술 개발에 투입되는 비용 회수를 위해서는, 높은 인건비를 대체하도록 지식 노동 시장을 타겟팅할 수 밖에 없다. 회계와 금융, 그리고 코로나 시대 이후의 소프트웨어 개발과 같은 고부가가치 직군이 가장 먼저 위협을 받을 수 밖에 없는 이유다.
결국 도메인을 막론하고 AI라는 특이점이 요구하는 생존 방법은 동일하다. 실무적인 "생산"이라는 가치는 점점 0으로 수렴할 것이다. 그 대신 AI가 리서치하고 생성한 결과물에 대한 "검증"과 이에 대해 최종적인 책임을 지고 의사결정하는 "오케스트레이터"만이 살아남을것이다.
정리하며
기술 발전 속도와 AI가 생성하는 코드의 퀄리티는 지속적으로 상승하겠지만 AI는 결국 도구에 불과하다.
개발자에게 '무엇을, 왜, 어떻게 만들어야 하는가'에 대한 명확한 설계 기준이 없다면, AI는 그저 겉보기에만 그럴듯한 레거시 코드를 대량으로 생산할 뿐이다. 소프트웨어의 최종적인 완성도는 AI의 성능이 아니라 사용자의 '판단 기준'에 비례한다.
이제는 아키텍처 제약을 설정하고, AI의 파편화된 지식을 하나의 시스템으로 통제하는 역량이 요구된다. 전체 구조를 파악하여 하네스 엔지니어링을 수행하는 오케스트레이터가 이 특이점의 시대에서 살아날 수 있는 유일한 방법이라고 생각한다.
그렇다면 이 오케스트레이터가 되기 위한 '판단 기준'은 어떻게 세우고 적용해야 할까. 다음 글, 개인 편: AI 시대, 개발자의 판단 기준에서는 이에 대한 고민을 다루려고 한다.