진정한 AI-native 기업은 어떤 느낌인가 (n8n에서의 3개월)

내가 근무했던 가장 AI 지향적인 기업은 지루한 일부터 먼저 자동화한다.

나는 3개월 전, 프로세스는 가볍고 "나중에 자동화하자"라는 말이 난무하는 다소 혼란스러운 스케일업(scaleup) 기업일 것이라 예상하며 n8n에 합류했다. 하지만 입사 둘째 주에, 나는 한 에이전트(agent)가 Linear 티켓, Slack 가용성, 그리고 HiBob의 부재중 상태를 확인하여 PR(Pull Request) 리뷰어를 할당하는 것을 목격했다. 데모를 보여주거나 숨겨진 지식을 활용하는 것이 아니었다. 그것은 그냥 작동했고, 누군가가 기억해야 할 일을 하나 줄여주었다.

나는 지난 2년 동안 내 스타트업을 운영하며 내가 AI를 완전히 파악했다고 확신했었다. 하지만 나는 거의 모든 것에 대해 틀렸다.

내가 틀렸던 것들

10명 미만의 기업에서 유일한 엔지니어로 일할 때는, 100명 이상의 조직이 자동화를 진지하게 받아들였을 때 어떤 모습인지 볼 수 없다. 나는 AI-native(AI 네이티브)가 된다는 것이 좋은 도구를 가진 엔지니어들을 의미한다고 생각했다. Copilot, GPT 래퍼(wrapper), 혹은 제품에 덧붙여진 챗봇 같은 것들 말이다. 또한 나는 스케일업(scaleup) 기업이 대기업보다 프로세스가 적을 것이라고 가정했다. 더 적은 회의, 더 가벼운 시스템, 빠른 움직임 같은 것들 말이다.

두 가지 가정 모두 틀렸다. n8n에는 프로세스가 있지만, 그 프로세스는 자동화되어 있다. 성숙도는 관료주의가 아니라, 그렇지 않았다면 모두의 하루를 갉아먹었을 조정(coordination) 작업을 처리하는 에이전트(agent)와 워크플로우(workflow)로 나타났다.

한 가지 더 인정하자면, 합류하기 전에는 워크플로우 자동화(workflow automation)가 사양 산업이 되어가고 있는 것은 아닌지 걱정했다. Claude Code나 유사한 에이전트 프레임워크(agent framework) 같은 도구들이 시각적 워크플로우 빌더(visual workflow builder)의 필요성을 완전히 대체할 것처럼 보였기 때문이다. 그 두려움은 약 일주일간 지속되었다.

서류상으로는 지루해 보이는, 하지만 중요한 에이전트들

입사 둘째 주, 나는 풀 리퀘스트(pull request)를 생성했다. 나는 리뷰어를 선택하지 않았다. 팀 캘린더를 확인하지도 않았다. Slack에서 누군가에게 핑(ping)을 보내지도 않았다.

n8n 워크플로우(workflow)가 PR을 포착하여, 어떤 팀이 해당 작업을 담당하는지 이해하기 위해 Linear 티켓을 읽고, 누가 휴가 중인지 HiBob을 확인한 뒤, 가용 가능한 리뷰어 두 명을 할당했다. 그러고 나서 Slack에 PR 링크와 변경 사항이 무엇인지에 대한 요약을 게시했다.

이 모든 과정은 단 몇 초밖에 걸리지 않았다. 만약 이 시스템이 없었다면, 누군가는 팀 페이지를 훑어보고, 캘린더를 대조하며, 여유가 있는 사람이 누구인지 추측한 뒤, 수동으로 그들에게 메시지를 보냈을 것이다. 5분 정도 걸리는 작업이다. 하지만 엔지니어링 팀 전체에서 하루에도 수십 번씩 이런 일이 발생하며, 5분에 수십 번을 곱하면 아무도 신경 쓰지 않아도 될 조정(coordination) 작업에 수 시간이 소요된다는 뜻이다.

이것은 컨퍼런스 강연 주제가 될 법한 그런 종류의 AI가 아니다. 아무도 "우리는 PR 할당을 자동화했습니다"라는 내용으로 블로그 포스트를 쓰지는 않을 것이다. 하지만 이것은 팀이 운영되는 방식을 실제로 변화시키는 종류의 AI다. 화려한 AI 기능들은 데모(demo)의 주인공이 되지만, 지루한 에이전트(agent)들은 시간을 되찾아준다.

엔지니어뿐만 아니라 모두가 자동화한다

내가 다녔던 스타트업에서 자동화는 엔지니어링의 영역이었다. 자동화가 필요한 것이 있다면 내가 직접 만들었다. 그것이 사고 모델(mental model)이었다: 엔지니어는 자동화하고, 나머지 사람들은 엔지니어가 만든 것을 사용하는 것이다.

n8n에서는 영업(sales) 팀이 워크플로 (workflow)를 통해 파이프라인을 추적한다. 마케팅 팀은 콘텐츠 배포 자동화를 실행한다. 누군가는 사무실 Slack을 위한 날씨 보고 봇을 만들었다. 월드컵 기간에는 경기 업데이트를 게시하는 에이전트가 있었다. 이것들은 사이드 프로젝트나 해커톤 데모가 아니다. 매일 프로덕션(production) 환경에서 실행되고 있다.

