조직 AX: 개발 자동화에서 전사 AI 전환까지

조직 AX란

AX(AI Transformation) 는 AI를 개인의 보조 도구로 쓰는 단계를 넘어, 조직의 업무 흐름 자체를 AI가 맥락에 접근하고 실제 행동까지 수행하는 구조로 바꾸는 일이다. 메일 초안·이미지 생성 수준의 도움에서, 데이터와 맥락을 읽고 결과물을 만들어 배포까지 하는 수준으로 옮겨 간다.

조직 AX에서 가장 크게 바뀌는 것은 개발 속도가 아니다. 문제를 정의하는 방식, 지식을 남기는 방식, 함께 일하는 방식이 바뀐다. AI의 성능은 계속 오르지만, 그 AI를 얼마나 잘 쓰는지는 조직이 맥락을 얼마나 쌓고 연결했는지에 달려 있다.

flowchart TB
  n1["개인 보조 (Copilot·챗봇)"] --> n2["개발팀 메인 도구 (코딩 에이전트)"]
  n2 --> n3["현업 확산 (비개발자의 자동화·바이브 코딩)"]
  n3 --> n4["플랫폼화 (설치·인증·데이터 연동·배포를 감춘 사내 AI 플랫폼)"]
  n4 --> n5["맥락 축적 (데이터 맵, 마크다운으로 쌓이는 업무 프로세스)"]

계기는 대개 모델의 질적 도약이다. 코딩 에이전트가 보조에서 메인 도구로 올라서면, 고급 구독료도 개발자 인건비에 비하면 싸다는 계산이 선다.

AX의 첫 질문은 기술이 아니라 목적이다. 인력을 줄여 비용을 아끼려는가, 인력을 유지하며 생산성을 높이려는가. 인력을 그대로 두고 생산성만 올리는 시나리오는 대부분 성립하지 않는다. 이걸 솔직히 합의하지 않으면 경영진은 「효율화」, 현업은 「우리 일은 AI가 못 한다」만 말하고, AI 팀은 정치적으로 안전한 과제만 골라 단순 반복 업무 자동화에 그친다.

개인 속도와 조직 속도는 다르다

AI로 개인은 빨라져도 보고·의사결정·협업 구조가 그대로면 조직 성과는 오르지 않는다. 도구 도입과 교육보다 과소평가된 병목이 협업이다. 레거시 조직에서 AX가 개인 생산성은 높여도 조직 전체의 산출과 비용 구조를 쉽게 바꾸지 못하는 이유다.

성공 원칙 다섯 가지

#	원칙	내용
1	진짜 병목을 찾는다	회사가 생각하는 AI 니즈와 실제 핵심 병목은 다를 수 있다
2	작고 반복되는 일부터	효과를 빨리 확인하고 신뢰를 쌓는다
3	데이터와 프로세스가 먼저	AI 개발보다 데이터 정리와 업무 재설계(BPR)가 앞선다
4	쓰는 것과 맡기는 것은 다르다	믿고 맡기려면 사람의 검수 부담을 줄이는 설계가 필요하다
5	성숙도에 맞는 외부 자원	AX 단계마다 필요한 외부 도움(컨설팅, 솔루션, 인력)이 다르다

FDE: 사람이 현장에 들어가는 구조

FDE(Forward Deployed Engineer) 는 고객 현장에 들어가 업무 프로세스를 이해하고 AI가 그 환경에서 실제로 돌아가도록 시스템을 만드는 엔지니어 직무다. 주요 AI 기업이 FDE 조직을 키우는 것은 기업 AX가 제품만 팔아서는 굴러가지 않는다는 뜻이다. 고객사마다 사람이 업무를 파악하고 설계해야 하면 AI 확산 속도는 인력 확보와 현장 적용 시간에 묶인다. 한 번 만든 제품을 낮은 추가 비용으로 파는 SaaS와 구조가 다르다.

먼저 측정한다: 세 가지 실험

전사 선언 전에 "어디까지 되는가"를 실험으로 잰다. 막연한 기대 대신 숫자와 사례가 생긴다.

