D-WORK 팀 프로젝트(2) - 개인적인 후기

이번 포스팅에서는 실제 구현할 때 팀장으로서 프로젝트 진행 계획을 어떻게 계획했는지와 어떤 부분을 담당했는지, 실제 구현하면서 트러블슈팅 했던 경험을 다뤄보려고 한다. D-WORK 프로젝트 관련해서는 마지막 포스팅이 될 것 같다.

 

팀장으로서 프로젝트 진행 계획

관련 산출물 관리에 대해서 익숙하지 않은 인원들도 많았어서, 최대한 프로젝트 진행에 대한 형태는 지키되, 문서들이 익숙하지 않은 문서들이 되어 '죽은 문서'가 되지 않도록 하려고 했다. 예를 들면 요구사항을 엑셀이 아니라 노션의 리스트 형식으로 정의해서 회의 중에 공유했고, 산출물도 팀원들 각각이 진행하기보다는 내가 진행을 맡고 함께 아이디어를 공유하는 형태로 진행 방식에 대한 이해를 공유하고자 했다. 프로젝트 진행 중에는 전체적인 구조와 필요한 부분, 기능 간에 연결될 부분을 팀원들에게 지속적으로 공유하고 현재 진행 상황을 항상 추적하고 있도록 주문했다.

팀 진행 플래그

팀 프로젝트 진행 플래그를 '성장' 에 초점을 뒀기 때문에 후다닥 진행하고 결과물을 내는 것보다 내가 이해한 코드를 짜는 게 좋다고 생각해 이 플래그들을 최대한 전달하려고 노력했다. ( 물론 성과 내야 하는 프로젝트거나 포트폴리오 용이면 욕심을 많이 냈겠지만 첫 팀 프로젝트라 그렇진 않은 것 같아서 기능에 대해서 욕심을 덜 냈다. )

 

팀원들과 정한 컨벤션

Git commit message 컨벤션 : feat, fix, docs, refactor와 같은 prefix를 이용해 커밋 메세지를 작성하려고 했다.

함수명, 변수명 컨벤션 : 변수명은 프리하게, 다만 함수명은 반드시 행위를 표현하도록 했다.

전반적인 코드 컨벤션 : ESLint, Prettier 이용

 

내가 담당한 파트

프로젝트 진행 관리

HTML 스켈레톤 구현, 기본적인 화면 CSS 구현

AWS 백엔드 구현 ( Flask, MongoDB )

클라이언트 API 요청 라이브러리 구현 ( API wrapper )

메모 글 렌더링 및 저장 구현

로그인 기능 구현

디렉터리 구조 정리

기능 명세화 / 요구사항 정의

 

프로젝트 초기에는 전체 구조와 기반 시스템을 많이 만지려고 했고, 팀원들이 안정적으로 기능을 개발할 수 있는 환경을 만드는 데 집중하려고 했다. 팀원들이 참조할 API wrapper를 구현하고 이후에 노션 렌더링, 로그인 등과 같은 기능을 구현했다. 프로젝트 진행 중에는 전반적인 흐름을 파악하고 관리하려고 했다.

 

설계 디자인 이론이나 SOLID원칙 같은 것들을 잊어버려서 다시 공부하고, 구조 설계에 대해서는 팀원들과 전체 회의 하면서 함께 설계했다.

 

1. HTML 스켈레톤과 기본적인 화면 CSS 구현

Figma에 정의된 대로 디자인

Figma에 정의된 대로 HTML 스켈레톤 구조를 짜고, 최대한 시맨틱 태그를 이용해서 작성하려고 했다. CSS 다루는 게 익숙하지 않아서 생각보다 CSS 작성하는 데 시간을 많이 썼었다. 초기 구조 이후에는 팀원들이 기능 구현을 맡은 부분에 대해서 추가 CSS를 작성했다.

 

2. AWS 백엔드 구현

백엔드 레포지토리

