[프로젝트 회고] Flowermari 꽃말 기반 꽃다발 생성 서비스

✅ Flowermari

✅ 프로젝트 설명

• 서비스 설명 : 생성형 AI를 활용한 꽃말 기반의 꽃다발 이미지 생성 서비스
• 기획 배경
  • 기존의 꽃다발을 선물하기 위해서는
    • 기존의 꽃다발은 꽃의 색과 형태에 주로 집중
    • 이미 만들어져 있는 꽃다발을 사는 경우도 많았음
    • 플로리스트에게 제작을 요청하고 싶어도 참고할 자료가 없었음
  • 우리의 서비스는
    • 사용자가 전달하고 싶은 마음을 꽃말 기반으로 꽃다발을 생성
    • 생성형 이미지로 제작하여 실제 꽃다발 주문제작에 참고 이미지를 제공
• 개발 기간 : 2024.02.26 ~ 4.04 (6주)
• 인원 : 6명

✅ 역할 (Infra / Backend)

• 인프라 구축 및 CI/CD 파이프라인 구축
• 인증 / 인가
• 꽃다발 검색 API

✅ 주요 기술 스택

Spring Boot, Spring Data JPA, Querydsl, Spring Security, JWT, Oauth2, MySQL

EC2, Nginx, Docker, Jenkins, Sonarqube

Gitlab, Jira, Notion

✅ System Architecture

✅ Keep

이번 프로젝트는 주어진 조건에서는 열심히 하였다고 생각한다. 취업 시즌에서 자기소개서, 이력서, 포트폴리오, 코딩테스트 준비 등 프로젝트 외적으로 신경써야 할 것들이 너무 많다보니, 나를 포함한 모든 팀원들이 프로젝트에 집중하지 못했었다. 프로젝트 완성도가 떨어졌지만, 이런 타이밍에 인프라 및 CI/CD 경험을 가져갈 수 있었던 것은 다행이라고 생각한다.

기술

1. 리눅스 기반 Linux, Docker, Nginx, Jenkins에 대한 학습하면서 개발

2. 젠킨스를 활용한 CD 파이프라인 구성

3. 멀티브랜치 파이프라인 적용

   • 저번 COMEET 프로젝트에서는 모든 브랜치를 dev 브랜치, main 브랜치를 기준으로 배포하였다. 그러나 이번 프로젝트에서는 frontend, main server, ai-server 기준으로 모두 브랜치를 다르게 가져가며 배포하는 멀티브랜치 파이프라인 전력을 선택했다. 또한 main back server는 dev와 deploy를 각각 두어 서버 상에서의 테스트를 거친 후에 dev에서 deploy로 push 하도록 아키텍처를 구성하였다.

   • 배포 브랜치

     • back-deploy
     • back-dev
     • front
     • ai-deploy (이는 AI 담당자가 진행)

4. DockerFile, Docker Hub repository를 활용한 배포 버전 관리
   

5. Docker Compose를 활용한 버전 관리, 한번에 컨테이너 관리

6. private repository에 설정파일 동시에 관리하여 변경 생겼을 때 자동으로 업데이트하는 파이프라인 구축

   

7. Sonarqube 활용한 정적 소스코드 분석을 통한 코드 품질 향상
   

8. querydsl을 활용한 동적 쿼리 작성

9. 이외 팀에서 얻은 기술적 성장

   • AI : Stable Diffusion Model 학습
   • Back : SSE, Redis Pub/Sub
   • Front : Styled Component, 라이브러리 사용하지 않은 순수 TypeScript와 CSS로 제작

전략

• 같이 프로젝트를 하며, 한 팀원의 마인드를 많이 배우게 되었다. 꽃다발 도메인 지식이 부족하다면서, 문제 해결을 위해 화훼 기능사까지 공부하여 기술에 적용하는 것을 보며 작은 충격을 받았다. SW 기술외에 도메인 지식을 공부하는데에 거부감이 없고 능동적이고 다각적으로 문제 해결을 하려는 태도로 접근할 필요를 느꼈다.

• 설계 단계에서 이번 프로젝트에서 주어진 시간에 알맞는 볼륨을 적절하게 가져갈 수 있었다.

협력

• 매일 아침 스크럼을 하면서 소통하고, 가벼운 업무 진행현황도 공유하였다.
• 어떠한 문제가 생겼을 때 2시간 이상 고민하게 되면 꼭 도움을 요청하도록 하였다.

