4. IT 서비스의 Product Lifecycle
서비스를 만들기 위한 무한의 굴레, 탑승하시겠어요?
우리는 일상 속에서 수많은 IT 서비스를 사용하고 있습니다. 가만 생각해보면 참 신기합니다. 이런 서비스는 도대체 어떻게 만들어지는 걸까요?
'IT 서비스는 코딩으로 만드는 거 아냐?'로 알고 계신 분들을 위해, 실제로 IT 서비스가 만들어지는 과정, IT product의 lifecycle에 대해 알려드리고자 합니다.
IT 서비스가 만들어지는 과정은 크게 초기 기획 - 상세 설계 - 화면 디자인 - 개발 - 테스트(QA) - 배포 및 운영의 6단계로 나눌 수 있습니다.
실제로 각 과정에서 어떤 일이 일어나는지 더 쉽게 이해하기 위해, 맛집 서비스를 만드는 상황을 예시로 들어 함께 설명하고자 합니다.
1. 초기 기획
IT 서비스를 만들기 위해서는, 가장 먼저 어떤 서비스를 만들 것인지 결정해야 합니다.
지금 사람들이 불편하게 생각하고 있는 부분은 무엇인지, 이 불편함을 내가 어떻게 해결해줄 수 있는지 조사하고 분석합니다. 그리고 정말 ‘어떤 서비스를 만들 것인가’에 대해 전체적인 기획을 진행합니다. 물론 해당 시장이 충분히 큰지, 만들려는 서비스가 사업적으로 경쟁력있는지도 함께 확인해야 합니다.
맛집 탐색 서비스를 만들고자 하는 경우, 사람들이 기존의 맛집 탐색 서비스에서 어떤 니즈(needs)를 가지고 있는지 찾아내야 합니다.
기존 사용자를 인터뷰하고 여러 지표를 확인하여 ‘맛집의 별점이나 후기를 믿기 어렵다.’, ‘주변 사람들과 나의 맛집 정보를 더 편하게 공유하고 싶다.’의 두 가지 니즈를 발견하였습니다. 이러한 데이터를 통해 ‘맛집 정보 기록 기능과 지도 공유 기능에 집중한 맛집 서비스’를 만들기로 결정합니다.
이 단계는 주로 기획 직무, 특히 사업 기획과 서비스 기획 직무가 함께 진행하는 경우가 많습니다.
2. 상세 설계
어떤 서비스를 만들지 결정했다면, 그 서비스의 세부 사항들을 설계해야 합니다.
이 단계에서 만드는 서비스의 세부적인 사항까지 모두 결정되어야 합니다.
맛집 탐색 서비스의 ‘상세 설계’를 한다고 생각해봅시다. 이 단계에서 사용자가 서비스에 처음 진입했을 때 어떤 화면을 보여줄 것인지부터 로그인 버튼을 눌렀을 때 비밀번호가 틀렸다면 어떤 문구를 노출해줘야 하는지, 지도는 직접 만들어서 제공할지, 네이버 지도나 구글 지도를 가져와서 사용할지 등등 수많은 사항을 고민하고 결정해야 합니다.
그렇기 때문에, 이 단계에 많은 직무의 사람들이 참여하게 됩니다. 주 담당자는 기획자이지만, 기획자는 지속적으로 개발자와 이야기하며 실제로 만들 수 있는 방식으로 설계가 진행되어야 합니다. 또한, 디자이너와 이야기하며 서비스에 적합한 화면 구조를 만들어야 합니다.
3. 디자인
IT 서비스의 상세 설계까지 완료되었다면, 다음으로는 디자인이 이루어집니다.
세부 사항까지 잘 정리된 상세 설계 문서를 바탕으로, 서비스가 사용자에게 보여지는 외부적인 모습을 디자인합니다. 서비스 배경에는 어떤 색을 적용할지, 검색창의 너비는 얼마나 넓어야 하는지, 맛집 검색 결과를 보여줄 때, 어떤 구조로 정보를 배치해야 더 정보 가시성이 높아지게 될지 고민하고 결정하게 됩니다.
이 과정 역시 ‘상세 설계’와 마찬가지로 다양한 담당자가 참여하게 됩니다. 주로 디자이너가 업무를 진행하지만, 상세 설계의 요소와 상충되는 부분은 없는지 기획자와 계속 소통해야 하고, 이런 디자인이 실제로 구현이 가능한 지도 개발자와 상의하며 진행되어야 합니다.
4. 개발
IT 서비스의 디자인까지 완료되었다면, 드디어 개발을 시작합니다.
‘서비스가 어떻게 동작해야 하는가’에 대한 세부적인 사항은 상세 설계와 디자인 과정에서 결정되었기 때문에, 개발 과정에서는 ‘이 동작을 어떻게 구현해야 하는가’를 고민하고, 실제로 그 동작이 컴퓨터 위에서 돌아갈 수 있도록 코드를 작성합니다.
’맛집을 검색했을 때, 검색 결과를 네이버 지도에서 가져온 지도 위에 표시해준다.’라고 설계되어있다면, 개발자는 네이버 지도를 어떻게 가져올지, 이렇게 가져온 지도와 우리가 가지고 있는 맛집 정보를 어떻게 연결해서 정확한 위치에 표시해줄 수 있을지 고민하며 서비스를 구현해나갑니다.
개발은 주로 개발자가 담당하지만, 문제가 생기거나 수정이 필요한 경우에는 기획자, 디자이너와 함께 소통하며 해결해나갑니다.
5. 테스트 (QA)
IT 서비스에 대한 모든 개발이 완료되었다고, 바로 세상에 내보낼 수는 없습니다. 개발 완료된 서비스가 실제로 기획했던 것처럼 동작하는지 확인이 필요합니다.
이러한 과정을 QA(Quality Assurance, 품질 관리)라고 합니다.
QA를 통해 개발 중 발생한 버그가 있는지, 또는 상세 설계 과정에서 놓친 케이스가 있는지 테스트하며 서비스 안정성을 높일 수 있습니다. 이때, 테스트는 기본적인 사용 방식은 물론, 매우 특이한 케이스까지 확인하며 문제가 있는 부분이 없는지 확인합니다.
맛집 탐색 서비스에 로그인 후 맛집 후기 글을 남기는 과정에서 누군가가 비밀번호를 바꿔버렸을 때, 어떤 오류 메시지가 나타나게 되는지까지 확인하며 사용자가 서비스를 오류 없이 사용할 수 있도록 검증합니다.
테스트는 주로 QA 담당자가 수행하며, 테스트 과정에서 찾아낸 오류는 기획/디자인/개발에 전달되어 수정 및 개선됩니다.
6. 배포 및 운영
테스트까지 모두 통과한 IT 서비스는 드디어 세상으로 나오게 됩니다.
물론 이렇게 완성된 서비스를 세상에 던져놓는다고 끝이 아닙니다. 많은 사용자가 문제없이 서비스를 사용하기 위해서는, 이렇게 세상에 오픈된 서비스를 계속해서 운영하고 관리해야 합니다.
사용자가 서비스 오류나 불편 사항에 대한 문의를 응대하기도 하고, 이렇게 인입된 문의나 의견을 모아 서비스의 개선 방안을 제안하기도 합니다.
주로 운영자가 담당하지만, 문의 대응이나 개선 제안의 과정에서 기획자와 긴밀하게 협업하는 경우가 많습니다.
IT product lifecycle은 위의 6단계로 이루어져 있습니다. 그리고, 이 과정들이 IT 서비스를 만들고 운영하면서 계속해서 반복됩니다.
IT 서비스는 한 번 만들면 끝이 아닙니다. 초기 기획에서 시작해서 상세 설계, 디자인, 개발, 테스트, 배포까지 완료하고 운영을 하던 도중, 서비스의 부족한 점을 발견할 수 있습니다. 아니, 필연적으로 발견합니다. 기능 개선이 필요하거나, 새로운 기능이 필요하다는 점을 '운영' 단계에서 발견하게 되고, 이는 다시 '초기 기획'으로 이어집니다.
Product lifecycle의 반복은 이러한 단계를 거쳐가는 도중에도 발생할 수 있습니다.
초기 기획에서 시작해서 쭉 cycle을 밟아가던 중, '개발' 도중에 특정 기능이 구현 불가능하다는 사실을 발견한다면 다시 '상세 설계' 단계로 돌아가서 다른 대책을 찾고 설계를 진행해야 합니다.
QA 과정에서 오류가 발견된다면, 다시 개발로 돌아가서 오류를 수정하고 다시 QA로 넘어가야 하죠.
IT 서비스를 만드는 6단계의 과정이 계속해서 순환되기에, 이러한 IT 서비스 생산 구조를 'Lifecycle'이라고 부르는 것입니다.
이러한 product lifecycle을 통해, IT 서비스는 만들어지고 개선될 수 있습니다.
IT 서비스는 6단계의 과정이 지속적으로 순환하며 만들어지고 발전한다는 사실을 알 수 있었습니다. 결국, IT 기획자도 이 lifecycle을 만들어가는 한 사람인 것입니다.
쉴 새 없이 돌아가는 IT product lifecycle 속에서, IT 서비스 기획자는 어떤 스킬을 가져야 할까요? 다음 글에서는 서비스 기획자에게 필요한 스킬에 대해 이야기해보도록 하겠습니다.
