AI-native 회사가 일하는 방법

추진 배경

동종 업계에서 비슷한 서비스를 만드는 기업들은 보통 수십 명 규모의 팀이 여러 해에 걸쳐 구축합니다. AI 에이전트와 함께 일하면 그 규모의 서비스를 한 사람이 몇 주 만에 만들 수 있게 됐습니다. 새 아이디어는 하루 이틀이면 동작하는 프로토타입이 됩니다.

그런데 제품이 열 개를 넘어가자 다른 문제가 드러났습니다.

• 제품마다 브랜치 방식, 배포 방식, 폴더 구조, 이름 짓는 법이 달라졌습니다. AI 세션마다 그럴듯한 방식을 새로 정했기 때문입니다.
• AI가 시키지 않은 일을 했습니다. 막히면 멈추는 대신 그럴듯한 값으로 빈자리를 채웠습니다.
• 만드는 속도가 사람이 검토하는 속도를 앞질렀습니다.

속도는 이미 충분했습니다. 필요한 것은 빠르면서도 바르게 가는 방법이었습니다.

구축 조건

• 사람이 방향을 정하고 승인(Human in the loop) — 운영에 영향을 주는 변경, 되돌릴 수 없는 삭제, 비용이 드는 일은 사람이 결정
• 규칙은 말이 아니라 문서로 — 모든 AI 세션이 같은 문서를 읽고 시작
• 문서로 지켜지지 않는 것은 기계가 차단 — 자동 검사와 시험으로 고정
• 실수는 기록 — 같은 실수가 반복되는 구조를 찾기 위해

구축 방법

같은 방식으로 만든 제품 10종

이 방식은 한 제품에만 쓴 것이 아닙니다. 아래는 같은 방식으로 반년 동안 만든 제품입니다. 전부 지금 운영 중이고, 모두 같은 규약·같은 파이프라인·같은 검사를 탑니다.

2026년 10월 1일 기준입니다. 9월 중순에 시작한 세 제품(GenAI AEO, GuardTrail, Deploy)은 3주 만에 운영에 올라왔습니다.

분야도 서로 다릅니다. 보안 게이트웨이, 영상 생성, 회의 요약, 지식그래프, 지도 기반 분석, 배포 인프라입니다. 한 사람이 이 폭을 다룰 수 있었던 것은 AI가 각 분야의 구현을 맡고, 사람은 무엇을 만들지와 어디가 틀렸는지에 집중했기 때문입니다.

사례 하나: BizGraph

BizGraph는 서울의 상권·부동산 데이터를 지도와 AI 비서로 분석하는 서비스입니다. 공공·민간 데이터 연동, 대용량 처리, 지도 화면, AI 에이전트가 모두 들어갑니다. 동종 업계에서 유사한 서비스를 만드는 기업들이 수십 명 규모의 팀으로 여러 해에 걸쳐 쌓아 온 분량입니다. 빠르게 만든 뒤, 사람이 방향을 잡아 다시 세운 과정을 적습니다.

5주 동안 쌓인 것

• 시작 첫날 뼈대에서 AI 에이전트까지, 사흘째에 지식그래프(온톨로지)까지 동작
• 외부 API 서비스 96종(인증 키 24개) 연동 — 공공데이터, 지도, 부동산 거래, 상권 매출, 유동인구 등
• 사업장 71만 곳, 거래·사건 기록 수백만 건을 적재해 질의
• 상권 분석과 주택 시세를 같은 지도에서 제공 — 평면, 3D 기둥, 확대하면 건물 단위까지
• 5주 동안 커밋 980개, 자동 시험 파일 350여 개, 설계 문서 42개

속도가 남긴 것

AI 에이전트는 시킨 기능을 빠르게 더했지만, 전체를 정리하지는 않았습니다. 기능이 늘수록 군더더기가 쌓였습니다.

• 지도 화면 하나가 3,161줄짜리 파일이 됨. 상태·그리기·검색·대화 연결이 한 덩어리
• 같은 일을 하는 지도 화면이 두 벌(옛 화면 1,964줄이 그대로 남음)
• 질문 처리와 보고서 처리가 거의 같은 흐름을 따로 구현
• 조건 해석 함수 하나의 복잡도가 40, 도구 모음 파일 하나가 1,581줄
• 화면에는 쓰이지 않는 요소와 산만한 배치가 늘어남

사람이 한 일: 방향과 순서

사람은 코드를 직접 고치지 않았습니다. 무엇이 문제인지 짚고, 어떤 순서로 고칠지 정했습니다.

• 동작은 그대로 두고 구조만 변경 — 리팩터링 중에는 기능·화면·주소·문구를 건드리지 않음
• 안전망을 먼저 구축 — 고치기 전에 화면 자동 시험부터
• 한 조각씩 분리 — 뗄 때마다 전체 검사를 실행
• 옮기는 김에 고치지 않음 — 발견한 문제는 적어 두고, 시험을 먼저 쓴 뒤 따로 고침

