요즘 개발사 상담을 받으면 "AI로 하면 훨씬 빨리 만들 수 있습니다"라는 말을 자주 듣습니다. 빨라진다는 말은 반갑지만 운영을 책임지는 입장에서는 다른 질문이 먼저 떠오릅니다. 빨리 만든 뒤에 요구가 바뀌면 어떻게 되는지, 지금 쓰는 업무 흐름과 어긋나지는 않는지, 그걸 누가 어떻게 확인하는지입니다.
저희도 2026년 3월부터 AI를 업무 시스템 개발에 쓰고 있습니다. 다만 처음 AI에게 시킨 일은 코드가 아니었습니다. 이 글은 그 선택을 하게 된 배경과 그래서 세우게 된 절차의 큰 줄기를 적은 연재의 첫 편입니다. 절차 안의 문서 하나하나는 다음 글에서 다룹니다.
20년 동안 손으로 쓰던 문서를 AI에게 먼저 맡겼습니다
이노자일 대표는 약 20년 동안 요구분석과 분석설계 문서를 직접 쓰면서 프로젝트를 진행해 왔습니다. 고객이 무엇을 원하는지 듣고 그것을 사용 장면 명세로 적고, 화면과 업무 규칙으로 풀어 내는 일입니다. 개발은 그 뒤에 옵니다.
요즘 "바이브코딩"이라고 부르는 방식이 있습니다. 말로 시키면 AI가 바로 코드를 짜 주는 방식입니다. 화면 하나를 금방 볼 수 있어서 처음에는 매력적입니다. 저희가 그 방식으로 바로 가지 않은 이유는 단순합니다. 20년 동안 겪은 프로젝트의 문제는 대부분 코드가 아니라 "무엇을 만들어야 하는지"를 서로 다르게 이해한 데서 생겼기 때문입니다. 코드를 빨리 짜는 도구가 생겼다고 해서 그 문제가 사라지지는 않습니다.
그래서 AI에게 처음 시킨 일은 사용 장면 명세를 쓰는 것이었습니다. 어떤 사람이 어떤 상황에서 시스템을 열고 무엇을 입력하고 어떤 결과를 받는지를 글로 적는 문서입니다. 사람이 쓰던 것과 같은 종류의 문서를 AI가 쓰게 한 것입니다.
800장이 넘는 문서를 받고 나서 절차를 다시 세웠습니다
처음 나온 결과는 14개 업무 영역, 800장이 넘는 문서였습니다. 한 장 한 장은 그럴듯했습니다. 문제는 그 분량을 사람이 읽고 확인할 수 없다는 것이었습니다. 확인하지 못한 문서는 아무리 많아도 합의된 요구가 아닙니다.
그 분량을 보면서 생각이 바뀌었습니다. 문서 하나를 잘 만드는 것보다 새로운 분석설계 절차를 세우는 일이 중요했습니다. 사람이 손으로 쓸 때는 쓰는 속도가 느려서 자연스럽게 한 번에 한 가지씩 확인했습니다. AI는 그 속도 제한이 없으니 확인하는 지점을 절차로 따로 만들어 두지 않으면 확인 없이 문서만 쌓입니다.
이노자일 홈페이지에 적어 둔 일하는 순서는 요구사항 분석, 설계, 개발, 운영·확장입니다. 그 앞 두 칸을 AI와 함께 하기 위해 잘게 나눈 것이 지금의 7단계입니다.
7단계, 단계마다 사람이 "예 / 수정 / 아니오"를 말합니다
7단계의 이름과 목적만 추리면 이렇습니다.
- 요구 식별 — 이번에 들어온 요구가 무엇인지 한 건씩 적습니다.
- 기존 기능과의 통합·영향 점검 — 이미 있는 기능과 겹치는지, 어디에 영향이 가는지 봅니다.
- 사용 장면 명세 — 누가 어떤 상황에서 무엇을 하는지 글로 씁니다.
- 업무 흐름 연결 — 장면들이 앞뒤로 이어지는지 확인합니다.
- 빠진 것 찾기와 화면 목록 — 흐름을 따라가며 없는 화면·기능을 찾고 화면 목록을 만듭니다.
- 화면정의서 — 화면마다 무엇이 보이고 무엇을 할 수 있는지 정합니다.
- 업무 규칙과 요구사항 추적표 — 지켜야 할 규칙을 적고, 처음 요구가 어느 화면·규칙으로 갔는지 표로 잇습니다.
단계마다 AI가 결과를 내면 사람이 "예 / 수정 / 아니오"로 답한 뒤에만 다음 단계로 넘어갑니다. "수정"이면 고친 내용이 우선하고 "아니오"면 그 자리에서 멈춥니다. 그리고 단계마다 넘어가기 위한 점검 조건이 따로 있습니다. 마지막 추적표에서 어디로도 이어지지 않은 요구가 0건이어야 "개발 준비 완료"이고 하나라도 남으면 앞 단계로 되돌아갑니다.
이 절차가 돌아가는 것은 AI가 똑똑해서가 아니라, 사람이 멈추는 지점이 절차에 들어 있어서입니다. 800장을 받았을 때 없었던 것이 바로 이 멈춤이었습니다.
요구 하나가 추가될 때가 진짜 시험대였습니다
처음 만들 때보다 어려운 것은 운영 중에 요구가 하나 추가될 때입니다. 급하니까 그 화면만 고치고 몇 주 뒤 다른 화면이 이상하게 동작하는 일은 개발을 맡겨 본 분이라면 한 번쯤 겪어 봤을 것입니다.
그래서 절차를 세 가지 진행 방식으로 나눴습니다. 요구 1건을 추가할 때는 기존 문서에 덧붙이며 영향을 점검하고, 전체를 새로 분석해야 할 때는 처음부터 다시 돌리고, 산출물이 하나도 없는 새 프로젝트는 인터뷰부터 시작합니다.
요구 1건이 들어오면 먼저 기존 기능과 어떤 관계인지 넷 중 하나로 판정합니다. 기존 묶음에 편입하거나, 새 묶음을 만들거나, 독립으로 두거나, 이미 있는 것과 중복이라 기각합니다. 그다음 어느 화면과 어느 흐름에 영향이 가는지 표로 남깁니다. 가령 조회 화면에 칸 하나를 더하는 요구라면, 그 칸을 저장하는 화면과 그 값을 쓰는 다른 흐름이 표에 같이 올라오는 식입니다.
지금은 분석과 시제품 코딩이 동시에 이뤄집니다. 운영 중에 요구가 추가되면 분석과 함께 기존 화면·기능에 미치는 영향을 평가한 뒤에 고칩니다. 빨리 고치는 것보다 어디가 같이 움직이는지 먼저 아는 것이 결과적으로 더 안정적이었습니다.
절차를 세운 뒤 달라진 것
이 절차로 한 고객사의 업무 시스템 세 개를 차례로 만들고 있습니다. 광고 관리를 2026년 6월에 시작했고, 영업 관리를 7월에, 구매·자산 관리를 8월 21일에 시작했습니다.
광고 관리 시스템의 사용 장면 명세는 6월 초에 이미 43번째 판까지 고쳐져 있었습니다. 요구가 계속 바뀌었고 문서가 그 변화를 따라갔다는 뜻입니다. 구매·자산 관리 시스템은 8월 21일에 시작해 10월 1일까지 213번째 작업 묶음을 마쳤고 화면 82개가 모두 구현돼 있습니다. 작업 묶음은 저희가 일을 끊는 단위이고 각 묶음은 점검을 통과해야 닫힙니다.
속도도 달라졌습니다. 복잡한 업무를 분석할 때, 예전에는 담당자별로 칸을 나눈 업무 흐름도를 한 주에 2~3장 그리는 것이 보통이었습니다. 지금은 AI가 한 시간 안에 2~3장 이상을 그려 내고 사람은 그것을 확인하고 고치는 데 집중합니다. 저희 체감으로는 분석 속도가 기존보다 10배 이상 빨라졌습니다. 시제품 개발까지 안정적이면서 빠르게 만들 수 있게 된 것도 이 덕분입니다.
개발을 맡기기 전에 코드보다 먼저 물어볼 것
AI로 빨리 만들어 준다는 제안을 받았다면, 결과 화면을 보기 전에 다음을 물어보셔도 됩니다. 저희가 절차를 세우면서 스스로에게 던진 질문이기도 합니다.
- 코드를 짜기 전에 어떤 문서가 먼저 나오는지, 그 문서를 제가 읽고 "예 / 수정 / 아니오"를 말할 수 있는 분량인지
- 제가 낸 요구 하나하나가 어느 화면과 어느 규칙으로 갔는지 표로 보여 줄 수 있는지
- 운영 중에 요구를 하나 추가하면, 고치기 전에 어느 화면이 같이 영향을 받는지 알려 주는지
- 작업을 어떤 단위로 끊고 그 단위가 닫히는 조건이 무엇인지
- "개발 준비 완료"라고 말하는 기준이 무엇인지
이 질문에 답이 있는 제안과 없는 제안은 같은 "AI 개발"이라는 말을 쓰더라도 하는 일이 다릅니다. 다음 글에서는 7단계에서 나오는 문서 7가지를 하나씩, 외주를 맡기는 쪽이 어떤 형태로 받아 보면 되는지 적겠습니다.