하루를 마무리 하기 전, 오늘 있었던 일들을 잔잔히 되짚어봅니다.
성공과 실패의 모든 요소에서 '배울 점'을 찾아내어 기록하고,
더 성장하는 내일의 나를 위해 'action plan'을 세웁니다.
매주 월요일. 스프린트 회의가 있는 날!!
우선 목표한 태스크들 중에서 구현되지 않은 3개 정도 기능이 있어 약간은 불편한 마음이었지만, 한개는 드롭박스를 사용하지 않고 버튼으로 선회해서 구현했고... 또 하나는 1주차 스프린트부터 끌어오던 마커 이미지 체인지 기능인데 결국 시간을 들여서도 해결되지 않아 어쩔수 없이 남겨둔 것. 마지막 하나는 로그인 기능을 구현하면 더 원활하게 하고자 일부러 남겨둔 것이었다.
이래저래 준비를 하고 노아님이 다른 동료들에게 피드백을 주시는 것을 옆에서 듣고 있었는데, 마침 오늘 코딩의 신 아샬님이 오셔서 동료의 코드를 보시고 일정부분 리팩터링을 해 주시겠다는 소식을 접하게 되었다.
모두에게 자신의 코드가 공개되는 것이 분명 부담스러운 일이야 하겠지만, 그래도 더할나위 없이 좋은 기회일 것 같아 동료에게 좋겠다면서(ㅎㅎ) 너스레를 떨었다.
그리고 등장하신 코딩의 신... 아샬님....!!!!
근 2시간이 넘도록 정말 중요한 말씀들을 쏟아주셨는데 내가 다 흡수하지 못하는게 느껴져서 너무 안타까울 지경이었다.
그럼에도 빠르게 중요한 내용들을 필기했는데 가히 충격에 가깝다고 느껴진 부분이 2개 있었다.
한가지는 내가 궁금했던 부분에 대한 해소. 또 한가지는 명치를 정통으로 씨~게 맞은 듯한 고통. 즉 나의 기저에 있던 무의식을 정통으로 조준하며 말씀하시는 것 같은 내용이었다.
진짜 가치가 맞느냐?
사실, 그 강의의 내용을 모두 이 블로그 글에 담을 수 없고 특강의 무게감을 여기에 다 녹여낼 수 없음이 아쉬울 따름ㅠㅠ.
어쨌든.
동료의 서비스 설계 문서 중에서 '유저 스토리'를 다듬는 과정을 보여주셨다.
여기서 진짜진짜 충격을 받았는데...
나도 모르게 맨 앞자리에 앉아 탄식(;;)을 뱉을 수 밖에 없었다.
As - 운동 팀에 합류하려는 사람
I - 운동 같이 할 사람 구하는 게시물 필터링
So - 시간 아끼려고, 빨리 찾으려고
이 세 문장을 보자마자 이제까지 내가 만든 사용자 가치는 그저 개발에 빨리 돌입하기 위해, 고민의 흔적이라곤 찾아볼 수 없는, 즉 문서를 위한 문서이자 사용자 가치를 적어내기 위한 사용자 가치였음을 뼈저리게 깨달았다.
아샬님이 저 문장을 쓰시자마자 갑자기 정신이 번뜩 들어 조용히 맥북을 가져와 내 문서를 펼쳐보았다.
'사용자' 입장에서 얻을 수 있는 가치란게 이 문서에서는 찾아보기 어려웠다.
내가 적어놓은 사용자 스토리 속에 가치는 정.말.로. 사용자에게 valuable한 것인가? 말이 좀 이상하긴 하지만, 내가 만들어낸 사용자 스토리를 기반으로 만든 서비스를 사용자들이 쓰면서 정말로 '가치롭다'고 느낄 수 있을까?
전혀 그렇게 느껴지지 않았다.
그저 양식에 맞추어 '사용자 가치'라는 걸 써본다고 하여 내 서비스를 통해 사용자가 가치를 얻을 수 있는게 아니다.
사용자 입장에서 정말 질-릴때까지 고민하고 생각해내야 그나마 얻을 수 있는 valuable thing이란게 생길까 말까이다.
이 관점에서 봤을 때 나의 사용자 스토리는 정말 사용자를 위한 것이 아니었음을 깨달았다. 문서를 위한 문서를 만들기 위해 더이상 시간을 써서는 안된다.
REST API와 프론트의 path는 정확히 어떤 점에서 다른걸까?
오늘 개발 설계문서를 수정하다가 탁. 하고 막히는 부분이 있었다.
바로 REST API와 프론트의 URL을 정하는 영역이었다.
사실 마카오 기프트 레벨테스트를 할 때도 궁금했고 마카오뱅크를 할 때도 궁금했고...
지금 생각하니 그걸 왜 질문하지 않았을까? 하는 의문마저 드는 ;;
얼마 전에 읽었던 웹지기 책에서 동사 형태를 사용하지 말라는 가이드를 보고는 아하 그렇구나 했는데, 그래서 동사 형태 말고 뭘 써야 하는건가?! 라는 질문에 스스로 답하지 못했다.
특히 프론트URL과 REST API가 같으면 안되는건가? 아니면 같아야만 하는건가? 왜 지난번 강의들과 예시에서는 달랐던거지? 어떤 점에서 어떻게 다르기에 이렇게 설정된거지? 라는 질문에 단 하나도 답변을 하지 못하면서 미궁속에 빠지게 되었다.
마침 그 때 아샬님이 오신 것이었고 강의를 들으면서 그 부분에 대한 크나큰 해결점을 얻을 수 있었다.
결론적으로 REST API는 리소스 중심으로 구성되어야 한다는 점이다.
아주 아주 중요한 예시로 아래와 같은 두 가지 문장을 비교할 수 있겠다.
UI: 화면에서 게시물 목록을 보여주는 데에는 두 가지 방법이 있음
로직: 게시물 목록
UI는 바뀐다. 언젠간 바뀔 것이며 또 환경이 변화함에 따라 바뀌어야만 할 것이다.
하지만 로직은 변하지 않는다.
그 변하지 않는 로직이자 리소스를 중심으로 REST API를 정해야 한다는 점이다.
이를 통해 점심시간 이후로 계-속 고민하던 REST API에 대한 큰 방향성을 얻게 되었다.
사실 깊이있는 고민을 하지 않는다면 아샬님이 말씀하신 대로 확률 높은 '우연'에 많은 것들이 그저 끌려가버리게 될 것이다.
내가 구현한 많은 코드들이 이미 그렇게 끌려갔을 가능성이 높다.
그럼에도 불구하고 더이상의 삽질을 멈추고 오늘 강의 내용에서 이해한 것을 바탕으로 설계문서를 좀 더 빌드하고, 실제로 사용자가 얻을 수 있는 가치를 질릴만큼(;;) 고민해서 그 가치를 충족시키기 위한 기능을 구현해야 겠다.
참. 쉬는시간에는 노아님을 붙잡고(ㅎㅎ) 지난 스프린트때 구현한 내용을 보여드렸다.
드롭박스가 구현이 안 된 부분을 버튼으로 선회하여 구현한 것이 영 마음에 걸렸는데, 다행히 좋은 피드백을 주셔서 기분이 좋았다.
크리티컬하지 않은 기능이라 마지노선으로 정한 시간을 투입한 뒤에 그 선을 넘어버렸을 때 과감하게 방향을 틀었는데 나쁘지 않았던 선택인 것 같다.
그럼에도 불구하고 회사에서 이랬다면 어땠을까? 라는 찜찜함이 남아있긴 하다.
만약 방법을 선회하여 구현한다면 그에 대한 충분하고 정당한 이유가 있어야 하지 않을까. 기본 중에 기본이다.
어쨌든. 다음 스프린트 때에는 장소 상세정보 페이지쪽을 모두 구현해보려 한다.
오늘 강의를 듣고 나니 더 어렵게만 느껴지는데...
그럼에도 불구하고 객체들의 협력을 잊지 말고, 또 서비스에서 사용자들이 얻어야 할 가치를 중심으로!! 문서 먼저 꽉- 잡고 구현해보자.
화이팅!
시/도 부분을 드롭박스로 구현하고 싶었으나 실패! 버튼으로 선회.. ㅎ.ㅎ
자 어디로 가볼까~ 이제 세부정보 페이지 구현해야지!
