성공 기준

Success Criteria

개념

만든 뒤에 무엇이 달라져야 이 작업을 성공이라 부를지 숫자와 시점으로 미리 적어 둔 조건입니다.

등장 배경

완료의 뜻이 만들었다는 사실에서 멈추던 시절이 있었습니다. 적어 둔 화면을 다 만들고 결함도 없으면 그 일은 끝이고 다음 항목으로 넘어갔습니다.

그러면 출시 회고에서 이번 건이 잘된 것인지 물었을 때 아무도 답하지 못합니다. 만들기로 한 것을 다 만든 것은 확실한데 만든 뒤에 무엇이 달라졌어야 했는지가 어디에도 없기 때문입니다. 그래서 대화는 일정과 결함 건수로 옮겨 가고, 그 항목을 만든 이유는 다시 나오지 않습니다.

반년 뒤에 더 나쁜 방식으로 드러나기도 합니다. 다른 일로 사용량을 뒤지다가 그 기능을 쓰는 사람이 거의 없다는 것을 알게 되는 것입니다. 그때는 만든 사람도 왜 그것을 앞자리에 놓았는지 기억하지 못합니다.

성공 기준은 이 판정을 문서를 쓰는 시점에 미리 정해 두는 칸입니다. 착수 전에 적어 두면 4주 뒤에 같은 문서를 열어 맞았는지 틀렸는지를 그 자리에서 가릴 수 있습니다.

작동 방식

성공 기준은 재는 대상과 값과 시점을 한 문장에 담습니다. 셋 중 하나가 빠지면 판정이 열리지 않습니다. 쿠폰 사용률 향상은 기준이 아니고, 출시 4주 뒤 결제 완료 건의 15퍼센트 이상에서 쿠폰이 쓰인다는 기준입니다. 앞쪽으로는 4주 뒤에 아무 결론도 못 내지만 뒤쪽은 그날 참인지 거짓인지가 정해집니다.

한 문장에 들어가야 하는 것은 다섯입니다.

  1. 재는 대상. 한 가지로만 읽히게 적습니다. 쿠폰이 쓰인다는 말은 코드가 들어가고 할인이 실제로 적용된 결제 건으로 못 박습니다. 그러지 않으면 코드를 넣어 보기만 한 건까지 세는 사람이 나옵니다.
  2. 값. 숫자로 적고 왜 그 숫자인지를 한 줄 붙입니다. 지금이 0퍼센트이고 비슷한 제품이 12에서 20퍼센트 사이라는 식입니다.
  3. 시점. 출시 4주 뒤로 못 박습니다. 1주는 처음 눌러 보는 반응만 잡히고, 6개월은 그 사이 바뀐 것들이 섞여 원인을 가릴 수 없습니다.
  4. 확인할 자리. 어느 화면의 어느 숫자를 누가 언제 보는지 적습니다. 이 줄이 없으면 4주 뒤에 그 숫자를 뽑는 일부터 새로 시작합니다.
  5. 못 미쳤을 때 할 일. 되돌릴지, 한 달 더 볼지, 그대로 두고 다음으로 갈지를 미리 고릅니다. 이 줄이 빠지면 미달인데도 아무 일이 일어나지 않고, 두어 번 반복되면 아무도 이 칸을 진지하게 채우지 않습니다.

개수는 하나나 둘이 적당합니다. 다섯 개를 적으면 셋은 맞고 둘은 틀린 결과가 나와 판정이 다시 논쟁이 됩니다. 하나를 주 기준으로 세우고 나머지는 같이 보는 숫자로 내립니다.

올라가야 할 숫자와 함께 나빠지면 안 되는 숫자도 적어 둡니다. 쿠폰이 15퍼센트에서 쓰이는 동안 결제 실패율이 오르지 않는다는 줄이 그런 항목입니다. 응답 속도나 보안처럼 동작이 아닌 조건은 비기능 요구사항 칸이 맡지만, 이번 작업으로 무너지면 안 되는 선은 이 옆에 두는 편이 낫습니다.

쓰이는 곳

이 칸이 일하는 자리는 넷입니다.

첫째는 PRD를 쓸 때입니다. 무엇을 왜 만들고 어디까지 되면 끝인지 적는 문서인데, 여기서 제품이 해야 하는 동작을 적는 기능 요구사항이 무엇을 만들지를 맡고 성공 기준이 왜 만드는지를 맡습니다.

