- 프로토타입은 쓰고 싶어 하는 사람이 있다는 것을 증명했습니다. 하지만 많은 사용자, 잘못 입력된 데이터, 여러 차례 거듭되는 수정은 아직 겪어 보지 않았습니다.
- 프로토타입을 통째로 버릴 필요는 없습니다. 그대로 둘 부분, 보강할 부분, 새로 만들 부분의 세 묶음으로 나누면 됩니다.
- 프로토타입 다음 단계에서 시간이 드는 일은 검증과, 시스템이 낸 결과에 책임지는 일입니다. AI가 속도를 높여 줄 수는 있어도 여전히 사람이 해야 합니다.
프로토타입이 증명한 것과 아직 증명하지 못한 것
AI 도구로 일주일 만에 데모를 직접 만들었다고 해 봅시다. 고객 두세 곳이 써 보고 마음에 들어 했습니다. 그래서 실제 시스템 개발 견적을 요청했더니 몇 달 단위의 일정이 돌아왔습니다. 가장 먼저 드는 의문은 일주일과 몇 달의 차이가 대체 무엇에 대한 값인가 하는 점입니다.
프로토타입은 예전에 소프트웨어 개발에서 가장 비싸게 얻던 답을 이미 얻었습니다. 쓰려는 사람이 있는지, 사용자가 어떤 화면을 알아보는지, 어떤 단계를 빼도 되는지입니다. AI가 나오기 전에는 이 답을 얻는 데 몇 달의 시간과 큰돈이 들었습니다. 그러니 바이브 코딩(vibe coding)으로 만든 프로토타입은 실제로 가치가 있고, 실제 시스템의 출발점으로 삼아야 합니다.
프로토타입이 아직 증명하지 못한 것은 데모 때 한 번도 겪지 않은 상황에서 어떻게 움직이느냐입니다. 이 표에 실제 시스템이 첫해 안에 반드시 마주칠 여섯 가지 상황을 모았습니다.
| 데모가 겪어 보지 않은 상황 | 실제 시스템에서 처음 겪을 때 생기는 일 | 운영 시스템이 미리 갖춰 두는 것 |
|---|---|---|
| 두 사람이 같은 물건을 같은 초에 예약합니다. | 물건은 하나뿐인데 두 사람 모두 예약 확정 안내를 받습니다. | 데이터베이스에서 해당 항목을 잠그는 규칙, 요청이 충돌하는 경우를 다루는 테스트 |
| 사용자가 지난 날짜나 음수 수량을 입력합니다. | 합계가 틀리고 월말 보고서가 어긋납니다. | 입력 데이터 검사와, 무엇을 고쳐야 하는지 사용자에게 알려 주는 안내 문구 |
| 기능 하나를 고쳤더니 다른 기능이 망가집니다. | 고객이 전화로 알려 와야 팀이 알게 됩니다. | 배포 전에 매번 돌아가는 자동화 테스트 세트 |
| 사용자가 열 명에서 수천 명으로 늘어납니다. | 사람이 몰리는 시간에 페이지가 느려져 쓸 수 없게 됩니다. | 사전 부하 테스트와 확장할 수 있는 구조 |
| 만든 사람이 퇴사하거나, AI에게 어떻게 지시했는지 기억하지 못합니다. | 누구도 선뜻 코드를 고치지 못합니다. | 다른 사람도 읽을 수 있는 코드 구조, 문서, 수정 이력 |
| 새 기능을 배포했더니 문제가 생깁니다. | 팀이 고객이 보는 앞에서 실제 시스템을 바로 고칩니다. | 먼저 시험해 보는 스테이징 환경(Staging), 몇 분 안에 이전 버전으로 되돌리는 롤백(Rollback) |
코드는 훨씬 싸졌지만, 실제 시스템에는 여전히 시간이 듭니다
AI 덕분에 코드를 쓰는 속도는 몇 배나 빨라졌습니다. 남은 일은 검증입니다. AI가 쓴 코드를 읽고, 일어나면 안 되지만 일어날 수 있는 경우를 시험하고, 고객의 돈과 데이터에 영향을 주는 결정을 내리는 일입니다. 이런 일에는 여전히 결과에 책임질 수 있는 사람이 필요합니다.
바이브 코딩으로 만든 코드는 대개 가장 짧은 길로 결과에 도달합니다. 같은 로직이 여러 곳에 반복해서 쓰여 있고, 변수 이름만 봐서는 뜻을 알 수 없으며, 테스트도 붙어 있지 않습니다. 이런 코드는 고칠 일이 없는 동안에는 잘 돌아갑니다. 그러다 가격 구조를 바꾸거나, 지점을 늘리거나, 회계 시스템과 연동해야 할 때가 오면 한 곳을 고칠 때마다 다른 곳이 망가질 위험이 생깁니다. 엔지니어들은 이런 부담을 기술 부채(Technical Debt)라고 부릅니다. 시스템을 고칠 때마다 이자가 붙기 때문입니다.
올해 잘하는 개발팀도 AI로 코드를 씁니다. 차이는 코드를 둘러싼 절차에서 납니다. 다른 엔지니어가 코드를 읽은 뒤에야 시스템에 합치는데, 이를 코드 리뷰(Code Review)라고 합니다. 코드를 고칠 때마다 저절로 돌아가는 테스트 세트가 있고, 실제 배포 전에 시험해 볼 별도의 환경이 있으며, 새로 온 사람이 일을 이어받을 수 있게 해 주는 문서가 있습니다. 견적서에 적힌 몇 달은 이런 절차에 드는 시간입니다.
가상 사례
음향 장비가 이중으로 예약된 행사 장비 대여 회사
행사 장비 대여 회사의 대표가 AI로 엿새 만에 예약 시스템을 만들었습니다. 영업 담당자 네 명은 Excel 파일을 그만 쓰고 이 시스템으로 옮겨 왔습니다. 첫 달은 아무 문제 없이 지나갔습니다. 그런데 행사가 몰리는 연말이 되자 영업 담당자 두 명이 같은 음향 장비 세트를 같은 날 서로 다른 고객 두 곳에 예약해 주었고, 시스템은 두 건을 모두 확정했습니다. 회사는 행사 당일 아침 장비를 트럭에 싣다가 이 사실을 알았고, 다른 대여업체에서 음향 장비를 빌려야 했습니다. 빌리는 값은 고객에게 받은 대여료보다 비쌌습니다.
엔지니어가 코드를 들여다보니, 장비가 비어 있는지 확인하는 단계와 예약을 저장하는 단계가 서로 떨어져 있었습니다. 그래서 두 사람이 첫 단계를 동시에 통과할 수 있었습니다. 프로토타입을 시험할 때는 한 번에 한 사람씩 썼기 때문에 이 문제가 드러난 적이 없었습니다. 회사는 시스템을 버리지 않고, 아래의 세 묶음 분류로 어디에 공을 들일지 정했습니다.
세 묶음으로 나누기: 유지, 보강, 재구축
- 프로토타입의 화면과 기능을 빠짐없이 목록으로 적습니다.
- 항목마다 두 가지를 묻습니다. 이 부분이 잘못 동작하면 누가 무엇을 잃는지, 그리고 내년에 이 부분을 얼마나 자주 고쳐야 하는지입니다.
- 유지 묶음은 잘못되어도 누구도 돈을 잃지 않는 화면과 보고서입니다. 지금 그대로 계속 씁니다.
- 보강 묶음은 로직은 맞지만 테스트나 데이터 검사가 아직 없는 부분입니다. 테스트를 추가하고 엔지니어에게 리뷰를 맡깁니다.
- 재구축 묶음은 돈, 재고, 권한, 고객 데이터를 다루는데 기존 구조로는 계속 고쳐 나가기 어려운 부분입니다.
이 사례에서는 장비 검색 화면과 달력이 유지 묶음, 대여 매출 보고서가 보강 묶음, 예약과 요금 계산이 재구축 묶음에 들어갔습니다. 남겨 둘 근거는 전체 목록과, 각 항목을 그 묶음에 넣은 이유입니다. 프로토타입이 부분별로 전혀 나뉘어 있지 않아 한 곳을 고치면 시스템 전체가 영향을 받는다면 이 방법은 통하지 않습니다. 그럴 때는 프로토타입을 요구 사항 명세로 삼아 전부 새로 만드는 편이 더 빠릅니다.
바이브 코딩으로 만든 그대로 써도 되는 시스템
모든 시스템을 운영 시스템으로 만들어야 하는 것은 아닙니다. 팀 안에서 몇 사람만 쓰는 도구, 석 달 뒤에 접을 실험, 짧은 캠페인용 웹 페이지는 개발팀을 따로 고용하지 않고 바이브 코딩으로 만든 그대로 써도 됩니다. 운영 시스템으로 만드는 투자는 시스템의 실수에 대가가 따르기 시작할 때 제값을 합니다.
운영 시스템으로 만들 때가 되었다는 신호
- 외부 고객이 로그인해서 사용합니다.
- 돈이나 재고가 시스템을 거쳐 갑니다.
- 두 팀 이상이 동시에 사용합니다.
- 시스템이 멈추면 회사 업무도 멈춥니다.
- 회계 시스템이나 다른 시스템으로 데이터를 보내야 합니다.
위험이 적은 길은 단계를 나눠 가는 것입니다. 첫 단계에서는 세 묶음 분류로 프로토타입을 평가합니다. 두 번째 단계에서는 위험이 큰 부분부터 만들고, 소수의 사용자에게 기존 방식과 함께 써 보게 합니다. 세 번째 단계에서는 바쁜 시기를 큰 사고 없이 한 번 넘긴 뒤에 모든 사용자를 옮깁니다. 그동안 숫자 세 개를 지켜보십시오. 팀보다 고객이 먼저 발견한 문제의 수, 배포 후 이전 버전으로 되돌려야 했던 횟수, 새로 온 엔지니어가 혼자 코드를 고칠 수 있게 되기까지 걸린 시간입니다.
개발팀 참고 · 기술 지표
Change Failure Rate, 사용자가 신고한 버그와 팀이 직접 잡은 버그의 비율, 돈과 재고를 다루는 부분의 Test Coverage, Commit부터 Production까지의 Lead Time, 신규 엔지니어의 Onboarding 기간을 추적합니다. 예약과 결제에는 Concurrency Test를 두고, 확인과 저장을 하나로 묶는 Transaction을 적용해야 합니다.
멈춤 규칙: 고객이 겪는 문제가 배포 두 번 연속으로 늘어나면 기능 추가를 멈추고, 망가진 부분의 테스트부터 보강하십시오.
BUSINESS & PRODUCT READINESS
개발팀과 이야기하기 전에 준비할 네 가지
대표가 이 네 가지 질문의 답을 들고 오면 평가가 훨씬 빠르고 정확해집니다. 답이 완벽할 필요는 없고, 대략적인 숫자도 괜찮습니다. 개발팀은 이 답을 보고 부분마다 얼마나 튼튼하게 만들어야 할지 정합니다.
기능 목록, 그리고 기능마다 잘못 동작하면 누가 무엇을 잃는지
사용자 수와 사용이 가장 몰리는 시간대
데이터를 주고받아야 하는 다른 시스템
누가 코드를 소유하고 인계 후 관리를 맡을지
프로토타입을 이어받아 비즈니스가 믿고 쓸 수 있는 시스템으로 만듭니다
비즈니스 규칙은 대표와 팀이 가장 잘 압니다. 어떤 물건은 겹쳐 예약해도 되는지, 가격은 언제 바뀌는지, 할인은 누가 승인하는지 같은 것들입니다. DNA Maker는 프로토타입을 살펴보고 팀이 실제로 일하는 모습을 옆에서 지켜보며 이런 규칙을 끌어낸 다음, 워크플로, 항목별 상태, 비즈니스 규칙, 테스트 케이스로 정리합니다. 프로토타입에서는 어려운 경우를 아직 만나지 않아서 맞게 돌아가던 동작이, 이제는 테스트로 검증된 동작이 됩니다.
저희는 세 묶음 분류로 프로토타입을 평가해 쓸 만한 부분은 남기고, 돈과 데이터를 다루는 부분은 확장할 수 있는 아키텍처 위에 새로 만듭니다. 엔지니어의 리뷰를 거치는 조건으로 AI를 코드 작성에 활용하고, CI/CD와 세 단계로 분리된 환경을 거쳐 배포합니다. 그런 다음 소스 코드, 문서, 배포 가이드를 넘겨 드려 회사가 직접 소유하게 합니다. DNA Maker는 2012년부터 500개가 넘는 프로젝트를 납품했기 때문에, 오픈 후 문제가 주로 어느 부분에서 생기는지 압니다. 이미 프로토타입이 있다면 데모 링크와 앞으로 12개월 동안 비즈니스에 필요한 것의 목록을 가지고 이야기를 나눠 보십시오.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
개발팀의 견적서와 작업 계획에 자주 나오는 용어입니다. 뜻을 알아 두면 시간과 돈이 각각 어디에 쓰이는지 읽어 낼 수 있습니다.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| Technical Debt | 우선 빠르게 짜 둔 코드에서 쌓여, 다음 수정을 더 느리고 위험하게 만드는 부담 | 대여료 계산식이 다섯 곳에 반복해서 들어 있어, 가격을 한 번 올릴 때마다 다섯 곳을 모두 찾아 고쳐야 합니다. | 시스템에서 부채가 가장 많이 쌓인 부분은 어디이고, 그 때문에 수정 작업이 얼마나 느려집니까? |
| Code Review | 다른 엔지니어가 코드를 시스템에 합치기 전에 읽어 보며 실수를 잡고 같은 기준을 지키게 하는 일 | AI가 쓴 요금 계산 코드를 다른 엔지니어가 읽고, 배포 전에 할인이 중복으로 적용되는 경우를 짚어 묻습니다. | 돈과 고객 데이터를 다루는 코드는 누가 리뷰하고, 매번 리뷰합니까? |
| CI/CD | 코드를 테스트하고 시스템에 올리는 과정을 손으로 하지 않고 매번 같은 단계로 자동 처리하는 파이프라인 | 코드를 고칠 때마다 시스템이 테스트를 알아서 돌리고, 통과하면 테스트 서버로 올립니다. | 코드 수정을 마친 뒤 실제 시스템에 올라가기까지 얼마나 걸리고, 아직 손으로 하는 단계는 어디입니까? |
| Staging | 실제 시스템을 그대로 본떠, 새 기능을 고객에게 내놓기 전에 시험해 보는 시스템 | 영업팀이 사전 예약 기능을 정식 오픈 일주일 전부터 스테이징 환경에서 써 봅니다. | 스테이징 환경은 실제 시스템과 어디가 다르고, 실제 배포는 누가 승인합니까? |
| Automated Test | 코드를 고칠 때마다 자동으로 실행되어, 중요한 기능이 여전히 제대로 동작하는지 확인하는 명령 모음 | 테스트가 두 사람이 같은 물건을 동시에 예약하는 상황을 재현하고, 한 사람만 예약되는지 확인합니다. | 실제 시스템에서 망가졌던 경우를 테스트 세트에 추가했습니까? |
| Rollback | 새 버전에 문제가 생겼을 때 시스템을 이전 버전으로 되돌리는 일 | 새 버전 때문에 견적서를 발행할 수 없게 되자, 팀이 5분 안에 이전 버전으로 되돌립니다. | 마지막으로 롤백을 연습한 것은 언제이고, 그사이에 생긴 데이터는 어떻게 되었습니까? |
| Refactoring | 시스템 동작은 그대로 둔 채, 나중에 고치기 쉽도록 코드 구조를 다시 정리하는 일 | 다섯 곳에 흩어진 대여료 계산식을 한 곳으로 모읍니다. 사용자 눈에는 아무 변화가 없습니다. | 이번 구조 정리로 다음 기능 개발이 어떻게 더 빨라지거나 저렴해집니까? |