Naweke - 1차 프로젝트 중간 회고

요즘 "나이키 홈페이지"를 클론하는 팀 프로젝트를 진행하고 있다.

단순히 홈페이지의 기능을 베끼는 프로젝트라기 보다는 특정 웹 서비스를 모티브로, 우리 팀이 재해석, 기획하여 제작하는 프로젝트이다.

 

이번 첫 스프린트 중 부족했던 점, 느낀 점, 배울 점들을 기록한다.

 

1. 결국엔 비즈니스, 사용자 우선 관점이 중요하다.

- 우리 팀은 2주간의 스프린트 동안 결제 모듈을 붙여서 실제 결제 기능까지 넣는 작업까지 진행하는 것은 무리라고 판단했다. 그래서 상품을 구매하는 과정은 "장바구니 담기" -> "결제 및 배송 완료"로 단순화 시켰다. 하지만 여기서 부족한 점이 있었고 멘토님께 지적을 받았다.

 

고객이 구매를 원하는 상품을 "장바구니에 담게 하는 것"은 고객 경험에 허들로 작용했다는 것

 

보통 장바구니에 담기는 상품은 "여러개의 상품을 바로 구매하가 위해서" 또는 "구매를 고려하기 위해서" 이다.

그런데, 우리는 장바구니에 1)"원하는 상품만 주문"하는 기능을 제외하고, 2)주문을 원하지 않는 상품은 "장바구니에서 삭제"하도록 구현했다.

또한 상품의 상세페이지에서 3)바로구매 하기 기능의 구현 필요성도 논의했었지만 기능 구현 내용이 기존 작업과 크게 다르지 않았기 때문에 학습에 크게 도움이 되지 않을 것 같아서 결국 제외했다.

 

우리가 내렸던 세 가지 선택은 결국 고객의 구매 경험에 허들을 만들었다.

 

첫 번째 문제는, 일단 고객이 상품을 구매하려면 '무조건' 상품을 장바구니에 담아야 하고, 장바구니에서만 주문이 가능했다. 여러개의 상품을 구매하는 고객은 고려했지만 하나의 상품을 바로 구매하고 싶은 고객은 놓칠 수 있는 구조였다. 물론, 여러개의 상품을 구매하는 고객도 결국엔 고려하지 못한 것이 되었지만.

고객은 항상 합리적인 소비를 하지 않는다. 때에 따라 기분에 이끌려 구매를 하기도 한다. '지금 바로' 관심 상품을 구매하려는 고객의 입장에서 이런 구조는 "아니 내가 돈을 써주겠다는데, 왜이렇게 귀찮게 물건을 사게 만들었어?"라고 생각할 수도 있고, 여기서 발생한 불편으로 고객은 더욱 편리한 서비스로 이탈할 수도 있다. 상세페이지에서 '바로 구매'기능을 만들었다면 하나의 상품만을 구매하고자 하는 고객이 조금 더 편리한 구매경험을 제공할 수 있었다.

 

두 번째 문제는, 첫 번째 문제와 이어지는데 결국 고객이 주문(Orders)하는 행위는 장바구니에 담는 행위(Carts)와 같았다. 즉, 우리가 만든 주문 시스템은, 고객이 구매를 원하는 상품을 두 번 주문하게 하는 구조였다. 장바구니에는 구매를 고려하는 상품들도 담을 수 있어야 하지만 그 기능을 뺐기 때문에, 장바구니에 담는 행위는 고객에게 "구매할 상품만을 넣어야 한다"는 의미가 되고 이것은 결국 "주문한다"와 같은 말이다. 

여러개의 상품을 구매하려는 고객은 내가 지금 당장 구매를 하지 않는 상품은 장바구니에서 삭제해야했다. 위에서 말했듯, 장바구니에는 바로 구매할 상품 뿐만 아니라 구매를 고려 및 유보한 상품들도 존재한다. 장바구니에 구매를 원하는 상품을 올려놓고 월급날만을 기다리는 직장인, 용돈을 모아서 원하는 상품을 구매하고자 장바구니에 넣어놓는 청소년들 등등 이런 고객이라면 장바구니의 불편함으로 우리 서비스를 충분히 이탈할 수 있다.

또한 한 번에 여러개를 구매하는 고객에게 엄청난 불편함을 줄 수 있다. 이렇게 되면 장바구니는 '구매할 상품만을 담아야'하기 때문에 고객은 상품을 장바구니에 넣을때 꽤나 '심사숙고'해야 한다. 구매하지 않을 상품은 어차피 장바구니에서 '삭제'해야만 하기 때문이다. 극단적으로 생각해보면 우리 서비스에서 상품을 100가지를 구매하려고 하는 고객이 있다고 하자. 서비스 입장에서 대박 고객이다. 그런데 이 대박고객은 100가지 상품을 구매하기 위해 장바구니에 해당 상품을 담는 심사숙고를 100번 해야한다. 이 한 문장을 적으면서도 실소가 나왔다. 어쨌든 말이 안되는 상황인 것이다.

 

세 번째 문제는, 능력의 한계를 미리 정하고 그 안에서 서비스 구현 정도를 타협한 것이었다. "우리가 배운 것을 적용한다"는 관점은 훌륭한 관점이다. 하지만 우리가 배운 것은 단순히 "코드를 작성하는 스킬"만 있는 것이 아니라, "문제 해결 마인드"도 있다. 우리는 배운 모든 것을 적용하기 보다, "배운 스킬"만을 적용하려고 했다.

짧은 스프린트 기간, 아직은 여러모로 부족한 우리들의 역량(코드, 문제해결, 비즈니스적 접근 등등)을 핑계로 적당한 수준으로 타협한 것이 잘못된 기획을 만들었다. 충분한 기획보다는 얼른 우리가 배운 API 작성 스킬, 웹 페이지 동적 기능 등등 스킬들을 적용해보는 것이 중요하고 그것이 중요한 경험이라고 생각했다.

 

하지만, 기술적, 역량적 한계는 멘토에게 도움을 요청하면 될 일이었다. 그러라고 그 분들이 계신거니까. 우리가 프로젝트에서 집중해야 했던 것은 결국 '개발자적 사고'였다. 웹 개발, 프로그래밍의 본질은 코드를 뱉어내는 것이 아니다. 그것은 수단에 불과하다. 본질은 WHY이다. 왜 그 코드가 필요하게 된 것인가, 무엇을 만들려고 했던 것인가, 꼭 무언가를 만들어야만 하는 것인가, 그렇다면 어떻게 효율적으로 만들어 낼 것인가 등 다각도에서 해당 문제를 바라보고 적절한 방법을 선택하는 것. 그것이 개발자처럼 사고하는 것이 아닐까라는 생각이 들었다.

 

덧붙여... 이제 나는 곧 취준을 해야하기 때문에 취준생의 입장에서도 생각해볼 수 밖에 없다.

우리가 진행한 프로젝트 사례가 만약 포트폴리오로 쓰이게 된다면, 이 프로젝트를 어떤 프로젝트로 보여주고 싶은가.

당연히, 뛰어난 기술적 역량과 멋진 기획 역량이 드러나면 좋겠지만 이번 프로젝트는 둘 다 없다.

물론 겨우 두 달 개발하고 멋진 결과물을 기대할 수는 없지만, 적어도 내가 보여줄 수 있었던 최선은 '본질을 알고 지키는 것'이 아니었을까 싶다. 설령 본질을 유지하는 과정에서 어려움이 있더라도 그것을 극복하고자 했던 어떤 노력을 했고, 왜 그런 노력을 했는지 등등.. 이것이 개발자가 갖춰야할 문제해결적 관점이니까.