나는 한 달간의 팀 프로젝트를 하면서 가장 중요한 것은 일단 뒤쳐지지 않는 것이라고 생각했다. 일단 같이 팀을 해서 프로젝트를 만든다고 하면, 당연히 못하는 사람보다는 코딩을 잘 하는 사람이랑 하고싶지 않은가? 하지만 프로젝트를 마치고 나니, 코딩 실력 또한 중요한 것은 맞지만 가장 중요한 것은 커뮤니케이션이라는 것을 깨달았다.
커뮤니케이션 이슈
#1) 백엔드와 프론트가 하는 일이 무엇인지 잘 몰랐을 때 일어났던 일
내게 주어졌던 일 중에 하나가 로드맵 수행페이지를 만드는 거였는데, 로드맵 수행페이지는 사용자가 로드맵을 생성했을 때 그 데이터를 불러와서 수행할 수 있게끔(로드맵 수정불가/ 상세내용 창 띄우기) 만드는 거였다.
일이 주어졌을 당시 로드맵을 저장하는 기능이 구현이 되지 않았어서, 로드맵 더미 데이터를 만들고 수행페이지를 만들라고 하시길래 나는 당연히 UI만 대강 구현하라는 줄 알았다. 그래서 하루면 끝낼 수 있겠구나! 라고 생각하고 천천히 하려고 했었는데, 팀장님이 일을 주실 때 생각했던 부분은 로드맵이 생성되었다는 가정 하에(이걸 더미데이터로 만들라는 거였다) 로드맵 수정이 되지 않고, 로드맵 노드를 눌렀을 때 상세내용 창을 띄우는 기능을 원하셨던 거였다.
일단 여기서 조금 엇갈렸다. 팀장님은 내게 세세한 부분을 전달하지 않았고, 나는 그대로 받아들인 것이다. 내가 한 번 더 확인차 물어봤거나, 팀장님이 내가 모르는 부분을 캐치하고 설명을 잘 해줬다면 일어나지 않았을 일이다. 하지만 우리는 서로를 잘 몰랐고, 팀장님은 내가 어느정도의 지식을 가지고 있으며 어떻게 설명을 해줘야한다는 점을 몰랐다. 그리고 한 번의 문제가 더 생겼다.
우리는 항상 오후 10시가 되면 본인이 했던 일을 티켓으로 정리해서 브리핑하는 시간을 가지는데, 나는 로드맵 수행페이지 UI를 구현했다는 말을 했다. 그랬더니 팀장님이 그것만 하는게 아니고 로드맵을 불러와서 넣는 부분까지 있어야하며, 상세내용 페이지 모달이나 그런 부분들도 있어야한다고 말씀해주셨다.
일단 내가 생각했던 내용과는 너무 달라서 당황스러웠다. 그래서 되물었다. "네?? 그거까지 제가 다 하는 거예요? 저장해서 불러오는 것까지?" 라고 물었더니 당연하다는 듯한 답변이 돌아왔다. 그걸 어떻게 하냐고 물으니 그건 내가 찾아봐야하는 영역이라고 하셨다.
로드맵을 저장해서 불러오는 건 사실 상 백엔드가 하는 일이다. 그래서 실제로 나한테 저장하고 불러오는 기능을 구현하라고 한 것은 아닐테고, 나중에 그런 기능이 구현된 것을 가정한 채로 얘기를 하신 것 같다. 그런데 나는 그걸 그대로 받아들였고, 어떻게 로드맵을 저장해서 불러오지?? 그것도 프론트가 하는 일인가? 그러니까 시키시는 거겠지? 라고 생각했다.
나는 프로젝트 초반에 백엔드가 하는 일이 뭔지 정확하게 몰랐다. 그래서 에디터에 save와 restore 기능을 추가해서 에디터에서 save를 누르면 로드맵 수행페이지가 로드될 때 restore되게끔 만들었다. 그렇게 며칠 동안 저장하고 불러오는 기능을 만들었고, 에디터 페이지와는 다르게 노드를 움직이거나 수정할 수 없게끔 만들었다.
내가 수정하는 부분은 로드맵 수행페이지였고, 다른 프론트분이 하시던 부분은 로드맵 에디터 쪽이였다. 그래서 나는 원래 로드맵 에디터를 건드릴 일이 없었으나, 세이브&로드 기능을 만들어야한다고 생각해서 에디터 쪽에 그런 버튼을 추가했던 건데 나중에 다 만들고 나니 왜 에디터 쪽을 건드렸냐는 말이 나왔다. 그래서 에디터를 담당하시던 프론트 분과 얘기를 했는데, 세이브 로드는 프론트에서 하는 게 아니고 백엔드에서 하는 것이라는 말씀을 해주셔서 그때 처음 알았다.. 내가 했던 세이브 로드 기능은 로드맵 수행페이지에서는 필요가 없었던 것이다(나중에 에디터 페이지에서는 그대로 사용하긴 했다).
그래서 그 분이 팀장님한테 내가 이러이러한 오해를 했다고 전달해주셨고, 나는 원래 내게 주어졌던 일이 그것이 아님을 깨달으면서 일단락되었다.
시간 제한이 있던 프로젝트에서 며칠 동안 그것만 붙잡고 있었던 게 시간이 너무 아까웠다. 내가 조금 더 정확하게 물어봤더라면, 내가 정확히 어떤 부분을 구현해야하는지 알 수 있었을 것이고 시간을 단축할 수 있었을 것이다. 그래서 나는 그 이후부터는 나에게 주어진 일이 이것이며, 이 부분만 구현하면 되는 건가요? 라고 되묻는 습관이 생겼다. 이로 인해 좀 더 정확하게 할 일을 파악할 수 있었다.
팀장님 또한 설명이 부족했다는 걸 인지하셔서 그 다음부터는 조금 더 세세하게 설명을 해주셨으며, 모르는 부분이 있거나 이해가 안되면 꼭 물어보라고 하셨었다.
#2) UI 적용 이슈
프로젝트가 거의 끝나갈 때쯤, 전체적인 기능은 마무리가 되었고 뒤로 미뤄놓았던 UI를 개선하는 작업만이 남아있었다. 내가 생각했던 건 원래의 UI를 좀 더 발전시킨 velog같은 형태였는데, 다른 프론트 분은 생각이 좀 다르셨다. 핀터레스트 같은 UI 형태를 원하셨던 것이다.
나는 아무리 생각해도 로드맵 사이트에 핀터레스트 같은 grid layout을 사용하게 되면 너무 난잡할 것 같다는 생각이 들어서 말씀드렸지만, 팀원 분은 그러한 형태여야 한다고 강하게 주장하셨다.
여기서 나는 괜히 논쟁하고 싶지도 않고, 내 생각이 틀릴 수도 있기 때문에 일단은 핀터레스트 같은 UI로 만들었다. 그런데 문제는 단순 CSS로만 적용하니까 페이지가 infinite scroll로 인해 로드될 때마다 페이지가 계속 새로고침되면서 올라가는 것이었다.
위와 같은 UI다. 계속 페이지가 새로고침되면서 올라가니까 보기도 안 좋고, 내 예상대로 너무 지저분해보였다. 라이브러리를 사용하면 해결되는 문제였지만 라이브러리를 파고 들기에는 시간이 너무 부족했기 때문에 CSS로만 적용한 거였다.. 그리고 저런 사진만 들어있는 게 아니고 우리 로드맵 사이트는 밑에 제목과 텍스트도 함께 포함되어 있는데, 그게 자꾸 짤리는 문제가 발생해서 그걸 해결을 못했었다.
여러 문제들도 있었고, 일단은 보기 좋은 UI가 아니라는 점에서 기각되었다. 애초에 나는 거의 대부분의 UI를 내가 만들기는 했지만 나는 UI 전담이 아니었고(내 의견대로 한 것이 아닌 모든 팀원의 의견을 반영했다), 그래서 다른 프론트 분이 핀터레스트 UI처럼 만들라고 했을 때도 나머지 팀원분들과 협의가 되었거나 동의했기 때문에 그렇게 만들라고 한 줄 알았다. 근데 만들어놓고 보니 다른 분들도 이런 건 원하지 않았다고 (...)
그 프론트 분도 이런 걸 원하는 거 아닌가? 라고 생각해서 이런 의견을 내셨다고 한다. 나도 그렇고 다른 프론트 분도 그렇고 결국 의견은 묻지 않은 채로 추측만한 것... 결국 바쁜데 시간만 낭비하게 된 셈이다. 어차피 나는 UI 전담이 아니니 다른 팀원들에게 한 번만 물어봤더라면 이런 고생은 하지 않았을 텐데.. 라는 생각이 들었다. 열심히 만들었는데 아예 갈아엎게 되니까 하기가 싫어졌었다.
그래서 앞으로는 나의 의견만이 아닌 다른 사람의 의견도 반영해야 할 때는 무조건 나 혼자(또는 소수의 사람과)는 실행하지 말아야겠다는 생각이 들었다.
배운 점 두 줄 요약!
- 내가 이해한 것이 맞는지 되묻거나 이해되지 않는 부분이 있다면 상세히 물어볼 것.
- 다수의 의견이 포함되어야 하는 안건에는 절대 소수끼리만 협의해서 채택하지 말 것! 모두의 의견을 물어보자.