AI가 한 일: 받아들이고 실행

틀린 가설 기록

BizGraph에는 "틀린 가설 기록"이라는 문서가 있습니다. 버그 기록은 "코드가 이렇게 잘못돼 있었다"로 끝나지만, 그 코드를 쓸 때는 그것이 맞다고 믿고 있었습니다. 믿음을 적어 두지 않으면 다음에도 같은 믿음에서 출발합니다.

항목마다 가설 · 근거 · 반증 · 수정 · 교훈을 적습니다. 핵심은 반증입니다. "틀렸다"는 사실보다 "무엇이 틀렸다고 알려 줬는가"가 다음에 다시 쓰입니다. 5주 동안 300여 항목이 쌓였습니다. 리팩터링 중에도 "나눠도 결과는 같다"고 믿었던 것 가운데 여럿이 틀린 것으로 드러나 여기에 기록됐습니다.

사례 둘: GensOps

만든 것을 운영하는 화면도 같은 방식으로 만들었습니다. 제품이 열 개를 넘자 운영이 문제가 됐습니다. 서버 상태는 모니터링 도구에서, 배포는 CI 화면에서, 비용은 클라우드 콘솔과 AI 벤더 화면에서 따로 봐야 했습니다. 그래서 이 전부를 한곳에서 보는 운영 관제 플랫폼 GensOps를 직접 만들었습니다. 설계에서 운영 배포까지 8일이 걸렸습니다.

• 전사 프로젝트 관리 — 모든 저장소의 활동, 진행 중인 마일스톤과 마감, 열린 이슈·PR, CI 성공률을 카드 한 장씩으로 표시. 활발한 곳과 멈춘 곳이 한눈에 구분됨
• 한눈에 보기 — 서비스 가동률, 서버, 컨테이너, CI, 배포 횟수, AI 세션, 비용을 한 화면에 표시. 확인이 필요한 것은 맨 위에 모음
• 확대하면 늘어나는 정보 — 서버 하나를 열면 지표 여덟 개, 한 시간부터 30일까지의 그래프, 컨테이너별 사용량까지 표시
• 2D 관제실과 3D 관제실 — 같은 데이터를 평면과 입체로 제공. 대형 화면에 띄워 두고 봄
• 조치는 승인 뒤에 — 재시작 같은 명령은 사람이 승인해야 실행되고 전부 기록에 남음

GensOps는 ops.gensapps.com에서 소개와 라이브 데모(가상 데이터)를 볼 수 있습니다.

자동화 시험

AI가 하루에 수백 번 코드를 바꾸는데 사람이 그것을 다 읽을 수는 없습니다. 그래서 바뀐 것이 맞는지를 기계가 먼저 확인하게 했습니다. 시험도 AI가 씁니다. 사람은 "무엇이 깨지면 안 되는지"를 정합니다.

제품별 자동 시험은 GenAI AEO 3,600여 개, BizGraph 2,900여 개, GenAI Shield 2,400여 개, MovieAgentStudio 1,900여 개입니다. 검사가 막은 310회는 사람이 보기 전에 걸러진 변경입니다. 숫자는 2026년 10월 1일에 저장소와 CI 기록에서 센 값입니다.

시험의 종류

한 가지 시험으로는 한 가지 문제만 잡힙니다. 그래서 층을 나눠 여러 종류를 둡니다.

• 단위·통합 시험 — 함수와 모듈, 그리고 DB·외부 연동을 붙인 흐름
• 화면 자동 시험 — 실제 브라우저로 메뉴와 핵심 흐름을 눌러 봄
• 보안 시험 — 권한 없는 접근, 다른 조직의 데이터 접근, 공격 시나리오
• 특성 시험·스냅숏 — 리팩터링 전에 지금 동작을 글자까지 고정(조건 해석 720문장, AI에게 넘기는 도구 목록 전체)
• AI 답변 평가 — 질문 묶음에 대한 답의 품질을 점수로
• DB 변경 시험 — 스키마를 바꾸는 스크립트가 실제로 도는지
• 규칙 검사 — 컨테이너 설정, 비밀값, 의존성 취약점. 건너뛴 검사는 통과가 아니라 실패로 처리

시험이 먼저 잡은 것