실험	방법	교훈
개발 자동화율	이미 끝난 PR들의 시작 시점 코드에서 태스크 설명만 주고 AI가 PR을 만들게 한 뒤, 사람의 Diff와 비교해 일치도를 잰다	실패 대부분은 태스크 설명이 부실해서다. AI가 아니라 요구사항 정의의 문제다
레거시 마이그레이션	전체 소스 접근권을 주고, 브라우저로 실제 화면에 접속해 화면·네트워크 요청을 분석하고 UI 구조·컴포넌트·데이터 모델·API·상태 관리를 정리하게 한다	기존 소스와 화면이 완벽한 기획서 역할을 하면 결과가 거의 의도대로 나온다. 오래 걸리는 일은 코딩이 아니라 기존 로직을 .md로 정리하고 테스트 케이스를 빠짐없이 쓰는 일이다
신규 서비스	짧은 요구사항 → AI가 PRD·기능 명세·페이지·UI 컴포넌트·API/모델 설계·사용자 흐름을 한 번에 생성 → 사람이 승인 → 랄프 루프로 구현	스펙만 잘 정의하면 구현은 원하는 대로 나온다. 동작하는 초안이 첫 미팅의 논의를 빠르게 한다

첫 실험은 작업 단위가 정리돼 있어야 가능하다. 태스크 하나 = 브랜치 하나 = PR 하나(GitHub Flow)라야 태스크 설명과 결과 Diff를 짝지어 채점할 수 있다. 랄프 루프(PRD 항목이 다 끝날 때까지 에이전트를 반복 실행하는 방식)는 프롬프트에서 하네스로에 정리돼 있다.

기존:

flowchart LR
  a1["요구사항 분석"] --> a2["기획"] --> a3["설계"] --> a4["구현"] --> a5["데모"]

AI:

flowchart LR
  b1["짧은 요구사항"] --> b2["PRD·명세·설계 일괄 생성"]
  b2 --> b3["사람 검토·승인"]
  b3 --> b4["루프 구현(명세 대비 검증 반복)"]
  b4 --> b5["동작하는 초안으로 첫 미팅"]

원칙: 맥락이 핵심 자산이다

원칙	뜻	실천
AI가 못하는 일은 거의 없어진다(전사 목표 선언)	코딩을 몰라도 많은 일을 자동화할 수 있다. 대상은 개발만이 아니라 문서·분석·운영·배포·데이터 처리 전부다	모든 직군이 자기 업무에서 자동화 대상을 찾는다
맥락(Context)이 핵심 자산이 된다	AI는 코드와 문서를 잘 만들지만, 왜 만들었는지·어떤 배경에서 결정했는지·어디로 가야 하는지는 조직이 남긴 맥락에서만 찾는다	생각과 암묵지를 글로 남긴다. PPT·문서를 마크다운으로 저장한다. 팀과 맥락을 공유하고 그 위에서 AI와 일한다

맥락 저장소는 AI가 읽기 쉬운 형식으로 고른다. 위키 서비스보다 로컬 마크다운 폴더(Obsidian 등)가 에이전트에게 읽히기 쉽다. 비개발자에게 Git 동기화가 허들이면 자동 pull/push 같은 보조 도구를 AI로 만들어 감춘다.

확산: 작게 시작해 허들을 치운다

1. 한 달짜리 Quick Win

거창한 계획 대신 한 달 안에 끝낼 수 있는 일로 사내 챌린지를 연다. 결과물은 직군마다 다르다.

누가	무엇을
비개발자	CRM에 없던 기능: 사이트 주소를 넣으면 쓰는 솔루션을 분석하고, 영업 리드 점수를 매기고, 제안 메일 초안까지 쓴다
개발자	에러 알람이 오면 로그를 뒤지던 일을 AI의 1차 원인 분석을 확인·승인하는 일로 바꾼다
개발팀 도구	페르소나(기획·설계·디자인·개발·리뷰·배포)를 조합해 태스크를 끝까지 처리하는 파이프라인, E2E·성능 테스트 자동화, 중앙 인증, 로컬 회의록

2. 비개발자 온보딩의 허들

개발팀이 먼저 익힌 방식을 현업에 전파하면 도구의 진입 장벽에서 막힌다.

