불안하고 아슬아슬했던 첫 프로젝트가 끝났습니다. 짧다면 짧고 길다면 긴 7주간의 기간 동안 최선을 다했지만 역시 항상 아쉬움이 남습니다. 아직 회고라는 단어가 어색하지만 그래도 회??????고????? 비스무리한 것을 해보겠습니다. 하고 싶은 말이 너무 많아서 완전 구구절절 다 쓸거에요.

💡프로젝트 소개

D3V[데:브]
하루 3개 질문으로 완성하는 개발자 면접 준비!

저희는 아이디어가.. 사실 엄청 많았습니다. 그 중 구체적인 기획을 진행했고 아쉬웠던 아이디어 먼저 소개해볼까 합니다.

[초등학생을 위한 경제 교육 서비스, Don'$ Touch Me!]

• 너무나도,, 유사한 서비스가 많았습니다
• 심지어 같은 SSAFY 내에서 진행한 프로젝트도 있었다는 점..!
• 도메인 지식 부족 + 구현 및 데이터에 매몰될 것 같다고 판단해 최종 탈락!

[방탈출 커뮤니티]

• 이 또한...! 유사한 서비스가 많았습니다.
• 기존 서비스 중에 생각한 기능 + α가 이미 있었습니다.
• 데이터를 어떻게 구할 것인가? + Pain Point 부족을 해결하지 못하고 최종 탈락!

[강제 긍정 SNS]

• 모든 부정적인 멘트를 긍정적으로 바꾸면 재밌겠다...에서 시작
• 근데 이걸 MVP로 들고가니.... 기술적 문제, 사용자 경험 등 다양한 걸림돌이 존재했습니다.
• 아이디어는 참신했으나? 다양한 걸림돌로 인해 최종 탈락! 하지만 정말 해보고 싶은 서비스에요

이 아이디어 외에도 수많은 아이디어를 논의하고 발전을 해보다 버리는 시간이 참 길었습니다. 타 팀이 아이디어를 정하기 시작하니 슬슬 불안하더라구요. 그래도 팀원들 덕분에 마음을 다 잡고 좋은 아이디어를 정했습니다.

[D3V]

• 왜?
  • 면접 준비는 미리 해야한다! 라는 생각은 모두가 가지고 있어요
  • 근데 막상 코테 붙고 면접까지 일주일 남은 시점... 치타마냥 일주일 동안 달립니다.
  • 코테는 백준, 리트코드 등 다양한 사이트가 있는데 왜 면접은 그런 사이트가 없을까?에서 시작됐습니다.
  • 그래서 모든 팀원들의 목표는 이 서비스로 실제로 면접 대비하자!라는 생각으로 개발했습니다.
• 기능
  • 매일 3개의 추천 질문 제공 (직무별)
  • 답변 기록 (음성,텍스트) 및 타임라인 기능
  • 질문 아카이빙 및 공유
  • AI 답변 피드백 + 사용자 간 피드백
• 기술 스택
  • 백엔드
    • Spring, Springboot, Spring Security, JPA, Querydsl
  • 프론트엔드
    • Typescript, React, Redux
  • 데이터베이스
    • PostgreSQL, Redis, H2
  • 인프라
    • Jenkins, AWS EC2, AWS S3, AWS Cloudfront, AWS Route53, Docker, Nginx

❓왜?

프로젝트 진행하면서 "왜?"라는 생각을 항시 염두해두고 진행했습니다. 그 "왜?"에 대한 정리입니다.

• 기술 스택 선정 기준

  • PostgreSQL
    사실 이전에 다들 MySQL만 써봤습니다! 궁금해서 PostgreSQL 썼어요! 라는 흐름을 기대하셨겠지만 정말 많은 생각을 하고 결정한 사안입니다. 이전에 데이터베이스 종류에 대한 글을 작성했을 때 이미 PostgreSQL을 사용하자고 결정한 후에 작성한 글인데 지금도 참 잘 선택했다 생각합니다. 저희 서비스는 "조회"가 가장 많을 것이라 생각했고 "조회" 성능이 정말 중요했습니다. 이 조회 최적화에 PostgreSQL에 장점이 있었고 면접 서비스에 VARCHAR 자료형이 정말 많이 사용되는데 PostgreSQL는 MySQL과 다르게 TEXT와 VARCHAR의 조회 성능에 차이가 없다는 근거로 PostgreSQL을 선택했습니다.

  • Querydsl
    Querydsl도 많은 생각이 있었습니다. 우선 JPA를 사용하면서 Querydsl을 사용하는 이유는 대부분이 아시 듯이 복잡한 쿼리를 Java 코드로 사용하고 싶어서! 입니다. 저희는 질문 엔티티에 정말 많은 연관관계가 있었는데 이 질문에 또 복잡한 로직이 몰빵되어 있기에 Querydsl을 선택했습니다. 실제로 복잡한 쿼리는 모두 Querydsl로 처리했습니다. 하지만! 저는 북마크를 구현하며 AccessLevel 로직 처리에 Querydsl을 사용하고 싶었으나 배포를 처음 해보며 여러...이슈가....발을 너무 묶어서 JPQL로 처리했습니다. 지금도 너무 아쉬운 경험입니다. 다음 프로젝트엔 꼭 공부해서 써봐야지.

  • React, Redux
    프론트 팀원들의 이야기를 옮기면, 새로운 기술 스택을 배우는 의미도 있지만 유지보수성과 상태 관리 측면에서 React와 Redux를 선택했다고 합니다.
    저희 서비스는 매일 새로운 질문을 제공하고, 사용자의 답변을 저장하며, AI 피드백을 추가하는 등 동적인 상태가 많았습니다. 이에 따라 컴포넌트 간 상태 관리를 명확하게 할 수 있는 도구가 필요했고, Redux를 선택하게 되었습니다.

• 컨벤션
  

  • 코드 컨벤션

    백엔드는 편하게 우테코 컨벤션을 사용했습니다. 설정 딸깍으로 해결할 수 있다는 점이 너무 매력적이었습니다. 회사에 입사하게 되면 컨벤션 배우느라 바쁘겠지만, 미리 설정해둘 수 있다면 컨벤션 신경 안쓰고 작성할 수 있어 좋다 생각합니다. 그 외에 메서드,클래스 명명법, DTO 네이밍, 디렉토리 구조 등 많은 컨벤션을 정하고 시작했습니다. 정할 때는 힘들지만 미리 안해두면 나중에 너무..힘들어진다 생각합니다.

  • 커밋 컨벤션
    팀원들의 동의 하에 정말 힘들 때 커밋 컨벤션을...지키지 않고 그냥 푸시한 기억이 있습니다 ㅎ 다들 재밌어 해줬지만 이러지 말아야겠다 생각합니다. 커밋 컨벤션은 나중에 로그 찾아보며 어떤 기능에 이상이 생겼는지 찾아볼 때 아주 유용했습니다. feat, fix, hotfix, refactor, docs, test, ci, chore, comment, remove 등 사용해봤는데 정상화의 범위에 있는 컨벤션이 왜 존재하는지 확실히 깨달을 수 있었습니다.

  • 브랜칭 전략
    저희는 git flow 전략을 채택했습니다. 브랜칭 전략 선택에 많은 생각이 있었는데, 우선 하나의 레포지토리에 프론트/백 같이 작업해야하는 특수한 상황, Git이 조금 어색했던 팀원들이 있었기에 전통적인 Git flow 방식을 따르는 것이 가장 안전한 선택이라 판단했습니다. 처음에는 다소 복잡하게 느껴지지만 각 기능과 버그 수정을 체계적으로 관리할 수 있었고 브랜치 꼬임과 충돌에서 많이 자유롭고 작업이 정리됐다는 느낌을 받았습니다.

• 그라운드 룰 + 개발 문화

  • 제가 팀장;;이었는데요. 제 기억으로는 유일하게 여러 번 말한 팀 문화는 모르면 화끈하게 공개하기 였습니다. 왜냐? 제가 그랬었으니까요. 학부 시절에 아무것도 모르겠는데 말도 못하고 답답했습니다. 그 때의 저를 제 팀원으로 받았으면 진짜 꿀밤 때리고 싶었을거에요. >>모르는 거 O, 모른 채 가만 있기 X<< 그 이후로 항상 마음 속에 품고 있는 대전제입니다. 지금도 모르는 것이 너무 많아 항상 이마에 ?를 써놓고 다닙니다.
  • 선칭찬 후 피드백 + 싸울 거 같으면 ~용체 사용. 제가 이 회고 글에서 제 개발 실력 자랑은 한 줄도 못쓰지만? 제 팀원들 자랑은 오천만줄 쓸 수 있습니다. 저희 팀은 싸움이 없었어요... 그래서 사실 이 규칙이 무용지물이었습니다. 모두 둥글둥글 행성같아서 좋았습니다.
  • 데일리 스크럼 + 스프린트 회고
    매일 오전에 무엇을 할지, 오후에 무엇을 했는지, 일주일 단위 스크럼이라 일주일마다 우리의 스프린트가 어땠는지! 시간을 가졌습니다. 처음 손발을 맞춰보기에 능률을 측정해두는 것이 굉장히 도움됐습니다. 또한 서로 어떤 일을 했고 어떤 일을 우선시해야하는지 소통이 바로바로 되었기에 충돌을 없애준 가장 큰 문화가 아닌가 생각합니다.
  • Jira 적극 활용 + 무조건 Merge Request + 코드 리뷰
    Jira의 고오급 옵션을 제공해주는 귀한 기회라 최대한 사용해보고자 Jira를 정말 열심히 사용했습니다. 그 결과 전국 18위, 반 1위의 이슈 수를 기록하며 프로젝트를 마무리했습니다. 아 정말 멋지다 우리 팀. 그리고 MR을 날리면 항시 코드 리뷰를 해주기로 했습니다. 저도 최대한 아는 범위 내 + 모르면 바로 질문 하는 리뷰를 많이 하려 노력했습니다. 하지만..역시! 마지막 주 쯤 되니 다들 바빠서 소홀해진 것이 아쉽습니다! 다음엔 좀 더 빠듯하게 일정을 잡아서 코드 리뷰 문화를 좀 더 성실히 수행해야겠습니다.

🐋배포

배포!!!!!!!!!!!!!!!!!!!!!!! 제가 맡겠다 했습니다. 너무 해보고 싶어서 제가 한다 했습니다... 아 이 내용은 눈물없이 작성할 수 없어서 나중에 총정리해서 링크 걸겠습니다.
그래도 우선 CI/CD를 경험했습니다. 젠킨스 할아버지 호락호락 하지 않더라구요.

배포 기한이 정해져있었는데 그 날까지 뭔가 너무 안되서 조금 늦은 기억이 있습니다. 경험이 정말 중요한 분야라고 생각합니다. 다음 프로젝트에서 배포를 맡게 될지 모르겠지만 한번 경험해보며 여러 문제를 겪어보니 한 3g 정도 자신감이 생긴 상태입니다. 주먹구구식으로 설정하고 배포한 느낌이었는데 나름 Jenkins 특정 IP에만 접속하게 해주고 cloudfront, Nginx 사용해서 https 설정해주고 다양하게 시도해봤습니다. 블루-그린 무중단 배포도 설정해보고 싶었는데 이건 시간날 때 한번 해봐야겠습니다.

배포가 제대로 안되서 팀원들이 많이 불편했을텐데도 많이 배려해줘서 너무 고마웠습니다.

이게 제가 처음에 생각한 아키텍쳐 구조였는데 보안 이슈로 개인 EC2에 접근이 힘들어 Jenkins를 서버^^ EC2^^에 같이 설치해서 동?작하는 제 생각엔 어색한 아키텍쳐로 완성되었습니다. 그래도 얼추! 유사하게 배포 파이프라인을 구성해서 혼자 만족하는 배포입니다. 지금보니 Nginx가 프론트엔드도 연결해주는 구조인데 완전 초반에 작성해서 어색한 부분이 눈에 띄네요.

Team. 9 to 6

이번 프로젝트에서 기술적 고민 (순환 참조, DDD 실패 경험 등)을 통한 성장도 작성하고 싶지만? 이미 따로 정리한 상태이고 velog에 따로 작성할 가능성이 높기에 이 글엔 가장 좋았던 점인 How to 협업에 대한 실마리를 마무리로 작성하고 싶습니다.

9 to 6 워라밸 지향팀이었지만 어쩌다보니 서로 자극받아 6 to 9 열정맨들이 되어버린 팀원들 덕분에 아주 좋은 프로젝트 경험을 할 수 있었습니다. 막판에 팀장 역할을 제대로 못했단 생각이 프로젝트 결과물 자체에 대한 자신감 부족으로 이어져 발표를 망칠 뻔 했지만? 우리 미친 (P) 팀원들 덕에 극복할 수 있었습니다.

✨ 마무리

이 프로젝트를 끝내고 돌아보니, 처음 기획할 때 가졌던 기대와 과정에서 겪었던 수많은 고민들이 한데 섞여 묘한 감정이 듭니다.

더 잘할 수 있었을까?
이 질문은 항상 따라오는 것 같습니다. 당연히 더 잘할 수 있었겠죠.
하지만 그 "더 잘할 수 있었을지 고민하는 과정 자체가 성장의 증거"라고 생각하기에,
이번 프로젝트에서의 시행착오도 소중한 경험으로 남았습니다.

더 배운 점이 있었을까?
배포부터 CI/CD, DB 설계, 코드 컨벤션, 협업 문화까지 정말 많은 걸 배웠습니다.
특히, 협업과 팀워크에서 얻은 인사이트가 가장 컸습니다.
혼자서 프로젝트를 진행했다면 절대 경험할 수 없었던 부분들이었고,
팀원들과 함께 문제를 해결하면서 기술적인 성장뿐만 아니라
"어떻게 더 나은 팀원이 될 수 있을까?"라는 고민도 할 수 있었습니다.

다음엔 어떤 개발자가 되고 싶을까?
다음 프로젝트에서는 좀 더 객관적인 시각으로 코드 품질과 프로젝트 구조를 볼 수 있는 개발자가 되고 싶습니다.
기능을 만드는 것도 중요하지만, "이 코드가 유지보수하기 좋은가?", "이 기술이 정말 최적의 선택인가?"
라는 질문을 더 많이 던지고 싶어요.

부족했던 점과 보완할 점
코드 리뷰 문화 강화: 막판에 바빠지면서 코드 리뷰를 소홀히 했던 점이 아쉬웠습니다.
배포 전략 개선: Jenkins를 처음 다루며 삽질을 많이 했는데, 다음엔 블루-그린 배포도 적용해보고 싶어요.
기능 기획의 현실적인 검토: 아이디어는 참신했지만, 개발 과정에서 예상보다 구현 난도가 높았던 부분이 많았습니다.
다음에는 MVP 단계부터 현실적인 범위를 더 철저히 검토해야겠다는 생각이 들었습니다.

찐막
이 프로젝트가 단순한 포트폴리오 이상의 의미로 남았으면 좋겠습니다.
결과물이 어떻게 평가되든 간에, 이 과정 속에서 얻은 성장과 팀원들과의 협업이 더 값진 것이었으니까요.
함께해준 팀원들 덕분에 정말 즐겁고 값진 경험이었습니다.