개발 자동화에서 조직 AX까지

3줄 요약

1. 퍼플아이오의 subicura(조성일)가 2025년 하반기부터 1년간 진행한 전사 AX(AI Transformation) 여정을 회고한 글이다. “배포해줘~” 한마디로 보안 점검을 거쳐 사내망에 자동 배포되는 시스템을 완성한 것을 계기로 삼았다.
2. 개발 자동화 벤치마크, 레거시 마이그레이션, 신규 서비스 개발이라는 세 실험이 공통으로 증명한 것은 AI의 성능이 아니라 요구사항(Spec) 정의의 질이 결과를 좌우한다는 사실이었다.
3. 그래서 회사 방향을 AX로 정하고 사내 AI 플랫폼 코코(KOCO)와 배포 시스템까지 만들었지만, 1년간 진짜로 바뀐 것은 개발 속도가 아니라 문제 정의·지식 축적·협업 방식이었다. AI 활용의 승부처는 조직이 자신의 맥락(Context)을 얼마나 축적하고 연결하느냐에 달려 있다는 것이 결론이다.

AI의 등장 — 보조에서 메인으로

2025년 초까지 저자는 GitHub Copilot, ChatGPT, Claude의 도움을 조금씩 받는 정도였다. 개발은 어디까지나 개발자가 하고 AI는 옆에서 보조하는 역할이었다.

전환점은 2025년 하반기 Claude Opus 4.1이었다. 저자는 AI가 보조에서 완전히 ‘메인’이 되는 순간이었다고 적었다. Sonnet과 Opus의 체급 차이가 컸고, 난생처음으로 월 $200짜리 플랜을 2개씩 구독했다. 저자는 이 비용을 이렇게 정리한다.

구독에 $400이라니 말도 안 되게 비싸 보였지만, 개발자 인건비를 생각하면 한없이 혜자스러운 가격입니다.

이때부터 Nano Banana Pro의 한글 품질, Typeless 음성인식, 끝까지 일을 해내는 OpenClaw 같은 툴이 쏟아졌다. 저자가 짚은 변화의 핵심은 도구의 다양성이 아니라 접근 범위였다. 이전까지 AI는 메일 초안이나 이미지 생성 수준에 머물렀지만, 이제는 내가 가진 데이터와 맥락(Context)에 접근하고 실제 액션까지 수행하게 되었다는 것이다.

세 가지 시도

2026년 초, 저자는 AI를 어디까지 적용할 수 있을지 궁금해 세 가지 질문으로 테스트를 설계했다.

1. 개발 업무 중 몇 %를 자동화할 수 있는가?
2. 기존 시스템을 차세대 버전으로 마이그레이션할 때 얼마나 효율적인가?
3. 신규 서비스 개발을 얼마나 안정적으로 빠르게 할 수 있는가?

첫 번째 — 개발 자동화 벤치마크

퍼플아이오는 Asana로 태스크를 관리하고 GitLab을 소스 저장소로 쓰며, 태스크 번호로 브랜치를 따는 GitHub Flow 방식으로 개발한다. 즉 PR 하나가 곧 하나의 작업 단위다.

저자는 최근 완료된 PR 180건을 샘플링해 각 PR의 Diff를 저장했다. 그리고 각 PR 시작 시점의 Git 코드를 되돌린 뒤, 오직 Asana 태스크 설명만 보고 사람의 개입 없이 AI에게 PR을 작성하게 했다. 그 결과 Diff를 사람이 짠 원본과 비교했다.

태스크 설명이 제대로 작성된 ‘구현 가능 PR’ 110건을 기준으로 한 결과는 다음과 같다.

실패의 원인은 대부분 ‘AI’가 아니라 ‘태스크 설명이 부실해서’였다. 문제는 모델이 아니라 요구사항 정의였다.

두 번째 — 레거시 시스템 마이그레이션

오래된 이슈가 있던 사내 CMS(Next.js/React)를 개선하는 작업이었다. 보통 우선순위가 낮아 방치되는 일인데, AI에 맡겨봤다.

AI에게 전체 소스코드 접근 권한을 주고 브라우저로 페이지를 분석하게 했다. AI는 브라우저를 띄워 CMS에 접근한 뒤 사용자가 로그인할 때까지 기다렸다가, 마이그레이션 대상 페이지에 접속해 각 화면과 네트워크 요청을 분석했다. 스크린샷을 찍고 UI 구조, 컴포넌트, 데이터 모델링, API 호출, 상태 관리를 정리했다. 저자가 이 실험에서 끌어낸 원리는 이렇다.

