2022.12.12 ~ 2023.01.11

한 달에 걸친 FarmFarm 파이널 프로젝트, 줄여서 ‘팜팜’을 완성한 기념으로, 팀 결성 과정과, 프로젝트 진행 과정에 대해 회고하는 글을 써보려고 한다. ‘한 살 터울’ 팀원들을 만나게 된 과정도 너무 특별한 경험이었고 개발 과정도 힘들었지만 즐거운 기억으로 남았기 때문에 편안하게 그 과정들을 되돌아보며 아쉬웠던 점과 개선할 점 등을 정리해 보려고 한다.

🌱 한 살 터울 팀원들과의 첫 만남

파이널 프로젝트 팀원을 선정하던 날, 나는 세미 프로젝트로 인해 매우 지쳐있는 상태였다..ㅋㅋㅋ

세미 프로젝트 팀원 5명 중 3명이 맡은 프로젝트 기능을 완성하지 못했고, 심지어 대부분의 기능을 내가 거의 짜주다시피 했기 때문에 체력적으로도 힘들었지만, 정신적으로도 고통 받았던 상황이었ㅇ..기도 했고 여차 저차 해서 파이널 프로젝트에서는 정중하게 세미 프로젝트 팀원 3명과 헤어지고 같이 열심히 했던 팀원 언니 한 명과 새로운 팀을 구하기 위해 나섰다.

여기서 참 재밌는 일화가 생겼는데, 막상 파이널 팀원을 구하려고 하니 다른 사람들에 대해서 잘 모르기도 했고, 내가 같이 하고 싶었던 세미 프로젝트 때 4명 짜리 팀이 있었는데 파이널 프로젝트에도 넷이 함께 하려고 한다는 이야기를 듣고 그럼 누구와 함께해야 하지.. 하면서 고민을 하고 있었다.

그러다가 어떤 분이 프로젝트 함께 하고싶다는 의사를 내비치셔서 그 분과 함께 하기로 하자 마자 내가 함께 팀을 하고 싶어했던 4명 팀에서 같이 하자고 말을 걸어왔다!!! 어떡하지 하고 고민을 하다가 함께 하기로 했던 분에게 양해를 구하고 언니와 나는 4명 팀에 합류했다.

알고 보니, 4명 팀은 나와 같이 하고 싶은 생각이 있었는데 말을 못하고 있다가, 선생님께서 ‘OO씨 데려와요~’ 하는 말을 듣고 용기를 내서 나에게 제안을 했던 것이었다. 시간이 지난 지금도 그때 선생님의 한마디가 신의 한 수였다며 웃곤 한다.
한 살 터울 팀원들을 만난 것이 나의 짧은 개발 인생의 큰 선물이 아닐까 생각한다.

참고로 팀 명이 한 살 터울인 이유는, 팀원의 나이가 줄 세우면 한 살 차이로 6명이 모두 다르기 때문이다 ㅋㅋ

🍏 1. 팀 규칙 정하기

건강한 프로젝트 진행을 위해서 우리 팀만의 규칙을 정하기로 했다. 국비 학원에서의 탈주라던가.. 빌런이라던가.. 악명 높은 이야기들이 많았기 때문에 규칙을 정하는 것이 좋은 선택이라고 생각했다. 물론 우리 팀원들은 이미 세미 프로젝트로 한번 검증(?)된 사람들이었기 때문에 크게 걱정은 없었다 ㅋㅋ

팀 규칙
  1) 탈주하는 사람 없이 끝까지 같이 하기
  2) 컨디션 조절 잘해서 결석 없이 프로젝트 준비하기
  3) 깃허브의 메인 머지 받고 내 파일 머지하기
  4) 내가 작업한 파일 백업 잘 해두기
  5) 이름 규칙, 명명 규칙 정해서 잘 지키기
  6) 열심히 하기
  7) 각자 프로젝트 진행 중 에러 모아서 정리해두기