GitHub - yoon5450/D-Work-Back-Public: D-WORK 프로젝트 백엔드 공개용 레포지토리입니다.

백엔드 구현은 AWS, Flask, MongoDB로 상대적으로 익숙하고 쉬운 것들로 구성했다.

 

3. 클라이언트 API 요청 라이브러리 구현

API wrapper 구조

API 요청 함수들을 분리하고, req라는 공통 요청 함수를 이용해 관리했다. 백엔드를 내가 구성했어서, 상대적으로 작성하기 어렵지 않았다. 프로그래머스에서 받은 API는 구조 삽입와 실제 content 삽입 요청 API 가 분리되어있어서, 이 부분에서 좀 헷갈렸었다.

 

4. 메모 글 렌더링 및 저장 구현

메모 글 저장 및 불러오기 기능

불러오기 기능을 만들 때 고려해야 할 점은 메모 리스트, 마크다운 구현 (작성 기능), 저장 및 불러오기 구현을 각각 다른 사람이 담당한다는 점이었다. 나는 노션 리스트에서 click 이벤트가 발생했을 때 화면에 컨텐츠를 불러와 렌더링해야 했기 때문에 목록의 아이템에서 document의 ID를 불러올 수 있도록 클릭하면console.log로 ID를 띄워 달라고 요청했었다. 생성된 목록에 대해서 이벤트 관리하고 load 함수를 넣기만 했더니 잘 작동하더라.

 

저장 기능은 키다운 이벤트로 관리했다. 키다운 이벤트마다 이벤트를 발생시키면 이벤트 빈도가 너무 빠른 것 같아 debounce로 이벤트 빈도를 조절했다.

 

5. 로그인 기능 구현

로그인 화면

로그인 인증 기능과 회원가입 기능을 구현했다. (사실 토큰이나 암호화를 전혀 신경 안 써서 구현했다고 하긴 좀 부끄럽다.) 결국엔 프론트엔드 프로젝트라서 백엔드 단을 크게 건드리지 않고 로그인 성공 데이터와 회원가입 정보 저장에 신경썼다.

 

6. 디렉터리 구조 정리

home
index.html
    ㄴstyle main.css
    ㄴlib
    ㄴutil > 수업 중 추가된 유틸함수
    ㄴstorage > getdata.js
    ㄴdom > 수업 중 추가된 유틸함수
    ㄴanimation
    ㄴmath
    ㄴrender
    ㄴsearch
    ㄴfilter
    ㄴnote
    ㄴconstant
    ㄴcalender
    ㄴapi
    ㄴasset

기존에 합쳐질 디렉터리를 정의하고 각 브랜치마다 따로 디렉터리를 생성해 사용했었는데, 디렉터리 구조가 너무 별로인 것 같아 lib로 한번에 모으도록 개선했다. 다시 보는데 기능별로 분리된 디렉터리가 많아서 좀 어지럽긴 하다.

 

7. 기능 명세화 / 요구사항 정의

기능 명세화 후 요구사항 정의

기능 명세화와 요구사항 분석을 주도해서 작업했다. 큼지막한 기능부터 기능에서 필요한 요구사항을 세부화해서 정리하면서 관리했다. 

 

프로젝트 진행 중 문제 해결

CORS 문제

AWS 백엔드단에서 CORS 문제가 발생했었다. 허용이 그렇게 어렵지 않다고 알고 있어서 다른 주소로 요청하는 방법을 채택했었다. 그런데 생각보다 문제 해결에 오래 걸려서 어려웠다. 알고 보니 app 호출과 CORS 라이브러리 순서의 문제였어서 단순한 한 줄 문제였어서 힘이 많이 빠지긴 했다.

app = Flask(__name__)
client = MongoClient('mongodb://' + DB_USER + ':' + DB_PASS + '@' + DB_HOST, 27017)
user_db = client.dwork
CORS(app)

진짜 한줄 ... CORS(app) T_T

 

restAPI 주소 문제

