1. 프로젝트 설명

해당 프로젝트는

인터파크 서비스 중 티켓팅 서비스에 대한 클론 코딩 서비스

입니다. 인터파크 티켓팅 서비스를 클론하고자 했던 이유는 동시성, 이미지 저장 및 처리 등 경험해볼 수 있는 것이 많다고 느꼈고 재미있을 것 같다고 생각하여 클론하고 했습니다.

구현 하고자 했던 기능들은 관리자가 뮤지컬과 스케줄을 등록하고 유저가 원하는 뮤지컬의 스케줄과 좌석을 선택하고 예매를 하는 기능입니다.

사용된 기술 스택은 아래와 같습니다.

백엔드 서버 구현을 위해서 Java/Spring 기술 스택을 사용했고 build tool은 Gradle을 이용했습니다.

RDBMS는 MySQL 8.0을 이용했으며 데이터 중심이 아닌 객체지향에 포커스를 맞추기 위해서 JPA (Hibernate)를 이용했습니다.

DevOps 환경은 서버 구동을 위한 EC2와 RDB 관리를 위한 서버로써 RDS를 이용했습니다. 그리고 CloudWatch를 통해서 AWS UI를 통해 로그 모니터링이 가능하도록 설정했고 ci/cd를 위해 docker와 git actions을 사용합니다. 마지막으로 jacoco를 이용해 코드 커버리지를 고려했습니다.

협업툴은 notion, slack, github project를 이용했고 프로젝트 버전 관리를 위해서 github를 이용했습니다.

🔗프로젝트 Github 링크

https://github.com/prgrms-be-devcourse/BE-03-InterMark

2. KPT

🛒Keep

페어 프로그래밍: 이번 프로젝트에서 예매 기능과 유저에 관한 기능들은 3명, 2명으로 나뉘어서 페어 프로그래밍을 진행했습니다. 이 때, 페어를 한 팀원에게 배운 점이 많다고 생각합니다. 페어를 한 팀원은 저보다 코드를 잘 읽었는다고 느꼈고 코드를 작성하는 것 만큼 읽고 이해하는 능력이 중요하구나를 느꼈습니다.
페어 프로그래밍의 단점도 명확하다고 생각합니다. 개발 속도가 많이 느려진다는 점입니다. 하지만 그 단점을 장점이 넘어선다고 생각하기에 어렵거나 중요한 기능에 대해서는 팀원들과 페어 프로그래밍을 통해서 많은 사람들의 생각을 반영해서 발생할 수 있는 문제들을 줄이는 것이 좋을 것 같다고 느꼈습니다.

프로젝트 초반의 짧은 스프린트: 이번 프로젝트 당시 초반 스프린트 기간을 3-4일 정도로 짧게 가져갔습니다. 그래서 회고를 자주하게 되었는데 협업 방식의 문제점도 느꼈고 설계도 잘못되었구나를 느꼈습니다.
하지만 스프린트를 짧게 가져감으로써 빠른 회고를 통해서 이를 최대한 이른 시간에 다잡을 수 있었다는 생각이 듭니다.

감정 회고: 프로젝트 중간에 팀원들이 느끼고 있는 감정들에 대한 회고를 진행한 적이 있었습니다. 대부분의 팀원들이 별다른 말을 하지 않았지만 한 팀원이 스프린트를 너무 빡빡하게 가져가는 것 같고 PR 코드리뷰를 너무 독촉하는 것 같다라고 말했습니다. 다른 팀원들도 해당 의견에 수긍했고 그 이후로 PR이 좀 더 꼼꼼하게 작성되고 팀 분위기도 많이 바뀌었다고 느꼈습니다.
이런 감정 회고를 하되 정말 진실되게 속마음을 다 터놓고 말하는 것이 좋다고 느꼈습니다. 말하는 사람도 감정 해소가 되고 듣는 사람도 놓친 부분이 있었구나를 알게 되어서 좋았습니다.

