AI 생산성의 병목, 코딩 전에 명세부터 바꿔봤다
28 Jul 2026
이전 글에서 AI가 구현을 빠르게 해도 검증과 판단이 새로운 병목이 될 수 있다고 이야기했습니다. 이번에는 그 병목을 줄이기 위해 AI를 코딩보다 앞선 요구사항 정리 단계에 배치해봤습니다. PoC에서 먼저 바꾼 것은 비개발자의 요청을 개발 가능한 명세로 만드는 과정이었습니다.
GitHub로 통일하면 깔끔할 줄 알았다
처음에는 AI가 가장 잘 다루는 GitHub를 중심으로 프로세스를 통일하려고 했습니다. 요청부터 Issue, Pull Request, 리뷰까지 한곳에 모으면 AI가 맥락을 이어받기 쉽고 관리도 단순해질 것 같았습니다. 돌이켜보면 사람의 업무 흐름보다 AI의 편의를 먼저 최적화한 선택이었습니다.
하지만 그 단순함은 개발자 입장에서만 단순했습니다.
비개발 직군에게 GitHub는 평소 업무에 필요한 도구가 아니었습니다. 이미 해야 할 일이 많은 사람에게 요청 하나를 남기기 위해 새로운 도구와 개념을 배우라고 요구한 셈입니다. 이들이 GitHub를 익히지 않는 것은 협조가 부족해서가 아니라, 학습 비용에 비해 얻는 이익이 작기 때문일 수 있습니다.
그렇다고 요청을 받지 않을 수는 없습니다. 결국 개발자가 내용을 듣고 다시 해석해 GitHub에 옮기게 됩니다. 당장은 이 방식이 빨라 보입니다. 그러나 요청의 배경과 결정 과정이 특정 개발자의 경험과 기억에 쌓이기 시작합니다. 그 사람이 자리를 비우거나 담당자가 바뀌면 다음 사람은 맥락부터 다시 복원해야 합니다.
사람이 문제였던 것은 아닙니다. 특정 사람이 해석하고 전달해야만 다음 단계로 넘어가는 구조가 병목이었습니다.
도구를 통일하는 대신 역할을 나눴다
그래서 모든 직군을 GitHub로 데려오는 대신, 각 도구가 잘하는 역할을 나눴습니다.
비개발 직군이 이미 사용하던 Notion을 요청과 대화의 입구로 삼았습니다. Notion이라고 요구사항이 저절로 명확해지는 것은 아닙니다. 다만 새로운 도구를 배울 필요가 없고, 담당자가 바뀌어도 요청과 대화가 같은 공간에 남습니다.
GitHub는 없애지 않았습니다. 명세가 확정된 뒤 구현과 리뷰를 담당하는 직군만 사용하도록 범위를 좁혔습니다. GitHub는 모두가 알아야 하는 공용 공간이 아니라, 코드 변경을 실행하고 검증하는 공간으로 남겼습니다.
그 사이를 AI가 연결했습니다.
- 비개발자가 익숙한 Notion에 요청을 남깁니다.
- AI가 요청과 기존 코드를 함께 읽고 초안 명세를 만듭니다.
- 구현 결과를 바꿀 수 있는 모호한 부분을 하나씩 질문합니다.
- 사람이 선택지를 검토하고 업무 의도에 맞는 결정을 내립니다.
- 명세가 확정되면 구현과 리뷰를 GitHub에서 진행합니다.
이 과정은 매번 즉흥적으로 대화한 것이 아니라, 제가 만든 두 가지 스킬로 반복할 수 있게 정리했습니다. 분석하기 스킬은 비개발자가 남긴 요청과 기존 코드를 함께 살펴 요구사항을 개발 가능한 수준으로 확장합니다. 명세화 스킬은 확장된 내용이 업무 의도에 맞는지 사람과 하나씩 확인하며 명세를 확정합니다.
AI는 Notion의 문장을 GitHub Issue 형식으로 복사하는 역할이 아니었습니다. 특정 개발자가 머릿속으로 하던 해석 과정을 질문과 명세로 남기는 역할을 맡았습니다.
두 글자 때문에 구현이 달라졌다
여러 출처의 알림을 한 화면에 모아달라는 요청이 있었습니다. 프로젝트가 드러날 만한 내용을 빼고 줄이면 이 정도였습니다.
여러 종류의 알림을 목록으로 보여주세요.
당일 알림만 최신순으로 보여주세요.
방향은 이해할 수 있습니다. 하지만 바로 구현하려고 보면 “당일”이라는 두 글자부터 명확하지 않습니다.
AI는 기존 코드를 조사해 초안 명세를 만든 뒤 이렇게 물었습니다.
“당일”은 오늘 0시 이후인가요, 현재 시각 기준 최근 24시간인가요?
날짜 기준이라면 매일 0시에 목록의 범위가 바뀝니다. 시간 기준이라면 현재부터 과거 24시간의 항목이 유지됩니다. 둘 다 “당일”로 이해할 수 있지만 실제 동작은 다릅니다.
평소라면 개발자가 둘 중 하나를 익숙한 방식대로 정하고 구현했을 가능성이 큽니다. 이번에는 AI가 두 선택의 차이를 드러냈고, 사람은 업무 목적에 맞춰 최근 24시간을 선택했습니다. AI가 정답을 대신 내린 것이 아니라, 결정이 필요한 지점을 구현 앞으로 끌어낸 것입니다.
이 짧은 대화를 시작으로 처음 요청에 없던 조건도 함께 정리됐습니다.
- 서로 다른 출처의 항목을 하나의 목록에 합칩니다.
- 현재 시각 기준 최근 24시간 이내 항목만 최신순으로 표시합니다.
- 출처마다 실제 발생을 나타내는 기준 시각을 정합니다.
- 시간이 없거나 해석할 수 없는 항목의 처리 방식을 정합니다.
- 화면의 목록과 미읽음 숫자가 같은 필터를 사용하게 합니다.
명세가 길어진 것 자체는 성과가 아닙니다. 중요한 것은 개발자가 임의로 채웠을 빈칸을 구현 전에 발견하고, 사람이 결정할 수 있는 선택지로 바꿨다는 점입니다.
결정이 앞당겨지자 뒤의 일이 줄었다
가장 먼저 체감한 변화는 구현 속도보다 되돌아오는 일이 줄었다는 점이었습니다. 구현 중 요청자에게 다시 확인하는 횟수가 줄었고, 서로 다른 해석 때문에 QA에서 되돌아오는 작업도 줄었습니다.
Pull Request 리뷰의 기준도 달라졌습니다. 명세가 모호할 때는 코드가 깔끔한지, 눈에 띄는 오류가 없는지를 주로 보게 됩니다. 완료 조건이 명확해지면 리뷰 에이전트도 실제 요구사항을 기준으로 확인할 수 있습니다.
- 서로 다른 출처의 항목이 같은 목록에 들어가는가?
- 최근 24시간 조건이 정확하게 적용되는가?
- 목록과 미읽음 숫자가 같은 데이터를 기준으로 하는가?
- 잘못된 시간 값이 합의한 방식대로 처리되는가?
명세는 요청자에게 보여주기 위한 문서로 끝나지 않았습니다. 구현 체크리스트이자 테스트 기준이고, 리뷰에서 무엇을 확인할지 정하는 계약이 됐습니다.
AI 때문에 관리할 일이 늘어난 것도 아니었습니다. 원래 구현 도중이나 QA에서 뒤늦게 하던 결정을 앞으로 옮긴 것입니다. 질문은 조금 늘었지만 재작업은 줄었고, 구현과 리뷰의 기준은 더 분명해졌습니다.
사람의 판단은 남기고, 개인 의존성은 줄였다
이 과정은 완전 자동화가 아닙니다. AI는 기존 코드와 요청을 읽고 선택지를 제시하지만, 어떤 동작이 업무 의도에 맞는지는 사람이 결정합니다. AI가 조용히 “최근 24시간”을 선택했다면 그것도 개발자가 임의로 해석한 것과 크게 다르지 않습니다.
제가 줄이고 싶었던 것은 사람의 판단이 아니라, 그 판단 과정이 특정 사람의 머릿속에만 남는 리스크였습니다.
Notion에는 요청과 대화가 남습니다. AI는 모호한 표현을 반복 가능한 질문으로 바꿉니다. 사람은 업무의 방향을 결정합니다. 확정된 명세는 GitHub에서 구현과 리뷰를 담당하는 사람에게 전달됩니다. 담당자가 바뀌어도 최소한 무엇을 왜 만들기로 했는지는 다시 확인할 수 있습니다.
따라서 이 글의 결론은 “AI가 알아서 개발하게 만들었다”가 아닙니다.
중요한 것은 모든 사람을 하나의 도구에 맞추는 일이 아니었습니다. 사람은 익숙한 곳에서 요청하고 판단하고, AI는 그 사이의 모호함을 명세로 바꾸며, 개발자는 GitHub에서 구현과 검증에 집중하게 하는 것이었습니다.
AI 생산성의 다음 병목을 줄이는 방법은 사람의 판단을 없애는 게 아니라, 그 판단이 더 이른 시점에 드러나고 다른 사람이 이어받을 수 있게 만드는 것인지도 모릅니다.