둘째는 이번에 만들 것의 경계인 범위를 자를 때입니다. 후보 기능마다 그 숫자에 닿는 데 필요한지를 물으면 됩니다. 관리자용 발급 화면이 없어도 15퍼센트에 닿는다면 그 화면은 이번 범위에서 빠집니다.

셋째는 우선순위 회의입니다. 성공 기준이 빈 항목은 뒤로 내립니다. 만들면 좋겠다는 말과 무엇이 얼마나 달라진다는 말을 저울에 함께 올릴 수 없기 때문입니다.

넷째는 출시 뒤 회고입니다. 적어 둔 날짜가 오면 같은 문서를 열고 숫자를 채웁니다. 이 한 번의 확인이 다음 분기에 같은 종류의 기능을 또 만드는 일을 막습니다.

고객 성공 쪽에는 고객의 목표와 거기 닿는 경로를 적어 두는 성공 계획이 있습니다. 이름이 닮았지만 층이 다릅니다. 이쪽은 우리가 만든 것의 성패를 재고, 그쪽은 고객사 한 곳이 무엇을 이루려 하는지를 적습니다.

실무 용례

"성공 기준이 없어서 이 문서는 리뷰를 못 하겠어요. 4주 뒤에 무엇을 보고 판정할지 적어 주세요."

무엇을 만들지는 적혔는데 왜 만드는지가 판정 가능한 형태로 적히지 않았다는 반려입니다.

"기준은 15퍼센트였고 실제로 9퍼센트가 나왔습니다. 한 달 더 보기로 했습니다."

미달이 나와 착수 전에 정해 둔 대응 하나를 골랐다는 보고입니다.

"이건 성공 기준이 아니라 할 일 목록이에요."

만들 것만 늘어놓았고 만든 뒤에 무엇이 달라지는지가 없다는 지적입니다.

페이지덱은 PRD 양식에 이 칸을 넣고 비어 있으면 리뷰를 열지 않는 규칙을 뒀습니다. 지현이 쿠폰 입력 기능에 적은 줄은 출시 4주 뒤 결제 완료 건의 15퍼센트 이상에서 쿠폰이 쓰이고 결제 실패율은 오르지 않는다는 두 줄입니다.

4주 뒤 숫자는 9퍼센트였습니다. 태오가 사용 기록을 갈라 보니 코드를 넣은 사람 중 3할이 오류 화면에서 멈춰 있었습니다. 미달일 때 한 달 더 본다고 적어 둔 덕분에 기능을 접는 대신 그 화면을 고쳤고, 다음 달에 16퍼센트가 됐습니다.

흔한 오해

기준을 높게 잡아야 좋은 문서라고 보는 경우가 가장 많습니다. 숫자가 크면 야심 있어 보이고 통과도 잘 됩니다. 그러나 이 칸의 목적은 의욕이 아니라 4주 뒤에 판정이 열리게 하는 데 있습니다. 근거 없이 40퍼센트를 적어 두면 9퍼센트가 나왔을 때 제품이 잘못된 것인지 숫자를 잘못 잡은 것인지 가릴 수 없습니다. 그러면 회고는 다시 인상을 주고받는 자리가 됩니다.

기준에 못 미치면 실패라고 보는 오해도 흔합니다. 이름이 그렇게 읽힙니다. 그런데 이 칸으로 얻는 것은 합격증이 아니라 판정 속도입니다. 틀린 가설을 4주 만에 확인하면 그 자리에서 다음 결정을 할 수 있고, 반년을 모르고 지나가는 쪽보다 낫습니다. 미달을 실패로만 다루면 팀은 닿을 것이 확실한 숫자만 적거나 이 칸을 비워 두는 쪽으로 움직입니다.

자주 헷갈리는 용어

용어무엇을 판정하는가성공 기준과의 차이
인수 조건이 작업이 끝났는지만들기로 한 동작이 다 되는지를 출시 전에 확인합니다. 성공 기준은 출시 뒤에 무엇이 달라졌는지를 재기 때문에, 인수 조건을 다 채워도 성공 기준에는 못 미칠 수 있습니다

같이 보면 좋은 페이지

  • PRD

    성공 기준이 문서의 다섯 칸 가운데 어디에 놓이는지 봅니다

  • 기능 요구사항

    같은 문서에서 무엇을 만들지를 맡는 칸을 봅니다

  • 성공 계획

    같은 말을 고객사 단위로 쓰는 쪽을 봅니다

마지막 업데이트 2026-09-26