API 주소를 많이 관리하다보니 헷갈려서 회원가입을 /register로 요청했어야 했는데 /signin으로 한참 요청하고 왜안되지? 하고 생각하고 있었다. api주소는 항상 확실하게 확인해야 할 것 같다.

 

이벤트 처리 문제

merge하면서 이벤트 관리에 문제가 많이 생겼었다.. merge 하기 전에는 이벤트 범위를 좁히지 않아도 문제가 없다. 왜냐하면 합치기 전에는 해당 이벤트 하나 뿐이니까. 같은 id, 같은 class, 같은 target 대상으로 다양한 문제가 발생할 수 있는 걸 알았고, 다음에는 이벤트 대상도 같이 정의를 해야 되지 않나. 하는 생각이 든다. UX적으로 생각이 부족했던 것 같은 반성이 든다.

 

디렉터리 구조 문제

디렉터리 구조가 정말 나빴다. 어떤 사람은 root에 작업 디렉터리를 넣어두고, 본인 이름으로 된 디렉터리로 다들 관리했어서(나 포함) 연계되는 기능을 파악하기 어려워서 디렉터리 이름을 명확하게 하고 lib로 한번에 합치도록 했다. 팀원들끼리 라이브러리를 합치고 연결하는 게 구조를 깔끔하게 유지할 수 있을 방법일 것 같다.

login, bookmark 등의 동작마다 디렉터리 관리하는 게 낭비 같은데 방법 없나? 라는 고민에서 login.js, bookmark.js 등과 같은 파일을 api 파일로 합쳐 관리하도록 했다.

 

매 파일마다 END_POINT와 STORAGE_KEY를 입력해야 하나?

constant 이용해서 export const를 이용해 한 파일에서 모든 키와 주소를 참조할 수 있도록 해결했다.

 

노션 저장 기능 최적화 방법을 스로틀링에서 디바운스로 수정

스로틀링으로 노션 저장 기능을 관리했더니 마지막에 입력하지 않으면 중간에 끊겨서 저장되는 문제가 있었다. 디바운스로 최적화 방법을 변경해 해결했다. 지금 생각해보면 디바운스 + 스로틀을 같이 사용해도 괜찮았을 것 같다.

 

검색 기능, 필터링 기능, 정렬 기능 따로 노는 문제

구현한 사람이 각각 다른 사람들이다 보니 각각 기능마다 따로 렌더링되고 있었다. sessionStorage를 이용해 각각 기능을 수행한 데이터를 가지고 있을 수 있도록 개선해 관리했다.

 

팀장으로서의 성장

팀장으로서 많이 성장한 프로젝트였던 것 같다. 팀에서 중심으로 볼 부분을 관리하고 팀원들의 아이디어를 취합하는 과정이 대단히 고민스럽긴 했지만 가치 있는 과정이라고 생각한다. 나는 팀장 지망으로 데브코스에 들어왔었기 때문에 다음에도 팀장을 할 것 같아 이쪽으로 성장하려고 고민을 했었다. 그러면서도 기능 구현에 소흘하지도 않았어서 진행 자체가 굉장히 만족스러웠다.

 

프로젝트 전체 구조를 계속 머리에 담고 있으려고 팀원들의 진행 상황과 아이디어를 주기적으로 인터뷰하며 알고 있으려고 했고, 팀원들의 코드도 읽으면서 구현 로직을 생각하고 있으려고 했다. 그러면서 필요할 것 같은 유틸 함수나 기능을 구현하면서 프로젝트 진행을 관리한 것이 특히 만족스럽다.

 

5명 팀에서 요구사항 정의/컨벤션 관리/코드 리뷰를 주도했고, 팀원의 생산성과 이해도를 높였다는 점에서 가장 만족스럽다.

 

피어 리뷰

팀원들끼리의 피어 리뷰에서도 프로젝트 진행 관리에 대한 호평이 많았다. 코드 리뷰나 의사소통 과정에서 적극적이고 팀원들의 아이디어를 존중한다는 의견이 가장 좋았다.

 