✅ Problem

결론부터 말하면 프로젝트 자체만 놓고 보면 실패한 프로젝트라고 생각한다. 다들 고생하였지만 각자 아쉬운 부분이 분명 많았을 것이라고 생각한다. 이번 회고 글에는 정말 솔직한 마음으로 작성하고자 한다.

그리고 개인적으로 맡지 않은 부분에서도 아쉬움이 있다면 작성하였다. 되도록 나의 부족함만을 반추하고 개인적인 내용만 회고하는 것이 좋다는 것을 알지만, 마지막으로 진행하게 되는 다음 프로젝트에서 1명을 제외한 팀원 빼고 멤버 변동이 없기 때문에 . 또한 아래에 작성한 내용들은 팀원들과의 긴 대화를 통해 나옹 내용을 취합한 것이기도 하다. 더 솔직하게 회고해야 다음 프로젝트에서 같은 실수를 반복하지 않으며 성장할 수 있을 것이라 우리는 믿는다!

우리가 꼽은 가장 큰 문제는 가장 큰 문제는 프론트 파트, 백 파트의 리더가 없었고 이를 전체적으로 아우르는 PM이 없었다는 것이었다. 즉, 업무 분담 및 전체 플로우를 이해하는 사람이 부재했었다. 지라가 있었지만 전체 일정을 잡는 것이 아니라, 각자 스프린트 단위 내에서 스토리 포인트 단위로만 업무를 스스로 배정하다보니 프론트엔드, 백엔드, AI의 개발 및 통합 테스트 타이밍이 맞지 않는 경우가 많았다. 또한 취업 기간으로 인한 프로젝트 투입 시간 및 노력 부족 & 이로 인한 초반 설계 미흡한 점도 있었다.

기술

• 인프라 세팅 완료 후, 블루 그린 무중단 배포를 해보고 싶었으나 백엔드 팀원이 해결하지 못한 업무를 맡게 되어 진행하지 못한 아쉬움이 있다. 이는 다음 프로젝트에서 적용해보고자 한다.

• 트러블 슈팅 시 back 서버 log를 인프라가 계속 확인해야했다. 이로 인해 에러 책임을 빠르게 알기 어려워 트러블 슈팅에 불필요한 딜레이가 자주 발생하였다.

• 여러 사용자들의 요청에 대한 동시성 처리 불가했다. 이는 AI 서버가 주어진 GPU 환경 내에서 구동하여 동시 처리가 불가능하여 어쩔수 없는 부분이었다.

• 프로젝트 시간 부족에 의한 CI 및 테스트 코드가 여전히 부재하였고, 결국 성능 테스트를 제대로 진행하지 못했다.

전략

• 저번 COMEET 프로젝트에 비해 프론트, 백 모두 설계에 들인 노력이 미흡했다고 생각한다.

  • 프론트엔드의 경우 피그마, 와이어 프레임이 사용자 워크 플로우에 따른 UX/UI가 고려되어있지 않아 추후에 코드를 수정해야하는 일이 많았다.

  • 백엔드의 경우 한 팀원이 2일간 디자인을 맡게 되면서 다른 한 팀원 혼자서 기능 명세서, API 명세서를 작성하게 되었는데, 이 때 다른 팀원들의 검토가 미흡하여 나중에 프론트에서 해당 명세서만을 참고하여 개발을 진행할 수 없었다. 요약하자면 문서로서의 기능을 하지 못한 것이다.

• 전반적으로 일정 관리가 제대로 되지 않았다.

  • 프론트 : 백 코드는 완성이 되었으나 프론트가 처음으로 React + Typescript로 개발하여 늦게 완성이 되었다. 이 때문에 통신 테스트가 늦춰졌었다.
  • 백 : 충분한 테스트 과정을 거치지 않아 로컬 내부에서 생기는 문제를 확인하지 못하여 통신 테스트에서 생기는 문제가 있었다.
  • 인프라 : 인프라 역시 서버가 전체적으로 정상 작동하는데 EC2 나오고 2주가량 걸렸다. EC2가 늦게 나온다는 것을 감안했을 때 조금 더 당겼어야 하지 않았나라는 아쉬움이 있다.

