우리가 "개발자"라고 부르는 직업이 근본적으로 다른 무언가로 변하고 있다고 믿습니다. 이것은 단순히 도구가 변하거나 생산성이 향상되는 문제가 아닙니다. 직업의 정체성 자체가 다른 곳으로 이동하고 있습니다. 만약 제가 이를 한 단어로 정의해야 한다면, 개발자는 파이프라이너 (Pipeliner)가 됩니다.

개발자는 언제나 "지능적 실행자 (intelligent executor)"였습니다

이 주장을 하기 위해서는, 개발자가 지금까지 실제로 무엇을 해왔는지부터 시작해야 합니다. 우리는 개발자를 "빌더 (builders)"라고 부르지만, 업무의 본질은 번역 (translation)이었습니다. 타인이 정의한 명세 (spec) — 계획, 요구사항, 티켓, 회의에서 오간 말들 — 를 가져와서 기계가 실행할 수 있는 형태로 구현하는 것입니다. 개발자는 인간의 의도와 기계의 실행 사이에서 통역사 역할을 수행했습니다.

하지만 이 번역은 결코 기계적이지 않았습니다. 명세는 항상 불완전하고, 모순적이며, 빈틈투성이입니다. 그 빈틈을 판단력으로 채우고, 예외 케이스 (edge cases)를 상상하며, 명시되지 않은 것을 추론하여 이 모든 것을 작동하는 시스템으로 만드는 것 — 그것은 단순 노동이 아니라 지적 노동이었습니다. 그래서 저는 개발자를 더 정확하게 지능적 실행자 (intelligent executor), 즉 지능을 사용하여 실행하는 사람이라고 묘사하고 싶습니다. 그것이 지난 수십 년 동안 개발자를 개발자로 만들어준 것이었습니다.

흥미로운 점은 이 역할이 여러 차례의 "자동화 위협 (automation threat)" 파도를 견뎌냈다는 것입니다. 어셈블리 (assembly)에서 고수준 언어 (high-level languages)로, 고수준 언어에서 프레임워크 (frameworks)로, 온프레미스 (on-premise)에서 클라우드 (cloud)로 말이죠. 추상화 (abstraction) 단계가 한 단계씩 높아질 때마다, _실행 (execution)_의 상당 부분이 자동화되었습니다. 더 이상 수동으로 메모리를 관리하지 않고, 직접 서버를 구축하지도 않습니다. 그럼에도 불구하고 개발자는 매번 살아남았습니다. 자동화된 것은 실행의 기계적인 (mechanical) 부분이었던 반면, _판단 (judgment)_이 필요한 실행은 인간의 몫으로 남았기 때문입니다. "실행"은 조금씩 깎여 나갔지만, "지능"은 온전하게 유지되었습니다.

이번에는 다릅니다 — AI가 "지능"의 영역을 가져갔습니다

바로 이 지점이 AI가 모든 것을 바꾸는 지점입니다. 현재 자동화되고 있는 것은 실행(execution)의 기계적인 부분이 아니라, 실행에 필요한 판단(judgment)입니다. 불완전한 명세(spec)의 빈틈을 채우고, 엣지 케이스(edge cases)를 상상하며, 명시되지 않은 내용을 추론하여 작동하는 코드로 변환하는 것 — 즉, 지능적인 실행자(intelligent executor)의 정의 그 자체 — 를 이제 AI가 수행합니다.

이것은 결정적입니다. 이전의 모든 자동화 물결은 개발자로부터 "실행"을 떼어갔지만, "지능"에는 결코 손을 대지 않았습니다. 덕분에 개발자는 더 높은 추상화 단계로 올라가 그곳에서도 지능적인 실행자로 남을 수 있었습니다. 하지만 이번에는 지능 그 자체가 가져가 버렸습니다. 개발자를 개발자로 만들었던 핵심 요소가 통째로 이전되고 있습니다. 기존의 공식인 "그저 더 높은 추상화 단계로 올라가라"는 이번에는 통하지 않습니다. 사다리 그 자체가 AI에게 넘겨졌기 때문입니다.

그렇다면 무엇이 남는가 — 지능을 배치하는 일

실행이 AI에게 넘어갔다면, 인간에게 남은 것은 무엇일까요? 답은 명확합니다. 그 AI가 일을 잘하도록 만드는 것입니다. 그리고 그것은 매우 거대한 작업임이 드러났습니다.

