🧑🏻‍💻 Intern Review

F&F는 Discovery, MLB 브랜드를 보유한 패션기업이다.
디자이너로 일할때 F&F 최종면접에서 탈락했던 좋지 않은 기억이 있지만, 개발자로 인턴을 할 수 있게되어 감개무량한 기분이 들었다. 나는 F&F에서 디지털 트랜스포메이션을 주도하는 프로세스팀의 프론트엔드 개발자로 인턴십을 진행했다.

첫인상

패션 회사의 사무실은 시끌벅적하고 자유로운 분위기라고 자주 듣곤했다. 하지만 내가 생각했던 분위기와는 정반대였다. 처음 사무실에 들어서는 순간 너무 조용하고 서로 할 말만 하는 조곤조곤한 분위기였다.

원래 개발팀은 이렇게 조용하고 각자 할일만 하는건가..? 당황스럽기도 했지만 하루만에 적응완료! 오히려 좋아! 오히려 집중이 잘되고 업무에 가속이 붙어 프로젝트를 보다 수월하게 진행할 수 있었다.

배운점

✔️ 회사를 선택하는 기준

이전에는 어느 회사에 지원할지, 어떤 회사가 개발자로서 좋을지에 대해 명확한 기준이 명확하지 않았다. 하지만 F&F 인턴십을 통해 나름의 기준을 만들었고, 회사를 보는 시야를 갖게되었다.

✔️ 수평적인 소통 및 업무

팀원들의 대화를 처음 들었때 큰 충격을 받았다. 기본적으로 서로를 존중하는 태도와 수평적인 소통을 통해 업무를 진행하고 있었기 때문인데, 보수적이고 군대문화의 회사를 다녔던 나에게는 말도 안되는 모습이었다. 특히, 최소 과정급으로 보이는 직원이 20대 직원에게 친절한 자세와 존댓말로 소통을 이어나가는 모습은 아직도 기억에 남는다.

처음에는 어색했지만, 지금은 개발문화에 한층 가까워졌다고 느낀다. 리더는 방향성과 비전을 제시하고 멤버들의 탁월한 성과를 끌어올릴 수 있게 도와주는 역할을 해야한다. 팀원들은 서로를 그리고 리더를 신뢰하며 각자의 생각과 관점을 공유하며 그 과정에서 충돌을 만난다면 적극적으로 대화하며 해결해야한다.

수평적인 소통을 바탕으로 업무가 진행되는 문화는 모든 개발팀의 선택이아닌 필수라고 생각한다.

✔️ 자유와 책임

나는 자유와 책임에 대해서는 나름 오랜 시간동안 경험했고 익숙하다.
이전 직장에서 팀리더를 겸하며 보수적인 분위기를 자유로운 분위기로 이끌어내며 좋은 결과물을 이끌어냈다. 이 과정에서 소위 고인물이라고 불리는 윗급 직원들의 정치질과 뒷얘기로 고난을 겪었지만, 좋은 성장의 밑거름이 되었다.

F&F에서는 이런 힘든 일 따위 아무도 겪을 필요 없었다. 먼저 출퇴근 시간이 매우 자유로웠다. 또한 서로에게 피해가 가지 않는 적당한 선에서 각자 휴식을 취하거나 퇴근을 하고 있었다. 물론 자유는 큰 책임이 따르듯 각자 맡은 업무는 완벽하게 소화해야 했다.

자유는 직원들의 건강한 책임감을 자연스럽게 습득할 수 있게 만들어주는 동시에 개인의 최대한의 역량을 이끌어내며 훌륭한 결과물을 이끌어낼 수 있다고 생각한다.

✔️ 코드 리뷰와 성장 가능성

F&F에서 유일하게 아쉬웠던 점은 코드리뷰의 부재였다. 내가 인턴십을 하며 바랬던 점은 코드 리뷰와 개발 문화를 직접 경험함이 었는데, 우리를 도와주는 사수도 없었고 팀장님은 중간에 프로젝트 가이드만 해주셨을뿐이다. 그렇다고 팀장님이 일부러 우리를 놓은건 당연히 아니었고, 너무나도 바쁜 스케줄 때문에 마주할 시간이 많지 않았다.

모든 회사가 코드리뷰를 하는 것은 아니다. 당장 업무에 투입되어야 하는 회사가 더 많은 상황이고, 당연히 회사는 배우는 곳이 아니라 '프로'들이 모여 이익을 창출하는 곳이기 때문에 불만을 갖는것 자체가 모순이다.

하지만 나의 소소한 바램은 내가 작성한 코드에 대한 리뷰를 받으며 서로간의 긍정적인 영향을 주고받으며 성장하고 싶다.

🧢 Project Overview

---

Link

✔️ 구현영상
✔️ Github
✔️ Figma
✔️ Style Guide
✔️ Schedule

---

작업 기간

2022.01.24 - 2022.02.25

인원

프론트엔드 4명 | 백엔드 3명

기술 스택

Used DevTools
JavaScript(ES6) | React.js | Styled-component | Recoil

Collabo Tools
Git&Github | Slack | Trello

Libraries
MUI | Rechart.js

Code Formatter
eslint | prettie

주요 구현사항

카테고리 파트의 마켓 검색량 페이지, 스타일랭킹 파트의 검색 필터 페이지 담당

• Recoil을 사용해 전역 상태 관리를 경험하고, 버튼 클릭 시 API 호출 및 데이터에 맞는 차트와 테이블을 구현했습니다.
• 영문 데이터 키값을 한글로 가공하여 각기 다른 차트 및 테이블에 적용했습니다.

