얼떨결에 리더가 되어 버렸던 이야기 - 프로젝트 회고

입사 후 프로젝트에 바로 투입 되었습니다.

 

프로젝트 완수 기간 - 3개월,

현 시점 - 기획 진행 중,프론트엔드 1인

도메인 - 클라이언트, 직원

저를 제외한 플랫폼 개발 협업 처음 (기획 1, 프론트엔드 1, 백엔드 2)

 

그렇기에 이전 회사에서 협업 경험을 가진 2년차 개발자인 제가 리더가 되어 버렸습니다.

 

속으로 외쳤습니다. 이야.. 아찔한데!!

그런데 사실은 어떡하지라는 기분은 들지 않았어요. 인생사 언제 무슨 일이 일어날지 모르는 것 아니겠습니까!!

뇌에 긍정적+100 아이템을 장착

어쩌다 리더가 된김에 이전에 여러 팀들과 소통하며 어깨너머로 보던 것을 적용하기로 했습니다!

이왕이면 공부하여 더 나은 환경을 구축하고 싶었지만 거기에 자원을 쏟기엔 시간 초침소리가 귀를 때렸네요!

 

우선은 기록을 통해 반복적인 업무를 지양하기로 했습니다. 

 

최소한의 툴(Figma, Notion) GIt flow, 개발 버그, 진행 현황, 태스크, API 이슈, 회의록 정책, Swagger 등을 정립 하여 커뮤니케이션을 최대한 효율화 하여 시간 비용을 단축 하였습니다.

 

 

이젠 기획에 관해 정립을 하기로 했습니다.

 

회사 내부 사정 상 기획 분이 들어오시기 전 까진 회사에 도움을 주시는 교수님과 대학원생분이 기획 겸 디자인을 맡고 있었습니다.

회사에 상주하고 있지 않았기에 우선은 모든 권한과 업무를 새로 오신 기획자분께 넘기기를 요청 드렸습니다. 그러지 않으면

소통에 있어서 문제점이 생길것이고, 실시간으로 반영이 되지 않고 요청 후 기다려야하는 비동기적 프로세스가 이루어지기 때문 입니다.

 

1차적인 문제를 해결한후 기획자 겸 디자이너 분께 웹 기획 템플릿(페이지명, 우측 상호작용 명시), 공통 컴포넌트 관리 등을 알려드렸습니다. 기획자분이 이전에 디자이너일을 하다 웹 기획이 처음이셨기에 이렇게 초기엔 했지만 기획자분이 어느정도 구조를 이해하시고 나선 주도적으로 학습하고 적극적인 커뮤니케이션을 통해 코멘트, 공통 컴포넌트 등 협업 시 필요한 부분들을 빠르게 적용해주셨기에

"엇 기획이랑 다른데요" 라는 불상사는 일어나지 않았습니다. 

다만 작은 어려움은 초기에 내가 알려준게 맞나라는 생각에 기획에 관하여 조금이나마 공부를 했었습니다.

 

다음으로 백엔드 분과 얘기를 나눴습니다.

 

백엔드 스택은 django였습니다. 그 이유는 웹 개발전까진 인공지능 연구를 하신 석사분, 신입 개발자분 

두분 모두 python을 다루셨고 django로 crud를 구현하고 orm으로 db를 다룰줄 아셨습니다.

그렇기에 걱정을 하지 않았고 나만 잘하면 되겠다 싶었죠! 하지만 json data 전달 과정에서 문제가 발생하였습니다.

 

1. 클라이언트 도메인, 직원 전용 도메인 중 같은 View를 보여주는 페이지인데 api url과 json 형식이 서로 다르다.

2. 이 후 두 도메인을 총괄하는 도메인이 생길 경우를 대비해 { name : 'shoes', value : 200 } 등 범용적으로 파싱이 되어야하는데
key값 자체가 값으로 사용하는 형식이 많았습니다.

 

이 이슈가 생겨난 이유는