정해진 팀 규칙은 위와 같았다. 사실 1번만 지켜져도 절반은 갈 것 같지만? ㅋㅋ

웬만한 규칙들은 정해진대로 프로젝트 진행 과정에서 잘 지켜졌던 것 같다.

아쉬운 점은 7)번 항목인데, 사실 프로젝트 진행 도중 발생하는 예외나, 문제는 수 없이 많았으나 그걸 전부 정리해놓기보다는 개발하는 데에 좀 더 치우쳤던 것 같다. 프로젝트 끝나고 기억을 되돌아보면서 잊혀진 문제들도 많고 기억이 나더라도 이미 코드가 덮어 씌워져 버리기도 했다는 게 아쉬웠다.

🍏 2. 주제 선정

파이널 프로젝트의 주제는 자유였기 때문에 어떤 주제로 프로젝트를 진행할 지에 대해 정하는 것이 굉장히 중요한 과제였다. 내가 공공 API를 활용한 사이트를 만드는 게 어떨 지에 대해 제안 했고, 어떤 API를 사용할 지에 대해 토의를 진행했다.

✏️ 공공 API 찾기

공공 API도 그 종류가 방대하기 때문에, 어떤 API를 사용할 지 정하는 것도 끝이 없는 과정이었다. 우선 여러가지 API를 탐색하면서 그 API를 가지고 어떤 사이트를 만들 수 있을 지 구상했다.

교통 정보 API를 활용한 주요 상권 인구 밀집도 제공 사이트, 날씨 API를 활용한 의상 추천 사이트 등등 여러가지 아이디어가 나왔다, 그 중 내가 제안한 아이디어는 주말 농장 API를 활용한 주말 농장 등록 및 잉여 생산물 교환 사이트였는데 이게 팜팜의 시초가 되었다.

🍏 3. 유스케이스 다이어그램

팜팜 프로토타입의 유스케이스 다이어그램을 만들었다. 처음엔 주말농장 API를 이용해서 주말농장 정보를 제공하고, 주말 농장을 운영하는 사람들이 잉여 생산물을 거래할 수 있는 사이트를 만들고자 했다.

여기서 문제가 발생했다. 팜팜이 거래의 중개 업체로서 금전을 관리하게 됐을 경우, 거래된 돈을 어떻게 처리할 지에 대한 생각이 부족했다. 판매자에게 일정액의 수수료를 떼고 지급할 경우 팜팜은 거래의 책임에서 자유로울 수 없고, 일체 수수료를 받지 않을 경우 결제 기능이 유명무실해졌다.

선생님도, 사이트의 정체성이 불분명하고 결제 기능을 넣어야 하는 이유가 보이지 않는다고 피드백 해주셨다. 우리는 사이트의 정체성을 두고 장시간 회의를 진행했다. 결제 기능을 빼고 회원들 간의 자유로운 거래를 허용할 지, 결제 기능을 넣되 팜팜만의 상품을 판매하는 쇼핑몰로 전환할 지에 대해 의견을 나누었다.

전자의 경우 6명이 진행하기에는 다소 프로젝트의 규모가 작은 감이 있었고, 애초에 쇼핑몰을 원하는 팀원들이 많았기 때문에 농자재를 판매하는 쇼핑몰과 농산물을 거래하는 플랫폼을 합치기로 의견을 모았다. 처음부터 확실하게 주제를 잡고 진행했으면 좋았을텐데 아쉬운 부분이다.

🍏 4. 와이어 프레임

주제를 잡고, 화면 구현을 위한 와이어 프레임 제작에 들어갔다. 와이어 프레임이 말 그대로 틀만 잡는 일이었음에도 우리는 다들 꼼꼼한 성격 탓에 거의 완성된 화면을 만들어 버렸다..ㅋ

그치만 다들 열정맨들이라 다른 조 틀만 잡는 시간이랑 크게 차이나지 않았다는 게 함정

완성된 와이어 프레임(Figma) - 화면을 거의 다 구현해버렸다..

