Netlify CTO 다나 로슨: 코딩은 이제 직업이 아니다

출처: The New Stack

“저는 90년대부터 이 일을 해왔습니다—인간이 프로덕션을 망치는 것을 방지하기 위한 가드레일을 수십 년 동안 구축해 왔죠. 이제 우리는 그 가드레일을 제거하고 이렇게 말합니다: ‘와, 우리와 함께 놀아보세요, 창조해보세요, 세상의 다음 경험을 만들어보세요.’” 라고 Netlify CTO Dana Lawson이 이번 주 런던에서 열린 AI Native DevCon에서 가득 찬 청중에게 전했습니다.

에이전시 AI는 새로운 추상화 레이어를 확립했습니다. 대화형 언어로 표현된 의도가 다음 프로그래밍 언어가 되어, 훨씬 더 많은 사람들이 이를 활용해 만들 수 있게 된 것이죠. AI가 빌더라고 부르는 존재를 가능하게 하면서 2029년까지 10억 개의 새로운 애플리케이션이 등장할 것입니다(IDC 보고서).

시민 개발자들에게는 분명 좋은 소식입니다. 하지만 많은 소프트웨어 엔지니어에게는 이번이 처음으로 경력에 대한 불확실성을 마주하는 순간이 될 것입니다. 업계—그리고 더 나아가 세상—은 너무 빠르게 변하고 있으며, 기술 분야 해고 소식이 헤드라인을 장식하고 있습니다. 설령 여러분의 회사가 그런 급진적인 조치를 취하지 않았더라도, 코드를 거의 작성하지 않게 된 지금 자신의 역할을 고민하는 것은 자연스러운 일입니다.

그렇다면 코드 작성이 더 이상 소프트웨어 개발을 정의하지 않을 때, 엔지니어를 구분 짓는 요소는 무엇일까요? Lawson에 따르면, 엔지니어는 에이전트 경험(AX, Agent Experience) 이 무엇이고, 어떻게 해야 하는지를 이해하는 사람들입니다.

런던에서 열린 AI Native DevCon에서의 Dana Lawson (출처: The New Stack)

엔지니어 역할이 바뀌었나요?

어느 정도는 그렇지만, 어느 정도는 그렇지 않습니다. 코딩은 엔지니어 업무의 4분의 1도 안 되는 일이며, 점점 전략적 가치가 가장 낮은 부분이 되고 있기 때문입니다.

“당신은 프로덕션의 목자(shepherd)입니다.” 라고 Lawson은 AX 시대의 엔지니어 경험을 설명합니다. “들어오고 나가는 것이 잘 이해되도록 보장하세요. 에이전시 경험을 제대로 구현한다면, 그 에이전트는 이벤트 기반 활동이 될 것이며, 신호는 개발자에게 푸시되고, 개발자는 풀하지 않아도 됩니다.”

이제는 에이전시 채택의 성공 여부가 복잡한 시스템에 대한 포괄적인 이해, 프로덕션까지의 경로, 그리고 비즈니스 컨텍스트에 달려 있습니다.

“에이전트 경험은 소프트웨어 전달 라이프사이클 전반에 걸친 새로운 시스템 컨텍스트와 의도를 고민하는 것입니다.” 라고 Lawson은 주장합니다. “이는 인간과 에이전트가 매끄럽게 협업하도록 설계하는 실천이며, 단순히 API 호출을 에이전트 친화적으로 만든다는 의미가 아닙니다.”

Netlify는 2014년에 프론트엔드 웹사이트와 애플리케이션 개발자를 위한 플랫폼으로 시작했습니다. 하지만 지금의 시민 개발자들은 ‘개발자’라는 언어를 사용하지 않으며, Git이 무엇인지조차 모릅니다. 이에 대응해 Netlify는 개발자뿐 아니라 AI 에이전트와 새로운 빌더와도 소통할 수 있도록 플랫폼을 재구축해야 했습니다.

두 새로운 청중을 위해 플랫폼을 재설계하면서 Netlify는 기존 개발자들에게도 더 나은 서비스를 제공하게 되었습니다. Lawson이 정의한 바와 같이 에이전트 경험은 개발자 경험과 사용자 경험의 결합이기 때문입니다. 양쪽을 모두 해결함으로써 그녀의 팀은 학문적·도메인 지식 장벽을 허물어, 컴퓨터 과학 학위가 없는 사람도 산업에 진입할 수 있게 만들었습니다.