증상	원인	해결
터미널 도구 교육이 설치·명령어 단계에서 멈춘다	비개발자에게 CLI 자체가 낯설다	GUI 에디터·데스크톱 앱에 AI가 붙은 도구로 시작한다. 익숙해지면 자연스럽게 CLI로 넘어간다
자동화를 만들어도 사내 데이터에 닿지 못한다	내부 시스템 접근 방법을 모른다	내부 데이터에 접근하는 커스텀 스킬을 배포한다

현업이 직접 만들면 필요한 것을 가장 잘 아는 사람이 만든다. 엑셀을 눈으로 비교하던 일, 매일 사람이 확인·지시하던 업무가 먼저 사라진다. 이 과정에서 개발자 수준의 AI 챔피언이 생긴다.

3. 남는 허들은 플랫폼으로 감춘다

잘 쓰는 사람은 알아서 잘하지만, 나머지에게는 허들이 남는다. 개발자가 한 명씩 도와주는 방식은 확장되지 않으므로 자생하는 구조가 필요하다.

남는 허들	플랫폼이 감추는 방식
개발 도구 설치	Node.js 등 개발 도구를 내장해 설치를 없앤다
메일·클라우드 드라이브로 흩어진 업무 자료	메일·캘린더·공유 드라이브를 연동해 묻고 답하고 생성까지 한다. 동기화한 파일은 색인·암호화해 보관한다
내부 시스템 연동의 까다로운 인증·설정	ERP·그룹웨어(전자결재 등)를 미리 연계해 둔다
노하우가 개인에게 머문다	스킬과 워크플로를 공유한다
배포	바이브 코딩부터 사내망 배포까지 한 번에 처리한다 (아래)

사내 플랫폼은 Claude 같은 상용 앱과 비슷한 모양으로 쓰기 쉽게 설계하고, 자체 개발은 최소화한다.

파일 기반 에이전트가 대표 패턴이다.

flowchart TB
  n1["재무 데이터(xlsx) + 월간 보고서 → 한 디렉터리"]
  n1 --> n2["대용량 xlsx → DuckDB에 적재, 컬럼 메타데이터 설정"]
  n1 --> n3["월간 보고서 → .md로 변환해 색인"]
  n2 --> n4["디렉터리를 공유 폴더로 담당자와 공유"]
  n3 --> n4
  n4 --> n5["플랫폼에서 프로젝트 생성 + 지침 #quot;이 디렉터리를 보고 경영 정보를 알려줘#quot;"]
  n5 --> n6["최근 지표·이슈 질문에 답한다"]

원래 가진 파일을 그대로 쓰므로 권한 문제가 생기지 않는다. 접근할 수 있는 사람만 공유 폴더를 본다.

바이브 코딩 앱의 사내 배포

개발자가 아닌 사람까지 바이브 코딩을 하면, 검토 없이 만든 결과물이 나중에 개발팀의 일로 돌아온다.

문제	왜 생기나	대응
API 키 노출, `.env` 파일 커밋	비밀 값을 코드나 저장소에 넣어도 동작은 하니 아무도 모른다. PR부터 배포까지 AI에 맡기면 사람이 볼 지점이 사라진다	배포 파이프라인에 비밀 스캔과 사람 승인을 넣는다(DevSecOps)
스프레드시트·Apps Script 대시보드가 느려짐	시트는 데이터베이스가 아니라 데이터가 쌓일수록 느려진다	결국 DB로 옮기는 마이그레이션 요청이 개발팀으로 온다. 데이터가 계속 쌓일 도구는 처음부터 DB를 쓰게 한다
BaaS로 만든 PoC를 옮기기 어려움	Supabase처럼 Postgres 위에 인증·스토리지·자동 생성 API·실시간 기능을 얹은 서비스는, 그 편의 기능이 DB 자체 기능이 아니다	다른 DB·서버로 옮길 때 인증·권한 정책·API 계층을 다시 만들어야 한다. PoC를 제품으로 키울지 미리 정하고, 그렇다면 플랫폼 종속 기능 사용을 의식적으로 고른다

그래서 사내에 바이브 코딩을 퍼뜨릴 때는 만드는 도구보다 배포·검토 경로를 먼저 깐다. 바이브 코딩이 늘면 "이거 팀에 공유하고 싶다"는 요청이 계속 생긴다. 배포는 비개발자가 혼자 넘기 가장 어려운 단계라서 플랫폼이 가장 신경 써야 할 기능이다.

