세계적인 AC로 유명한 Y Combinator의 공동창업자 Paul Graham은 스타트업에 대해 ‘매우 빠르게 성장하도록 디자인된 기업(a company designed to scale very quickly)’으로 정의 내린 바 있습니다. 영세기업과 스타트업을 가르는 가장 결정적인 차이는 가파른 성장 가능성이 있다는 것입니다.
그런 점에서 스타트업에게 속도는 곧 생명이나 다름없습니다. 규모의 경제에 기대기 어려운 스타트업으로서는 경쟁자들의 추격을 허용하지 않는 빠른 경쟁우위 구축이 최선의 전략입니다. 하지만 고객의 요구사항을 정확하게 충족시키는 제품을 만드는 일 또한 개발의 속도 못지않게 중요합니다. 결국 사업의 성패를 좌우하는 것은 사용자들의 선택이기 때문입니다.
얼핏 생각해보더라도 두 가지 조건을 모두 만족시키는 것은 까다로운 일입니다. 특히 개발과 기획이 어느 정도 분리되어 있는 조직에서는 더욱 그렇습니다. 기획 부서가 개발에 대한 전문적인 지식을 갖추고 있는 경우라면 더할 나위가 없겠지만 그렇지 않은 대부분의 경우 개발팀은 제품 개발에 필요한 구체적인 지침의 부재로 어려움을 겪습니다.
그리고 작년 말, 저희도 정확히 같은 문제로 골머리를 앓고 있었습니다. 창업 초기에 아직 개발에 관한 체계도 제대로 잡혀있지 않았던 상태에서 빠듯한 개발 일정에 쫓기고 있던 상황이었습니다. 이미 개발 중인 기능에 대해서도 팀원 간에 이해한 내용이 다른 경우가 비일비재했고 하루에도 몇 번씩 현재 진행 중인 개발 방향이 기획 의도와 부합하고 있는지 팀원들끼리 질문을 주고받기도 했습니다.
하지만 그럼에도 3개월 남짓한 짧은 시간 안에 저희는 이렇게 많은 진전을 이뤄냈습니다. 가끔 어떤 분들은 저희가 처음부터 이런 속도를 유지하고 있었던 것으로 생각하시는 경우도 계시지만, 물론 그 사이에는 제품 개발 프로세스를 개선하기 위한 꾸준한 노력들이 있었습니다. 그러한 수많은 시도들 중에서도 가장 의미 있었던 작업 중 하나로 저는 오늘 인수조건(Acceptance Criteria) 작성에 대해 이야기해 보려고 합니다.
인수조건(Acceptance Criteria)이란
일반적으로 제품을 통해 우리가 만족시키고자 하는 사용자의 요구는 아래의 예시들과 같은 일상 언어로 표현됩니다.
“키워드 검색 기능이 필요합니다.”
“작업물 공유가 좀 더 편했으면 좋겠어요!”
이러한 요구조건들은 제품 개발의 방향성을 제시해줄 수는 있지만 그 자체로 시스템 구성에 필요한 세부요건(System Specification)들을 특정하기는 어렵습니다. 이 때문에 대부분의 조직에서는 본격적으로 개발에 착수하기 이전에 요구분석 결과를 바탕으로 제품의 기능과 목적을 정의하는 과정을 거칩니다. 이때 가장 핵심적인 과정이 바로 인수조건(Acceptance Criteria)을 결정하는 것입니다.
인수조건은 제품이 최종 사용자 혹은 시스템이 제시하고 있는 요구사항을 만족하고 있는지를 판별하기 위한 기준입니다. 인수조건은 제품 개발 과정 전체에 걸쳐 주된 이정표와 같은 역할을 하기 때문에 해당 인수조건이 관장하는 범위와 pass/fail의 요건을 명확하게 만드는 것은 제품 개발 프로세스에서 매우 중요한 의미를 갖습니다.
인수조건의 가장 큰 특징은 철저하게 사용자의 관점에서 제품의 기능을 정의한다는 것입니다. 인수조건을 바탕으로 진행되는 인수 테스트(Acceptance Test)는 제품이 처음에 의도했던 대로 동작하고 있는가에 초점을 두고 있습니다. 따라서 인수조건 도입은 기획자를 비롯하여 개발자와 QA 팀, PM까지 제품 개발에 관여하는 모든 인원이 요구사항에 대해 동일한 이해를 공유하고 있을 것을 전제로 합니다.
빠지기 쉬운 함정
인수조건은 간결하고 쉬운 언어로 기술하는 것을 원칙으로 하기 때문에 개발에 대한 배경지식이 없는 인원도 인수기준 설정에 참여할 수 있다는 장점이 있습니다. 그러나 비교적 간단해 보이는 실행 과정과 요구조건에도 불구하고 아래에서 언급한 것과 같은 저지르기 쉬운 몇 가지 실수들은 예상치 못한 문제들을 발생시키기도 합니다.
1. 모든 인수조건은 테스트가 가능해야 합니다.
이것은 의외로 생각보다 많은 팀에서 저지르는 실수입니다. 앞서 설명한 것처럼 인수조건은 제품이 초기의 요구사항을 만족시키고 있는지를 알아보기 위한 도구입니다. 따라서 인수조건은 구현된 기능의 테스트 통과 여부를 정확하게 구분할 수 있는 측정 가능한 기준을 제시해야 합니다. 그러한 기준이 불명확한 인수조건은 잠재적으로 제품 테스트 단계를 무력화할 위험이 있습니다.
2. 제품 요구사항(Product Requirement)은 될 수 있는 한 세분화되어야 합니다.
보통 인수조건 작성의 바탕이 되는 제품 요구사항들은 개발에 적합한 형태로 충분히 세분화되어있지 않을 가능성이 높습니다. 지나치게 넓은 범위를 대상으로 하는 요구사항은 많은 세부 과제를 포함하는 인수조건을 만들어 내기 쉽고, 이는 개발 상의 효율성과 편의를 위해 인수조건은 최소한의 기능 단위를 포함하고 있어야 한다는 본래 의도에 어긋나는 결과로 이어지게 됩니다.
3. 인수조건은 최종 결과물에 대한 가이드라인을 제공하지 않습니다.
인수조건은 구현된 기능이 최종적으로 충족시켜야 하는 조건을 나타내는 것으로, 달성 가능한 목표를 제시하는 것을 목적으로 합니다. 따라서 요구사항에 포함되지 않은 설계 조건을 서술하거나 구체적인 솔루션을 언급하는 등 개발 과정에 대한 지침을 제공하는 것은 개발 과정에서의 유연성을 떨어뜨리고 인수조건이 해당 기능 범위에서 나타날 수 있는 여러 사용자 행동을 포괄하기 어렵게 만들 수 있습니다.
좋은 인수조건을 작성하는 방법
이처럼 인수조건을 작성하는데는 의외로 상당한 주의가 필요합니다. 저를 비롯한 팀원들도 초기에는 여러 시행착오를 거치며 인수조건 작성을 정착시키기 위해 많은 노력을 기울였습니다. 그럼에도 불구하고 앞서 언급한 것처럼 인수조건은 잘만 활용한다면 상당히 유용한 도구가 될 수 있습니다. 이 글을 읽고 계신 독자 여러분들께도 도움이 되기를 바라면서 저희들이 좋은 인수조건을 작성하기 위해 활용한 방법 중 일부를 소개합니다.
1. 예시를 최대한 활용하기
인수조건을 작성할 때 가장 중요한 것은 고객의 요구사항에 대한 구성원들의 이해를 일치시키는 것입니다. 따라서 이 단계에서는 자의적인 해석의 여지를 제거하여 요구사항이 포함하고 있는 개념들을 모두가 같은 방식으로 이해하도록 만드는 과정이 필요합니다. 이때 가장 효과적인 것이 구체적인 예시를 활용하는 방법입니다. 인수조건과 함께 자주 사용되는 유저 스토리(User Story) 기법은 사용자 행동 예시를 바탕으로 요구사항을 재구성하는 좋은 사례 중 하나입니다.
2. 내용은 이해하기 쉬운 언어로 분명하게
인수조건은 내부 구성원이라면 누구나 이해할 수 있는 용어를 사용하여 작성되어야 합니다. 작성된 내용은 사용자의 관점에서 가시적으로 드러나는 기능 범주뿐만 아니라 사용자는 인지하기 어렵지만 시스템의 확장성과 사용성에 영향을 미치는 비기능 범주까지 포함해야 합니다. 불필요한 세부 설명과 제약 조건은 되도록 인수조건에 포함하지 않는 것이 좋습니다.
3. 결과는 항상 모든 관계자에게 공유
작성된 인수기준은 반드시 관련된 팀원 모두에게 공유하고 의견을 수렴하는 과정을 거쳐야 합니다. 이러한 과정을 통해 개발팀은 구현해야 하는 기능을 정확하게 인지하게 되고 기획 부서와 다른 구성원들은 구현된 기능으로부터 기대할 수 있는 결과를 이해하고 예측할 수 있습니다.
4. Definition of Done
인수조건에 포함된 완료 기준은 개발팀이 제품 개발의 완료 여부를 가늠할 수 있을 만큼 구체적이고 측정 가능해야 합니다. 인수 테스트를 통과한 제품이 요구사항을 제대로 충족시키고 있다는 사실을 신뢰할 수 있는 경우에만 해당 인수조건은 제대로 작성된 것입니다.
5. 누구나 참여 가능
인수조건 작성에는 원칙적으로 제품 개발에 관련된 구성원이라면 누구나 참여할 수 있습니다. 흔히 그러한 작업은 기획팀에서 담당하는 업무라고 생각하고 수동적인 자세를 취하기 쉽지만, 인수조건 작성 시에는 개발팀을 포함하여 제품 개발에 관여하는 직군들이 가능한 많이 참여하는 것이 더 좋습니다.
이는 제품 요구사항에 대한 구성원들의 이해를 일치시키려는 근본적인 목표 달성에 도움이 될 뿐만 아니라 보다 다양한 시각을 통해 인수조건 작성 시 미처 고려하지 못한 사용자 행동이 존재할 가능성을 최소화합니다. 특히 개발 주기가 짧고 기능 우선순위의 변동이 심한 경우 인수조건 작성 참여를 장려하는 것은 조직 내의 혼선을 방지하는 역할을 수행할 수 있습니다.
6. 중요한 것은 항상 개발 전에
인수조건은 항상 해당 기능에 대한 개발이 시작되기 전에 작성이 완료된 상태여야 합니다. 인수조건은 제품 개발에 요구사항을 제대로 반영하도록 만들기 위한 장치이므로 개발이 시작된 이후 작성을 시작하는 경우에는 인수조건 작성의 의미가 크게 퇴색될 수밖에 없습니다. 또한 개발 중에 인수조건의 내용이 변경되는 경우에도 반드시 제품 개발에 관계된 모든 인원들에게 해당 사실을 공유해야 합니다.
좋은 인수조건은 제품 개발에 분명한 방향성을 부여하고 의도된 개발 목표를 제대로 구현하고 있는지를 효율적으로 검증할 수 있게 하는 유용한 도구입니다. 인수조건 작성 과정에서 형성된 구성원들의 제품 요구사항에 대한 공통된 이해는 소통 비용과 그에 따른 개발 지연으로 인한 리스크를 줄여주는 동시에 한정된 조직 역량을 집중시키는데 큰 도움이 됩니다.
흔히 제품 개발 프로세스라고 이야기하면 무언가 복잡하고 고도로 체계화된 시스템 같은 것을 떠올리기 쉽습니다. 하지만 시스템도 결국은 사람들이 일하는 방식 그 자체일 뿐이라는 것을 생각해보면 비교적 작고 단순해 보이는 방법으로도 생각보다 많은 것들을 바꿀 수 있습니다. 불과 몇 달 동안의 크고 작은 노력들이 모여 지금의 저희들을 만든 것처럼 말입니다.
Yeoleum / Product Manager
