개념 증명

"이거 만들 수 있어요?" 라는 질문에 개발팀이 "해 봐야 압니다" 라고 답하던 시절이 있었습니다. 틀린 말은 아니지만 결정에는 아무 도움이 되지 않습니다. 묻는 쪽은 같은 답을 가능하다는 뜻으로도 어렵다는 뜻으로도 읽을 수 있었습니다.

그래서 판단은 늘 두 갈래 중 하나로 흘렀습니다. 확신이 없으니 아예 손을 대지 않거나, 반대로 일정을 세우고 넉 달을 만들다가 마지막 주에 벽을 만났습니다. 앞쪽은 할 수 있었던 일을 놓친 손실이고, 뒤쪽은 넉 달과 개발자 세 명의 인건비를 쓰고도 남는 것이 없는 손실입니다. "일단 시작해 보고 안 되면 방향을 틀죠" 로 끝난 안건이 반년 뒤 같은 회의에 그대로 다시 올라오는 일이 흔했습니다.

개념 증명은 그 판단을 미리 사 오는 방식입니다. 넉 달을 걸기 전에 2주를 써서 가장 위험한 한 가지만 실제로 돌려 보고, 되는지 안 되는지를 확인한 다음에 나머지 결정을 내립니다. 완성품을 내기 전에 작게 만들어 보는 물건은 네 가지가 있는데, 그중 개념 증명이 맡는 몫은 기술 쪽 불확실성 하나입니다.

확인할 질문 하나를 고르고, 그 질문에만 답하는 최소한의 코드를 정해진 기간 안에 돌려 본 뒤 결과를 판정하는 순서로 진행합니다.

1. 검증할 가정을 한 문장으로 적습니다. "문서 10만 건을 한 번에 검색해 1초 안에 결과를 돌려줄 수 있다" 처럼 참인지 거짓인지 가릴 수 있게 씁니다. "검색을 개선할 수 있다" 는 판정이 안 되니 가정이 아닙니다.
2. 성공과 실패의 선을 숫자로 못 박습니다. 응답이 1초 안에 들어오면 성공, 3초를 넘기면 실패라고 미리 정해 둡니다. 끝난 뒤에 기준을 정하면 애매한 결과가 매번 성공으로 읽힙니다.
3. 기간과 인원을 먼저 고정합니다. 2주에 개발자 한 명처럼 정해 두고, 그 안에 답이 안 나오면 답이 안 나온 것으로 처리합니다. 기간을 열어 두면 개념 증명이 조용히 개발로 바뀝니다.
4. 가장 위험한 한 부분만 만듭니다. 로그인과 화면 디자인, 예외 처리, 권한 관리는 전부 뺍니다. 데이터를 손으로 넣고 결과를 터미널에 찍어도 됩니다.
5. 결과를 판정하고 코드는 버립니다. 남기는 것은 무엇을 어떤 조건에서 확인했는지 적은 한 장짜리 기록입니다.

마지막 단계를 아까워하는 경우가 많습니다. 개념 증명의 산출물은 코드가 아니라 결론입니다. 2주 만에 예외 처리도 없이 쓴 코드를 그대로 제품에 얹으면 기술 부채가 됩니다. 빨리 가려고 미뤄 둔 정리 작업이 쌓여 나중에 이자처럼 시간을 빼앗는 상태입니다.

위험이 기술 쪽에 몰려 있을 때 맞는 방식입니다. 만들면 팔릴지는 대충 알겠는데 애초에 만들 수 있는지가 불확실한 상황, 즉 실현 가능성 리스크가 가장 큰 상황입니다. 처음 쓰는 외부 서비스에 우리 데이터를 맞출 수 있는지, 응답 속도가 계약에서 약속한 수준까지 나오는지 같은 질문이 그렇습니다.

반대로 맞지 않는 자리가 셋 있습니다. 사람들이 쓸지 안 쓸지가 불확실하면 MVP를 내보내야 합니다. 화면 흐름이 이해되는지가 궁금하면 프로토타입을 만들어 보여 주는 쪽이 빠릅니다. 다 만든 기능을 실제 운영에서 검증하려면 고객 몇 곳에만 먼저 여는 파일럿이 그 자리입니다.

한계도 분명합니다. 첫째, 개념 증명의 성공은 기술이 된다는 뜻일 뿐이고 그 기능이 팔린다는 뜻이 아닙니다. 둘째, 작은 규모에서 통한 결과가 실제 규모에서 무너질 수 있습니다. 문서 1만 건에서 0.4초가 나왔다고 100만 건에서 4초가 나오지는 않습니다. 셋째, 만든 사람이 판정까지 하면 결과가 후해집니다. 열 번 돌려 0.8초와 4초가 섞여 나왔는데 평균만 적어 성공으로 넘기는 식입니다. 기준을 적어 둔 사람과 결과를 읽는 사람을 갈라 두면 이 문제가 줄어듭니다.

"이건 PoC 로 2주만 잡고 되는지 보고 결정하죠."

넉 달짜리 일정을 승인하기 전에 기술 위험만 먼저 걷어내자는 제안입니다.

"PoC 는 성공했는데 그 코드를 그대로 올릴 수는 없어요."

확인은 끝났으니 이제 처음부터 제대로 다시 만들어야 한다는 뜻입니다.

"그건 PoC 로 확인할 게 아니라 사용자한테 물어볼 문제예요."

기술이 아니라 수요가 불확실한 질문이니 방법을 잘못 골랐다는 지적입니다.

페이지덱에서 문서 안의 내용을 뜻으로 검색해 주는 기능을 검토할 때 이 말이 나왔습니다. 지현이 "문서 10만 건에서 1초 안에" 라는 선을 적어 오자, 태오가 2주 동안 검색 부분만 떼어 돌려 보고 0.8초라는 숫자를 가져왔습니다. 화면도 로그인도 없이 명령어로 결과를 찍는 수준이었습니다.

그 2주가 결정한 것은 기능을 만들지 말지가 아니라 어느 방식으로 만들지였습니다. 세 방식 중 하나만 기준을 넘겼기 때문입니다. 만약 셋 다 3초를 넘겼다면 그 기능은 이번 분기 계획에서 빠졌을 텐데, 그것도 2주로 산 결론입니다.

실패한 개념 증명을 실패한 일로 여기는 경우가 가장 많습니다. 2주를 썼는데 안 된다는 답이 나왔으니 시간을 버린 것처럼 보입니다. 하지만 안 된다는 답도 사려던 것 그대로입니다. 넉 달을 쓴 뒤에 알게 될 사실을 2주에 알았으니 열네 주를 아낀 셈입니다. 이걸 실패로 처리하는 조직에서는 다음부터 아무도 개념 증명을 제안하지 않고, 대신 확실하지 않은 일에 곧바로 넉 달짜리 일정이 잡힙니다.

성공을 만들어도 좋다는 승인으로 읽는 것도 흔합니다. 증명이라는 말이 붙어 있으니 무언가 입증된 느낌이 들기 때문입니다. 실제로 입증된 것은 기술 한 가지뿐이고, 만들 값어치가 있는지는 손도 대지 않은 질문입니다. 이 둘을 섞으면 기술적으로는 훌륭하게 돌아가는데 쓰는 사람이 없는 기능이 완성됩니다.