• 이건 실패요인보다는 아쉬움인데, 외부적으로 제한조건이 너무 많았다.

  • EC2 서버가 생각보다 늦게 나왔고 처음 인프라를 구축하는 과정에서 2주 조금 넘게 시간이 걸렸다. 때문에 프론트 / 백이 로컬에서 테스트를 할 수 밖에 없었다.
  • GPU 서버가 제공이 늦었고, 이에 대한 정보를 주지 않아 AI 테스트 및 기능 제한이 있을 수 밖에 없었다. 다행히 AI 담당자가 빠르게 대응해주었다.

• 팀원들이 포스트맨 사용이 익숙하지 않은 상황에서 swagger 대신 포스트맨을 사용하여 제대로 활용하지 못했었다.
  

• Admin 계정의 필요성

  • 이번에 프로젝트 도중 인증/인가를 급하게 맡게 되면서 카카오 소셜 로그인으로만 인증인가를 사용하게 되었다. 이때 admin 계정을 따로 만들지 않아 테스트에 반드시 필요한 로그인 과정에서 불편함이 있어, 소셜로그인을 거치지 않는 로그인 프로세스를 만들 필요성을 느꼈다.

협력

• PM의 역할의 부재
• 소통 문제
  • 프론트는 잘 모르겠지만 백 간의 소통이 잘 안되었다고 생각한다. 기존에 미리 말했던 내용이 공유가 되지 않아 나중에 다른 말이 나오는 경우가 많았다. 결국 우리가 설계 단계에서 명확히 하지 않았던 것들이 되돌아왔다.

✅ Try

위에 너무 부정적인 피드백들만 작성을 한 것 같지만, 오히려 반대이다! 이러한 문제를 우리는 해결할 수 있는 준비가 되어있다. 정확히 문제가 무엇인지 파악하였고, 이번 프로젝트에 아쉬움이 있는 만큼 다음 프로젝트를 더 열심히 하고 싶은 마음이 있기 때문이다.

한 멤버를 제외하면 팀 멤버 변동 없이 마지막 프로젝트에 들어가게 되는 만큼 장단점이 확실하다고 생각한다. 장점은 서로의 특징, 강약점을 잘 알고, 이에 따른 적절한 업무배분이 가능하다는 것이다. 또한 이번 프로젝트에서 아쉬웠던 부분을 확실하게 개선하고자 하는 공감대가 형성되었다는 것이다.

그러나 그만큼 이번 프로젝트와 매우 다르고 기발한 결과물이 나오는 것을 기대하기는 어려울 것이다. 또한 새로 들어오는 친구가 마지막 면접만을 남기고 들어오는 상황인 만큼 6인이 아닌 5인으로 진행할 확률이 높다는 리스크가 있다.. 이를 잘 고려하여 설계단계부터 탄탄하게 가져가보자!

기술

• 인프라

  • 실시간 로깅 모니터링
    • Grafana Loki & Promtail
  • Spring Cloud Config 로 application.yml 공유

• 백

  • 기술
    • Swagger 재도입
    • Flyway 사용 필요한지 검토
      • https://engineerinsight.tistory.com/206
  • 로깅
    • logback xml 배워서 적용해보기
  • Admin 계정
    • ROLE_ADMIN을 만들거나
    • 따로 admin login controller를 만들어 관리하기
  • 리팩토링에서 적용하고 싶은 내용
    • 멀티 모듈 프로젝트

전략

• 요구사항 명세서 → 기능 명세서 → ERD / 화면 정의서 → API 명세서 순서로 차례대로 설계

• 프론트

  • 공개된 다른 프로젝트나 (우테코 등) 참고 사이트를 보면서 UI나 컴포넌트 구성을 좀 많이 참고

• 백

  • 다음 프로젝트 주제를 먼저 확인해야겠지만, 가능하다면 서버를 역할별로 나누어 관리해보고자 한다.

  • 백 컨벤션을 초반에 더 제대로 맞춰야할 것 같다. 이번에 인프라 세팅을 완료하고 확인해보니 컨벤션이 제대로 맞춰져있지 않고 지켜지지도 않고 있었다. 추후라도 백엔드로 합류할 예정인 내가 중간중간 확인하지 못한 잘못도 있었다.

  • COMEET에서 진행했던 것 처럼 백 Validation을 제대로 적용할 필요가 있다.