보통 AI가 만든 결과가 이상한 건 “내 맘에 안 들어서"입니다. 내 맘에 안 드는 이유는 요청을 모호하게 했기 때문이고(예: “기획전 관리 기능 만들어줘”), 반대로 ‘기존 페이지 소스코드와 화면’ 자체가 완벽한 기획서가 될 수 있다면 결과는 거의 의도한 대로 나옵니다.

기본 기능은 완벽하게 동작했다. 저자는 여기서 “이제 코드를 잘 타이핑하는 것보다 기능을 어떻게 명확히 정의하느냐가 더 중요해졌다"며 “Spec이 짱이다!“라고 정리한다. 이후 큰 규모의 차세대 마이그레이션 프로젝트를 기존 계획 대비 절반도 안 되는 리소스로 완료했다. 가장 오래 걸린 작업은 코딩이 아니라 기존 로직을 .md 파일로 정리하고 테스트 케이스를 빠짐없이 짜는 일이었다.

세 번째 — 신규 서비스 개발

요구사항만 잘 정의하면 구현은 원하는 대로 나왔으므로, 신규 시스템 구축도 효율적이었다. 기존의 긴 과정(요구사항 분석 → 기획 → 설계 → 구현 → 데모)이 압축됐다. 이제는 요구사항을 받자마자 AI가 기획하고 개발까지 마쳐, 첫 미팅부터 동작하는 데모를 보여주고 피드백을 받는다.

흐름은 이렇다. 3~4줄짜리 요구사항을 받으면 그걸로 PRD(제품 요구사항 정의서)를 만들고, 그 파일로 기능 명세를 정의한 뒤, 기능별 페이지·UI/컴포넌트·API/모델 설계·사용자 Flow를 한 번에 생성한다. 사용자가 검토·승인하면 그대로 Ralph Loop으로 밤새 코드를 짠다. 명세를 보고 구현하고, 제대로 짰는지 체크하고, 다시 검증하는 루프까지 돌리면 구현에만 6시간 정도 걸렸다.

이렇게 잡은 매장관리 시스템 초안은 첫 미팅 때 이미 동작하는 화면으로 논의를 시작할 수 있어 방향 잡기가 훨씬 쉬웠다. 최종 버전은 초안과 달라졌지만, 이 역시 기존 계획 대비 절반의 리소스로 구현했다.

전사적 선언

세 실험에서 확신을 얻은 저자는 2026년 초 회사의 방향을 AX로 정했다. 모든 업무를 자동화하고 연말까지 인당 생산성을 200% 올리는 것을 목표로, 개인과 조직이 일하는 방식을 바꾸기로 했다. 두 개의 대전제를 세웠다.

AI가 못하는 일은 거의 없어질 것이다. 코딩을 몰라도 많은 업무를 일정 수준 이상 자동화할 수 있다. 개발뿐 아니라 문서 작성, 분석, 운영, 배포, 데이터 처리까지 자동화의 대상이 된다.

앞으로는 맥락(Context)이 핵심 자산이 될 것이다. 나의 생각과 암묵지를 끊임없이 글로 남기고, 본 자료를 markdown으로 저장하며, 팀과 맥락을 공유하고 그 위에서 AI와 함께 일해야 한다.

단기적으로 한 달 내에 할 수 있는 것부터 하자며 사내 AI 챌린지 ‘Quick Win’을 열었다. 총 28개 프로젝트가 등록됐고, 참가자들은 평균 83%의 업무 시간 절감을 확인했다.

구체적 사례는 이렇다.

• 비개발자는 평소 쓰던 CRM에 없던 기능을 직접 만들었다. 사이트 주소를 넣으면 스크립트를 분석해 어떤 솔루션을 쓰는지 파악하고, 영업 리드 점수를 계산해 제안 메일 초안까지 써주는 기능이다.
• 개발자는 에러 알람이 오면 로그를 뒤지고 코드를 찾던 삽질을, AI가 1차 원인 분석을 끝낸 결과를 확인·승인하는 것으로 바꿨다.

사내 정보는 옵시디언(Obsidian)에 모으기로 했다. AI가 로컬 .md 파일을 읽고 해석하는 능력이 컨플루언스보다 낫다고 판단했기 때문이다. 가장 어려운 점은 비개발자에게 Git을 가르치는 일이어서, 5분에 한 번씩 알아서 pull/push하고 충돌이 나면 파일을 쪼개 머지 컨플릭트를 방지하는 옵시디언 플러그인(second-brain-plugin)을 몇 시간 만에 만들었다. 모바일에서도 Claude Code 작업을 이어가려고 터미널·AI 코딩 기능이 포함된 Mac 앱(PurpleMux)도 만들었다. 11개 언어를 지원하고, 어느새 중국인 사용자도 생겼다.