팀원들의 개발 속도를 생각: 팀원들의 개발 속도를 파악하고 그것을 고려해서 스프린트 일정을 잡은 것이 좋았습니다. 널널해서 좋은 것이 아니라 개발 속도가 느릴 수 있음을 이해하고 팀의 최대한의 속도를 이끌어냈다는 생각이 듭니다.

❌Problem

도메인에 대한 이해 부족: 팀원들 모두가 도메인에 대해 전반적으로 이해도가 떨어졌다고 생각합니다. 그 이유는 클론 코딩 프로젝트임에도 인터파크 서비스에 대해서 제대로 뜯어보지 않았기 때문이라고 생각합니다. 인터파크 서비스에 대해서 알아오기라고 따로따로 하는 것이 아니라 해당 서비스를 같이 보면서 세세하게 뜯어보고 그 기능을 우리 코드, 생각대로 흉내내는 것이 클론 코딩이라고 생각하는데 그런 과정이 없었다는 부분이 아쉽습니다.

너무 큰 ERD와 잘못된 MoSCoW 파악: 먼저 처음에 너무 크게 ERD를 설계했고 그걸 토대로 MoSCoW를 너무 CRUD에 초점을 맞추고 계획해서 모든 엔티티에 대한 CRUD 기능만 구현하고 조금 더 도전적이고 경험하지 않은 부분들, 생각해보지 않은 부분들에 대한 시도가 적었다는 생각이 듭니다. Must have를 정말 해당 서비스를 배포할 수 있기 위해서 최소한 필요한 기능을 생각하고 선정했으면 어땠을까라는 생각이 듭니다.

초기 프로젝트에 대한 기반 설계 부족: 첫 협업 프로젝트이다 보니까 팀원들 모두 의욕도 넘쳤고 빨리 구현하고 싶다는 마음이 강했다 보니까 생각하고 가야하는 부분들을 놓쳤습니다. 코드 컨벤션, 테스트 컨벤션, 패키지 구조, PR 코드리뷰 시 approve 기준 등 놓치고 가니까 프로젝트 중간에 계속 언급되었던 것 같습니다.

🗻Try

(위 문제들에 대한 부분 외의 부분)

문제에 대해서 의견을 나누는 시간: 프로젝트 중 구현에도 시간이 빡빡하긴 하지만 그래도 고민, 배움에 대한 시간 투자를 해야 프로젝트에 대해서 할 말이 있다고 느낍니다. 어떤 문제가 발생했고 그 문제를 해결하기 위해선 어떤 기술들이 필요하고 그 중 어떤 기술을 어떤 이유로 선택했고 결과적으로 이런 방식으로 해결했다라는 이야깃거리를 만들면 좋을 것 같습니다.

3. 느낀점

: 처음 경험해본 협업 프로젝트다 보니까 부족했던 부분들이 너무 많았다는 생각이 듭니다. 프로젝트 진짜 망했다는 느낌도 받았고 진짜 잘하고 있다는 느낌도 받았습니다. 너무 잘하고 싶다는 생각, 많이 얻어가고 싶다는 생각, 빨리 구현하고 싶다는 생각이 뒤섞이면서 갈피를 못잡았던 것 같습니다. 프로젝트 중에 많은 생각들을 했는데 느낀점에서는 개인적인 부분( 내가 부족했던 부분, 내가 만족했던 부분 등 )만 작성하겠습니다.

1. 서비스에 대한 관심

: 사실 저희가 정했던 인터파크라는 서비스를 딱 한 번 써본적이 있을 정도로 잘 모르는 서비스였습니다. 그러다 보니까 프로젝트를 진행하면서 어떤 프로세스로 진행되어야 하는 지 이해를 하지 못한 부분도 있었고 왜 이렇게 설계 해야하는지 이해가 되지 않는 부분도 있었던 것 같습니다.

멘토님께서 관심있는 도메인의 회사로 가라고 하셨는데 그 이유가 뭔지 알겠다고 느꼈던 부분이 흥미가 조금씩 떨어지니까 프로젝트 진행에도 영향이 갔습니다. 뭘 해야할지 모르겠고 의욕도 나지 않았던 것 같습니다.

