프론트엔드 : https://github.com/Capybara-Clinic/mnu_pub_order_system
백엔드 : https://github.com/Capybara-Clinic/capybara-qr-order
1. 시작 배경
졸업을 앞두고 추억 한번 만들어보자는 계기로 대동제에 노점을 열기로 했다. 단순히 음식을 파는 데서 끝내지 않고, 나름 전공인데 뭐라도 해야하지 않겠냐며 모바일 주문·결제 시스템을 도입하자고 제안했고, 그 제안을 실제로 구현하게 되었다.
2. 기획 단계
주제 선정
발주자와 사용자가 명확했기에 복잡한 기획 없이 바로 주문-결제 시스템을 만들기로 결정.
인원 배정
프론트엔드 팀, 백엔드 팀으로 나눴으며, 백엔드 인원중 한명이 DB 설계를 맡기로 함.
일정 계획
축제일인 6월 4일 전까지 완성. 마감은 5월 28일로 잡고 계획을 세움.
회고
실사용자가 곁에 있어 빠른 피드백이 가능했던 점은 장점.
그러나 일정이 촘촘하게 계획되진 않아 일정관리가 어렵게 느껴졌음.
백엔드를 맡은 2·3학년들에게 개념을 가르치는 데 많은 시간이 들었고, 그만큼 실제 구현 경험을 많이 주지 못한 것이 아쉬움.
3. 설계 단계
프론트엔드 산출물
- 와이어프레임
- 스토리보드
- 프로토타입
백엔드 산출물
- DB 설계
- API 기본 구조 정립
회고
산출물이 중간중간 빠졌고, 공유 위치도 통일되지 않아 팀 간 진행도를 파악하기 어려웠음.
팀 간 소통 공간이 제대로 정해지지 않은 것도 문제였음.
산출물 관리와 마일스톤 정의의 중요성을 절감.
4. 구현 단계
진행 과정
본격적으로 개발을 시작하면서 여러 이슈가 발생.
이슈 요약
스토리보드 불명확성
그림 중심의 추상적인 스토리보드가 이해를 방해하여 스크립트로 보완
→ 스토리보드 스크립트
API 문서 부재
프론트와 백 간의 연결을 위해 API 명세를 요청하고 작성
→ API 문서 (1차), 최종본
깃허브 충돌
서로 다른 루트 커밋으로 브랜치가 갈라짐.
→ 루트 커밋 강제 삭제
회고
이슈가 본격적으로 터지기 시작한 시기.
API 명세는 정말 필수라는 걸 체감했고, 미완성된 산출물조차 유용했다는 점이 역설적으로 느껴졌다.
그리고 백엔드에서 데이터를 거지같이 만들어서 주면 아무리 구조분해 할당을 해도 코드와 기분이 아주 더러워진다는 점도 알게됨.
원래는 모놀리식 아키텍처를 염두에 뒀으나, 사용자 기준으로 기능이 나뉘다 보니 결과적으로 MSA와 유사한 구조로 확장됨.
하지만 명확한 아키텍처 산출물 없이 진행하다 보니 설계에 일관성이 없어진 점은 아쉬움으로 남음.
5. 배포 단계
환경
AWS EC2 기반 배포.
주요 이슈 및 해결 과정
도커 제약 문제 (학교 실습용 서버)
인바운드/아웃바운드 포트가 한 개라는 제약으로 인해 운영 불가능
→ AWS로 변경하여 문제 해결
프론트 통합 실패로 사용자별 개별 서버 구성
형상관리 도중 병합 충돌, 병합한 코드가 제대로 작동하지 않는 문제
→ 각 사용자별 개별 서버 운영 및 포트 개방
EC2 메모리 부족
프론트 서버 메모리 점유율이 높아 백 엔드 서버가 구동되지 않음.
→ 메모리 크기를 늘린 인스턴스 신규 생성 및 이전으로 해결
실시간 장애 대응
테스트에서는 경험하지 못했던 케이스들이 다양하게 나타났음.
→ 장애 대응 기록 및 실시간 수정으로 어떻게든 해결
회고
버그가 알파/베타 테스트를 통과한 후에도 끊임없이 터졌다.
예상치 못한 상황, 특히 인터넷 연결 불안정 등은 사용자 경험에 큰 영향을 줬다.
QA 관점 테스트와 실제 운영 환경 테스트는 큰 차이가 있다는 걸 체감.
도커파일과 도커 컴포즈의 필요성을 뼈저리게 느꼈고, 다중 서버 관리에는 모니터링 도구도 필요하다는 교훈을 얻음.
접속 로그나 트래픽같은 걸 측정하지 못한게 너무 아쉬웠다.
6. 종합 회고
프로젝트는 졸업 전 마지막 팀 활동이자 실사용자를 위한 실전형 프로젝트였고, 동시에 개발과 운영을 총괄해본 경험이었다.
아쉬운 점은 많았지만, 오히려 그런 점에서 배우는 것도 많았다.
특히 기술에 욕심내서 오버 엔지니어링으로 완성하지 못하고 끝내는 것보다 차라리 덕지덕지 기워붙여서 어떻게는 동작하는 게 훨씬 나은 결과물인 것을 체감했다...
아키텍처 설계, 산출물 관리, 명세 문서화, 자동화 및 모니터링, 배포 전략 등 실무에서 필요한 요소들에서 내가 얼마나 부족한지 뼈저리게 깨닫게 되었다.
완전 자동 결제 시스템을 만들고 싶었는데, 사업자 등록되어야 가능한 이슈로 인해 사용자가 직접 송금시키고 캐셔가 수동으로 확인하는 방향으로 바뀌어서 아쉬웠다.
공부해볼 것들 키워드
SSE, 메세징 큐
MSA, 헥사고날 아키텍처, 도커 컴포즈, 오케스트레이션
CI/CD, 테스트 자동화
서버 모니터링