화면 크기는 마켓 컬리의 사이즈를 참고하여 1000px로 고정했다. 미디어 쿼리를 적용하면 좋았겠지만, 다들 프론트엔드의 섬세함과는 거리가 멀었기 때문에 미디어 쿼리는 적용하지 않기로 했다. 세미 때 미디어 쿼리를 적용해서 아주 만족했던 경험이 있기 때문에 조금 아쉬웠지만, 기능에 집중하기로 했다.

🍏 5. DB 설계

성실한 팀장이 필요한 DB 테이블과 컬럼을 정리해왔다. 세미 때는 내가 팀장이기도 했고, 웬만한 부분을 도맡아서 했기 때문에 신선한 경험이었다. 연신 감동 받았다며 팀장한테 고맙다고 절을 했다 ㅋㅋ

팀장이 정리해온 DB 내용을 토대로 내가 덧붙일 부분은 덧붙이고 수정할 부분을 수정해서 DB의 기반을 완성했다. 그 내용을 토대로 팀원들과 함께 ERD 설계에 들어갔다.

처음 설계했을 때는 이 정도로 테이블이 많지 않았는데, 중간에 조금 추가됐다. 반품이나 STOCK_HISTORY 테이블 같은 경우에는 처음에 생각하지 못했던 부분이라 기능을 구현하면서 추가됐다. 또 상담 부분 테이블도 내가 내 기능 구현을 끝내고 추가한 부분이다.

정규화 과정을 진행하면서 테이블을 나눴는데, 관계형 데이터베이스는 정규화 과정을 통해 테이블을 나누는 과정이 필수라고 하지만, SQL을 작성할 때 JOIN이나 서브 쿼리를 사용하여 ‘SELECT’를 해야 하기 때문에 성능 하락을 야기할 수도 있다고 한다. 모든 이미지를 테이블을 나눠 생성했다가, 하나의 이미지만 등록되는 경우(회원 프로필 이미지) 에는 테이블을 합쳐서 관리하기로 했다.

🍏 6. TRELLO

프로젝트를 기획하면서, 하나 씩 단계가 늘어감에 따라 일정을 관리하고 조율할 협업 툴이 필수가 됐다. 세미 때는 깃허브에 있는 Projects 탭을 활용했는데, 아무래도 아직 나온 지 얼마 되지 않아서 조금 사용이 불편했던 경험이 있었기 때문에 트렐로(Trello)를 이용하여 프로젝트 일정을 관리하기로 했다.

팀원 별로 커버의 색상을 지정해서, 각자 진행 예정, 진행 중, 완료 탭으로 나누어 관리했다. (완료 탭의 스크롤바 길이로 나 혼자 살짝 경쟁(?)도 했었다)

팜팜의 트렐로

또 트렐로를 사용함과 동시에 한눈에 진행 과정을 확인할 수 있는 WBS를 구글 스프레드시트로 만들어 구글 드라이브에서 공유했다.

약간 기간이 중구난방이긴 하지만.. 아무래도 모든 인원이 프론트엔드랑 백엔드를 같이 하다보니 시간 배분이 힘들었던 것 같다. 처음에는 선생님이 프론트엔드랑 백엔드를 나눠서 팀 선정을 해주신다고 했는데, 대부분이 백엔드를 희망해서 무산됐다 “에라 모르겟다 그냥 하고싶은 사람끼리 하세요~” 가 돼버려서 그냥 모든 인원이 공평하게 프론트와 백을 나눠서 맡았다.

그래도 발표 일주일 전까지 개발을 마치고 클라우드에 배포 한 후에 통합 테스트 기간을 갖기로 했던 계획은 정확하게 지켜졌다. 마지막 일주일 동안 고쳤던 오류가 어마어마했다. 오류 찾기에 큰 공을 세운 한 팀원이 있었는데 너무 고마우면서도 “제발 내 오류가 아니라고 해줘.. 엉엉” 하면서 징징대기도 했다