2. 기능 개발 코드과 테스트 코드를 같이 짜기

: 이번 프로젝트를 하면서 느꼈던 가장 큰 부분입니다. 저는 기능 코드를 다 짜고 나서 테스트 코드를 짜기 시작했는데 이렇게 되니까 다시 한번 더 기능에 대해서 코드를 보면서 이해를 하고 테스트 코드를 짜게 되어서 비효율적이라고 느꼈고 (기능 코드를 짤 때 그 순간이 가장 해당 기능에 대한 이해도가 높은 시기인 것 같습니다.) 테스트 코드만 짜고 있다 보니까 흥미가 더 떨어지는 듯한 느낌을 받았습니다.

3. 트러블 및 공부한 부분 문서화

: 매 과제와 프로젝트마다 문서화하자 문서화하자 말만 하고 제대로 이행하지 못했는데 이번 프로젝트도 문서화를 제대로 하지 못했습니다. 나중에 다시 생각하고 쓸려고 하니 그때 어떤 고민을 했었는지 기억도 잘 안나고,,, 진짜 오늘부터 지금 이순간부터 모든 생각을 문서화 하겠다 다짐합니다,,,

4. 스크럼 마스터

: 이번 프로젝트에서 스크럼 마스터를 맡게 되었는데 제가 생각했던 SM보다 더 해야할 일이 많다는 것을 느꼈습니다(사실 스크럼만 진행하면 되는 줄 알았는데,,,) 결정을 내려야 하는 순간도 많았고 팀원 모두를 이해시키고 설득해야하는 순간도 있었습니다. 이런 경험을 하면서 스크럼 마스터로써 너무 부족하구나를 많이 느꼈고 어떤 방식으로 협업을 해야할 지 많이 생각을 했던 것 같습니다. 그 생각들을 적어보겠습니다.

스크럼 시간은 짧게 가져가는 것이 좋을 것 같습니다.: 스크럼이란 것이 매일 어떤 일을 할 것이고 어제 어떤 일을 했는지 일정을 공유하고 어려운 부분이 있는지 공유하는 시간이기에 길어질수록 분위기도 처지고 그 분위기가 이어져서 업무에도 영향을 끼치는 것 같습니다.

그렇다고 무조건 짧게 빨리는 좋은 것 같지 않습니다.: 회의가 처지는 느낌이 들어서 팀원들의 의견을 많이 묻지 않으면서 후다닥 끝냈던 적이 있었는데 그 회의에서 정말 얻은 것이 하나도 없고 해결된 것도 없다는 것을 많이 느꼈습니다. 그래서 회의가 처지지 않게끔 중간에서 SM이 잘 조절해야겠다고 느꼈습니다.

스크럼 마스터가 기록까지 하기는 어렵다,,,: 회의를 진행하면서 기록까지 하려고 했는데 그러다 보니까 회의에 공백 시간도 생기고 문서화도 제대로 되지 않는다고 느껴서 다음 프로젝트 진행 시엔 전문 서무가 한명 필요하겠구나 느꼈습니다.

책임감도 있어야 하고 리더쉽도 있어야 하는 자리에 앉게 되면서 후회도 많이 하고 제 부족함에 대해서 많이 느꼈습니다. 그래서 팀원들에게 미안한 순간들도 많았지만 이 부족했던 경험을 토대로 다음에도 한번 해보고 싶다는 생각도 들었던 것 같습니다.

마지막으로 프로젝트를 하면서 감정적으로 힘든 부분들이 많았습니다. (불안하고 답답하고 이게 맞나라는 생각) 근데

팀원들이 파이팅하면서 분위기를 환기시켜줘서 끝까지 프로젝트를 할 수 있었던 것 같습니다. 너무 고맙습니다.

요번 협업 경험을 토대로 다음 최종 프로젝트도 잘 해보고 싶다는 생각이 듭니다. 파이티이이잉~~

Uploaded by

N2T

이왕할꺼 제대로 하자.