이 시기 사내에서 진행 중인 자동화 프로젝트는 다음과 같다.

확산과 허들

개발팀이 AI를 먼저 접했으니, 자연스럽게 함께 일하는 현업 부서로 확산했다. 그런데 문제는 시작부터 터졌다.

Windows 환경에서 cmd를 난생처음 보는 분에게 Claude Code를 가르치는 건 생각보다 훨씬 어려웠습니다. 설치하고, cmd가 뭔지 설명하고, cd로 디렉토리를 이동하는 법을 알려주는 데 교육 시간의 대부분이 날아갔습니다.

그래서 툴을 바꿨다. 구글이 만든 IDE인 Antigravity였다. GUI 기반에 AI Assistant를 지원해 초보자도 바로 쓸 수 있었다.

이 전략은 성공했다. 초기 허들이 크게 낮아졌고, 여기서 자연스럽게 Claude Code와 cmd 환경으로 넘어왔다. 내부 데이터에 접근하는 커스텀 스킬을 배포하자 사내 자동화 앱과 대시보드가 폭발적으로 늘었다. 현업이 직접 만들기 때문에 뭐가 필요한지 더 잘 알았다. 저자가 가장 기분 좋았다고 꼽은 피드백은 이것이다.

“4~5시간 걸리던 수작업인데, 아침에 출근하면 이미 완료되어 있어요.”

개발자 수준의 ‘AI 챔피언’들이 현업에서 탄생하기 시작했다.

진짜 문제는 따로 있었다

판이 커지자 공통적인 병목이 드러났다. AI 성능이 아니라 환경과 인프라였다.

• Windows 중심의 업무 환경
• M365 / OneDrive 기반의 분산된 업무 방식
• 내부 시스템 연동을 위한 까다로운 인증/기본 설정
• 그리고 배포의 어려움

개발자가 한 땀 한 땀 도와주는 데는 한계가 있고, 결국 스스로 자생할 수 있어야 했다. 그래서 Quick Win 때 만든 DocSync를 전면 개조해 사내 AI 플랫폼 코코(KOCO)를 만들었다. Claude/Claude Cowork와 유사하되, 사용자가 최대한 쉽게 쓰도록 설계했다.

주요 특징은 다음과 같다.

• 개발 도구(Node.js) 내장, 별도 설치 필요 없음
• OneDrive / 메일 / 캘린더 연동 (묻고 답하고 생성까지)
• SAP 등 내부 데이터베이스, 그룹웨어(전자결재·지원관리) 연계
• 스킬 및 워크플로우 공유
• 바이브 코딩부터 사내망 배포까지 한 번에

메일과 공유 드라이브의 파일을 싱크해 SQLite에 색인하고 암호화해서 보관한다. 일반 사용자가 보안 걱정 없이, 복잡한 설정 없이 업무를 자동화하고 바이브 코딩까지 할 수 있게 됐다. 약 80명을 대상으로 3개월간 테스트하며 피드백을 받고 있다.

저자가 꼽은 좋은 사례는 ‘경영 정보 Agent’다. 재무 데이터를 xlsx로 받아 월간 보고서를 한 디렉토리에 모으면, 커스텀 llm-wiki가 대용량 xlsx를 DuckDB에 밀어 넣고 컬럼 메타데이터를 설정한 뒤 월간 보고서는 .md로 변환해 인덱싱한다. 이 디렉토리를 OneDrive 공유 폴더로 만들어 담당자에게 공유하고, KOCO에서 “이 디렉토리를 보고 경영 정보를 알려줘"라고 지침을 넣으면 끝이다. 내가 가진 파일을 기반으로 조회하니 권한 이슈도 없다.

배포 — 글의 메인 주제

바이브 코딩이 늘수록 “이거 팀에 공유하고 싶은데요"라는 요청이 커졌다. 배포의 요구사항은 간단했지만 설정은 까다로웠다.

• 내부망에 배포할 것
• 배포 전에 보안 검토(Security Review)를 받을 것
• 사용자별로 인증하고, 공유 범위(전체 / 일부 사용자 / 비공개)를 설정할 수 있을 것