🍏 7. 명명 규칙 설정

명명 규칙을 설정하고, 클래스나 파일을 생성할 때 일괄적으로 적용했다. 세미 프로젝트 때 명명 규칙을 설정하지 않고 프로젝트를 진행했더니 프로젝트 파일 상태가.. 중구 난방에 폴더도 누군 만들고 누구는 안 만들고 난리가 나서, 규칙과 통일성의 중요성을 깨달았다. 완벽하게 지켜지지는 않았지만 규칙을 설정한 덕분에 나름 깔끔하게 파일들이 정리됐다.

🌱 본격적인 개발의 시작(?)

기획 단계가 끝나고 본격적으로 개발에 착수했다. 스프링 환경 세팅 후에 각자 맡은 기능의 화면을 구현하는 작업을 먼저 진행했다. 우리는 Spring Legacy Project였기 때문에 JSP를 통해 화면을 구현했다. 처음에 먼저 HTML과 CSS, JS로 화면을 구현한 후에 HTML로 만든 파일을 JSP로 전환하는 방식으로 구현을 진행했다.

🍏 1. 화면 구현

본격적인 화면 구현 전에, CSS에 root 함수를 통해 공통적인 요소에 대한 스타일을 지정했다. 팀원들이 root 요소를 만들어 놓은 것에 대해 편하다며 고마워했다. 피그마(Figma)로 미리 화면을 거의 구현해놨기 때문에 화면 구현은 빠르게 진행됐다. 세미 때 화면 구현을 진짜 열심히 했던 터라 화면 구현은 쉽게 끝났다.

🍏 2. 기능 구현

화면 구현이 끝나고 Back-End 구현이 시작됐다. 세미 때 했던 기능과 겹치는 부분은 금방 끝났지만, 다들 새로 구현하는 기능이 많아서 모르는 부분이나 익숙하지 않은 부분은 각자 구글링 해가며 개발을 해야했다.

다들 책임감도 강하고 열정도 넘쳐서 다른 팀원들에게 폐를 끼치지 않기 위해서라도 정말 열심히 맡은 기능을 다 구현해냈다. 심지어 계획에 없었거나, 시간이 남으면 구현하기로 했던 부분도 거의 구현을 해서 정말 뿌듯했다. 이 때만 해도 다양하고 많은 기능을 전부 구현했다는 것이 잘하는 것이라고 생각했었다. 프로젝트가 끝나고는 그 생각이 180도 바뀌게 됐지만 ㅋㅋ

나는 팜팜에서 여러가지 기능을 맡았는데

마이페이지(주문 내역, 후기 관리, 작성 게시글 관리, 작성 댓글 관리, 찜 목록)
상품 상세 페이지, 주문, 주문 취소, 반품 신청, 배송 조회
1:1 상담

등등을 맡았다. 처음엔 내가 맡은 기능이 어느정도인지 가늠이 잘 안됐는데 구현하면서 정말 많았고, 다 구현하느라 진짜 힘들었다..

거의 대부분의 기능을 비동기로 처리하려고 했고, 결제와 결제 취소 기능을 꼭 제대로 구현하고 싶었다. KG 모빌리언스는 사업자 등록증이 필요해서 사업자 등록증 없이 테스트 결제를 구현해볼 수 있는 아임포트의 카카오페이 API를 사용했다. 간단한 API이긴 하지만 API를 swiper.js 외에는 처음 사용해봤기 때문에 하나하나 아임포트에서 제공하는 공식 문서를 읽어가며 만들었다.

처음에는 API에 요청을 전송하는 부분도 힘들었다. request에 header와 body가 따로 존재한다는 사실부터 다시 공부해야 했다. 또 JSON 데이터를 전달받아 파싱하는 부분에서도 애를 먹었다. JSON 데이터를 꺼내서 사용하는 방법도 쉽지 않았고, 여러 방법중 DTO를 만들어 객체에 담는 방식을 사용했다.