1. 초기에 클라이언트 도메인과, 어드민 도메인을 각각 분담하여 작업을 하신다고 하셔서 "좋습니다!" 라고 얘기를 했었던 나!

2. 프론트엔드에서 받는 Json 포맷 형식을 미리 사전에 정립하지 못한 나!

 

곧바로 회의를 열었고

앞선 이슈의 해결책으로 도메인으로 구분하지 말고 같은 컴포넌트가 많은 View로 업무를 분담, json 구조 통일을 하도록 얘기 하였습니다. 

또한 재작업의 대한 용서를..ㅠ..쿠후후훕 빌었습니다. 그 뒤로는 빨리빨리 Api를 뽑아내주셔서 정말 편했습니다!

그리고 자잘한 트러블등은 본래 프로젝트를 하며 당연 시 겪으며 성장하는 것 아니겠습니까! 넘어가도록 하겠습니다.

 

저 또한 프론트엔드 혼자 개발하면서 고려해야 할 점이 있었습니다.

1. 신규 인력 투입 시 잘 읽혀야 하는 코드여야 한다.

2. 변경에 유연한 컴포넌트여야 한다.

3. 빠르게 개발 해야 한다.

 

 

*신규 인력 투입 시 잘 읽혀야 하는 코드여야 한다.

 

1. 코딩 컨벤션을 지켰습니다. (eslint + prettier)airbnb 코드 스타일을 적용 하였습니다.

2. 매개변수에 event를 받는 함수들은 handle prefix style을 적용 했습니다.

3. 프로젝트 구조를 도메인(estimate, product 등)을 중점으로 구성하였습니다.

그 이유는 도메인으로 의존성을 두고 있어 분리 시 조금 더 용이했고 폴더내에 그 도메인에 해당하는 constants, customHooks 등 한데 모여져있기 때문에 인력 투입 시 맥락 파악이 수월해 보였습니다. 또한 기획 변경이 잦았기 때문에 해당 도메인에만 존재하는 컴포넌트가 공통 컴포넌트로, 또는 공통 컴포넌트가 한 곳에만 쓰이는 컴포넌트가 되는 경우가 되려 있었는데 이럴 경우 단일책임원칙을 지켜 분기처리 보다는 최대한 새로이 만들거나, 추상화와 컴포넌트 합성을 하였고 폴더 구분이 명확했기에 수월했습니다.

자세한 변수, 컴포넌트 view와 비즈니스 로직 분리 - customhook으로 구성, utils 함수, suspense Errorboundary 선언적 설계 등 염두에 두고 개발을 했습니다.

webpack config alias 를 적용하여 딥한 임포트시 (./../../) 상대경로 대신 @로  절대 경로로 설정 하였습니다.

폴더 내 최상위 index에서 최대한 Import가 가능하도록 하였습니다. 

import { Images } from '@common'; //원하는것만 쏘옥 쏘옥

 

*변경에 유연한 컴포넌트여야 한다.

 

 어느 프로젝트든 마찬가지지만 특히 애자일 기법으로 개발하고 있었기에 변경에 유연하게 컴포넌트를 구현해야 했습니다.

우선은 기획이 바뀔 염두를 두어 원자 단위로 컴포넌트를 설계 했습니다. 컴포넌트 구성은 

JBEE님의 https://jbee.io/web/components-should-be-flexible/ - 변경에 유연한 컴포넌트

진유림님의 https://www.youtube.com/watch?v=edWbHp_k_9Y - Frontend Clean Code

 

 

두 분을 글과 영상을 참고하여 컴포넌트의 관심사의 분리,커스텀 훅, 추상화 등 결합도를 낮추고 응집도 올리도록 노력하였습니다.

이로 인해 추가, 변경, 삭제시에 최소한으로 의존영향을 줄일 수 있었습니다. 

(세밀하게 설명된 글과 영상을 통해 조금 더 지식들을 세공하였습니다. 예로 공통 컴포넌트에서 한 컨테이너에서만 특정한 변경이 필요한 경우 애초에 추상화를 잘해놨어야 하고 컴포넌트 합성을 통한 해결 등 분기 처리를 최대한 지양해야 단일책임원칙을 지킬 수 있습니다.)

 