Button, PageTitle 공통 컴포넌트 구현

• 받아오는 데이터에 따라 페이지의 Title이 무분별하게 반복되는 것을 발견하여, Title 공통 컴포넌트를 구현했습니다.
• 현업에서도 예상하지 못한 재사용이 가능한 파트가 있으면 빠르게 공유하고 효율적인 해결책을 제시해야겠다는 생각을 했습니다.

재사용 컴포넌트 관리의 중요성 경험

• 작은 단위의 컴포넌트부터 bottom-up 방식으로 개발하였으며, 컴포넌트를 조합하여 재사용성을 높였습니다.
• Button 공통 컴포넌트를 구현했지만, 각자 다른 컬러와 props를 사용하고 props를 다양하게 받다보니 관리 측면에서 어려웠습니다.
• 모든 컴포넌트를 재사용할 수 없다는 것을 배웠고, 적절한 재사용에 관한 고민과 설계의 중요성을 느꼈습니다.

Recharts(LineChart, ComposedChart, PieChart) & Material-ui(Table) 시각화 라이브러리 활용

• 현업에서 자주 사용되고, 공식 문서 및 커스텀 관련 자료가 많아 Recharts와 MUI를 선택했습니다.

스타일 가이드 공유 및 일관성있는 프로젝트 방향 제안 (자세한 내용 보러가기)

• 직관적인 레이아웃과 컬러 및 폰트 등 스타일 가이드를 제안해 통일된 디자인을 유지했습니다.

구현 결과

카테고리 파트의 검색 데이터 페이지 입니다. 데이터 키값을 가공 및 적용하여 각기 다른 차트 및 테이블을 구현했습니다.

스타일 랭킹 파트의 조건부 검색 필터 페이지 입니다. 오른쪽의 조건부 필터 페이지를 맡았습니다. 버튼 클릭 시 조건에 맞는 API호출 및 데이터에 맞는 차트 및 테이블을 구현했습니다.

🧢 Project review

배운점

✔️ 컴포넌트 재사용에 대한 고민과 경험

프로젝트 중반쯤 불편함을 느끼기 시작했다. 페이지를 구현하기전에 만들어놓은 버튼 컴포넌트가 가지각색으로 사용되고 있었기 때문이다. 재사용 컴포넌트를 만드는 이유가 코드의 편리성과 일관성있는 프로젝트의 진행을 위함 아닌가? 라는 의문과 불편함을 느끼기 시작했다.

팀원들과의 수차례 미팅을 하며 내가 느낀 불편함을 공유했지만, 결국 해결되지 못했다. 시간이 갈수록 각자의 스타일에 맞게 컴포넌트가 변형되었다. 버튼 컴포넌트를 다같이 신나게 재사용하다 보니 페이지마다 다른 색상과 다른 props를 사용해야 했고, props를 너무 다양하게 받아오게 되어 관리측면에서 어려움을 느꼈다. 결론적으로 모든곳에서 사용 가능한 컴포넌트를 만들었지만 관리에 실패한것이다.

리액트는 재사용성을 중요하게 강조하지만, 모든 컴포넌트를 재사용 가능하게 만들수는 없을 것이고 그렇게 하면 안된다고 생각이 들었다. 이유는 간단한데, 관리가 힘들어지기 때문이다. 프로젝트의 규모가 커지다 보면 재사용 가능한 컴포넌트를 많이 사용하게 될텐데, 많이 사용할 수록 유지보수가 힘들어서 적당하게 맞는 부분만 사용할 수 있도록 해야된다고 느꼈다.

이러한 시행착오를 통해 재사용성에 대해 더 고민해보고, React에서 재사용을 위한 기술에 대해 추가 학습을 하며 최선의 방법을 찾아봐야겠다는 생각이 들었다.

칭찬해 주고 싶은 점

✔️ 의견차이를 해결하는 태도

스타일랭킹 페이지의 필터 페이지를 구현하는 과정에서 데이터 조회 시 전체 및 매장 별 데이터를 따로 받아야 했다. 하지만 회사로부터 전달받은 데이터가 이미 틀이 잡혀 정리가 되어있고 양이 많아 수정하기에 다소 복잡하다고 판단된다는 백엔드 팀원의 의견이 있었다.

문제를 해결하기 위해 의견이 부딪히는 상황에서 Mock Data를 활용한 시연영상을 보여주고, 그림을 그리며 더 쉽게 이해할 수 있게 설득했다. 반대로 백엔드에서 구축한 구조를 어떻게 활용할 수 있을지, 수정을 한다면 어느정도의 범위를 얼만큼의 시간이 소요될지에 대해서 설명을 듣기도 했다. 수차례의 토론과 팀장님의 가이드를 통해 데이터의 절반만 편리한 형태의 구조로 수정하기로 결정되었고, 덕분에 마감 기한보다 빠르게 결과물을 완성할 수 있었다.

프로젝트 기간동안 사소한 문제일지라도 분명 서로간의 언쟁이 높아질뻔한 경우가 몇번 있었다. 하지만 이럴때일수록 나의 태도를 돌아보며 상대방을 너무 몰아가는것이 아닌지, 혹은 과한 감정표현으로 마음을 상하게 하는 것이 아닌지 스스로 경계했다. 더불어 의견이 부딪히더라도 최대한 부드럽고 유연한 스탠스로 잘 좁혀나가려 노력했다.