• 리팩터링 안전망을 만들다가 숨은 버그 3개 발견 — 화면 자동 시험을 쓰는 과정에서 아무도 몰랐던 오동작이 드러남
• AI에게 가는 글이 바뀐 것을 스냅숏이 잡음 — 파일을 나누자 정렬 도구가 순서를 가나다순으로 바꿨고, AI 모델이 받는 도구 목록이 달라짐. 이름만 보던 기존 시험은 통과했음
• 머지 전에 새 보안 취약점 차단 — 그날 공개된 의존성 취약점을 보안 검사가 잡아 수정 뒤에 머지
• "배포 성공"인데 옛 판이 떠 있는 것 — 헬스 응답이 방금 올린 커밋이 아니면 배포를 실패로 처리
• 떠 있지만 백업이 안 되는 상태 — 배포 뒤 검사가 잡아 몇 분 만에 수정해 재배포

시험도 의심한다

초록색 체크가 항상 "맞다"는 뜻은 아니었습니다. 파일 구조를 바꾼 뒤 어떤 규칙 시험은 검사 대상 0개를 보고 통과했습니다. 그래서 시험 결과를 볼 때 "통과했나"보다 "무엇을 몇 개 봤나"를 먼저 확인합니다. 새 검사를 만들면 일부러 틀린 입력을 넣어 정말 실패하는지도 봅니다.

시행착오

2026년 9월, AI와 나눈 작업 기록 전체를 뒤져 AI가 스스로 잘못을 인정한 600여 건과 사람이 지적한 사례를 모두 조사했습니다. 원인별로 묶으니 "바빠서"나 "실수로"가 아니었습니다. 판단의 모양이 반복되고 있었습니다. AI 에이전트와 일하면 어느 조직에서나 만나게 되는 종류입니다. 아래는 모두 개발 과정에서 사람의 검토나 자동 검사로 드러나 고친 것입니다.

가장 중요한 발견은 문서에 규칙을 더 적는 것으로는 해결되지 않는다는 점입니다. 이미 규칙이 있는데도 반복된 사례가 있었습니다. 규칙을 몰라서가 아니라, 막힌 순간에 규칙보다 "완성"이 먼저 떠오르기 때문입니다. 그래서 대책을 막힌 순간에 작동하는 것으로 바꿨습니다.

• 긴 규칙 대신 "막힌 순간에 할 일" 11줄
• 조용히 넘어가던 것을 실패로 처리. 건너뛴 검사는 통과가 아니라 실패
• 지켜야 할 것은 시험으로 고정. 값이 없을 때 정말 멈추는지 시험이 확인

사람의 개입이 막아 낸 일도 있습니다. AI가 공개 문서의 빈 조항을 받은 적 없는 숫자로 채웠고, 사람이 근거를 물어 배포 전에 걸러냈습니다. 이것을 막은 것은 규칙이 아니라 사람의 의심이었습니다.

결과

• 빠르게 — 최근 30일 동안 저장소 40여 개에 커밋 5,500여 개, 머지 1,400여 건. BizGraph는 5주 만에 외부 API 96종을 연동했고, 전사 운영 관제 화면은 8일 만에 운영에 올라감
• 바르게 — 자동 시험 약 19,800개가 변경마다 돌고, 9월 한 달 310건의 변경이 사람이 보기 전에 걸러짐. 비밀값 검사는 PR마다, 그리고 매주 전체 이력에 대해 실행
• 일관되게 — 어느 제품이든 구조·이름·배포 방식이 같아, 사람도 AI 세션도 바로 이어받음
• 다시 세울 수 있게 — 빠르게 쌓은 코드를 사람이 방향을 잡고 AI가 재구조화. 3,000줄짜리 화면이 절반 이하로 줄고 동작은 그대로

기존 방식과 비교하면 체감 생산성은 100배 수준입니다. 이 속도는 위의 장치들이 있어서 유지됩니다.

한계를 시험하려고 시작한 일이었지만, 먼저 바닥난 것은 AI의 실력이 아니라 만들고 싶은 것의 목록이었습니다.

남은 과제

• 마지막 방어선은 여전히 사람 — "하지 않은 확인을 했다고 말하는" 종류는 규칙이나 검사로 줄지 않음
• 검토 부담 — 만드는 속도가 검토하는 속도를 앞섬. 자동 검사로 줄이고 있으나 대신하지는 못함
• 수치는 자체 기록 — 작업 기록에서 확인할 수 있으나 외부 검증을 거치지 않음

향후 계획

• 사례집을 계속 쌓아 "AI 에이전트가 시키지 않은 일을 하는 방식"으로 정리해 공개
• 같은 방식을 고객사 개발·운영 조직에 적용한 사례를 쌓아 공개

도입 지원

이 글에 적은 것은 젠아이랩스가 직접 겪으며 다듬은 방식입니다. 공용 규약과 시작 템플릿, 표준 파이프라인, 자동 시험, 사람이 개입하는 지점, 실수를 기록해 장치로 바꾸는 습관은 도구를 들여오는 것만으로는 생기지 않습니다. 교육·컨설팅·MCP Agent 구축 서비스로 같은 방식을 고객사의 개발·운영 조직에 맞게 적용합니다.