“에이전트 오류 메시지를 명확히 하고, 빌드 출력을 기계가 읽을 수 있게 구조화하고, 불필요한 마찰을 없앴을 때, 우리 개발자들도 혜택을 받았습니다.” 라고 Lawson은 회상합니다. “우리가 인간의 가정을 하나씩 없앨수록, 플랫폼은 모두에게 더 나아집니다.”

두 종류의 빌더에게 중요한 것은 ‘무엇을 만들 것인가’ 입니다.

Outcome Engineering이 주장하듯, AI는 인간의 대역폭을 제한 요소로서 제거합니다. 따라서 엔지니어의 업무는 **‘무엇을 만들지 않을지’**를 결정하는 일에 더욱 집중하게 됩니다.

“쓴맛 나는 진실은, 여러분이 곧 수개월 안에 구식이 될 수많은 무언가를 만들게 될 것이라는 점입니다. 올바른 경로를 찾고, 의도를 올바른 영역에 배치하는 것이 핵심이 될 겁니다.” 라고 Lawson은 The New Stack과의 후속 인터뷰에서 말했습니다. “이때문에 개발 및 엔지니어링 관행이 핵심이 됩니다. 이제 전 세계 누구든지 문자 그대로 무언가를 만들 수 있기 때문이죠.”

엔지니어는 빌더가 만든 것이 비즈니스, 고객, 보안, 그리고 세상에 적합한지를 검증해야 합니다.

“우리는 압축(compaction) 을 구현하고, 압축(compression) 을 고민하며, 인터넷이 모두에게 개방되고 민주화된 상태를 유지하도록 올바른 리소스를 구축해야 한다는 책임감을 짊어지고 있습니다. 동시에 환경 친화적이어야 합니다.” 라고 그녀는 덧붙였습니다.

즉, 엔지니어링은 내부 기술 스택, 사람, 프로세스에 그 어느 때보다 집중해야 합니다.

에이전트와 에이전시 의도를 위한 시스템 재구축

“우리는 의도를 표현하는 방식부터 시스템이 소통하는 방식까지 전체 스택을 재고해야 합니다. 그래야만 신뢰할 수 있기 때문이죠.” 라고 Lawson은 말합니다. 기업용 시스템은 원래 인간 운영자를 위해 설계되었으니까요.

“당신이 루프에 참여한다는 전제 하에 설계된 의도였지만, 에이전트는 연속적으로 작동하도록 설정된 시스템을 다루기 힘듭니다. 경계 너머를 볼 수 없고, 모든 API가 서로 다른 방언을 사용하기 때문이죠.” 라고 Lawson은 설명합니다. 중요한 워크플로우는 구전으로만 전해지고, “2022년 Slack 스레드에 남겨진, 문서화되지 않은 Terraform 모듈”에만 존재합니다.

Lawson이 제시한 에이전트 경험을 향상시키는 아키텍처 진화는 다음과 같습니다.

• API → 기능(Capability): 기존 소프트웨어 아키텍처는 POST, GET, PATCH와 같은 API 엔드포인트를 제공했지만, 에이전트‑네이티브 시스템은 ‘create_a_site’, ‘deploy_repository’ 와 같이 무엇을 달성하고 싶은지를 표현하는 기능 수준 연산을 제공합니다.
• 요청‑응답 → 이벤트‑드리븐: 요청하고 기다리는 방식에서 벗어나, 에이전트는 이벤트를 구독하고 시스템 행동을 관찰하며, 허가된 경우 자율적으로 행동합니다.
• 기계‑읽기 가능 → 에이전트‑읽기 가능: 기존에 인간이 이해하기 어려웠던 “신비로운” 아키텍처 조각들을 에이전트와 인간 모두가 이해할 수 있는 설계 청사진으로 전환해, 변경 전 시스템을 파악하도록 돕습니다.

“이 개발 사이클은 연속적인 인간‑에이전트 루프가 됩니다. 이제는 운영팀에 넘겨주는 ‘핸드오프’가 아니라, 모든 사람이 동시에 참여하고, 인간은 판단·미감·방향성을 제공하며 루프에 남아 있습니다. 이 루프는 기계 속도로 움직이며, 엔지니어를 대체하는 것이 아니라 모두의 빌더 역량을 증폭시킵니다.” 라고 Lawson은 말합니다.

인간이 설정한 에이전시 경계

“에이전트는 단순히 코드를 작성하는 것이 아니라, **엔터프