*빠르게 개발 해야한다

 

클라이언트와 직원 도메인을 따로 개발하기엔 페이지 수가 많고 기획이 마무리 되지 않은 시점에서 진행하는 중이라 두 곳에서 같이 쓰이는 컴포넌트가 변경되거나 추가될 시에  두 번의 작업을 하기 싫었습니다. 결국은 한 프로젝트에서 두 개의 도메인을 함께 개발하고 이 후에 분리를 하자 생각했습니다.

 

이 방법에 있어서 고려해야 할 점이 있었습니다.

1. 의존성이 낮은 방식이여야 한다.

2. 두 도메인에 따른 동적인 Router를 구현해야 한다.

 

저는 ENV를 사용했습니다.

그 이유는 script 명령어로 env에 설정된 환경변수로 인해 Router단에서 변수로 활용해 동적인 URL이 가능하기 때문입니다.

또한 두 곳 모두에서 쓰는 컴포넌트 같은 경우에도 환경변수로 분기를 처리를 해줘서 편했습니다. 

이후 분리 시 의존된 곳이 거의 없이 정말 편했습니다.

 

하지만 고려한다해도 완벽하게 될리없었고 먹음직스러워 빨리 먹어치고 싶은 스파게티 코드도 있었고, 초반엔 type에 따른 동적인 table 컴포넌트를 구현하고자 했지만 점점 요구사항에 맞춰 신의 탑처럼 거대해진 코드도 존재했었습니다. 끄흐흡,,

 

그치만 이 과정을 통해 여러모로 정말 많이 배웠습니다.

 

가장 크게 깨달은 점은
개발자란 단순한 코딩능력뿐만 아니라 커뮤니케이션 그리고 비즈니스 관점으로 프로젝트를 바라보는 시각을 필요하다는 것 입니다.

https://www.youtube.com/watch?v=3H4umWD5bwI 

 

이 부분을 몸소 느낀 적이 있었습니다.

기획 당시 이 플랫폼은 공장 매칭 과정 중 클라이언트와와 직원이 대면하여 중요한 사항을 검토하고 의사결정을 해야 하는 부분이 필요하였는데 아무래도 오프라인 만남 이후엔 이 플랫폼을 굳이 사용하지 않아도 전화로 계약할 수 있겠다 생각이 들었습니다. 이 만남 또한 플랫폼내에서 이루어지도록 고심하였고 오프라인에서 일어나는 모든 과정을 웹에 도입하자라고 얘기가 나왔지만 그 당시 정책적인 부분, 일정 부분등 여러모로 어려움이 있었고 저는 이 과정을 현 플랫폼 프로세스 사이 "협의 중"을 추가하자고 제안하였고 긍정적으로 채택되어 간단히 개발비용, 실 서비스 사용자들의 유출을 방지 할 수 있었습니다. 재미난 경험이었고 개발자는 사용자과 제일 가까워야 하는 직업이구나를 다시금 깨닫게 되었습니다.

 

그리고 저 자신에게 아쉬움도 많이 생겼습니다.

"내가 가는 방향이 최선인가", "우물 안 개구리인 나", "더 깊은 경험을 해보고 싶다" 공부해! 라는 느낌의 말들이 머릿속에 살게 되었습니다.

근데 뭐 어쩌겠습니까, 하면 되지용

 

아무튼! 이 모든 과정을 통해

결과적으로 동료분들과 함께 성공적 프로젝트를 일정내에 차질 없이 완수 해냈습니다. 🚀

제 이야기에 귀기울여 들어주시고, 주도적으로 의견을 서로 내준 덕분에 해냈다고 생각합니다. 

 

 

 

 

이..이글은 여기가 마침표에요!

회고는 처음 써봅니다. ㄲ..끄끝입ㄴ디다.. 이렇게 글 길게 적은것도.. 처음이에요.. 

여기까지 봐주셨다니.. 감사합니다 : )