회고를 하는 방법은 다양하다. 그냥 일기처럼 자신이 어떤 과업을 수행했고, 그 과정에서 무엇을 배웠는지 적어내려가는 단순한 방법에서 조금 더 구체적이고 체계적인 방법론까지. 회사 홈페이지 제작 프로젝트를 마치고, 함께 작업한 팀원들과 회고의 시간을 갖고 싶었다. 그렇게 KTP 방식을 적용하게 되었다.
KTP
Keep : 프로젝트에서 만족했고, 앞으로의 업무에서 지속하고 싶은 부분
Problem : 프로젝트에서 부정적인 요소로 작용했거나 아쉬웠던 점
Try : Problem에 대한 해결 방식으로 다음 프로젝트에서 시도해볼 점
역할
강00 (FE/BE)
PC 버전 About, Tech, Service, 이미지 슬라이드 UI 작업
알파/메인 서버 설정 및 배포
다국어 세팅, 모션 등 관련 작업 대응
김가영 (FE)
PC 버전 Home, Service-냐호, Service-HSD, Service-Sensil, Crew&Culture, 인터뷰 모달, CMC, Deli, News 페이지 UI 작업
Mobile 버전 Home, Service, Service-HSD, Service-Sensil, 인터뷰 모달, CMC, Deli, News 페이지 UI 작업
테크 블로그 리뉴얼
알파/메인 서버 설정 및 배포
피드백 대응 및 UI 수정
주00 (FE)
Mobile 버전 About, Service-냐호, Tech, Crew&Culture, 이미지 슬라이드 모달, 인터뷰 모달, GNB, Footer 페이지 UI 작업
PC 버전 Home 모션 적용, 냐호 슬라이드 생성, About 추가작업
테크 블로그 수정
피드백 대응 및 UI 수정
김00 (BE)
뉴스 (최신, 리스트) API 생성 및 페이지네이션 작업
관련 작업 대응
회고를 해보자
프론트엔드 개발
| Keep | Problem | Try |
| 1. 새로운 프레임 워크(Next.js), 라이브러리를 학습하고, 빠르게 적용 | 1. Next의 특징(SSR)을 충분히 활용하지 못함 | 1. 개발 및 프로젝트 관리 역량 키우기 |
| 2. 국/영문의 다국어 싱크를 알맞게 적용 | 2. 다국어 적용 후, 크로스 브라우징 이슈 대처 어려움 | 2. 디자인 및 리소스 감수, 커뮤케이션을 철저히 |
| 3. 다양한 레이아웃 및 컴포넌트 퍼블리싱 작업 | 3. pc/mobile 버전이 아닌 반응형 제작 필요 | 3. 미구현 기능 보완 |
| 4. 복잡한 애니메이션, 인터렉션을 고민하고 적용 | 4. 기획 단계에서 개발자 참여 제한으로 커뮤니케이션의 어려움 | 4. 라이브러리 및 새로운 기술은 공식문서부터! |
Problem
대외 공개되는 홈페이지로 SEO를 위해 Next.js를 사용하였으나, SSR을 충분히 활용하지 못했다고 생각한다. 외부 API를 불러오는 일부를 제외하고는 로딩 속도 및 성능상의 문제로 CSR로 전환했다. lazy loading, suspense 등을 추가해 특징을 살리는 리팩토링 필요.
UI 개발 완료 후 다국어 적용을 했을 때, 텍스트 길이로 기존 UI가 깨지는 곳이 많았다. 텍스트 크기를 반응형으로 조정하거나, 텍스트 자체를 수정했다. 처음부터 염두해 뒀더라면 UI 작업을 할때부터 처리 기능을 넣었을 것. 또한 윈도우, safari 등 다른 브라우저 확인은 필수다.
pc와 mobile 디자인이 각각 분리되었고, 공통요소가 없었기 때문에 각각 작업, device를 인식하는 라이브러리로 구분했다. 아이패드, 탭 등 다양한 모바일 기기에 대응이 어려웠다. 반응형일 경우 디자인 시안 또한 반응형이 필수다.
외부 디자인 시안으로 모션 레퍼런스 공유나 개발 관점에서 궁금한 점들에 대한 커뮤니케이션이 어려웠다. 특히 리소스, 디자인 시안 검토 등 초기 커뮤니케이션이 잘 되었더라면 효율이 더 좋았을 것이라고 생각한다.
Try
설계, Global css, 전체 레이아웃, 컴포넌트 구성, 코드 컨벤션 등 사전 합의 후 착수 (유지보수 효과적인 컴포넌트 만들기). 개발 전과 후 전체 개발 프로세스 체크리스트 만들어 관리 Next 오류 (Hydration), 성능 개선할 예정
assets, 디자인 가이드 등 필요한 부분들은 미리 점검하고 한번에 요청하기. 픽셀, 사이즈 등 제대로 제작되었는지 확인하기
백엔드 개발
| Keep | Problem | Try |
| 뉴스 API 관련 작업 | 페이징 처리에서 기존 양식과 조금 다르게 개발되어 맞추는데 추가 작업이 들어감 | 모듈화나 공통으로 뺄 수 있는 부분은 빼는 것이 필요해 보임 |
| QueryDSL을 사용한 페이징 처리 | 뉴스 정보에 대한 API를 개발하고 프론트와 연동해서 개발자의 추가 공수를 없애는 것이 필요할 듯 | 서버나 환경에 의존성을 갖는 부분은 외부로 빼자 (ex: s3) |
| 알파 및 라이브 DB 뉴스 데이터 처리 | assets 리소스는 s3를 사용하는 것이 효과적 | 뉴스 관리를 위한 API 및 admin 페이지 개발 필요 |
정리
프로젝트를 진행하면서 개인적으로 말하지 못했던 고민과 개선사항에 대해 이야기 하고 나니 프로젝트 운영의 방향이 더욱 명확해졌다. 잘한 부분은 서로 칭찬하고 용기를 북돋아주고, 개발적인 고민을 나누다보니 함께 작업하는 팀원들을 믿고 작업을 완성했다는 것이 더욱 보람있었다. 프로젝트는 개발을 하는 그 순간 뿐 아니라 시작 전과 후의 전 과정이라는 것을 다시 한번 느꼈고, 개발자에게 회고가 얼마나 중요한지 몸소 실감하는 시간이었다.