AI는 강력한 실행 엔진(execution engine)이지만, 스스로는 아무것도 하지 못합니다. 무엇을 입력값으로 받아야 하는지, 어떤 컨텍스트(context)가 함께 제공되어야 하는지, 출력값이 무엇을 기준으로 검증되어야 하는지, 실패했을 때 어디로 흘러가야 하는지, 그리고 그 출력값이 다음 단계의 무엇과 연결되어야 하는지 — 누군가는 이 모든 것을 설계해야 합니다. 지능이라는 원재료를 어디에 쏟아부을지, 어떤 파이프(pipes)를 통해 흘려보낼지, 그리고 어떤 밸브(valves)로 이를 제어할지를 결정하는 일 말입니다. 저는 이것을 파이프라인(pipeline)이라고 부릅니다.

여기서 "파이프라인"은 CI/CD 파이프라인이나 데이터 파이프라인과 같은 좁은 의미의 기술 용어가 아닙니다. 훨씬 더 광범위합니다. 지능이 흐르는 전체 경로를 설계하고 관리하는 것을 의미합니다. 이는 벽돌을 쌓는 일이라기보다, 도시 전체의 물이 어떻게 이동할지를 설계하는 수자원 엔지니어가 되는 것에 더 가깝습니다. 벽돌은 이제 AI에 의해 무한히 찍어내집니다. 문제는 그 벽돌들을 어떻게 흐름(flow)으로 배열하느냐이며, 그 흐름을 다루는 사람이 바로 파이프라이너(pipeliner)입니다.

이는 개발자가 '코드를 작성하는 사람'에서 '흐름을 설계하는 사람'으로 이동한다는 것을 의미합니다. 자신의 손으로 구축하던 사람에서 손들을 배열하는 사람으로 말이죠.

왜 '개발자(developer)'라는 단어가 더 이상 적합하지 않은가

하지만 여기서 하나의 생각이 떠오를 수 있습니다. 만약 흐름을 설계하고 연결하는 것이 일이라면, 개발자는 원래부터 그것을 하고 있지 않았던가요? 함수들을 배선하고, 모듈들을 연결하고, 데이터 흐름을 설계하는 것—이 자체가 파이프라이닝(pipelining) 아닌가요?

미시적인 수준에서는 그 말이 맞습니다. 어떤 의미에서 개발자는 항상 파이프라이닝을 해왔고, 이를 부정할 수는 없습니다. 하지만 결정적인 차이는 그 파이프라이닝이 일어나는 단위(unit)—즉, _수준(level)_에 있습니다.

지금까지 개발자의 파이프라이닝은 코드 수준 안에 갇혀 있었습니다. 주어진 사양 내에서 함수와 모듈을 배선하고, 이미 그려진 시스템 경계 안에서 말입니다. 그보다 높은 수준—우리가 이것을 왜 구축하는지, 어떤 고객 문제를 해결하는지, 비즈니스 용어상 흐름이 어떻게 보여야 하는지—는 보통 다른 사람(기획자, PM, 비즈니스 측)에 의해 결정되어 개발자는 그 울타리 안에서만 흐름을 엮었습니다. 파이프라이닝의 단위가 코드 수준에 머물렀기 때문에 '개발자(developer)'라는 이름—즉, 개발하는 사람—으로 충분했습니다.

지금 시대가 요구하는 것은 다른 수준에서의 파이프라이닝입니다. 코드 수준을 넘어서는 곳에서: 실제 고객 문제가 해결되는 비즈니스 수준에서 흐름을 설계하고, 그것을 해결하는 전체 시스템의 수준에서 말입니다. AI가 코드 수준의 파이프라이닝을 담당하게 되면서, 인간에게 남은 것은 그 위의 파이프라이닝입니다. 그리고 이 작업은 더 이상 코드를 개발하는 것에 관한 것이 아니므로, 좁은 단어인 '개발자(developer)'로는 담아낼 수 없습니다. 특정 재료로서의 코드에 얽매이지 않으면서 여러 수준에 걸쳐 흐름을 짜는 사람—그것이 제가 새로운 이름이 필요하다고 생각하는 이유입니다. 바로 파이프라이너(pipeliner)입니다.

파이프라이너의 역량 — ABCD2

그렇다면 이 파이프라이너는 어떤 역량이 필요할까요? 저는 이를 다섯 가지로 정리했습니다. 이해(Comprehend), 추상화(Abstract), 해체(Dissolve), 구축(Build), 설명(Describe). 이들의 첫 글자를 따서, 저는 이것을 ABCD2라고 부릅니다.

이것들을 추상적으로만 나열하면 와닿지 않으므로, 하나의 시나리오를 통해 실례를 들어보겠습니다. 어떤 회사가 "AI를 사용하여 고객 환불 프로세스를 자동화하고 싶다"라고 말한다고 가정해 봅시다. 파이프라이너(Pipeliner)는 이 문제를 어떻게 다룰까요?