• 팀 관리

  • 프론트에서 A가 팀장을 맡아 전체적으로 필요한 우선순위를 파악하여 소통하여 B에게 업무를 부여하는 역할을 확실히 주는 방식을 택해야 할 것 같다. C는 기능 단위, 기술적으로 집중할 수 있으니 고려하여 업무 배분을 하면 되지 않을까 생각한다.

  • 백엔드는 EC2가 나오기 전에 모두 모여서 패키지 구조와 기본 엔티티 틀을 짜고 나서 각자의 기능 구현으로 넘어가보자.

    • 패키지구조
    • 엔티티
    • 기본 Service, Controller, Repository
    • 공통 에러 핸들링

• 기타

  • 주어진 도메인 말고, 서비스 명을 담은 도메인 구매하서 서비스답게 진행해보자!

협력

• 내가 전체 PM을 맡아야 할 것 같다. 적절하게 업무를 배분하고 백, 프론트 파트별로 관리하는 사람을 두어 중간 다리 역할을 가져가도록 해야 할 것 같다.

• 아침 스크럼을 제외하고 퇴근 직전에 금일 진행된 내용을 확인하는 절차도 가져가면 더 밀도있게 진행할 수 있다는 생각도 들었다.

• 한 팀원의 공통 프로젝트 노션 정리가 정말 잘 되어 있었다. 능력자 분이 계셨다고 하는데, 이를 많이 레퍼런스 삼아 문서 정리를 제대로 해보고자 한다.

✅ 소감

☘️ 인프라를 맡아 리눅스 환경에서 개발을 진행하고 서버를 구축하면서 어플리케이션에만 갖혀있던 시야가 넓어질 수 있는 좋은 경험이었다. 백엔드 엔지니어가 되기 위해서는 인프라에 대한 이해도 높아야 한다는 말이 있듯이, 이번 프로젝트를 진행하면서 보다 배포, 테스트, 로깅, 모니터링에 대한 공부를 진행하고 싶은 욕구가 생겨났다.

☘️ 이번에 팀원들과 회고를 진행하면서 프로젝트는 결국 협력이라는 것을 다시금 깨닫게 되었다. 각 팀원들은 성격도 다르고 잘하고 좋아하는 것도 달랐으며 남모르게 힘들었던 부분도 달랐다. 100의 능력을 가진 두명이 모여서 150밖에 만들어내지 못한다면, 멋진 프로젝트를 만들어내기 위해 300의 능력의 가진 사람을 찾는 것이 무엇이 중요할까? 차라리 나와 내 팀원이 어떤 것이 부족하고 어떤 것을 어려워하는지 알고 이를 어떻게 해쳐나가야 할지 고민하는 것이 좋지 않을까?

☘️ 퇴사한지 얼마 되지도 않은 것 같은데 싸피가 2달도 남지 않았다는 사실이 믿기지 않는다. 그러나 그 사이에 성장한 내 모습을 보면 열심히 하긴 했구나라는 부끄러운 뿌듯함이 있다. 결국 나를 제일 잘 알아줄 수 있는 건 내 자신인 만큼 고생한건 고생했다고 인정해주고 보듬아 주는 것도 나여야 할 것이다. 나를 포함한 싸피 친구들 모두 힘들고 많이 지쳐보인다. 얼어붙은 취업 시장이 얼마나 지속될지는 아무도 모르기에 우리는 내일만을 바라보고 달려서는 안될 것이다.

예전 학원 선생님과 오랜만에 전화를 했다. 잘 버텨보겠다고 한 내 말에 "뭘 버티냐, 지금 성장하는 시간을 누구보다 즐겨야지" 라고 하셨다. 좋아하는 일을 하기 위해 나온 내 마음, 어찌보면 초심을 잊지 않고 낭만처럼 소중히 지키고 이뻐해야겠다고 늘 다짐하는 요즘이다. 공부하는 것은 힘들지만 즐겁다. 프로젝트는 지치지만 즐겁다. 창진이와 이야기 할 때도 느꼈다. 힘들어도 즐거운게 맞다고.

너무 글이 길었다. 생각이 많은 요즘이다! 날씨가 좋으니 더 싱숭생숭한가보다 ㅎㅎ

내일도 어김없이 키보드를 두드리다 ⌨️ 해를 쬐고 ☀️ 물을 마시고 🫙 노래를 듣자 🎧 :)