선생님의 도움을 받지 않고 혼자 구현하고 싶은 욕심이 있어서 열심히 구글링을 했다. 결제 기능은 생각보다 너무 간단했다. 아임포트 API에 간단한 요청만 보내면 결제가 가능했다. 물론 결제 검증 처리를 해주긴 했지만 아마 실제 돈이 오고가는 결제를 구현하려면 100배는 더 어렵고 복잡할 것 같다.

결제 취소를 요청하기 위해서는 아임포트측에 결제 정보에 엑세스할 수 있는 토큰을 발급받아 그 토큰을 이용해서 결제 취소 승인을 받아야 했다. 이 부분이 조금 힘들었다. 일단 토큰을 발급 받는 부분과, 결제 취소 요청하는 부분을 따로 구현해야 했고 구글링도 하고 공식 문서도 봐가며 결제 취소를 구현해냈다.

다른 사람들이 보면 허접하고 별것 아니지만 파이널 프로젝트 때 결제 취소를 구현한 사람이 나밖에 없어서 뿌듯했다.

웹소켓을 이용해서 상담 기능도 만들었다. 소비자(회원)과 관리자가 각각 다른 화면으로 상담을 진행해야 했기 때문에, 두개의 채팅을 만드는 것과 같았다. 백엔드 부분은 금방 구현했지만 화면을 두 개나 만들어야해서 힘들었다. 왜 실무에서 프론트 엔드와 백엔드가 나눠져있는 지 알 것 같았다.

화면을 만드는 건 재미는 있는데 시간이 생각보다 많이 걸린다. React나 vue를 사용하면 조금 단축 되려나..

하나 하나 배우고 만들어 가면서 내가 모르는 기반 지식에 대한 갈증이 점점 커진다. CS지식이 중요하다는 얘기가 괜히 있는게 아닌 것 같다.

기본기와 CS 관련 지식을 열심히 공부해야겠다는 생각이 든다.

🍏 3. 배포와 테스트

우리는 한 달 가까운 기간 중 발표를 일주일 앞두고 웬만한 기능을 거의 완성했다. 발표 일주일 전 부터는 프로젝트를 배포하고 테스트 기간을 갖기로 했다.

배포는 세미 프로젝트 때 배포를 경험해봤던 내가 맡아서 진행했다. 역시 경험이 중요하다고 한 번 해보니 두 번째 진행할 때는 훨씬 수월하게 진행했다!

배포를 하면서 진짜 우여곡절이 많았는데, SQL을 사용할 때 로컬에서 진행할 때는 문제없었던 쿼리들이 자꾸 예외를 발생시켰다.

리눅스에서는 SQL의 자동 형변환을 지원하지 않는건지 타입이 안맞는 데이터를 비교한 부분에서 어김없이 예외가 발생했다.

내가 담당한 부분이 아니라 다같이 모여서 문제를 찾고 수정했다.

배포 후에는 계속해서 테스트를 진행하며 오류나 보완할 점을 찾았다. 테스트 코드를 작성해뒀으면 이렇게까지 힘들지 않았을텐데 짧은 기간동안 프로젝트를 2번이나 진행하다보니

배울 수 있는 부분이 한정됐던게 아쉬웠다.

일주일이라는 기간동안 어마어마한 오류들과 문제점들을 찾아 수정하고 보완했다. 덕분에 발표날 단 하나의 예외도 발생하지 않았다.

우리팀은 그렇게 파이널 프로젝트 1등을 차지했다.

한 달이라는 짧으면 짧고 길면 긴 시간동안 정말 즐거운 시간이었다. 물론 육체적으로 힘들긴 했지만

다들 마음이 잘 맞았고, 열심히 해서 얼굴을 찌푸릴 일이 하나도 없었다.

이런 팀원들을 또 만날 수 있을까싶다.

프로젝트를 진행하면서 좋았던 점, 아쉬웠던 점, 고쳐야 할 점이 많이 있었다.