이해(Comprehend). 먼저 당신이 연결해야 할 세상을 이해해야 합니다. 이 작업은 "환불"이라는 단어가 이 회사에서 실제로 무엇과 맞닿아 있는지를 파악하는 것입니다. 환불은 회계 장부(accounting ledger)와 연결되고, 재고를 반전시키며, 고객의 신뢰에 영향을 미치고, 세무 및 법적 문제와도 직결됩니다. 오직 해피 패스(happy path)만을 보는 사람은 여기서 이미 실패한 것입니다. 세상이 실제로 어떻게 돌아가는지 모른다면, 당신이 연결해야 할 바로 그 대상 자체를 오해하게 됩니다. 이해(Comprehension)란 파이프라인의 재료를 정확하게 아는 것입니다.

추상화(Abstract). 당신이 이해한 현실은 무질서합니다. 예외 사항, 특수 사례, 그리고 사내 정치 등이 모두 뒤엉켜 있습니다. 그 무질서한 현실로부터 당신이 다룰 수 있는 필수적인 구조만을 뽑아내는 것이 추상화(Abstraction)입니다. 다음과 같은 뼈대를 세우는 것이죠: "환불은 궁극적으로 5단계로 이루어진다 — (거래 식별) → (환불 자격 판단) → (금액 계산) → (승인 획득) → (실행)." 좋은 추상화는 중요한 것을 버리지 않으면서 현실을 단순화합니다. 그러한 균형 감각이 추상화의 핵심이며, 배우기 가장 어려운 부분입니다.

해체(Dissolve). 이제 추상화된 뼈대를 실행 가능한 단위로 나눕니다. 왜 나누어야 할까요? 만약 AI에게 전체를 통째로 던져주며 "환불을 알아서 처리해"라고 한다면, 출력값(output)을 검증할 방법이 없기 때문입니다. 한 덩어리로 되어 있으면 어디서 잘못되었는지 알 수 없습니다. 각 단위가 독립적으로 검증 가능하도록, 즉 AI가 각 조각을 처리할 수 있고 인간이 각 조각을 확인할 수 있도록 해체(Dissolve)해야 합니다. 해체는 단순히 작게 자르는 것이 아니라, 검증 가능한 경계(verifiable boundaries)를 따라 자르는 감각입니다.

Build (구축). 이제 해체된 단위들을 하나의 흐름으로 엮어내야 합니다. 각 단계에 AI를 배치하고, 단계 사이에 검증 (verification) 과정을 삽입하며, 실패 시 인간에게 업무를 넘기는 폴백 (fallback)을 설계하고, 승인 단계에는 인간이 개입하는 루프 (human-in-the-loop)를 구축하십시오. 단위를 만드는 것과 흐름을 만드는 것은 서로 다른 능력입니다. 좋은 부품들을 모았더라도 흐름이 엉켜 있다면 시스템은 제대로 작동하지 않을 수 있습니다. 구축한다는 것은 실제로 물이 흐를 수 있도록 배관을 연결하는 것과 같습니다.

Describe (설명). 마지막으로, 당신은 그 흐름을 명확하게 설명할 수 있어야 합니다. 이것은 부가적인 능력이 아니라 필수적인 능력입니다. 당신이 무엇을, 왜, 어떻게 연결했는지 말로 표현할 수 없다면, 그 파이프라인은 유지보수할 수 없고, 감사 (audit)할 수 없으며, 다른 사람에게 인계할 수도, 판매할 수도 없습니다. 그리고 더 근본적으로, 설명한다는 것은 정의를 스스로 소유한다는 것을 의미합니다. "이 환불 로직은 이런 방식으로 판단해야 한다고 내가 결정했다"라고 말할 수 있고, 그 결과에 책임을 지는 것입니다. 설명하는 능력은 소유권 (ownership)과 분리될 수 없습니다.

이해 (Comprehend), 추상화 (Abstract), 해체 (Dissolve), 구축 (Build), 설명 (Describe). ABCD에 두 가지가 더 추가되었으므로, 이것은 ABCD2입니다. 그리고 이미 눈치채셨겠지만, 이 다섯 가지 중 어느 것도 "좋은 코드를 작성하는 능력"이 아닙니다.

증거로서의 FDE

이러한 역량 세트는 아직 널리 인식되지 않았지만, 그 프로토타입은 이미 시장에 존재합니다. 바로 FDE — 포워드 디플로이드 엔지니어 (Forward Deployed Engineer)입니다.

FDE는 전통적인 개발자와는 다른 일을 합니다. 그들은 고객의 조직으로 들어가 그들의 세계를 이해 (comprehend)하고, 실제 문제를 추상화 (abstract)하며, 이를 해결 가능한 단위로 해체 (dissolve)하고, 실제로 작동하는 흐름을 구축 (build)하며, 이를 고객 조직에 설명 (describe)하고 설득합니다. FDE의 가치는 코드 라인 수에서 나오는 것이 아닙니다. 고객의 혼란스러운 현실을 도구와 연결하는 능력에서 나옵니다.

