회고 개요
ver와 함께했던 첫 팀 프로젝트가 끝나고, 이번 주부터는 Inu와 새로운 프로젝트가 시작됐다. 그동안 해왔던 여러 미션과 비교해보면 이번 프로젝트에는 굵직한 차이점들이 몇 있다.
-
Back-end 팀과의 협업
- 지금까지는 서버와 DB를 혼자서 혹은 FE 팀원과 간이로 구성해왔다.
- 이번에는 처음으로 BE 클래스 두 분과 함께 프로젝트를 진행한다.
-
React 사용
- 지금껏 바닐라 JS로 모든 미션을 진행해왔기 때문에 이번이 첫 라이브러리(프레임워크) 사용이다.
-
CSS-in-JS 첫 적용
- Styled-components 라이브러리를 사용하여 CSS-in-JS 방식을 처음으로 적용했다.
이런 여러 차이점 때문에 프로젝트 기획 자체는 지금까지 해왔던 프로젝트들에 비하면 굉장히 단순하고 쉬웠음에도 개발이 쉽게 이뤄지지 못하고 있다. 오늘 회고는 지난 프로젝트와 달랐던 요소들을 중심으로 어땠는지, 어려운 점이 있었다면 왜 그랬는지, 어떻게 해결했는지를 작성해보려 한다.
1. Back-end 팀과의 협업
공격 수비 구분 없이 온 필드를 뛰어다니던 동네 축구에서 공격수와 수비수 포지션을 나눈 동호회 축구로의 발전. 그런데 이제 패스 전략 고민을 곁들인...
지난 프로젝트에서 먼저 BE 팀과의 협업을 경험한 FE 클래스 팀 중에 BE 팀과 마찰이 발생했던 팀이 있다고 들었다. 요구하는 쪽과 요구사항을 반영해주는 쪽의 견해차 때문이었던 것 같은데 흔히 발생할 수 있는 갈등이라고 생각한다. 그러므로 이번 프로젝트에서 BE 분들을 뵙고 가장 먼저 무리한 요구와 충분히 할 수 있는 요구의 범위에 대해 여쭤보았다. 혹여나 내가 BE의 작업 메커니즘을 잘 몰라서 어려운 것을 너무 쉽게 요구하는 상황이 생기면 본의 아니게 그것이 갈등으로 이어질 수 있다고 생각했기 때문이다. 반대로, 충분히 할 수 있는 요구를 배려라는 명목으로 하지 않으면 더 좋은 서비스를 만들 기회를 놓칠 수 있으므로 미리 그 점에 관해 이야기를 나눈 것이다.
ver와 진행했던 지난 프로젝트에서 느꼈던 것은 BE가 생각하는 적절한 자료구조와 FE가 생각하는 그것이 꽤 차이 날 수 있다는 것이다. 따라서, 서비스를 분석하고 그것을 실현하기 위해 어떤 데이터형식이 적절한지 토의하고 합의하는 과정이 반드시 선행되어야 한다는 것도 지난 프로젝트에서 직접 겪으며 배웠다(Thx ver!). 그러므로 이번에도 그 과정을 먼저 진행했고 정말 감사하게도 BE 팀에서도 다소 개발이 지연되는 것을 감수하고 토의 결과를 담은 API 명세 가 버전을 만들어 주셨다.
그래서 사실 BE 팀과의 협업은 지금까지로는 굉장히 만족스럽다. FE, BE 두 팀 다 굉장히 열린 마음으로 상대 팀의 이야기를 들었고, 일방적인 수용이 아닌 토의를 통해 어떤 것은 FE, 어떤 것은 BE 팀의 의견대로 진행되었다. 분야를 가리지 않고 협업할 때 가장 중요한 것은 의사소통이다. 이번 프로젝트팀은 모두가 배려하면서도 의견을 적극적으로 펼치고, 수용할 수 있는 자세를 갖고 있어서 의사소통이 원활하게 잘 이뤄졌다.
2. Front-end 팀원과의 협업
로마에 가면 로마법을 따르라는데…. 두 나라가 합쳐질 땐 어떤 법을 따라야 하나…?
이번 프로젝트에서 FE 개발을 함께하는 Inu는 같이 프로그래밍할 기회는 없었지만, 종종 코드를 봐왔기 때문에 실력 있는 분인 걸 이미 알고 있었다. 역시 함께해보니 나보다 훨씬 경험도, 지식도 많으셔서 배우는 점이 많았다. 그러나 예상치 못한 곳에서 어려움이 발생했는데, CSS 스타일링하는 방식에 큰 차이가 있었다. 자세한 내용은 실례가 될 수 있으므로 적지 않겠지만, 많은 이야기를 나눠보니 나도, 팀원분도 나름의 이유가 있었다. 보통 프로젝트를 진행하면 마크업과 스타일링을 함께 후다닥 진행한 후 파트를 나눠 JS로 기능을 붙이는 것에 집중하곤 했는데, 이번에는 CSS 스타일링에서 방식의 차이가 있다 보니 진도가 굉장히 더뎠다.
선택지는 두 가지가 있었다. 첫 번째는 그냥 한 사람이 마크업과 스타일링을 혼자서 끝내버리는 것, 두 번째는 방식을 함께 합의하여 통일하고 기존처럼 같이 코드를 작성하는 것. 완성도와 시간 효율을 생각하면 전자가 적절했을 수 있다. 특히, 이번 프로젝트는 구현 요구량이 많지 않기 때문에 현실적인 선택지였다. 그러나 이 프로젝트는 결과물 자체를 만드는데 큰 의의가 있기보단, 현업에서 발생할 수 있는 다양한 상황들을 미리 겪고 해결하는 방법을 익히는 모의고사 같은 것으로 생각한다. 그러므로 이 문제를 전자의 방식으로 피해 가는 것 보단, 의견을 통일한 후 함께 작업하는 것이 적절하다고 판단했다.
이 과정에서 매우 좋았던 점은 우리 둘 다 쉽게 제가 그냥 양보할게요. 팀원님 방식대로 빨리 진행해요~ 하지 않았다는 것이다. 상대방을 배려하는 자세는 굉장히 중요하지만, 그렇다고 논리적인 이유 없이 자신의 주장을 포기하는 것은 팀의 발전에 도움이 되지 않는다고 생각한다. Inu와 나는 각자의 방식과 이유를 설명하고 이번 프로젝트에서 어떻게 적용될 수 있는지 설득했다. 꽤 시간이 걸리긴 했지만, 대화를 거치고 복합적으로 상황을 고려했을 때, Inu의 주장이 일리가 있다고 판단하여 그 방식대로 코드 작성을 시작했다. 그러나 이후, 몇 가지 문제가 있어 다시 내 방식으로 바꾸게 되었다. 최종적으로 선택한 방식이 무엇이든, 이런 과정을 겪은 것은 유익했다. 토의 끝에 내린 결과를 실제로 적용하다가 문제가 발생했을 때 다시 빠르게 방향을 바꾸는 것도 나름 잘한 판단이라고 생각한다.
모든 의사결정에는 Trade-off가 있다. 이번에는 위와 같이 진행했지만, 때에 따라서 마크업이나 CSS가 차지하는 중요도의 비중이 정말 낮은 경우, 긴 토의 시간과 자주 바뀌는 코드 작성 convention은 비효율적이다. 이번 경험은 다음에 비슷한 상황이 발생했을 때, 합리적인 방향을 선택하기 위해 참고할 좋은 사례로 남을 것 같다.
3. 기술
1) React
앞서 적었듯, 나는 리액트가 처음이었다. 처음 사용해본 감상은…. 와! 짱이다.
정말 편했다. 바닐라로 웹페이지를 구현할 때 고민하고 어렵게 구현했던 것들이 리액트에는 이미 구현되어 있고 자동으로 수행해 주었다. state에 render가 종속된 것도 아주 직관적이고 좋았다. 바닐라 미션을 진행할 때는 어떤 구조로 어떻게 짤까? 부터 고민했었는데 리액트는 그런 것을 전부 대신해주니 편하면서도 조금 아쉬운 느낌 ㅎㅎ
첫 주라서 그렇겠지만, 아직 아쉬운 점도 많다. 이번 주는 굉장히 기초적인 useState, useEffect 등을 사용하여 화면을 띄우는 데 급급했고, 최적화는 고려하지 못했다. 또, 데이터를 언제 어디서 얼마큼 fetch 받아와야 하는가도 기준이 명확하지 않아 고민이 많이 됐다.
유용하고 인기 많은 도구인 만큼 그 기능을 최대한 잘 활용하고 싶다. 동시에 너무 의존하지는 않고자 한다. 그냥 알아서 해주나 보다 하지 않고 내부 동작을 잘 이해하고 사용하려 한다. 그래야 언젠가 찾아올 흐름에 변화에 대처할 수 있지 않을까.
2) Styled-components
리액트와 다르게 사용하자마자 편하다는 느낌을 받지 못했다. 오히려 사용법이 익숙하지 않아 계속 굳이? 싶은 생각이 들었다. css를 적용한 컴포넌트를 만들고 className을 toggle하는 방식이 아닌 props도 받아 state에 따른 css 스타일을 정의하는 것이 신기하긴 했지만 편리하게 와닿지는 않았다.
css 속성을 주기 위해 각각의 html tag를 컴포넌트로 잘게 쪼개야 할 것 같은 생각이 들어서 그렇게 했더니 오히려 쓸데없이 코드만 길어지고 가독성도 떨어졌다. 그리고 전역적으로 사용되는 속성이나, scss의 mixin같은 기능도 어떻게 사용할 수 있을지 찾아보았는데 이 부분들에서는 편리하진 않았다.
그래서 수요일 하루는 styled-components를 비롯한 css-in-JS를 왜 많은 사람이 사용하는지를 찾아봤다. 찾아본 결과 여러 장점에 대해 알 수 있었고 대부분은 내가 사용이 익숙지 않아서, 또는 프로젝트의 규모가 너무 작아서 잘 느끼지 못했던 것일 뿐 공감할 수 있었다. CSS-in-JS도 하나의 방법일 뿐이다. npm install 수가 높으니까 사용하는 것이 아니라 장점을 명확히 이해하고 사용하도록 해야겠다.
