유저 스토리와 인수 조건

최근 2주 동안 출시 예정 서비스의 주문과 결제를 담당하는 화면에 5개가 넘는 변경 사항이 생겼다. 변동 사항을 팀원 전체가 인지할 수 있도록 Notion으로 문서화를 했고 시각화가 필요한 부분은 Figma로 만들었다. 수십 문장을 여러 번 고치고 옆자리 팀원에게 의견을 물어보며 완성했다. 그래서 4~5시간은 족히 걸렸다. '이 정도면 다들 이해하겠지'라고 스스로 생각할 정도로 정리가 괜찮게 되었다. 아니 괜찮은 줄 알았다.. ㅎ

해당 문서를 한국 팀원들은 이해하는 데 어려움이 없었다. 하지만 베트남 현지에서 원격 근무 중인 외국인 개발자 2명은 아니었다. 가끔 조언을 구하는 다른 팀의 CPO님과 이야기하다 상황 설명을 하고 내가 만든 문서를 보여드렸다. 그리고 텍스트는 User story로 작성하고 Wireframe으로 User flow를 만드는 게 좋겠다는 피드백을 받았다.

User story와 Wireframe은 이미 익숙한 개념이었다. User story는 PM으로서 처음으로 Backlog를 구성할 때 사용했다. 하지만 당시 개발팀 수준에는 User story보다 더 구체적인 명세를 하는 것이 더 명확할 것 같아 실제 활용까지는 하지 않았다. Wireframe도 작년에 서비스를 최초 구상 시에 잠깐 사용하고 말았었다. 하지만 익숙한 두 방법을 여기에 활용할 생각은 못했다.

그렇게 조언을 듣고 외국인 개발자에게 User story와 Wireframe으로 명세하겠다고 했다. 그러자 한 분이 User story의 실제 활용 예시를 스크린샷으로 보내주셨다. 그 스크린샷에 'Acceptance Criteria'라고 적혀 있었다. 뭔가 중요한 요소일 것 같아 구글링을 통해 개념을 파악했다. User story가 러프한 요구사항이라면 Acceptance critieria는 해당 User story를 달성하기 위한 구체적인 요구사항 또는 시나리오다. 개념을 파악한 후 기존에 내 마음대로 잘 썼다고 착각한 요구사항들 중 하나를 User story와 Acceptance criteria 형식으로 변경했다. 그리고 외국인 개발자에게 해당 내용을 보내고 "Do you understand?"라고 보냈다. 그리고 답은 "Understnad.". 야호.

외국인 개발자 두 분과는 커뮤니케이션 이슈가 항상 존재한다. 같은 사무실에서 일하지도 않고 Slack이나 Google meet으로 모든 상황을 풀어내기에는 서로의 영어 실력이 처참하기 때문이다. 그래도 오늘은 이런 힘든 상황 덕분에 User story, Acceptance Criteria와 Wireframe을 활용하며 문서화하는 것의 중요성을 배웠다. 한국인 개발자분들만 있었다면 지금 당장 문서화하지는 않았을 것이다. 일단 말은 통하고 이해는 되니까. 하지만 나중을 생각하면 당장 문서화를 하지 않는 것이 큰 기회비용을 불러왔을 것이다.

220811