AI 개발에서 뒤늦게 깨달은 것들: 코딩보다 먼저 정해야 하는 것들

AI와 함께 소프트웨어를 만들다 보면 처음에는 속도에 놀라게 된다.
아이디어를 말하면 화면이 나오고, 기능을 설명하면 코드가 만들어지고, 문서를 요청하면 순식간에 초안이 생긴다.

하지만 프로젝트를 조금만 이어가다 보면 다른 문제가 드러난다.
빠르게 만들어진 결과가 정말 내가 원한 것인지, 나중에 수정할 수 있는 구조인지, 요구사항과 설계가 서로 맞는지 확인해야 한다.

이번 프로젝트를 진행하면서 가장 크게 느낀 점은 이것이었다.

AI 개발에서도 소프트웨어 개발의 기본은 사라지지 않는다.
오히려 AI가 빠르게 만들어주기 때문에 기준을 더 빨리 잡아야 한다.

AI는 속도를 높여주지만 방향을 정해주지는 않는다

AI는 모호한 요청에도 그럴듯한 결과를 만들어낸다.
이건 장점이기도 하지만 위험이기도 하다.

요구사항이 흐리면 AI는 빈칸을 스스로 채운다.
그러면 결과물은 빠르게 나오지만, 내가 원한 소프트웨어와 조금씩 멀어질 수 있다.

그래서 AI 개발에서 먼저 해야 할 일은 코딩이 아니었다.
무엇을 만들 것인지, 누구를 위한 것인지, 어디까지 만들 것인지, 무엇은 하지 않을 것인지를 먼저 정해야 했다.

처음 요구사항이 완벽할 필요는 없다.
하지만 최소한의 기준은 있어야 한다.

• 목적
• 사용자
• 핵심 기능
• 제외할 기능
• 완료 기준

이 기준이 있어야 AI가 만든 결과를 보고 “맞다” 또는 “아니다”라고 판단할 수 있다.

요구사항은 목록이 아니라 구조로 관리해야 한다

처음에는 요구사항을 목록으로 정리하면 충분해 보인다.
하지만 요구사항이 늘어나면 단순 목록은 금방 한계에 부딪힌다.

어떤 요구사항이 다른 요구사항을 포함하는지, 어떤 요구사항이 중복되는지, 어떤 요구사항이 서로 충돌하는지 알기 어려워진다.
하나를 바꾸면 어디까지 영향을 주는지도 추적하기 힘들다.

그래서 요구사항은 단순한 문장이 아니라 관계를 가진 구조로 관리해야 한다.

각 요구사항에는 ID가 있어야 하고, 요구사항 사이에는 관계가 있어야 한다.
포함, 세분화, 중복, 충돌, 의존, 관련, 대체 같은 관계를 명시해야 한다.

이렇게 해야 요구사항이 쌓여도 전체 구조를 잃지 않는다.

사람에게는 추상화된 보기가 필요하다

요구사항을 꼼꼼히 기록하는 것만으로는 부족했다.
사람은 모든 요구사항을 한 번에 읽고 이해하기 어렵다.

그래서 상세 문서와 함께 추상화된 보기가 필요했다.

예를 들면 이런 것들이다.

• 전체 관계를 보는 그래프
• 특정 요구사항 주변만 보는 포커스 보기
• 상위 요구사항에서 하위 요구사항으로 내려가는 브레이크다운 보기
• 여러 세부 요구사항을 큰 개념으로 묶어 보는 추상화 보기

결국 요구사항 관리는 단순 문서 관리가 아니라, 사람이 복잡한 구조를 이해할 수 있게 돕는 도구가 되어야 했다.

분석은 생략하면 안 되는 단계였다

요구사항을 정리한 뒤 바로 설계로 넘어가고 싶어진다.
하지만 실제로 해보니 요구사항과 설계 사이에는 분석 단계가 필요했다.

분석은 “무엇을 만들 것인가”를 “어떤 문제 구조인가”로 바꾸는 과정이다.

이 단계에서 도메인 개념, 상태, 관계, 업무 규칙이 드러난다.
예를 들어 요구사항 삭제를 어떻게 처리할지, 관계가 있는 요구사항은 삭제할 수 있는지, 삭제된 항목을 조회할 수 있는지 같은 문제는 단순 UI 문제가 아니었다.

이런 규칙을 분석에서 정리하지 않으면 설계와 구현 단계에서 계속 다시 결정해야 한다.

MVP는 작게 만드는 것이 아니라 검증 가능한 범위를 정하는 것이다

MVP를 처음에는 “작게 만든 첫 버전” 정도로 생각하기 쉽다.
하지만 이번 프로젝트에서 MVP는 “검증 가능한 첫 범위”에 더 가까웠다.

무엇을 넣을지보다 중요한 것은 무엇을 뺄지였다.

