By Mark 지난 20년 이상 소프트웨어 엔지니어링 업계의 관행과 조직 문화를 돌아보면, 기술적 의사결정의 정점에 서 있는 자와 그 아래에서 시스템을 지탱하는 자에 대한 평가는 극단적으로 엇갈려 왔습니다. 신규 프로젝트를 주도하며 백지상태에서 시스템의 청사진을 그리는 이른바 초기 개발자나 거시적인 아키텍트는 업계에서 늘 엄청난 대우를 받으며 조직 내 최우선 핵심 인력으로 평가받아 왔습니다. 그들은 언제나 혁신의 아이콘이자 시스템의 창조자로 인식되었습니다.
반면, 그들이 만들어낸 시스템을 이어받아 기술 부채를 해결하고, 복잡하게 얽힌 스파게티 코드를 풀며 이른바 남이 남긴 쓰레기를 치우는 유지보수 및 운영 엔지니어는 누구나 쉽게 대체할 수 있는 평범하거나 하위 인력으로 취급되곤 했습니다. 새로운 프레임워크나 솔루션을 도입하는 사람은 핵심 인력으로서 상위 엔지니어의 칭호를 얻지만, 그 도입으로 인해 발생한 파편화된 운영 환경을 수습하고 야간에 장애를 처리하는 사람은 언제나 조명받지 못하는 백그라운드의 노동자였습니다.
목차
최근 거대언어모델 기반의 AI 에이전트와 코딩 어시스턴트가 본격적으로 엔터프라이즈 환경에 도입되면서, 코드의 절대적인 생산 비용이 0에 수렴하는 현상이 발생하고 있습니다. 이러한 기술적 특이점 앞에서 많은 사람들은 기득권을 쥐고 있던 기존의 상위 개발자나 설계자들이 무한한 생산력을 가진 AI를 부리며 시스템 전체를 쥐락펴락하는 진정한 핵심 인력으로 더욱 득세할 것이라 예측했습니다. 하지만 최근 현업에서 벌어지는 실제 상황은 이와 정반대의 양상을 띠고 있어 이 글을 시작하게 되었습니다.
과거에는 소프트웨어를 처음부터 끝까지 만들어내는 물리적 시간이 길었기 때문에, 초기 설계자들은 그럴싸한 뼈대를 만들고 그 책임을 운영팀에 던진 뒤 다른 신규 프로젝트로 넘어가며 자신의 높은 몸값을 유지할 수 있었습니다. 그러나 이제는 AI로 인해 초기 생산 시간이 극단적으로 짧아지면서, 개발자가 자신이 만든 결과물을 다른 팀에 넘기기 전에 본인이 직접 운영 환경에 배포하고 테스트의 영역까지 감당해야 하는 상황이 빈번해지고 있습니다. 그리고 바로 이 지점, 시스템을 실제로 굴러가게 만드는 운영의 디테일과 런타임의 엣지 케이스 영역에서, 코드 한 줄 제대로 짜지 않고 설계에만 익숙했던 상위 핵심 인력들이 무참히 무너지는 경우를 수 없이 목격하고 있습니다.
1:N의 붕괴, 그리고 1이 되어버린 희소성의 종말
과거 소프트웨어 개발 조직의 구조는 철저하게 1 대 N의 비율을 따랐습니다. 1명의 뛰어난 아키텍트 혹은 리드 개발자가 거시적인 아키텍처를 설계하면, N명의 실무 개발자들이 그 설계를 바탕으로 모듈을 나누어 세부 코드를 구현했습니다. 여기서 조직의 핵심 인력은 단연코 큰 그림을 그리는 1명의 아키텍트였습니다. 전체 시스템의 모순을 피하고 컴포넌트 간의 결합도를 낮추는 통찰력은 소수만이 가진 희소한 자원이었고, 세부 구현을 담당하는 N명의 인력은 상대적으로 교체하기 쉬운 자원으로 여겨졌습니다.
사람들은 AI가 코딩을 대체하기 시작하자, 이 1 대 N의 구조가 1 대 AI로 바뀔 것이라고 생각했습니다. 즉, 1명의 아키텍트가 수많은 AI 에이전트를 거느리고 명령을 내리며 더욱 강력한 지배력을 행사할 것이라는 예측이었습니다. 하지만 현실은 전혀 다르게 흘러가고 있습니다. 1 대 N의 희소성 구조가 1 대 1로 변한 것이 아니라, 조직 생태계 전체에서 남는 숫자가 그저 평면적인 1이 되어버렸습니다.
이러한 현상이 발생하는 이유는 명확합니다. 탑다운 방식의 거시적 설계와 뼈대를 잡는 작업조차 AI가 놀라울 정도로 잘 해내기 때문입니다. 과거 아키텍트만이 가졌던 넓은 시야, 다이어그램을 그리는 능력, 디자인 패턴의 적용과 같은 지식은 이미 거대언어모델의 가중치 속에 완벽하게 내재화되어 있습니다. 누구나 적절한 프롬프트만 입력하면 그럴싸한 마이크로서비스 아키텍처 다이어그램과 보일러플레이트 코드를 순식간에 얻을 수 있습니다.
그 결과, 큰 그림만 그릴 줄 알던 기존 탑다운 설계자들의 희소성은 완전히 증발해 버렸습니다. 시장에서 대체 불가능한 자원으로 여겨지던 기득권의 가치가 무너지면서, 큰 그림을 그리는 능력만으로는 더 이상 핵심 인력으로 살아남을 수 없는 생태계가 도래한 것입니다. 진입 장벽이 낮아진 것이 아니라 희소 자원의 축이 완전히 이동해 버렸습니다. 큰 그림은 누구나 AI를 통해 그릴 수 있지만, 그 그림이 실제 물리적인 서버 위에서 충돌 없이 작동하도록 만드는 판정 역량은 아무나 가질 수 없는 새로운 희소 자원이 되었습니다.
생산 비용의 붕괴와 검증 비용의 폭발적 증가
AI 도구의 발전으로 인해 코드를 작성하고 기능을 구현하는 속도는 인간의 물리적 인지 및 타자 속도를 완전히 벗어났습니다. 그러나 개발 라이프사이클 전체를 조망해보면, 작성된 코드가 프로덕션 환경에 배포되고 사용자에게 안정적으로 서비스되기까지의 과정은 더욱 험난하고 복잡해졌습니다. 소프트웨어 엔지니어링에서 생성 비용은 급감했지만, 그 결과물을 검증하는 비용은 기하급수적으로 폭발하고 있기 때문입니다.
태어날 때부터 레거시인 AI 생성 코드의 본질
엔지니어들이 반드시 명심해야 할 사실은 AI가 생성한 코드는 본질적으로 태어날 때부터 레거시 성격을 띤다는 점입니다. 레거시 코드란 단순히 오래된 코드를 의미하는 것이 아니라, 동작은 하지만 작성자의 정확한 의도를 알 수 없고, 수정했을 때 시스템의 어느 부분이 파괴될지 예측할 수 없는 코드를 말합니다. AI 모델은 주어진 프롬프트의 컨텍스트 창(Context Window) 내에서 확률적으로 가장 적합한 텍스트 토큰을 예측하여 출력할 뿐입니다. AI는 우리 회사의 시스템이 수년간 겪어온 역사, 특정 비즈니스 도메인만의 미묘한 엣지 케이스, 데이터베이스의 숨겨진 제약 조건, 그리고 암묵적으로 합의된 팀 내의 인프라 컨벤션을 온전히 이해하고 코드를 작성하지 않습니다.
따라서 AI가 뱉어낸 방대한 코드를 마주하는 개발자의 입장은, 전임자가 퇴사하면서 문서 하나 없이 남기고 간 거대한 스파게티 코드를 처음 열어보는 유지보수 담당자의 입장과 정확히 일치하게 됩니다. 내가 직접 타이핑하여 작성하지 않은 코드를 읽어 내려가며, 이 코드를 작성한 주체인 AI의 의도를 역추적하여 추론해야 합니다. 특정 함수를 수정했을 때 발생하는 폭발 반경이 어디까지 미치는지, 그리고 메모리 누수 없이 안전하게 격리된 영역이 어디인지를 코드의 흐름만 보고 판단해야 합니다.
가설과 검증, 시스템 고고학자의 부상
이러한 맥락에서 오랫동안 빛을 보지 못했던 유지보수 및 운영 중심 엔지니어들의 업무 방법론이 AI와의 협업 루프와 완벽하게 맞아떨어집니다. 이들은 과거부터 자신이 만들지 않은 시스템에서 장애가 발생했을 때, 표면적인 현상을 바탕으로 논리적인 가설을 세우고, 애플리케이션 로그와 분산 트레이싱 데이터를 파헤쳐 가설을 검증하며, 시스템의 부작용을 최소화하는 방식으로 코드를 수선해 온 시스템 고고학자들입니다.
항상 백지상태에서 신규 솔루션 개발에만 매진해 온 탑다운 중심의 엔지니어는 무의식중에 자신이 모든 것을 설계하고 통제할 수 있다는 전제를 깔고 작업합니다. 이들은 남이 짠 코드를 깊게 읽고 의심하는 근육이 훈련되어 있지 않습니다. 반면, 유지보수 현장에서 굴러본 엔지니어는 기본적으로 남의 코드, 나아가 자신이 짠 코드조차도 불신하는 근육이 고도로 발달해 있습니다. 이 불신은 방어적 프로그래밍의 습관과 촘촘한 테스트 코드 작성으로 직결되며, AI가 섞어 놓은 환각 덩어리 속에서 실제로 안전하게 동작하는 로직만을 분리해 내는 결정적인 역량이 됩니다. 이제 기업이 간절히 찾는 조직 내 최고의 핵심 인력은 코드를 빠르게 짜는 사람이 아니라, 눈앞의 코드가 운영 환경에서 안전하게 동작할 것인지를 정확히 판정하고 수선할 수 있는 사람입니다.
탑다운과 바텀업의 오해, 그리고 창발성의 부재
개발 생태계를 논할 때 흔히 아키텍처 중심의 탑다운 접근법과 구현 중심의 바텀업 접근법을 이분법적인 대립항으로 둡니다. AI 시대에 디테일에 강한 바텀업 방식의 운영 개발자가 유리하다는 현상을 두고, 거시적인 탑다운 설계 자체가 무용지물이라는 극단적인 결론으로 빠져서는 안 됩니다. 여전히 코드를 정교하게 다루며 디테일까지 파악하고 있는 진짜 아키텍트가 AI를 활용할 때의 파괴력은 단순한 실무 엔지니어의 생산성을 아득히 초월합니다. 현재 업계에서 도태되며 붕괴하고 있는 부류는 시스템의 세부 구현을 전혀 모르면서 입으로만 다이어그램을 그리는 가짜 설계자들입니다.
바텀업 방식의 명확한 한계
동시에 우리는 순수한 바텀업 방식이 가지는 치명적인 한계도 명확히 인지해야 합니다. 실제로 AI를 보조로 둔 단독 1인 개발 프로젝트나 순수 바텀업 방식의 접근은 규모가 커질수록 뚫을 수 없는 천장에 부딪힙니다. 가장 대표적인 실패 모드는 개별 부품이나 단일 마이크로서비스 단위로는 완벽하게 동작하지만, 이들을 결합하여 전체 시스템으로 올렸을 때 정합성이 완전히 어긋나버리는 현상입니다.
소프트웨어 시스템에서 가장 중요하고 치명적인 속성들은 개별 부품을 잘 만든다고 해서 자연스럽게 창발되지 않습니다. 작은 함수들을 조립하다 보면 언젠가 훌륭한 시스템이 만들어질 것이라는 생각은 망상에 불과합니다. 거시적인 관점에서 다음의 요소들은 반드시 프로젝트 초기 단계에서 설계적인 판단을 통해 결정되어야 합니다.
- 데이터 모델링의 일관성: 도메인 엔터티 간의 관계를 어떻게 설정하고 분산 환경에서 데이터의 정합성을 어떻게 유지할 것인가.
- 신뢰 경계와 보안 컨텍스트: 내부 서비스 간의 통신과 외부 인터넷 구간 사이의 권한 검증 구간을 어디에 배치할 것인가.
- 실패 의미론: 특정 컴포넌트의 데이터베이스가 다운되었을 때 시스템 전체가 마비될 것인가, 아니면 캐시된 데이터를 보여주며 우아한 저하를 이뤄낼 것인가.
- 트랜잭션 경계: 마이크로서비스로 쪼개진 환경에서 비즈니스 로직의 원자성과 데이터의 격리성을 어떻게 보장할 것인가.
이러한 시스템 레벨의 거시적 구조를 명확히 정의하지 않고 그저 AI가 만들어준 코드 블록을 바텀업으로 무작정 쌓아 올린 시스템은, 결국 아키텍처의 불일치로 인해 운영 단계에서 유지보수를 포기하고 전면 재작성이라는 비극적인 파국을 맞이하게 됩니다. 훌륭한 결과를 내는 AI 기반 소프트웨어 프로젝트들의 이면에는 항상 견고하게 설계된 요구사항 명세와 엄격하게 격리된 모듈 간의 인터페이스 설계가 선행되어 있다는 사실을 간과해서는 안 됩니다.
유지보수 개발자의 두 가지 부류와 엇갈리는 운명
이 지점에서 우리가 그동안 평범하거나 하위 인력이라고 치부했던 유지보수 개발자라는 용어를 해체하여 바라볼 필요가 있습니다. 현업에서 유지보수라는 이름으로 묶여 있는 엔지니어 그룹은 실제로는 문제 접근 방식과 역량에 따라 완전히 다른 두 가지 부류로 나뉘며, AI 시대에 이들의 운명은 극단적으로 엇갈리게 됩니다.
패턴 매칭 패치 작업자의 소멸
첫 번째 부류는 이슈 트래커를 통해 티켓을 할당받으면, 기존에 선임들이 남겨놓은 위키나 알려진 장애 패턴을 뒤져 기계적으로 해결책을 매칭시킨 후 코드에 덧대는 유형의 개발자입니다. 이들은 시스템 장애의 근본적인 원인을 집요하게 파고들기보다는, 당장 눈앞에 붉게 표시된 에러 로그를 덮고 현상적인 버그를 수정하는 데 급급합니다. 구조적인 리팩토링 없이 if문을 계속해서 추가하며 코드의 복잡도만 높이는 역할을 합니다.
지금 이 시간에도 이 직군은 AI와 코딩 에이전트에 의해 가장 1순위로 빠르게 대체되고 있습니다. 프로젝트의 방대한 코드베이스를 벡터 데이터베이스로 주입받고 컨텍스트를 완벽하게 기억하는 AI 에이전트는, 단순한 패턴 매칭 기반의 버그 수정, 라이브러리 버전 업데이트, 린트 에러 해결과 같은 티켓을 인간보다 훨씬 빠르고 정확하게 처리해 냅니다. 과거 유지보수 개발자의 다수를 차지했던 이들은 더 이상 조직의 핵심 인력으로 남을 수 없습니다.
장애 추적 및 가설 검증 설계자의 생존과 도약
두 번째 부류는 자신이 직접 설계하거나 구축하지 않은 거대하고 복잡한 블랙박스 시스템에서 장애가 발생했을 때, 코드의 호출 흐름을 집요하게 역추적하고 운영체제 레벨의 메트릭까지 파헤치며 근본 원인을 찾아내는 가설 검증형 운영 엔지니어입니다. 앞서 논의한 AI 시대에 살아남는 구조적 우위는 전적으로 이 두 번째 부류에 해당합니다.
이들은 소스 코드를 읽는 것을 넘어, 코드가 컴파일되고 운영체제 위에 올라가 메모리를 할당받고 네트워크 패킷을 주고받는 일련의 물리적인 과정을 이해하고 있습니다. 그렇기 때문에 AI가 생성한 수천 줄의 코드 더미 속에서도 논리적인 결함과 성능 병목 지점을 정확하게 짚어낼 수 있습니다. 이들은 시스템이 운영 환경의 디테일에서 어떻게 예기치 못하게 무너지는지 수많은 밤을 새우며 경험으로 체득했기 때문에, AI가 내놓은 결과물의 신뢰성을 판정할 수 있는 유일한 핵심 인력이 됩니다.
소프트웨어의 본질: 숨겨진 실패와 운영의 무거운 책임
AI를 통해 초기 제품의 프로토타입을 만들어내는 속도가 기하급수적으로 빨라졌다고 해서, 소프트웨어라는 결과물에 대한 엔지니어의 책임까지 가벼워지는 것은 결코 아닙니다. 혼자서 강력한 LLM을 비서로 활용하며 미친 듯한 속도로 기능들을 반복 배포한다 하더라도, 소프트웨어의 세계에는 겉으로 당장 드러나지 않는 치명적인 숨은 실패들이 곳곳에 도사리고 있습니다.
단일 유저가 로컬 환경에서 테스트할 때는 완벽하게 응답하던 시스템도, 실제 프로덕션 서버에 올라가 런타임이 길어지면 미세한 메모리 누수로 인해 며칠 뒤 서서히 붕괴하기 시작합니다. 특정 이벤트로 인해 트래픽이 평소의 열 배 이상 몰리는 순간, 데이터베이스의 락 경합이나 커넥션 풀 고갈로 인해 대규모 타임아웃 장애가 발생합니다. 코드에 숨겨진 사소한 논리적 결함이나 외부 API 통신 과정에서의 권한 탈취 취약점은, 돌이킬 수 없는 대규모 고객 데이터 유출 사고로 직결됩니다.
과거에는 이러한 운영 환경의 잔혹한 문제들을 인프라 엔지니어, DBA, 보안 팀 등 여러 부서가 방어벽을 치고 막아 주었습니다. 하지만 AI의 도입으로 1인당 생산성이 극단적으로 압축되고 배포 파이프라인이 단축된 현재, 코드를 만들어내는 속도에만 취해 운영의 디테일을 무시하고 배포를 남발하는 설계자들은 배포 직후부터 시작되는 진짜 소프트웨어 라이프사이클의 무거운 책임 앞에 직면하게 됩니다. 실행 자본이 무너지고 거시적 설계마저 자동화된 시점에서 남은 단 하나의 진실은, 쏟아져 나오는 코드가 유발할 운영 환경의 재앙을 사전에 차단하고 통제할 수 있는 검증 능력이 가장 가치 있는 자산이라는 것입니다.
학습 경로의 구조적 비대칭성: 누가 미래를 통제하는가
미래의 엔지니어링 생태계에서 최종적인 승패를 가르는 진정한 변수는 탑다운이냐 바텀업이냐의 취향 차이가 아닙니다. 핵심은 거시적인 시스템 아키텍처의 세계와 마이크로 단위의 메모리 할당 및 코드 구현의 세계를 자유자재로 오르내릴 수 있는 왕복 가능한 역량을 누가 보유하고 있느냐입니다. 그리고 이 지점에서, 현장의 디테일을 다루며 진흙탕에서 굴러본 운영 엔지니어들이 지니는 가장 강력하고 방어하기 어려운 구조적 무기가 등장합니다. 그것은 바로 학습 경로에 내재된 구조적 비대칭성입니다.
프롬프트 창 뒤로 가려져 버린 디테일의 학습 기회
디테일에 강한 가설 검증형 유지보수 엔지니어는 엉망진창인 남의 코드를 수선하고 시스템의 아주 작은 모듈을 디버깅하여 결합하는 과정에서 수없이 많은 실패를 겪게 됩니다. 하지만 이 고통스러운 디버깅 과정 속에서 변수들이 어떻게 상호작용하는지, 데이터베이스 쿼리가 어떻게 디스크 IO를 발생시키는지 체감하며 시스템 전체를 아우르는 큰 그림을 뇌 구조에 자연스럽게 매핑하게 됩니다. 이들은 바텀업의 파편화된 지식을 기반으로 거시적인 아키텍트로 진화할 수 있는 상승 경로를 밟아나갑니다. 이 과정에서 AI는 그들의 뇌가 더 높은 수준의 패턴을 인식할 수 있도록 도와주는 완벽한 지식의 증폭기가 됩니다.
반면, 처음부터 전체 시스템의 큰 그림만 좇으며 세부적인 코드 구현의 골치 아픈 부분들을 철저히 AI의 프롬프트 창 너머로 위임해 버리는 설계자는 돌이킬 수 없는 치명적인 함정에 빠지게 됩니다. AI가 인프라 설정의 복잡한 디테일과 귀찮은 예외 처리 로직, 스레드 동기화 문제 등을 모두 빠르고 깔끔하게 대신 처리해주기 때문에, 이 엔지니어는 겉보기에는 훌륭한 시스템을 단숨에 구축한 것처럼 보입니다. 그러나 시스템이 장애를 일으켰을 때 그 밑바닥을 파고들어야 하는 순간, 이들은 스스로 운영 수준의 세부 사항을 다루고 고민하며 얻을 수 있었던 귀중한 엔지니어링 학습 기회 자체를 원천적으로 차단당한 상태라는 것을 깨닫게 됩니다.
AI의 능력이 고도화될수록, 세부 디테일을 들여다보지 않는 자의 기술적 성장은 멈춰버립니다. 그들은 프롬프트의 겉핥기식 명령에만 익숙해질 뿐, 에이전트가 뱉어낸 코드가 왜 그런 형태를 띠어야만 하는지에 대한 근본 원리(First Principles)를 학습할 기회를 영영 잃어버리게 됩니다.
실행하는 설계자만이 쟁취할 수 있는 최종 진화
유지보수 경험을 뼈대로 삼고 있는 엔지니어는 AI의 도움을 받아 자신의 약점이었던 거시적 설계와 초기 구현의 생산성을 극대화합니다. 자신이 직접 검증하고 수선하며 통제할 수 있는 코드 블록들을 활용하여 아키텍처의 스케일을 넓혀나가는 명확한 진화의 사다리를 오르고 있습니다. 그러나 세부 구현의 고통을 기피한 채 입과 다이어그램으로만 설계를 논하던 자들은, 그 구현의 짐을 AI에게 온전히 떠넘긴 대가로 영원히 디테일의 세계로 내려갈 수 있는 사다리를 잃어버렸습니다.
이것은 단순히 누가 더 코드를 미려하게 작성하느냐의 수준을 넘어선 문제입니다. 생태계의 한쪽 진영에는 완벽한 풀스택의 완성형 엔지니어로 진화할 수 있는 튼튼한 사다리가 존재하고, 다른 한쪽 진영에는 기술의 기저로 내려갈 사다리 자체가 AI에 의해 완전히 끊어져 버린 학습 경로의 구조적 비대칭성입니다. 소프트웨어를 생산하는 시간이 짧아질수록 역설적으로 그 시스템의 밑바닥을 지탱하는 운영 디테일의 가치는 폭등할 수밖에 없습니다.
결론: 새로운 생태계의 단 하나뿐인 핵심 인력
소프트웨어 개발 조직 내에서 1:N이라는 전통적인 인력 배분 구조의 희소성이 완전히 파괴되고 순수한 1만이 생존하는 현재의 지각 변동 속에서, 진정으로 가치 있는 인력은 신규 프로젝트의 청사진만 화려하게 뽑아내는 사람이 아닙니다. AI가 숨 쉴 틈 없이 쏟아내는 방대한 레거시 코드의 숨겨진 의도를 집요하게 파악하고, 날카로운 가설로 운영 환경의 예비 장애를 검증해 내며, 작은 컴포넌트 단위의 신뢰성을 바탕으로 거대한 시스템 아키텍처를 견고하게 직조해 내는 통합적 역량을 갖춘 사람만이 살아남습니다.
유지보수와 디버깅이라는 거칠고 냄새나는 현장에서 묵묵히 쓰레기 코드를 치우며 훈련된 엔지니어들은, 역설적이게도 남의 코드를 가장 빠르고 정확하게 판정하는 데 고도로 특화되어 있습니다. 이들은 AI를 맹목적으로 믿어야 할 코드 생성기가 아니라, 자신이 완벽하게 통제하고 검증할 수 있는 범위 내에서 물리적인 설계를 실체화하는 가장 강력한 무기로 다룰 줄 아는 자들입니다.
탑다운 설계의 필요성과 비즈니스 가치를 명확히 인지하면서도 결코 코드의 디테일을 놓치지 않고 통제하는 왕복 가능한 엔지니어, 자신이 검증한 디테일을 기반으로 점진적인 아키텍처 확장을 이루어내는 이른바 실행하는 설계자들이야말로 다가오는 인공지능 시대의 소프트웨어 생태계를 절대적으로 지배하게 될 유일무이한 핵심 인력입니다. 기득권의 환상은 이미 깨졌고, 살아남는 자의 조건은 실행과 검증으로 완전히 재편되었습니다.
덧붙이는 글: 조직의 해체와 고독한 원맨쇼의 딜레마
최근 이 글을 쓰게 된 결정적인 계기가 하나 더 있어 첨언을 남깁니다. 얼마 전 비슷한 연배이자, 한때 중견 기업에서 C레벨 엔지니어로 ‘핵심 인력’ 대우를 받으며 군림하던 분을 가까이서 지켜볼 기회가 있었습니다. 그는 AI라는 새로운 패러다임 앞에서 완전히 길을 잃은 상태였습니다.
그분을 보며 느낀 감정은 씁쓸함을 넘어선 충격이었습니다. 거대한 조직과 실무를 대신해 줄 부하 직원들이 사라지고 AI와 자신만 홀로 남겨지니, 과거의 화려했던 직함이 무색할 정도로 시스템에 단 하나의 유의미한 기능조차 스스로 구현하지 못하고 있었습니다. 기술적 결정권자라는 타이틀은 거대한 조직의 인프라 위에서만 유효했던 껍데기였던 것입니다.
그 무력한 모습을 거울삼아 저 스스로에게 뼈아픈 질문을 던지게 되었습니다. ‘나는 지금 이 급변하는 생태계에서 어떤 사람으로 적응해 나가고 있는가?’, ‘내가 지금 AI를 레버리지 삼아 구축하고 있는 이 고독한 원맨쇼가 과연 옳은 방향일까?’
과거 제가 리드했던 개발 팀의 규모는 대략 6명 남짓이었습니다. 조직이 그 이상 커지면 커뮤니케이션 오버헤드가 발생해 팀을 분리하곤 했습니다. 그런데 놀라운 것은, 과거 그 6명의 인력이 한 달 내내 매달려야 했던 분량의 프로젝트를 지금의 저는 AI 에이전트 파이프라인의 도움을 받아 단 8시간 만에 홀로 끝내버렸다는 사실입니다.
이 압도적인 생산성 앞에서 묘한 고립감마저 듭니다. ‘내가 사회성이 부족해서 사람들과 협업하는 대신 결국 혼자 모든 것을 통제하고 처리하는 방식을 택한 것일까?’ 하는 인간적인 고뇌도 스쳐 지나갑니다. 심지어 최근 유행하는 멀티 에이전트(Multi-Agent) 프레임워크를 띄워 여러 AI 객체끼리 상호 논의하게 만드는 과정조차 제게는 불필요한 오버헤드이자 비효율로 느껴집니다. 그들이 떠드는 시간을 기다리느니, 디테일을 아는 제가 직접 시스템의 흐름을 짚어주고 단일 프롬프트로 통제하는 것이 훨씬 빠르고 정확하기 때문입니다.
조직이라는 거대한 환상이 걷히고 순수한 엔지니어링 역량만 남았을 때, 누군가에게 조직의 상실은 아무것도 할 수 없는 무력함으로 다가옵니다. 하지만 묵묵히 코드를 꿰매고 시스템의 바닥을 뒹굴어본 이들에게, 지금의 이 외로운 8시간은 진정한 핵심 인력으로 거듭나는 가장 밀도 높은 시간일 것입니다.
사람과의 커뮤니케이션을 줄이고 AI와 독대하며 시스템을 조립하는 이 방식이 때로는 비사회적으로 보일지라도, 실행하고 검증할 수 있는 자가 모든 것을 통제하게 되는 이 방향성은 결코 틀리지 않았다고 생각합니다. 스스로 묻고 스스로 증명해 내는 이 고독한 원맨쇼가 결국 다가올 미래 생태계의 가장 강력한 지배 구조가 될 것인지, 조직의 지원을 받으면서 살아 남는 매니징으로 남아야될찌 고민을 하게 됩니다.
직장과 직업의 차이가 여기서 느껴질 줄은 몰랐습니다.