[쇼핑몰 프로젝트 1일차] 회원정보수정 페이지 구현과 FE-BE 협업에 대한 고민

고민한 부분

지금껏 빅데이터 관련 프로젝트를 할 땐 보통 데이터로 얻은 정보를 시각화하여 전달하고 도출한 아이디어로 앱 서비스 등을 제안하는 것이 주였기 때문에, 기획-디자인-개발팀으로 나누었어도 프로토타입 수준으로만 구현했었다.

그래서 사실상 개발을 할 줄 아는 인력은 모두가 엉겨 붙어서 안드로이드 스튜디오를 지도 앱이나 필터 기능이 있는 리스트 앱 등을 간단히 구현했었고, 지금처럼 프론트와 백을 나누어서 동시에 개발하는 것은 처음이었다.

처음인 만큼 가장 고민되던 부분은 백엔드와 프론트엔드의 경계가 모호한 부분들이나 우선순위 문제였다.

오늘 같은 경우, 로그인 성공의 여부는 백엔드 DB에서 user id의 대조가 필요한데 아직 구현이 되지 않은 상태였다.

정보수정 페이지를 만들기 위해선 우선 로그인에 성공해야 하지 않나? 그럼 백단에서 로그인 기능을 구현하기 전까지 유저 정보가 담긴 DB를 이용하는 모든 작업(수정이나 탈퇴, 장바구니 등 거의 모든 기능)은 미뤄지는 것인가? 이걸 이렇게 하면 언제 다해? 이렇게 하는 게 아닌 것 같은데

당연히 이렇게 생각하고 개발하면 비효율의 극치로, 시간에 쫓기게 된다.

이런 사고로 완성이 가능한 경우는 아마도 1인 개발자일 때 정도일 것이다.

어딘가 이상한건 알았지만 혼자 고민해봐도 명쾌한 해답은 얻지 못했다.

해결책

다행히도 팀원들과의 미팅에서 직접 의견을 나누고, 오피스아워 시간에 코치님의 조언도 들으면서 사고가 바뀌었고 해결 방법이 보이기 시작했다.

그런데 꼭 로그인 한 상태에서만 회원정보수정 페이지를 만들 수 있는건 아니잖아요? - 한 팀원의 결정적이었던 한 마디

처음엔 멍해져서 ‘뭐지 이 발상의 전환? 그게 어떻게 가능하지?’ 라고 생각했지만 그 말을 시뮬레이션해보니 바로 납득이 되었다.

나는 너무 복잡하게 생각하고 있었다. 여러 명이 분담하여 하는 일은 말 그대로 깃브랜치가 마지막에 병합되는 그림처럼 각자 평행선을 달리다가 모인다. 이걸 머리로는 아는데 익숙지 않아서 적용시킬 생각을 못했다.

로그인을 해야 회원정보수정 기능이 뜬다는 것은 순전히 이용자의 입장이었다!

이젠 개발자의 입장에서 사고해야 한다! 개발자는 로그인 페이지와 회원정보수정 페이지를 동시에 제작할 수 있다.

그리고 아이디어 선정->자료조사->취합->PPT 제작->발표의 단방향적인 순서대로 진행되던 지금까지의 일반적인 팀플과는 다르게, 개발 프로젝트는 애자일 방식으로 중간중간 계속 기능들을 테스트하고 추가, 수정, 삭제하는 것이 유연하게 이루어진다.

일단 만들어본다.

분석 프로젝트를 할 때 기능 구현이 다 안 되었어도, 겉으론 구현이 된 것처럼 앱을 만들었다. 여기서도 마찬가지다. 처음엔 일단 보이는 부분들을 다 만들어보면서 쌓아 올리면 되는 것이었다.

그렇게 생각하니 확실히 보는 관점이 달라졌다.

지금까진 앞으로 개발해야 될 사이트의 요구사항들을 가지런히 정리해서 봤을 때에도 답답하고 막막하게만 생각 했으나, 이젠 어떻게 분리해서 작업하면 효율적일지 요구사항을 뜯어보며 그룹핑하게 되었다.

‘이렇게 하는게 아닌 것 같은데? 이거 기간 내에 끝낼 수 있나?’ 에서 ‘이 페이지를 먼저 만들고 나면 백에 이걸 요청하고, 저 페이지를 먼저 만들 수 있겠는데,’ 같은 생각을 할 수 있었다.

느낀점

앞서 말했듯, 나는 그간 해온 프로젝트들이 단방향 순서를 가지고 있어 중간에 변동이 없고 매 과정을 거의 완벽하게 짚고 넘어갔던 경험들이 쌓여있었다. 거기에 실제로 동작하지 않는 아이디어 상태로 끝마친 프로젝트가 많았기에 구현에 미련이 남아있었고 더 집착한 것 같다. 그래서 로그인 후 정보 수정 후 탈퇴 … 이런 구현을 하나하나 다 제대로 동작하게끔 완성하면서 넘어가야 한다는 사고의 흐름을 가지고 있던 것이다.

지금 생각해보면 민망하다고 생각할 정도로 수 시간 전의 나는 진심으로 그렇게 생각하고 있었다.

결과적으로 백단에서의 기능이 빠진 채여도 프론트에서 최대한 보여지는 부분을 자연스럽게 구현할 수 있고, 이를 나중에 함께 논의하여 조정하면 그만이라는 것을 깨달았다.

완성도를 낮게 해도 된다는 뜻이 아니라, 완벽하려고 집착할 필요는 없다는 마음가짐이 유연한 사고를 하는데에 도움 되는 것 같다.

쓰면 쓸수록 당연한 말이라 민망하지만, 개발자스러운 사고방식을 체화하는건 머리로 알고 있는 것과는 별개의 일이며 역시 직접 해보면서 느껴야 되는 것 같다.

직접 상황 속에서 고민해보고 나서야 개발에서의 분업의 의미를 실감했기 때문이다.

결과

그래서 오늘은 첫날이니만큼 백단을 신경쓰지 않고 새로이 생성한 폴더 내에 회원정보수정 페이지를 되는대로 구현했다. 자잘하게 수정해야 될 부분들이 있지만, 이후 백단에서 주소를 연결해주고 유저 정보를 가져오고 업데이트하는 기능만 추가하면 된다.

프론트단에서 최대한 더 넣을 수 있는 기능이 무엇일지 고민하며 유효성 검사 함수들도 넣어뒀다.

merge request시 설명은 최대한 백엔드 팀원들과 소통이 잘 되도록 쉽게 설명하는 것에 초점을 맞췄다. 아래는 오늘 한 부분들을 머지한 내용이다.