목차12개 항목
출처와 참고
subicura의 「개발 자동화에서 조직 AX까지」(2026.07)를 바탕으로 재구성한 노트다.
조직 AX란
AX(AI Transformation) 는 AI를 개인의 보조 도구로 쓰는 단계를 넘어, 조직의 업무 흐름 자체를 AI가 맥락에 접근하고 실제 행동까지 수행하는 구조로 바꾸는 일이다. 메일 초안·이미지 생성 수준의 도움에서, 데이터와 맥락을 읽고 결과물을 만들어 배포까지 하는 수준으로 옮겨 간다.
조직 AX에서 가장 크게 바뀌는 것은 개발 속도가 아니다. 문제를 정의하는 방식, 지식을 남기는 방식, 함께 일하는 방식이 바뀐다. AI의 성능은 계속 오르지만, 그 AI를 얼마나 잘 쓰는지는 조직이 맥락을 얼마나 쌓고 연결했는지에 달려 있다.
flowchart TB n1["개인 보조 (Copilot·챗봇)"] --> n2["개발팀 메인 도구 (코딩 에이전트)"] n2 --> n3["현업 확산 (비개발자의 자동화·바이브 코딩)"] n3 --> n4["플랫폼화 (설치·인증·데이터 연동·배포를 감춘 사내 AI 플랫폼)"] n4 --> n5["맥락 축적 (데이터 맵, 마크다운으로 쌓이는 업무 프로세스)"]
계기는 대개 모델의 질적 도약이다. 코딩 에이전트가 보조에서 메인 도구로 올라서면, 고급 구독료도 개발자 인건비에 비하면 싸다는 계산이 선다.
먼저 측정한다: 세 가지 실험
전사 선언 전에 "어디까지 되는가"를 실험으로 잰다. 막연한 기대 대신 숫자와 사례가 생긴다.
| 실험 | 방법 | 교훈 |
|---|---|---|
| 개발 자동화율 | 이미 끝난 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["최근 지표·이슈 질문에 답한다"]
원래 가진 파일을 그대로 쓰므로 권한 문제가 생기지 않는다. 접근할 수 있는 사람만 공유 폴더를 본다.
바이브 코딩 앱의 사내 배포
바이브 코딩이 늘면 "이거 팀에 공유하고 싶다"는 요청이 계속 생긴다. 배포는 비개발자가 혼자 넘기 가장 어려운 단계라서 플랫폼이 가장 신경 써야 할 기능이다.
요구 사항
- 내부망에만 배포한다.
- 배포 전에 보안 검토를 거친다.
- 사용자별로 인증하고 공유 범위(전체 / 일부 사용자 / 비공개)를 정할 수 있다.
구조
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 도구로 시작하는 온보딩, 내부 데이터용 커스텀 스킬이 확산을 만든다.
- 혼자 되는 구조를 만든다. 설치·인증·데이터 연동·배포를 플랫폼이 감추고, 보안 스캔·사람 승인·앞단 인증 프록시로 안전하게 공유하게 한다.
관련 노트: 브라우저 안 빌드·프리뷰 환경, AI 플랫폼 전환과 일의 재편, AI로 개발 가속하기, 프롬프트에서 하네스로, AI 시대 개발자의 역할, 조직의 디지털 전환과 웹 거버넌스