요구 사항

내부망에만 배포한다.
배포 전에 보안 검토를 거친다.
사용자별로 인증하고 공유 범위(전체 / 일부 사용자 / 비공개)를 정할 수 있다.

구조

flowchart TB
  n1["사용자: 바이브 코딩"] --> n2["공개 범위 설정"] --> n3["#quot;배포해줘#quot;"]
  n3 --> n4["로그인한 사용자 계정으로 GitLab 연동, 임의 이름 프로젝트 생성, 파일 업로드"]
  n4 --> c1
  subgraph ci["GitLab CI/CD"]
    c1["빌드"] --> c2["보안 스캔"] --> c3["Slack 알림"] --> c4["담당자 승인"] --> c5["배포"]
  end
  c5 --> n5["사내 Kubernetes, DB는 SQLite, /data를 퍼시스턴트 볼륨으로"]

접속:

flowchart LR
  ing["Ingress"] --> px["인증 프록시"] --> pod["앱 Pod"]
  px -->|"미인증"| login["로그인 화면"]
  px -->|"인증됨 + 앱 권한 있음"| pass["통과"]
  px -->|"권한 없음"| block["차단"]
  px -->|"모든 접근"| audit["감사 로그로 남김"]

설계 결정	이유
별도 솔루션 없이 기존 CI/CD 사용	이미 운영 중인 파이프라인에 단계만 더하면 된다
기본 DB는 SQLite + `/data` 볼륨	바이브 코딩 앱 대부분은 작다. DB 서버를 따로 띄우지 않아도 데이터가 남는다
보안 검토를 CI 중간의 스캔 단계로	사람이 매번 코드를 읽지 않아도 배포 전에 걸러진다
최종 배포는 사람이 승인	완전 자동화는 아직 불안하다. 마지막 판단은 사람이 쥔다
인증을 앱이 아니라 앞단 프록시가 맡음	앱마다 인증 코드를 넣게 하면 비개발자가 만든 앱마다 보안 수준이 달라진다. Cloudflare Access 같은 제로 트러스트 접근 프록시 방식으로, 앱은 인증을 몰라도 된다

인증·인가를 앱 밖으로 빼는 판단은 세션 인증과 토큰 인증의 일반 원칙과도 맞닿는다.

다음 단계: 맥락을 모으고 연결한다

도구와 배포 시스템을 갖추면 남는 병목은 맥락의 양과 질이다. 방향은 "없는 데이터는 모으고, 모으는 맥락은 더 정확하게 만들고, 서로 연결한다"이다.

할 일	방법
가시성	데이터 맵을 만들고, 중요한 데이터부터 우선순위대로 연계한다
비정형 데이터 회수	이메일과 로컬 PC에 묻힌 정보가 마크다운으로 자연스럽게 쌓이도록 업무 프로세스를 리팩터링한다
빈 맥락 채우기	업무 흐름을 고치거나 새 시스템을 만들어 보완한다. 예를 들어 전자결재에 AI 스크리닝과 검수·제안 단계를 더하면 결재 과정의 판단이 데이터로 남는다

정리

목적부터 합의한다. 비용 절감인지 생산성인지 솔직히 정하고, 개인 속도가 아니라 협업 구조의 병목을 본다.
실험으로 먼저 잰다. 과거 PR을 태스크 설명만으로 재현해 보면 자동화율과 실패 원인이 숫자로 나온다. 실패 대부분은 AI가 아니라 요구사항 부실이다.
스펙과 기존 자산이 기획서다. 신규 개발은 PRD·명세를, 마이그레이션은 기존 소스·화면·테스트 케이스를 정확히 주면 구현은 따라온다. 시간이 드는 곳은 코딩이 아니라 정리다.
맥락이 자산이다. 암묵지를 글로, 문서를 마크다운으로, AI가 읽기 쉬운 저장소에 모은다.
작게 시작하고 허들을 치운다. 한 달짜리 Quick Win, GUI 도구로 시작하는 온보딩, 내부 데이터용 커스텀 스킬이 확산을 만든다.
혼자 되는 구조를 만든다. 설치·인증·데이터 연동·배포를 플랫폼이 감추고, 보안 스캔·사람 승인·앞단 인증 프록시로 안전하게 공유하게 한다.

버그 제보