서론
업무상으로 BDD(행위 주도 개발)를 다음 분담 방식으로 진행해 보고 있습니다. 팀에서 결정한 사양을 바탕으로 제가 초안을 만들고, AI에게 이를 시나리오 등의 BDD 형식으로 작성하게 한 뒤, 완성된 것을 제가 리뷰하는 흐름입니다.
이 글에서는 AI가 작성한 BDD에 대해 사람이(저) 무엇을 지적하고 수정했는지를 정리했습니다. 지적 사항들을 기록하여 분류해 보니, 내용은 대략 4가지 종류로 모였습니다.
결론부터 말씀드리자면, 사람이 고친 것은 문장의 오류가 아니라, 'AI가 넓게 제시하고 사람이 좁히는' 판단이었습니다.
본 기사에서는 BDD를 작성하기까지의 과정을 다룹니다. 관계자와의 인식 맞추기나 구현은 아직 앞으로의 단계입니다.
배경: '요구사항과 다르다'로 발생하는 재작업(手戻り)
저희는 위탁 개발을 하며 다음과 같은 흐름으로 업무를 진행하고 있습니다.
클라이언트의 요구사항 → 디렉터 → 엔지니어 → 스테이징에서 클라이언트가 확인
이 흐름에서, 스테이징을 확인한 클라이언트로부터 '요구사항과 다르다'는 말을 듣고 재작업(手戻り)이 발생하는 경우가 있었습니다. 원인의 대부분은 요구사항이 사람을 거쳐 전달되는 과정에서 해석이 조금씩 어긋나면서 세 당사자가 각각 다른 인식을 가진 채 진행되어 버리는 것이었습니다.
그래서 BDD의 자연어 기반 '행위 기술'을 클라이언트, 디렉터, 엔지니어 세 사람이 인식을 맞추는 기준으로 삼는 방식을 사내에서 시도하게 되었습니다.
진행 방식
이번 진행 방식은 다음과 같습니다.
- 팀에서 사양을 결정하고 제가 초안으로 정리합니다.
- 초안을 AI에게 전달하여 사양으로 정형화합니다. 부족한 점이나 상세 내용도 추가하도록 합니다.
- GitHub Copilot으로 사양을 Gherkin 형식으로 변환합니다.
- 제가 리뷰하며 오류나 부족한 부분을 추가합니다.
제가 담당한 기능의 BDD는 이미 작성을 마쳤습니다.
다만, Gherkin은 비엔지니어에게 읽기 어렵다는 문제가 있습니다. 따라서 관계자들에게 설명할 때는 각 멤버의 BDD를 정본으로 하여 작성한, 비엔지니어용 설명 자료를 사용했습니다.
지적 사항을 기록하는 규칙
리뷰 도중부터 AI에 대한 지적이나 수정 지시를 기록으로 남기도록 했습니다. 나중에 되돌아보며 AI가 어디서 실수하기 쉬운지 알기 위해서입니다.
기록에는 단 하나의 규칙만 두었습니다.
AI가 제안한 내용만을 자신의 지적으로 취급하지 않는다.
AI와 대화하며 사양을 구체화하다 보면, AI의 제안에 제가 '그대로 괜찮습니다'라고 답하는 경우가 자주 있습니다. 이때 세부 사양까지 자신이 지시한 것처럼 기록하면 누가 무엇을 판단했는지 알 수 없게 됩니다.
그래서 다음과 같이 나누어 기록했습니다.
- 자신이 명확하게 지적/지시한 것
- AI가 제안하고, 자신이 채택을 판단한 것
- AI가 제안했을 뿐, 아직 합의하지 않은 것
이 규칙 덕분에 '사람이 고친 내용'만을 추출하여 분석할 수 있었습니다.
지적 사항을 분류하니 4가지로 모였다
기록된 발언은 여러 채팅 분량을 합쳐 약 110건이었습니다. 세부 내역은, AI의 출력이나 전제를 바로잡은 '지적'이 약 36건, 작업 또는 확인을 요청한 '요청'이 약 52건, 사양 판단 및 정보 제공이 약 21건입니다 (기록표의 행 수와 발언 수를 센 대략적인 수치입니다).
이 중 '지적'을 분류하니 다음 4가지로 모였습니다. 4가지에 해당하지 않는 지적(자료 오인정정 등)이 약 4건 있었습니다.
| 분류 | 내용 | 지적 건수 |
|---|
| ① 대상 범위/운용 판단 | 어떤 상황에서 사용할 기능인지, 어디까지 다룰 것인지 | 약 14건 |
| ... | | |
| ②는 '지적'으로는 1건이지만, 사양서나 정의 확인을 요청하는 주고받음은 '요청'으로 반복적으로 나왔습니다. 건수 이상으로 사양의 내용을 좌우한 분류입니다. | | |
각각 구체적으로 살펴보겠습니다.
① 대상 범위/운용 판단
가장 많았던 것이 이 종류의 지적이었으며, 전체 지적의 약 4할(36건 중 14건)을 차지했습니다.
AI는 발생 가능한 케이스를 빠짐없이 하려고 합니다. 그 자체로는 장점이지만, 실제 운용에서는 일어나지 않는 장면이나 담당 범위 바깥까지 사양을 넓혀버리는 경우가 있었습니다.
예를 들면 다음과 같습니다.
한 번만 사용하는 처리를, 통상적인 운용에서도 사용할 전제처럼 작성해 버린다
릴리스 준비 때 한 번만 쓰는 일괄 취합을, 일상 운용에서도 사용할 것처럼 쓰거나, 일반 처리와의 병용에 대해 여러 번 확인하게 만들었습니다. -
예외 대응을 위해, 전용 기능이나 절차를 늘려버린다
어떤 종류의 실패가 발생했을 때를 대비하여, AI는 추가적인 재시도 절차(re-try procedure)를 제안해 왔습니다. 하지만 실제 운영 환경에서는 연관 부서에 확인하면 끝나는 문제입니다. 절차가 늘어나면 운영이 번거로워지므로, 추가하지 않도록 지적했습니다. - 판단 조건을 너무 넓게 설정하는 것
공개 여부를 판단할 때, 과거 실행 이력까지 포함하려고 했습니다. '이번 처리 결과만으로 판단하면 충분하다'고 전달했습니다. - 다른 기능 이야기를 끌어들이는 것
다른 화면의 사양이나, 다른 담당자가 작성하는 배치(batch) 본체 사양까지 검토 대상으로 넣었습니다. 관련 부분은 다루되, 담당 범위 밖의 내용은 제외하라고 지적했습니다.
이것들을 Before/After로 비교하면 다음과 같습니다.
| 예시 | AI 출력 (Before) | 나의 지적 | 수정 후 (After) |
|---|---|---|
| 일회성 처리 | 일괄 수취와 일반 수취를 병용했을 경우의 동작을 시나리오나 질문으로 여러 번 제시 | '이건 한 번만 사용한다' | 병용 고려를 제외하고, 일괄 수취를 일회성 처리로 기술 |
| ... |
어떤 상황에서 사용할지, 어디까지 다룰 것인지에 대한 판단은 업무와 운영을 아는 사람만이 할 수 있습니다. 위의 예처럼, AI에게 맡기면 발생 가능한 케이스를 넓게 포괄하려다 기능이 늘어나는 방향으로 진행되기 쉽다는 것이 이번 저의 체감입니다.
② 근거(API 사양・DB 정의) 확인
AI는 그럴듯한 가정을 세우고 사양을 쓰거나, 가정에 기반하여 질문해 옵니다.
예를 들어, 필수 항목이나 null 처리 방식을 API 사양서나 테이블 정의를 보지 않고 결정하려 했습니다. 그래서 'API 문서와 마이그레이션(migration)을 실제로 비교하며 확인해 달라'고 요청했습니다.
근거를 확인하면서 사양을 다듬어 가자, 다음과 같은 점들이 나왔습니다.
- 연관 데이터에서, 항목 자체가 존재하지 않는 경우와 값으로 명시적으로 null이 온 경우를 구분할 필요가 있었다 (업데이트 시 기존 값을 유지할지, 초기화할지가 처리 방식이 달라지기 때문에). 항목이 존재하지 않을 때 기존 값을 유지한다는 처리는 제가 지정했습니다. - ID로 받아들일 수 있는 값의 범위는 DB 정의를 근거로 정할 필요가 있었다
- DB 상으로는 null을 허용하고 있지만, 기존 관리 화면에서는 입력 필수인 항목이 있었다
마지막 예시는, 데이터가 가져와지는지 여부만 보고는 알아차리기 어렵습니다. 가져온 후에 기존 화면에서 수정할 수 있는지까지 생각해야 합니다. 이것은 디렉터(director)에게 상담할 사항으로 남겼습니다.
가정 상태 그대로 질문을 받으면, 사람은 매번 '실제는 어떻게 되어 있는가'를 스스로 조사해서 답변하게 됩니다. 미리 근거를 확인한 후에 질문을 받는 것이 대화 횟수를 줄이는 느낌이었습니다.
Before/After를 시나리오로 보여주면 다음과 같은 이미지가 있습니다 (항목명이나 동작은 가공했습니다).
| 내용 | |
|---|
| AI 출력 (Before) | 사양서도 테이블 정의도 보지 않고, '항목이 비어있으면 빈 값으로 업데이트한다'고 가정하여 시나리오화 |
| ... | |
| Before | |
Scenario: 설명문이 공백으로 연관된 경우
When 설명문이 공백인 데이터가 연관되는
Then 설명문은 공백으로 업데이트된다
After
Scenario: 설명문 항목이 연관 데이터에 존재하지 않는 경우
When 설명문 항목을 포함하지 않은 데이터가 연관되는
Then 설명문은 업데이트되지 않고, 기존 값이 유지된다
...
'공백(空)'이라는 모호한 단어가 사실 두 가지의 별개의 상태를 가리키고 있었다는 예시입니다.
③ 팀 내 일관성
이번에는, 팀 멤버들이 각각 다른 기능의 BDD를 담당하고 있습니다. 그리고 기능들 사이에는 공통되는 부분이 있습니다.
그런데 AI는 눈앞의 BDD만 보고 최적의 방식을 생각합니다. 그 결과, 비동기 처리나 알림(notification), 실행 상태 관리 등을 다른 멤버의 BDD와는 다른 방식으로 설계해 버렸습니다.
도중에 이 불일치에 알아차리고, 다음과 같이 방향을 전환했습니다.
다른 멤버가 작성한 BDD 방식을 참고하여 수정해 주었으면 합니다.
또한, 비동기 처리와 알림은 같은 형태로 해 주었으면 합니다.
그 외에도 공유하는 부분은, 그쪽을 우선으로 해 주었으면 합니다.
AI의 출력 (Before)
비동기 처리나 알림, 실행 상태 관리 등을 자신의 BDD만 보고 독자적인 방식으로 기술함
...
AI가 제안했던 방식이 그것만 보면 나쁘지는 않습니다. 하지만 같은 시스템 안에서 같은 것을 다른 방법으로 구현하면, 구현도 유지보수도 매우 어려워집니다. '이 기능에 최적의 것'보다 '팀으로서의 일관성'을 우선한다는 판단은 인간이 명시하지 않으면 AI가 선택하지 않았습니다.
또한, 공유하는 부분에 대해서는 다른 담당자와 함께 검토할 필요가 있습니다. 상대방 기능의 내부 사양을 자신의 담당 측에서만 결정하지 않도록 주의했습니다.
④ 확정 사항과 가안의 구분
AI와의 대화를 통해 사양을 구체화하다 보면, 문서 안에 '확정된 것'과 '아직 논의 중인 것'이 뒤섞입니다. 이 구분이 무너지는 경우가 몇 번 있었습니다. 무너지는 방식은 두 가지가 있습니다.
답변 완료된 내용이 미결 사항에 남아 있는 경우
질문에 답변을 했음에도 불구하고, 문서의 '미확정/논의 사항' 란이 쉽게 줄어들지 않았습니다. 답변한 내용이 본문이나 시나리오에 반영되지 않고 미결 란에 그대로 남거나, 같은 논점을 또 질문받는 경우가 발생했기 때문입니다.
이때 전달했던 내용은 다음과 같습니다.
확인 사항은 모아서 부탁드립니다.
작게 나누어 진행하다 보니 확인 사항이 전혀 줄지 않습니다.
| 내용 | |
|---|
| AI의 출력 | 답변 완료된 내용이 미확정 란에 그대로 남아 있고, 새로운 질문이 하나씩 추가됨 |
| ... | |
| 질문이 조금씩 나오다 보니, 답변할 때마다 새로운 질문이 생겨나서 끝이 보이지 않게 됩니다. 관련된 논점은 모아서 확인해 달라고 요청하고, 답변한 내용은 미결 란에서 빼내 사양으로 옮기도록 부탁했습니다. | |
가안이 확정된 사양처럼 작성되는 경우
반대 방향의 오류도 있었습니다. 제가 '일단 이걸로'라고 제시했던 임시 값이나 다른 멤버에게 상담하기 위한 가안이, 확정 사양처럼 쓰이는 경우가 있었습니다.
상담용 안을 멋대로 확정시키면, 상담 기회 자체가 사라집니다. 임시 값에는 임시라는 것을 명기하고, 미확정 란에 두도록 지적했습니다.
지금 어느 단계인지
비슷한 이야기로 작업 단계의 착오도 있었습니다. AI가 '구현 측 파일이 미갱신입니다'라고 남은 작업처럼 계속 보고하는 경우가 있었습니다. 하지만 지금은 아직 구현 전 BDD를 만들고 있는 단계입니다. 구현 측 반영은 다음 공정이기 때문에, 현재 완료 조건에는 해당하지 않습니다.
무엇이 결정되었고, 무엇이 결정되지 않았는지, 그리고 지금 어느 단계인지. 이 상태를 관리하는 것은 끝까지 인간의 역할이었습니다.
AI에게 맡길 수 있었던 것
여기까지 지적하는 이야기만 했지만, AI에게 맡겨서 잘 된 부분도 많습니다. 주로 다음 세 가지입니다.
- 기술(記述): 제가 생각한 사양의 초안을 Gherkin 시나리오로 작성함 -
- 포괄성(網羅): 정상 케이스뿐만 아니라 실패 시나 경계값 등의 시나리오를 도출함 -
- 정리(整形): BDD 전체 형식을 맞춤. BDD 변경 사항을 설명 자료에 반영함
특히 포괄성에 대해서는, 인간이 놓쳤던 케이스를 AI가 제시해 준 경우도 있었습니다. 그리고 AI가 포괄적으로 작성해주기 때문에, '이 케이스는 운영상 일어나지 않으니 제외한다'라는 판단(①)을 할 수 있었던 면도 있습니다.
즉, AI가 넓히고, 인간이 좁히는 역할 분담이 되어 있었습니다.
회고
지적 사항을 네 가지로 분류해 보니, 인간이 수정했던 것은 문서의 오류가 아니라, 판단이 필요한 부분이었다는 것을 알게 되었습니다.
| AI가 잘한 것 | 인간이 맡은 것 |
|---|
| 사양 초안을 시나리오로 작성함 | 어떤 상황에서 사용할지, 어디까지 다룰지를 결정함 |
| ... | |
| 반대로 말하면, 이 네 가지를 처음부터 AI 지시에 포함했다면, 지적 횟수를 줄일 수 있었을지도 모릅니다. 예를 들어 다음과 같은 지시입니다. | |
- 예상되는 운영과 담당 범위를 처음에 명시할 것
- 사양이나 정의가 손에 있다면, 가정을 세우기 전에 반드시 확인하게 할 것
- 다른 멤버의 결과물과 공통하는 부분은 기존 방식을 우선시하도록 할 것
- 답변 완료된 논점은 미결 란에서 빼고, 가안에는 가안임을 명기하도록 할 것
끝으로
현 시점에서 각 멤버의 BDD를 바탕으로 설명 자료를 작성하여 관계자들에게 공유했습니다. 지금은 피드백을 받고 있는 단계입니다.
이후로는, 피드백을 BDD에 반영하여 세 사람의 인식을 맞추고 구현으로 진행할 예정입니다. 그 과정에서 다음 점들을 확인하고 싶다고 생각합니다.
토론
- BDD가 정말로 인식(認識) 일치 기준으로서 기능하는지
- 회고에서 언급된 4가지 포인트를 처음부터 지침에 포함하면, 실제로 지적이 줄어드는지
AI에게 BDD를 작성하게 하는 상황에서는, 작성시키는 것보다 '무엇을 수정할지'를 결정하는 데 인간의 시간이 사용되고 있었습니다. 이 점이 AI로 명세를 작성하고 있는 분들께 도움이 되기를 바랍니다.
Discussion