기술 평가 점수도 좋았으니 아무튼 좋은 것 아닐까.

 

개인적으로 느낀 점

프론트단 Promise 이용하면서 느낀 점

개념 공부가 확실히 많이 도움이 되긴 하는구나. ajax, promise, callback, xrh와 같은 개념은 정말 중요한 개념들이라 닳도록 읽어봤던 기억이 난다. MDN 문서도, 모던 자바스크립트 책도, GPT한테도 물어물어 공부했는데, 실제로 사용하려고 보니 내 기대보다도 손발처럼 쓰여서 편리했다.

 

백엔드 구현하며 느낀 점

프론트와 백엔드 소통을 중심으로 두고 파악하려고 했다.

REST API 형식으로 구성하면서 일부러 CORS 이슈를 마주해보려 했는데 서버단에서 CORS를 허용하는 것이 생각보다 간단했고, flask_cors 등을 활용하여 손쉽게 설정할 수 있었다.

다만, 무제한 허용은 보안상 문제가 될 수 있으므로 실제 서비스에서는 CORS(origin) 제한 설정이 필요할 것 같았다.

 

Git과 협업 과정에서 느낀 점

• Merge 과정
  다른 사람의 코드에서 중첩되는 함수나 이벤트를 파악하고 수정하는 일이 어려웠지만,
  기능 목적을 파악하고 중복 문제를 해결하는 과정에서 많은 학습을 했다.
• 코드 스타일 다양성
  사람마다 코드 작성법이 달라 초기에는 이해하기 어려웠지만,
  의도와 로직을 파악하려는 과정이 팀 협업에 있어 매우 유익했다.
• Git에 대한 두려움 극복
  clone → fetch → merge → push 과정을 여러 번 반복하면서 익숙해졌다..
  브랜치 전략과 충돌 해결 능력도 실제로 사용해보며 체득했다.
  Pull Request가 생각보다 어렵지 않더라.
• 모듈화 구조
  코드가 커지더라도 기능 단위로 나누면 충돌이 줄어들었다.
  파일명 정리와 import 관리만 잘 하면 협업이 꽤 수월함을 경험했다.

 

팀 활동에서 느낀 점

일단, 팀원분들이 의견 나누는데 부담이 없이 해주고 의견에 대한 반박 등과 같은 내용을 적극적으로 나눠줘서 고마웠다.

나는 학생 시절에는, 항상 팀 활동에서 앞에 서서 가는 걸 좋아했지만, 그다지 팀원들을 믿지는 않았다. 의욕적인 사람이 정말 없었어서 그랬다. 그런 환경을 만든게 내가 아닌가. 하는 고민이 생길 정도로 데브코스에서는 의욕적인 팀원들이 많아서 좋았다.

신뢰할 수 있는 사람들과 작업한다는 점이 신기한 경험이긴 했다. 내가 성격이 많이 바뀌기도 했지만. 예전에 팀장을 할 때는 독불장군 성격이었어서. 개인적인 공부에 대한 욕심이 있어 많이 내려놓아서 그런 것 같기도 하고. 사실 아직 잘 모르겠다.

 

마무리

추가적으로 설계 원칙(SOLID 원칙, 의존성 역전 등)에 대해서는 개념적으로는 익숙하지만, 실제 진행하면서 설명하기도 어려워서 조금 덜 신경썼는데 ( 학교 다니면서 배웠으니 알게 모르게 쓰긴 했을 거다. ) 다음에 진행할 프로젝트에서는 아토믹 디자인을 의도적으로 생각하면서 해보고 싶다. 아무래도 리액트 프로젝트가 될 것 같은데 리액트가 아토믹 디자인이 찰떡이니까.
어우. 프로젝트 마무리한지는 좀 됐는데 후기 글을 마무리하는 데 오래 걸렸다. 시원하게 털어낸 느낌이기도 해서 후련하다.