배포 대상은 사내 EKS(Kubernetes) 환경으로 구축했고, 배포 파이프라인은 별도 솔루션 없이 GitLab CI/CD를 그대로 썼다. 사용자가 “배포해줘~“라고 하면, 현재 로그인한 사용자 아이디로 GitLab에 연동 로그인하고 랜덤한 이름의 프로젝트를 생성한 뒤 파일을 전부 올린다. 그러면 자동으로 빌드·배포까지 이어진다. 데이터베이스는 기본 SQLite이고 /data 폴더를 persistence volume으로 설정했다.

보안 검토도 파이프라인에 얹었다. CI/CD 중간에 보안 스캔 단계를 넣었고, 검토가 끝나면 Slack으로 알람이 온다. 실제 배포는 담당자가 한 번 더 확인하고 승인한다. 저자는 “완전 자동은 아직 좀 불안하다"고 덧붙였다.

마지막 퍼즐은 인증이었다. 전체 공개가 아니라 비공개로, 혹은 특정 사람에게만 공유하는 권한 제어가 필요했다. 앱마다 일일이 인증 코드를 넣는 가이드를 만들까 하다가 Cloudflare Access를 소개받고, 프록시처럼 모든 트래픽이 한곳을 거치게 하면 된다는 아이디어를 얻었다.

그래서 ‘Purple Access’라는 자체 프록시 레이어를 만들었다. EKS의 Ingress ALB는 이제 Pod을 직접 바라보지 않고 Purple Access를 바라본다. 인증이 안 됐으면 로그인 창을 띄우고, 로그인하면 접근하려는 앱에 대한 권한이 있는지 체크한다. 있으면 통과, 없으면 차단, 모든 접근은 감사 로그로 남는다. 예전 같으면 이런 리버스 프록시 엔진을 직접 만드는 건 골치 아픈 일이었겠지만, 이 또한 AI의 도움으로 며칠 만에 해결했다.

이렇게 배포 기능이 완성됐다. 바이브 코딩을 하고, 공개 범위를 정하고, “배포해줘~“라고 하면 보안 점검 후 내부망에 배포되고 사내에 공유된다.

가장 눈여겨본 대목

내가 곱씹은 것은 글 전체를 관통하는 방향의 전환이다. 저자는 처음에 AI를 ‘개발을 더 빠르게 해주는 도구’로 여겼지만, 1년 뒤 가장 크게 바뀐 것은 개발 속도가 아니었다고 말한다.

문제를 정의하는 방식이 바뀌었고, 지식을 남기는 방식이 바뀌었으며, 함께 일하는 방식이 바뀌었습니다.

이 글의 서사는 “AI가 얼마나 잘하는가"를 증명하려다 시작해서, “조직이 얼마나 잘 정의하고 잘 기록하는가"로 답이 옮겨가는 구조다. 첫 실험의 70% 일치도조차 성능이 아니라 태스크 설명의 부실이 결정했고(“Spec이 짱이다”), 레거시 마이그레이션에서는 기존 소스와 화면 자체가 완벽한 기획서 역할을 했다. 확산의 병목도 모델이 아니라 Windows·인증·배포 같은 환경이었다. 결국 저자가 최종 자산으로 지목한 것은 코드나 도구가 아니라 조직이 남긴 맥락(Context)이다. AI는 코드를 잘 짜고 문서를 잘 정리하지만, 왜 이 기능이 만들어졌는지, 어떤 배경에서 의사결정을 했는지, 앞으로 어디로 가야 하는지는 조직이 남긴 맥락에서만 나온다는 것이다.

그래서 다음 단계도 데이터와 맥락을 향한다. 데이터 맵으로 가시성을 높이고, 업무의 input/output이 자연스럽게 마크다운으로 쌓이도록 프로세스를 리팩토링하며, 부족한 맥락은 업무 흐름 개선이나 신규 시스템으로 채운다. 전자결재에 AI 스크리닝·검수 단계만 보완해도 의미 있는 맥락이 데이터로 모인다는 것이 저자의 생각이다.

지난 1년 동안 우리가 만든 것은 여러 개의 AI 도구와 하나의 배포 시스템이었습니다. 하지만 그 과정에서 정말 바뀐 것은 도구가 아니라 일하는 방식이었습니다. 이제 우리는 사람이 모든 일을 직접 처리하는 조직이 아니라, 사람이 남긴 맥락 위에서 AI가 함께 일하는 조직을 만들고 있습니다.

출처

subicura(조성일), 퍼플아이오 — “개발 자동화에서 조직 AX까지” (2026-07-14) 원문: https://subicura.com/2026/07/14/ax-journey.html

본문 이미지는 원문에서 인용했다.