다시 말해, FDE는 이미 파이프라이너 (Pipeliner)입니다. AI가 실행 (Execution) 단계를 완전히 장악하기도 전에, 시장은 이미 "연결하고 설계하는 자"의 가치가 "실행하는 자"의 가치를 압도하는 지점을 발견했습니다. 최근 몇 년 동안 FDE가 가장 높은 보수를 받는 엔지니어링 직군 중 하나가 된 것은 우연이 아닙니다. 그것은 파이프라이너 시대의 선행 지표입니다.

진짜 문제 — 완충제로서의 "실행"이 사라짐

FDE와 같이 소수가 위로 올라가는 동안, 그 아래에서는 정반대의 현상이 일어납니다. 지금까지 "실행 (Execution)"은 지식 노동의 거대한 완충 지대 (Buffer zone)였습니다. 아주 뛰어나지 않더라도, ABCD2를 완벽히 갖추지 못했더라도, 대부분의 사람들은 잘 정의된 과업을 성실히 수행하는 것만으로도 유용했습니다. 명세서 (Spec)를 코드로 변환하는 개발자, 데이터를 정리하는 분석가, 할당된 캠페인을 운영하는 마케터, 템플릿에 맞춰 문서를 만드는 사무직 직원까지. 그들은 모두 "지능적인 실행자 (Intelligent executors)"였으며, 실행이라는 완충제 위에서 안정적으로 일해 왔습니다.

이 완충 지대가 사라지고 있습니다. 일단 AI가 실행을 담당하게 되면, 성실한 실행만으로는 더 이상 가치를 창출할 수 없습니다. 남는 것은 파이프라인 (Pipeline)을 설계하는 것입니다. 완충 지대가 사라진 세상에서는 기술 분포의 "중간"이 붕괴합니다. 최상위 파이프라이너와 대체된 실행자 사이에 위치하며 대부분의 지식 노동자들이 머물렀던 넓은 중간 계층이 완전히 얇아집니다.

그리고 이것은 단지 개발자만의 이야기가 아닙니다

여기서 논의의 범위가 폭발적으로 확장됩니다. ABCD2는 개발자에게만 요구되는 역량이 아닙니다. 당신이 AI를 실행 엔진 (Execution engine)으로 삼아 그 위에서 작업하는 순간, 지식을 다루는 모든 노동자에게 동일하게 요구됩니다.

플래너(Planner) 또한 더 이상 계획을 작성하는 사람이 아니라, 문제를 이해하고, 해체하며, AI가 좋은 계획을 생성할 수 있도록 흐름을 설계하는 사람입니다. 마케터, 분석가, 컨설턴트, 변호사, 회계사도 마찬가지입니다. 각 도메인에서 "실행 (Execution)"은 AI에게 넘어가고, 남는 것은 그것을 지시하는 파이프라이닝 (Pipelining)입니다. 직함은 다르지만, 요구되는 근본적인 역량은 단 하나, ABCD2로 수렴합니다. 따라서 파이프라이너 (Pipeliner)는 개발자의 미래이기 이전에 지식 노동자 (Knowledge worker)의 미래입니다.

문제는 이 다섯 가지를 실제로 수행할 수 있는 사람이 적다는 것입니다. 지금까지 그래왔고, 앞으로도 그럴 것입니다. 이해(Comprehending), 추상화(Abstracting), 해체(Dissolving), 구축(Building), 그리고 기술(Describing)은 매뉴얼로 가르칠 수 없습니다. 이러한 능력은 판단력(Judgment), 취향(Taste), 주인 의식(Ownership), 시스템 사고(Systems thinking) 위에 세워지며, 이러한 능력은 훈련을 통해 쉽게 복제되지 않습니다.

역사는 이미 이러한 패턴을 보여주었습니다. 역직기 (Power loom)가 직조를 자동화했을 때, 수많은 직공이 모두 역직기 설계자로 전환되지는 않았습니다. 역직기를 설계하고 운영할 수 있는 사람은 극소수였으며, 필요한 인원 또한 극소수였습니다. 실행이 자동화되면, 그 실행을 설계하는 자리는 실행을 수행하는 자리보다 항상 훨씬 적습니다. 지금 일어나고 있는 일도 구조적으로 동일합니다. 유일한 차이점은 이번에 자동화되는 것이 손이 아니라 지능이라는 점이며, 따라서 영향을 받는 것이 육체 노동이 아니라 지식 노동 전체라는 점입니다.