회사에는 이를 부르는 이름이 있다: Hunderfutter Zeit. 도그푸딩 (Dogfooding). 매 분기마다 팀들은 자신의 시간을 잡아먹는 작업들을 식별하고, n8n의 자체 제품을 사용하여 이를 자동화하려고 시도한다. 누군가 강요해서가 아니라, 이곳 사람들이 자신들이 만드는 제품을 직접 사용하고 아끼기 때문이다. 당신의 제품이 워크플로 자동화 도구이고 영업 팀이 직접 자신들만의 워크플로를 구축하고 있다면, 사용자(user)와 제작자(builder) 사이의 피드백 루프 (feedback loop)는 매우 짧아진다.

기술적 지식이 없는 사람들이 누가 시키지도 않았는데 스스로 자동화(automation)를 구축하는 모습은 본 적이 없었다. 대부분의 기업에서 "우리는 AI를 사용한다"는 말은 누군가 Notion AI 구독을 했거나, 마케팅 팀이 초안 작성을 위해 ChatGPT를 사용한다는 의미다. 하지만 n8n에서 "우리는 AI를 사용한다"는 것은 채용 담당자가 지원서를 스크리닝하는 워크플로(workflow)를 가지고 있고, 영업 담당자는 통화가 끝날 때마다 CRM을 업데이트하는 워크플로를 가지고 있으며, 오피스 매니저가 재고가 임계값 아래로 떨어지면 비품을 주문하는 워크플로를 가지고 있다는 의미다.

이것은 완전히 다른 차원의 이야기다. 이는 하향식(top-down) 도구 도입이 아니다. 반복적인 업무에 대해 자동화가 기본 응답(default response)이 되는 문화다.

엔지니어링이 문화를 강화하는 방식

엔지니어링 측면은 이를 한 단계 더 발전시킨다. 우리는 개발자들이 일하는 방식을 표준화하는 커스텀 에이전트 기술(custom agent skills)을 보유하고 있다. 예를 들어, CI 검증을 통과할 수 있도록 풀 리퀘스트(pull request)를 포맷팅하는 create-pr 기술, 체계적인 버그 탐색을 위한 diagnose 기술, 그리고 구현 사항을 설계 문서와 동기화 상태로 유지하는 명세 기반 개발(spec-driven development) 워크플로 등이 있다. 또한 thermo-nuclear code review(네, 실제 이름이다)나 코드를 작성하기 전 설계를 스트레스 테스트하기 위한 grill-me와 같이 커뮤니티에서 구축한 기술들도 있다.

이것들은 "AI 마법"이 아니다. 엔지니어링 결과물의 변동성(variance)을 줄여주는 구조화된 패턴들이다. 신입 사원은 5년 차 베테랑과 동일한 PR 프로세스를 따르는데, 이는 해당 기술이 포맷팅과 CI 체크를 처리하기 때문이다. 운영 환경(production)의 문제를 디버깅하는 엔지니어는 reproduce-minimize-hypothesize-instrument(재현-최소화-가설 설정-계측) 루프를 동일하게 따르는데, 이는 diagnose 기술이 이를 강제하기 때문이다.

그리고 엔지니어링 팀이 매일 자동화된 워크플로 안에서 생활하기 때문에, 제품을 만드는 경험 자체가 달라진다. 흥미로운 새로운 기능 중 하나는 n8n의 내장형 자율 에이전트(autonomous agent)인 Instance AI와 AI 워크플로 빌더(AI Workflow Builder)다. 하루 종일 만드는 도구가 자신의 업무를 자동화하는 데 사용하는 바로 그 도구일 때, 타인을 위해 제품을 만들 때였다면 숨겨져 있었을 마찰(friction)을 발견하게 된다.

"AI-native"가 실제로 의미하는 것

n8n에 합류하기 전, 내가 정의한 AI-native는 AI 기능을 출시하고 내부적으로 AI 도구를 사용하는 기업이었다. 그것은 틀렸거나, 적어도 불완전한 정의였다.

대부분의 기업은 AI 도구를 구매한다. 엔지니어들에게 Copilot을 제공하고, 제품에 챗봇을 추가하며, 분기별 전사 회의(all-hands)에서 "AI 전략"을 발표한다. 그것은 AI-adjacent(AI 인접) 단계다. 이는 기업들이 클라우드 컴퓨팅을 도입했던 방식과 같다. 즉, 다른 누군가가 관리하는 인프라로서 외부에서 덧붙여진(bolted on) 형태다.

AI-native는 다르다. 자동화(Automation)는 하나의 프로젝트가 아니라 기본 운영 모드(default operating mode)다. 사람들이 반복적인 문제를 겪을 때, 설령 그들이 고객이 아닐지라도 제품을 찾게 된다. 에이전트(Agents)는 PR 할당이나 파이프라인 추적과 같이 화려하지 않은 조정 업무(coordination work)를 처리하며, 데모용으로 보여주기 좋은 기능들은 그 다음 순위가 된다.

3개월이 지난 지금, 만약 체크리스트를 작성해야 한다면 그 내용은 짧을 것이다. AI-native 기업은 자신의 운영(operations)을 가장 먼저 자동화한다. 엔지니어뿐만 아니라 모든 구성원이 자동화를 구축하고 유지 관리한다. 제품 팀은 공격적으로 자사 제품을 직접 사용하며(dogfoods), 내부의 고통을 신호(signal)로 취급한다. 그리고 에이전트가 지루한 업무를 수행하는데, 왜냐하면 바로 그곳에 가장 많은 시간이 소요되기 때문이다.

좋은 도구들을 갖춘 1인 창업자로서 나는 이 중 그 어떤 것도 배울 수 없었을 것이다. 핵심은 문화(culture)다. 문화는 시뮬레이션할 수 없다.