KPT 방식으로 정리 해봤다.

prompt:tip KPT 방식은 keep, Problem, try의 약자로 3가지 관점에서 상황을 분석하는 회고 방법론이다

🌱 KPT

🍏 Keep

트렐로와 WBS를 통한 일정 관리
- 트렐로와 WBS를 이용하면서 나 뿐만 아니라 팀원들의 진행 상황까지 파악할 수 있어, 일정 조율과 관리에서 편리함을 느꼈다.
명명 규칙 설정
- 프로젝트의 규칙을 통일하는 것이 중요하다는 것을 알게됐다.
회의록 및 프로젝트 기반 내용 문서화
- 대부분의 내용을 문서화하여 회고를 작성하는 지금도 프로젝트의 진행 상황을 확인할 수 있었다.
테스트 기간
- 테스트 기간을 갖고, 오류와 문제를 찾아서 개선한 점
팀원간의 원활한 소통
- 작은 사항이라도 모두 팀원과 회의를 통해 결정한 점

🍏 Problem

RestAPI 규칙 미준수한 점
트러블슈팅 기록을 철저하게 하지 못한 점
와이어 프레임을 너무 상세하게 만들었던 점
DB 정규화 과정을 상세하게 하지 못한 점
Test 코드 미작성
기능의 양에 집중한 점

🍏 Try

RestAPI 규칙에 맞게 리팩토링
Github Issue 탭 활용한 트러블 슈팅 기록
DB 정규화 과정에 맞게 시도
JUnit을 활용한 테스트 코드 작성, 테스트 커버리지 70% 이상 달성
기능의 양보다 질에 집중하기, 경우의 수 철저하게 확인하기

🌱 마무리

즐거운 만큼 아쉬운 점도 많았던 프로젝트였다. 학원을 수료하고 여러 공부를 진행하면서 프로젝트에서 아쉬운 점이 많이 보였다. 기능 구현에 집중하느라 중요한 것을 많이 놓치기도 했다. 테스트 코드를 작성해봤다면, RestAPI에 대해서 공부하고 구현했다면, SpringBoot를 배웠다면 등등..

고칠 점도 많이 보였다. 리팩토링의 중요성도 깨닫게 되었다. 물론 실무자가 본다면 그냥 다시 만드는게 나을 프로젝트일 수도 있지만 그래도 이 작은 프로젝트를 하면서 많은 것을 배웠다. 커뮤니케이션의 중요성도 느꼈다. 내가 아무리 열심히 해도 팀 프로젝트에서 팀원이 누구냐에 따라서 결과물은 천차만별로 달라질 수 있을 것 같다.

마지막으로 프로젝트를 끝마치면서 배우고 싶은 것들이 많이 생겼다.

테스트 코드 작성 방법, JUnit 활용하기
- 실무에서는 테스트 코드 작성이 필수라는 것을 알게됐다. 학원에서는 아무래도 일정이 빡빡하다보니 Test 코드에 관련된 건 배우지 못했다. 따로 공부해서 작은 프로젝트를 만들어 봐야겠다.
SpringBoot 공부하기
- 우리 프로젝트는 Spring Legacy Project로 진행됐다. 수료를 하고 대부분의 회사에서는 Boot를 사용한다는 것을 알게됐다. 어쩐지 이름이 Legacy더라.. Boot 사용법과, JPA, Gradle 등의 사용법을 배워야겠다.
RestAPI 공부하기
- Get과 Post만 사용해서 요청을 주고 받았는데 RestAPI에 대해 알게됐다. 알고나서 보니까 내 코드가 너무 조잡해보였다. RestAPI에 대해 공부하고 리팩토링을 진행해야겠다.

그 외에도 해보고싶고 배우고 싶은 것들이 너무 많다. 개발자는 평생 공부해야한다더니 정말 맞는 말인 것 같다. 차근 차근 다 배워야지!!

모든 취준생들 다 화이팅이다!!

파이널 프로젝트(farmfarm) 회고