예를 들어 저장형 보기는 나중에 필요할 수 있지만 MVP에서는 제외했다.
대신 요구사항 CRUD, 관계 CRUD, 기본 그래프 조회, Mermaid 출력처럼 첫 버전에서 검증해야 할 핵심만 남겼다.

MVP에는 포함 범위뿐 아니라 제외 범위, 저장 포맷, API 응답, 완료 기준, 검증 체크리스트까지 있어야 했다.
그래야 첫 버전이 끝났는지 판단할 수 있다.

용어집은 나중에 만들면 비용이 커진다

가장 체감이 컸던 부분 중 하나는 용어였다.

처음에는 비슷한 말을 섞어 써도 큰 문제가 없어 보였다.
하지만 문서가 늘어나자 같은 개념을 여러 표현으로 부르고 있었다.

예를 들어 View, 뷰, 롤업, 추상화 보기 같은 표현이 섞이면 나중에 대표 용어를 정리할 때 요구사항, 분석, 설계, MVP 문서를 모두 다시 확인해야 한다.

이 경험을 통해 용어집은 문서의 부록이 아니라는 걸 알게 됐다.
용어집은 사람과 AI가 같은 개념을 같은 말로 다루기 위한 작업 도구다.

새로운 핵심 개념이 나오면 먼저 대표 용어를 정하고, 사람이 이해할 수 있도록 유사어를 함께 기록해야 한다.
AI는 대표 용어를 사용하고, 사람은 유사어를 통해 검색하고 이해할 수 있어야 한다.

검증은 나누어 보고 마지막에 연결해서 봐야 한다

검증도 한 번에 전체를 보면 놓치는 것이 생긴다.
반대로 부분만 보면 전체 흐름이 끊긴 것을 놓칠 수 있다.

그래서 검증은 두 단계가 필요했다.

먼저 나누어 검증한다.

• 산출물 구조 검증
• 내용 정합성 검증
• 방법론/인수인계 검증
• 통합 흐름 검증

그리고 수정 후에는 전체 흐름을 다시 본다.
요구사항, 용어집, 분석, 설계, MVP, 로그, 방법론이 서로 이어지는지 확인해야 한다.

또 하나 중요한 점은 검증과 수정을 섞지 않는 것이다.
검증 단계에서는 먼저 문제를 찾고, 수정은 발견사항을 모은 뒤 묶어서 하는 것이 더 효율적이었다.

로그는 산출물이 아니라 시간순 증거다

프로젝트를 진행하면서 로그의 역할도 다시 생각하게 됐다.

산출물은 현재 기준을 정리한 문서다.
요구사항 문서, 분석 문서, 설계 문서, MVP 명세, 용어집 같은 것들이 여기에 해당한다.

반면 로그는 현재 기준을 다시 정리하는 문서가 아니다.
로그는 그 기준이 어떤 대화와 판단을 거쳐 만들어졌는지 남기는 시간순 기록이다.

나중에 검증하려면 로그가 필요하다.
왜 그런 결정을 했는지, 어떤 질문이 있었는지, AI가 어떤 판단을 했고 사람이 어떻게 조율했는지 확인할 수 있어야 한다.

정리는 산출물에서 하고, 흐름은 로그에 남긴다.
이 구분이 중요했다.

좋은 방식은 규칙과 템플릿으로 남겨야 한다

작업 중에 좋은 방식이 생겨도 문서화하지 않으면 다음 세션에서 반복되지 않는다.
특히 AI와 작업할 때는 세션이 바뀌면 이전 맥락이 사라질 수 있다.

그래서 반복되는 방식은 규칙과 템플릿으로 승격해야 한다.

• 새 세션이 먼저 읽을 문서
• 작업 에이전트의 기본 규칙
• 검증 에이전트의 기준
• 요구사항 템플릿
• 분석 템플릿
• 로그 템플릿
• 새 프로젝트 체크리스트

이런 것들이 있어야 다음 작업도 같은 기준에서 시작할 수 있다.

정리하며

이번 프로젝트를 통해 얻은 가장 큰 교훈은 단순하다.

AI로 소프트웨어를 만들수록 대충 시작해도 되는 것이 아니다.
오히려 기준을 더 빨리 잡아야 한다.

요구사항을 먼저 잡고, 용어를 통일하고, 분석을 분리하고, MVP 범위를 고정하고, 검증 방식을 정하고, 로그를 남겨야 한다.

나중에 정리해도 된다고 생각한 것들은 결국 더 큰 비용으로 돌아왔다.
용어집을 늦게 만든 것도 그랬고, 로그의 목적을 뒤늦게 분명히 한 것도 그랬다.

AI 개발에서 중요한 것은 AI가 코드를 얼마나 빨리 만드는지가 아니었다.
사람이 얼마나 명확하게 기준을 세우고, AI와의 대화를 그 기준 안에서 관리하느냐였다.