[회고] SSAFY 2학기 특화 프로젝트 회고

1. 프로젝트 개요

프로젝트명 : NAEDA (내다)

서비스 개요 : 얼굴로 결제하고, 구미 지역경제를 살리는 지역 특화 금융 앱

내용 : 페이스페이로 결제할 때마다 포인트가 쌓이고, AI가 소비를 분석해주며, 모은 포인트를 구미 지역 상품권으로 교환하는 핀테크 서비스

Spring Boot 메인 서버 + FastAPI AI 서버 + Android 앱(사용자/단말기) + POS 웹으로 구성된 MSA 풀스택 프로젝트로, 26.02.11 ~ 03.29, 약 7주간 진행 (SSAFY 14기 특화 프로젝트)

---

2. 프로젝트 요약

프로젝트 수치 정리

항목	수치
총 커밋 수	981개
전체 기간	47일 (2/11 ~ 3/29, 아이디어 회의 2주 포함)
개발 기간	34일 (2/24 ~ 3/29, 첫 커밋 기준)
브랜치 수	18+개 (feature 브랜치 포함)
팀 인원	6명
컴포넌트	5개 (Backend, AI 서버, 사용자 앱, 단말기 앱, POS 웹)

---

팀원별 커밋 기여도

팀원	커밋 수	주요 담당
김*재	~204	Backend (계좌·이체·거래·FDS·포인트·챗봇)
성*훈	~183	AI + Frontend (얼굴인식·OCR·Liveness·소비분석)
김*우	~177	단말기 앱 + Frontend (포인트 상점·소비 리포트)
조*희	~167	Android 사용자 앱 (회원가입·자산·결제 UI)
이*혁	~141	Backend + Infra (인증·JWT·EC2·매장·Kafka)
김*영	~116	Backend (결제 엔진·FCM·POS·카드·OCR)

※ 본인은 결제 엔진을 메인으로, 필요에 따라 FE·AI까지 넘나든 백엔드 중심 풀스택 포지션

---

주별 커밋 추이

기간	주차 설명	추이	커밋 건 수	비고
2/11-2/16	초기 아이디어	░░░░░░░░░░░░░░░░░░░░	0건	브레인스토밍 회의
2/17-2/23	아이디어 확정	░░░░░░░░░░░░░░░░░░░░	0건	주제 확정 (회의)
2/24-3/1	설계·환경구축	█░░░░░░░░░░░░░░░░░░░	11건	기획 확정·세팅
3/2-3/8	기반 구축	███████████░░░░░░░░░	109건	뱅킹·인증·회원가입
3/9-3/15	결제·AI 연동	█████████████░░░░░░░	124건	결제 엔진·FDS·얼굴검증
3/16-3/22	기능 확장	████████████░░░░░░░░	121건	FCM·챗봇·앱 UI
3/23-3/29	QA·마무리	████████████████████	196건	버그 수정·발표 준비

---

기술 스택

분류	기술	버전	핵심 선정 이유
Backend	Java + Spring Boot	17 / 3.5.11	금융권 표준, SSAFY API 연동, Spring Security
	PostgreSQL	-	트랜잭션 안정성, 관계형 데이터
	Redis	-	결제 요청 상태 관리(TTL) + RefreshToken 저장
	JWT (JJWT)	0.12.6	Stateless 멀티 클라이언트 인증
	Firebase Admin (FCM)	9.4.3	결제/공지/축제 푸시 알림
	Kafka	spring-kafka	결제 후처리 이벤트 발행 (비동기)
AI 서버	FastAPI + Python	0.116.1	얼굴 인식·ML 라이브러리 통합, MSA 분리
	InsightFace	0.7.3	얼굴 벡터 추출·매칭 (512차원)
	PaddleOCR	2.8.1	신분증 OCR
	OpenAI API	-	구미 AI 챗봇
	OpenCV / onnxruntime	4.10 / 1.22	Liveness 검증, 모델 추론
사용자 앱	Kotlin + Compose	Latest	Google 공식, CameraX 직접 접근
단말기 앱	Kotlin + Compose	Latest	사용자 앱과 스택 통일, 얼굴 결제
POS 웹	React + Vite	19 / 6	포스기 결제 요청 생성 화면
Infra	Docker Compose, EC2, GitLab CI/CD	-	배포 자동화, SSAFY 인프라

---

아키텍처

[사용자 앱 - Android]              [단말기 앱 - Android]        [POS 웹 - React]
 얼굴등록/뱅킹/포인트/리포트         얼굴인식/전자서명/결제       결제요청 생성
         │                              │                          │
         └──────────────┬───────────────┴──────────────────────────┘
                        ▼
              [Spring Boot 메인 서버]
              뱅킹 · 결제엔진(RBA) · 포인트 · FCM · 인증(JWT) · Kafka
                        │
              ┌─────────┴─────────┐
              ▼                   ▼
      [FastAPI AI 서버]     [PostgreSQL + Redis]
       얼굴인식 · Liveness   사용자·계좌·거래·포인트
       OCR · 소비분석·챗봇   얼굴벡터(암호화)·결제요청(TTL)

---

3. 프로젝트 타임라인

: 26.02.11 ~ 26.03.29 (7주) 동안 진행된 SSAFY 14기 특화 프로젝트 "NAEDA (내다)" 의 타임라인 (아이디어 회의 약 2주 + 개발 약 5주)

---

[ 1주차 (26.02.11 ~ 26.02.16) ] - 초기 아이디어 브레인스토밍 단계

팀 커밋 0건 (기획 회의 단계)

주요 활동

날짜	활동
02.11	15여 개 아이디어 브레인스토밍 — 목적 제한 환급(블록체인), 랜선 집사, 자취생 예산 코치, 페이스페이, AI 신용평가, M&A 인수합병, 스마트팜, 페이앱 등
02.12	후보를 3개(랜선 집사 / 자취생 예산 / 페이스페이)로 압축

난관

• 압도적인 지지를 받는 아이템이 없어 의견이 분산됐다.
• 블록체인을 넣을지 말지가 계속 논쟁거리였다. "핀테크 80% + 블록체인 20%" 같은 절충안도 나왔지만 현실적 문제가 걸렸다.

코치/컨설턴트 피드백

• 컨설턴트님: "블록체인을 깔짝 넣을 거면 넣지 말고 핀테크만 해라. AI·데이터 쪽에 초점을 맞춰라."
• 코치님: "은행 앱을 완성도 있게 만들고 AI 기능을 더하는 방향도 좋다."

1차 결론

• 블록체인은 과감히 제외하고 핀테크 + AI로 방향을 좁혔다.
• 후보를 랜선 집사·자취생 예산·페이스페이 3개로 압축하고, 각 아이디어를 다음 주에 심화하기로 했다.

회고

첫 주는 "판을 벌리는 주간" 이었다.

별의별 아이디어가 다 나왔고, 특히 블록체인을 얹을지 말지로 시간을 꽤 썼다.

결국 "깔짝 넣을 거면 빼라"는 피드백에 블록체인을 접고 핀테크·AI로 좁힌 게 이후 방향을 정리해준 결정이었다.

---

[ 2주차 (26.02.17 ~ 26.02.23) ] - 아이디어 심화 및 주제 확정 단계

팀 커밋 0건 (기획 회의 단계)

주요 활동

날짜	활동
02.19	3개 후보 심화 논의 (랜선 집사 / 자취생 예산 / 페이스페이) + 얼굴 인식 정산·은행 기본 앱 등 추가 검토
02.23	팀원별 최종 의견 취합 → 페이스페이로 주제 확정, 이어 "페이스페이 지역 특화" vs "여행 예산 관리" 비교

후보별 검토

• 랜선 집사(투명 후원 핀테크) — 후원금 사용처를 투명하게 공개하는 콘셉트는 좋았으나, 발표 시 공격 포인트가 많아 접었다.
• 자취생 예산 관리 — 앱으로서 꾸준히 쓸 만하다는 평은 있었지만, 볼륨이 작다는 지적에 부딪혔다.
• 페이스페이(+ 얼굴 인증) — 가장 재밌지만 정확도·신뢰도가 최대 난제였다. 화장·마스크·모자 같은 변수, 쌍둥이 오인식, 2차 인증 필요성 논쟁이 이어졌다.

코치/컨설턴트 피드백

• 컨설턴트님: "도전할 거면 해봐도 된다. 다만 걱정이 80%다. 40일 안에 페이스페이가 가능하겠나?" — 정확도를 못 챙길 거면 하지 말라는 냉정한 조언.
• "쌍둥이도 인식 가능하다는 걸 보여주면 게임 끝", "이거 잘 만들면 토스 면접 가서 물어볼 거다" 같은 기대 섞인 피드백도 있었다.

팀원별 의견 (02.23)

팀원	의견
성*훈	페이스페이 강력 지지 — 포인트·후원 연계 아이디어
조*희	페이스페이 지지 — "부족해도 부족한 대로 가보자"
김*재	페이스페이 + 블루투스 비콘 기반 2차 인증 아이디어
김*영	페이스페이 + 구미시 크라우드펀딩·지역 연계 제안
김*우	지문페이 검토 — 지문 인식기 필요·정확도 한계로 보류
이*혁	자취생 예산 볼륨업 주장 (카드 연동까지)

결론

• 일단 주제를 페이스페이로 확정했다.
• 지역 특화 방향이 붙으면서 "여행 예산 관리"는 화면상 보여줄 게 없다는 이유로 탈락했다.
• 코치님 조언 반영: Flutter 대신 안드로이드 네이티브, 데이터 방대함을 고려해 구미 지역으로 한정, 얼굴 인식 정확도에 집중.

회고

2주차는 "주제를 못 박는 주간" 이었다.

세 후보를 놓고 공격 포인트를 하나씩 따져보며 페이스페이로 좁혀갔다.

개인적으로 뿌듯한 건, 내가 낸 "페이스페이 + 구미 크라우드펀딩·지역 연계" 아이디어가 최종 콘셉트인 구미 지역 특화의 씨앗이 됐다는 점이다.

"얼굴 결제"라는 도전적 기술에 "구미 지역경제"라는 이야기가 붙으면서, 단순 토스 클론이 아닌 우리만의 색이 생겼다.

---

[ 3주차 (26.02.24 ~ 26.03.01) ] - 기획 확정 및 설계·환경 구축 단계

팀 커밋 11건 | 내 커밋 (김*영) 1건

팀 주요 활동

날짜	활동	담당
02.24	프로젝트 구조 초기화, BE/FE 프로젝트 생성	김*재, 김*영
02.25~27	아키텍처 문서 작성, README·gitignore 정리, docker-compose로 Postgres 초기 환경 구성	김*재, 이*혁
02.26	페이스페이 + 지역 특화로 주제 최종 픽스, 2차 인증(전화번호 앞 4자리)·정확도·단말기 방향 확정	팀 전체

팀 난관

• 얼굴 결제 + 지역경제라는 넓은 기획을 남은 약 한 달 안에 담아야 해서, 기능 우선순위 를 나누는 데 시간이 필요했다.
• Backend ↔ AI ↔ Android 3자 간 API 명세를 어디까지 확정하고 개발을 시작할지 감을 잡기 어려웠다.
• 02.26 회의에서 "단말기 앱" 의 정의가 명확해졌다 — 단순 관리 앱이 아니라 실제 매장에 놓이는 "단말기"여야 한다는 것.

해결 방법

• 페이스페이 결제 전체 플로우를 Must로 못 박고, 나머지는 뒤로 미루는 방식으로 범위를 정리했다.
• ERD와 API 명세를 우선 초안 수준으로 잡고, docker-compose로 로컬 DB 환경부터 통일했다.
• 정확도 강조 피드백("토스 수준이 아니면 안 된다")에 따라, 얼굴을 정면·상하좌우로 촬영해 벡터를 쌓는 등록 방식을 설계에 반영했다.

결과

• 프로젝트 뼈대(Spring Boot / Android / AI / infra) 세팅 완료
• 기능 우선순위와 개발 로드맵 확정, 각자 담당 영역 배분

회고

3주차는 "판을 까는 주간" 이었다.

2주간의 회의로 주제가 페이스페이 + 구미 지역 특화로 확정됐고, 이제 실제 코드로 옮길 준비를 했다.

---

[ 4주차 (26.03.02 ~ 26.03.08) ] - 기반 구축 단계

팀 커밋 109건 | 내 커밋 (김*영) 3건

팀 주요 활동

날짜	활동	담당
03.03~04	얼굴 등록 중계 API, 얼굴 벡터 암호화 저장	김*영
03.06	계좌·이체·거래내역(TransactionLog) API 전면 구현 (EntityController테스트)	김*재
03.06	로그인 API, JWT Provider·SecurityConfig, RefreshToken Redis 저장	이*혁
03.06	회원가입 8단계 화면, 디자인 시스템·네비게이션 세팅	조*희
03.06	단말기 앱 기본 구현, AI-BE 폴백 전략	김*우, 성*훈

03.03·03.04에는 개발과 병행해 기획을 다듬는 피드백 회의도 있었다.

코치/컨설턴트 피드백 (03.03~04)

• AI 챗봇은 RAG로 — 구미 지역 데이터에 한정해 정확한 답을 내려면, 챗봇을 RAG 방식으로 구미 특화 데이터에 학습시키는 게 맞다는 방향을 잡았다.
• 코치님 브레인스토밍 — "당근처럼 구미 안에서 서로 거래", "라면 축제 같은 데서 바로 결제(당시엔 QR)", "구미 지역 상권을 살리는 느낌으로 가라". → 지역 특화의 방향이 '상권 살리기'로 구체화됐다.
• 근거를 남겨라 — "정확도를 개선할 때마다 사진과 수치를 기록해 두라", "판단 기준 수치에는 왜 그 값인지 이유가 있어야 한다". 일란성 쌍둥이 테스트(주변 지인 중 없으면 당근으로라도 찾아보자)도 숙제로 나왔다.
• DB 정리 지적 — 체크/신용카드 결제 내역이 섞여 있으니 분리할 거면 제대로, 포인트 잔액은 사용자당 1:1, FDS 이상거래의 "탐지 후 액션"이 정의 안 됨, 알림 종류·제목 정보 부재 등

팀 난관

• SSAFY 금융 API 응답 형태를 파악하며 계좌·이체·거래내역 도메인을 한 번에 쌓아야 했다.
• 얼굴 인식(AI 서버)과 메인 서버 사이의 연동 규약(등록/매칭 요청·응답)을 처음 맞추는 과정에서 시행착오가 있었다.
• 기획이 완전히 확정되기 전에 개발을 시작해, 개발과 기획 수정이 동시에 굴러갔다. (챗봇 방식·구미 볼륨·DB 구조 등이 이 주에 바뀜)

해결 방법

• Backend는 도메인별로 Entity → Repository → Service → Controller → 테스트를 세트로 쌓아 올려 일관성을 확보했다.
• AI 연동은 폴백 전략(AI 실패 시 대응)을 먼저 정해 통합 리스크를 낮췄다.
• 결제 인증 정책을 회의에서 확정했다. (얼굴 등록 후 1차 전화번호(디폴트) + 2차 PIN 6자리, 거래가 생기면 FCM 알림 발송)

결과

• Backend: 계좌·이체·거래내역·인증(JWT) API 기반 완성
• Android: 회원가입 플로우 8단계 화면, 디자인 시스템 구축
• AI/단말기: 얼굴 검증 파이프라인·단말기 기본 플로우 착수
• 기획: 챗봇 RAG 방향, 구미 지역 상권 콘셉트, 결제 인증 정책 확정

회고

4주차는 각자 자기 영역의 토대를 쌓는 주간이자, 기획을 개발과 병행해 다듬은 주간이었다.

나는 얼굴 결제의 초입인 "얼굴 등록 중계"와 "얼굴 벡터 암호화 저장"을 맡았다.

원본 이미지는 저장하지 않고 암호화된 벡터만 보관한다는 설계를, 실제 코드로 옮기면서 생체정보를 다루는 감각을 처음 익혔다.

한편 회의에서 챗봇을 RAG로 가자, 구미 상권을 살리는 방향으로 가자는 피드백이 나오면서 기획도 함께 움직였다.

기획이 덜 굳은 채로 개발을 시작하여 이 주에 방향이 여러 번 바뀌었지만, 덕분에 "구미 지역 특화"라는 색이 더 선명해졌다.

---

[ 5주차 (26.03.09 ~ 26.03.15) ] - 결제 엔진 & AI 연동 단계

팀 커밋 124건 | 내 커밋 (김*영) 13건

팀 주요 활동

날짜	활동	담당
03.09~10	결제 엔진 전면 구현 (매장 조회, 결제 entity, Redis 결제 상태관리, 단말기 폴링, 계좌이체 연동, 결제 시나리오 완성)	김*영
03.10	RBA 추가 인증 화면(PIN/전화번호/전자서명), 포인트 상품 구매·주문 API	조*희, 김*재
03.11	FDS 룰 평가 엔진 (Strategy 패턴 - 심야/빈도/금액 이상 탐지), FDS 결제 통합	김*재
03.11	얼굴 검증 테스트 페이지, 로그인 서버 연결, 앱 배포서버 연결	성*훈
03.10~13	EC2 세팅, DDL 스키마 최종 반영, 소비 분석 AI API, 자산/계좌 상세 화면	이*혁, 성*훈, 조*희

팀 난관

• 포스기(웹) → 단말기(앱) → 서버로 이어지는 결제 상태 흐름을 어떻게 안전하게 관리할지가 핵심 난제였다. 상태가 꼬이면 이중 결제나 유령 결제가 생길 수 있었다.
• FDS(이상거래 탐지)를 결제 프로세스 어디에 끼워 넣을지, AI 얼굴 검증과 순서를 어떻게 둘지 조율이 필요했다.

해결 방법

• 결제 요청을 Redis에 상태 머신으로 관리하고, 단말기가 상태를 폴링하도록 설계했다.
• FDS는 Strategy 패턴으로 룰별(심야·빈도·금액)로 분리해 확장 가능하게 만들고, 결제 프로세스에 점수 기반으로 통합했다.

결과

• 결제 전체 플로우 동작 (요청 생성 → 폴링 → 얼굴 매칭 → 결제 → 상태 갱신)
• FDS 룰 엔진, RBA 추가 인증 화면, 포인트 상품 구매까지 결합
• EC2 배포 환경·소비 분석 AI 착수

회고

5주차는 프로젝트에서 내 역할이 큰 주간이었다.

프로젝트의 심장인 결제 엔진을 이 한 주에 몰아서 만들었다.

동시에 FDS, RBA 인증 화면, 얼굴 검증이 결제 파이프라인 위에서 하나로 붙기 시작하면서, "이게 진짜 되는구나"를 체감한 주였다.

---

나의 5주차 활동 정리

주요 활동

날짜	시간	커밋	내용
03.09	09:32	Feat	Store Repository·Entity 구현 (매장 도메인)
03.09	10:20	Feat	매장 조회 API — Controller/Service 추가
03.09	16:14	Feat	결제 API 전면 추가 (entity·repository 포함)
03.10	10:58	Feat	Redis 기반 결제 요청 저장 및 상태 관리
03.10	13:43	Feat	결제 요청 생성 및 단말기 폴링 API
03.10	14:40	Feat	계좌이체 API 연동 및 결제 내역 저장
03.10	16:19	Feat	결제 시나리오 완성
03.11	09:58	Fix	거래기록·중복거래 방지 버그 해결
03.11	12:28	Feat	POS 포스기 웹 화면

난관

• 결제 상태 관리 — 요청이 PENDING에서 시작해 아무 상태로나 튀지 않게, "허용된 전이"만 통과시켜야 했다.
• 중복 거래 방지 — 단말기 폴링 구조 특성상 같은 결제가 두 번 처리될 위험이 있었다.

해결 방법

• PaymentRequestRedisService에 상태 전이 규칙을 못박았다.

  PENDING    → PROCESSING
  PROCESSING → SUCCESS | FAILED | BLOCKED
  SUCCESS / FAILED / BLOCKED → (종료, 전이 불가)

• 허용되지 않은 전이는 예외로 막고, Redis TTL(기본 30초) 로 방치된 요청은 자동 만료시켰다. 매장별 인덱스도 따로 뒀다.

결과

• 포스기 → 단말기 → 서버로 이어지는 결제 상태 흐름 안정화
• 결제 시나리오(정상/실패/차단) 전체 완성, 중복 거래 방지

회고

결제 상태를 Redis 상태 머신으로 설계한 경험이 좋은 배움이었다.

처음엔 "그냥 DB에 상태 컬럼 하나 두면 되지 않나" 싶었지만, 짧은 수명의 결제 요청·폴링·TTL을 생각하면 Redis가 맞았다.

무엇보다 테스트를 함께 쌓아 둔 덕분에, 다음에 결제 시나리오를 통째로 갈아엎을 때도 괜찮았다.

---

[ 6주차 (26.03.16 ~ 26.03.22) ] - 기능 확장 단계

팀 커밋 121건 | 내 커밋 (김*영) 6건

팀 주요 활동

날짜	활동	담당
03.16~20	FCM 알림 체계 (축제·공지·결제 성공 푸시), 관리자 페이지 1차	김*영, 이*혁
03.19~20	알림 설정·배송 주소 도메인, 구미 AI 챗봇(OpenAI), 홈 화면 챗봇	김*재
03.19~20	얼굴 등록 화면 고도화, 단말기·얼굴 검증 강화	성*훈
03.19~22	결제 확인·2차 인증 화면, 카드 등록 연동, 알림 설정 화면, 홈 화면	조*희
03.19~20	매장 등록, 회원 탈퇴 API, Kafka Docker 설정, 포인트 상점 연동	이*혁, 김*우

팀 난관

• FCM을 결제·공지·축제 등 여러 트리거에 붙이면서, 알림 발송 시점과 실패 처리를 정리해야 했다.
• 기능이 폭발적으로 늘면서 알림 설정·배송 주소 등 부가 도메인과 결제 후처리(Kafka)까지 붙어 시스템이 복잡해졌다.

해결 방법

• 결제 성공 이벤트에 FCM 발송을 연결하되, 발송 실패가 결제 자체를 막지 않도록 try-catch로 분리했다.
• 결제 후처리를 Kafka 이벤트로 비동기 발행해 결제 응답 속도와 부가 작업을 분리했다.

결과

• FCM: 결제 완료·공지·축제 알림이 실제 폰에 도착하는 것 확인
• 구미 AI 챗봇, 알림 설정/배송 주소, 카드 등록, 2차 인증 화면 등 기능 대폭 확장

회고

6주차는 "결제가 끝난 다음"을 채우는 주간이었다.

결제만으로는 서비스가 완성되지 않는다.

알림이 오고, 포인트가 쌓이고, 챗봇이 매장을 추천해줘야 앱다워진다.

나는 FCM을 결제·공지·축제에 붙이는 일을 맡았는데, 내 코드가 만든 알림이 실제로 폰에 뜨는 걸 봤을 때 신기하고 좋았다.

기능이 빠르게 늘면서 즐거웠지만, 동시에 "이걸 다음 주에 다 안정화할 수 있을까" 하는 불안도 함께 커졌다.

---

나의 6주차 활동 정리

주요 활동

날짜	시간	커밋	내용
03.16	14:38	Feat	축제 FCM 발송 API
03.16	17:29	Feat	공지사항 알림 전송용 API
03.17	12:45	Feat	관리자 페이지 1차 구현
03.20	10:49	Feat	결제 FCM 발송 API 완성

난관

• Firebase Admin SDK 세팅(google-services)과 의존성 충돌로 초기에 발송이 안 됐다.
• 결제 성공 시점에 알림을 붙이되, 알림 실패가 결제 트랜잭션에 영향을 주지 않게 분리해야 했다.

해결 방법

• google-services·의존성을 정리해 Firebase 초기화를 잡고, 이벤트 기반으로 FCM 발송을 결제 로직에서 떼어냈다.

결과

• 결제/공지/축제 3종 FCM 발송 완성, 관리자 페이지 기반 마련

회고

FCM은 "되게 만드는 것"보다 "안정적으로 붙이는 것"이 어려웠다.

초기 세팅에서 한참 헤맸지만, 한 번 파이프라인이 뚫리자 공지·축제까지 빠르게 확장할 수 있었다.

결제 후처리를 이벤트로 떼어낸 경험은 "결제 응답은 빠르게, 부가 작업은 뒤에서"라는 감각을 잡게 해줬다.

---

[ 7주차 (26.03.23 ~ 26.03.29) ] - QA 및 마무리 단계

팀 커밋 196건 | 내 커밋 (김*영) 38건

팀 주요 활동

날짜	활동	담당
03.23~24	관리자 공지사항 CRUD & FCM, 회원가입 중복 처리, 맛집 데이터	김*영
03.25~26	맛집 정보 저장, 홈/스플래시/전체 UI 개선, 결제 후처리 Kafka 복원	성*훈, 조*희, 이*혁
03.27	OCR(신분증) 성능 강화, 단말기 Liveness 추가, 비밀번호 찾기 화면, 다크모드	성*훈, 조*희, 김*영
03.28	OCR 강화, 입금내역 조회, 거래내역·카테고리 수정, 카드 내역 수정	성*훈, 이*혁, 김*영
03.29	카드 삭제, 카테고리 변경, 페이스페이 등록 수정, 비밀번호 파트 최종 수정, 포팅 매뉴얼	이*혁, 성*훈, 김*영

QA 버그 백로그 (일부)

발표 주에는 전 화면을 훑으며 50여 개 버그를 리스트업해 팀이 나눠 잡았다.

대표적인 것들:

• 페이스페이 결제가 아예 매치 안 될 때 30초를 안 기다리고 바로 넘어감
• 페이스페이 결제 시 포인트 적립이 안 됨, 거래내역에 적립 포인트가 중복 표시
• 알림 설정을 꺼도 알림이 발송됨, 안 읽은 알림 개수 미표시
• 포인트 주문 500 에러, 포인트 내역 보기 튕김
• 결제 상세에 매장 이름 대신 매장번호 노출, 거래내역에 실패 건까지 표시
• 구미시 소식이 최신순으로 정렬 안 됨, 지도 필터 UI·확대 범위 문제
• PIN 재등록 시 틀린 번호를 쳐도 넘어감

팀 난관

• OCR 반복 튜닝 - 신분증 OCR이 현장 사진 품질에 따라 계속 어긋나 여러 명이 며칠간 반복 수정했다.
• 막판 통합 충돌 - 각자 만든 기능을 dev에 몰아서 합치니 카드·맛집·비밀번호 파트에서 버그가 연쇄적으로 터졌다.
• 비밀번호 찾기 로직 - 발표 직전까지 인증 로직이 계속 어긋나, fix_pw 브랜치에서 밤새 수정과 롤백을 반복했다.
• QA 물량 - 결제·포인트·알림·지도 전 영역에서 자잘한 버그가 쏟아져, 50여 개 백로그를 파트별로 나눠 처리해야 했다.

해결 방법

• OCR은 PaddleOCR 파라미터와 전처리를 조정하며 반복 튜닝, Liveness를 단말기에 추가해 위조를 걸렀다.
• 막판 버그는 브랜치를 분리(fix_pw, card_error_fix, ocr_fix)해 파트별로 격리하고, 안 되면 과감히 롤백했다.
• 포팅 매뉴얼과 시나리오를 정리하며 발표·데모 준비를 병행했다.

결과

• OCR·카드 내역·맛집·비밀번호 등 잔여 버그 대응, 발표 가능한 완성도 확보
• 포팅 매뉴얼·데모 시나리오 정리, 최종 배포

회고

7주차는 "통합의 주간" 이었다.

앞선 몇 주가 각자 쌓는 시간이었다면, 이 주는 그 조각들이 부딪힌 시간이다.

특히 발표 전날 밤(3/29), 비밀번호 찾기 로직을 붙잡고 fix, fix, fix... 를 반복하다 결국 rollback으로 마무리한 그 몇 시간이 프로젝트 통틀어 가장 시행착오가 많았다.

그럼에도 팀이 파트별로 브랜치를 나눠 격리하고, 안 되면 빠르게 되돌리는 판단을 하면서 끝내 발표를 했다.

---

나의 7주차 활동 정리

주요 활동

03.23 - 관리자 공지사항

시간	내용
02:30	관리자 공지사항 CRUD & FCM
02:36	공지사항 테스트 코드 추가
02:49	reference type 추가 (NOTICE)
03:26	API 공지사항 문서 추가

03.24~26 - FE 잔손질

시간	내용
03.24 15:51	회원가입 시 중복 오류 처리
03.25 09:38	맛집 부분 추가 (BE)
03.25 10:39	웹 화면 전면 수정
03.26 15:20	효과음 변경 / 구미시 소식 최신순 정렬

03.27 - OCR 지옥

시간	내용
14:02	비밀번호 변경 API
16:01	OCR 파트
16:11	OCR 파트 재수정
16:30	OCR 오류 수정
16:52	OCR 수정
17:21	OCR 재차 수정
17:37	OCR 재재재수정

03.28~29 - 카드 & 비밀번호 지옥

시간	내용
03.28 22:39	카드 결제 로그 에러 수정
03.28 23:10	카드 내역 조회 수정
03.28 23:50	카드 수정
03.29 22:08	비밀번호 찾기 로직 변경
03.29 22:42	fix
03.29 23:02	fix
03.29 23:10	rollback

난관

• OCR - 3/27 오후, 신분증 OCR을 한 시간 반 동안 6번 연속 고쳤다. 커밋 메시지가 '재수정'을 지나 '재재재수정'까지 갔다. 익숙하지 않은 Python/AI 파트라 더 헤맸다.
• 카드 내역 - 외부(SSAFY) 카드 API 응답 형태에 계속 끌려다니며 3/28 밤 내내 반복 수정.
• 비밀번호 찾기 - 발표 전날 밤, 로직을 바꾸고 fix를 5번 넘게 반복하다 결국 롤백.

해결 방법

• OCR·카드·비밀번호를 각각 ocr_fix, card_error_fix, fix_pw 브랜치로 격리해 다른 파트 영향 없이 붙잡고 수정했다.
• 끝내 안 되는 부분은 자정을 넘겨 붙잡기보다 롤백으로 안전한 상태를 확보하는 판단을 했다.

결과

• 관리자 공지 CRUD, 비밀번호 변경 API 등 기능 마무리
• OCR·카드·맛집 잔여 버그 대응, 발표 데모 성공

회고

7주차(개발 마지막 주)는 나에게 가장 힘든 주간이었다.

구미시 소식 정렬·포인트 폰트 같은 자잘한 FE 버그부터 OCR·카드·비밀번호까지, 50여 개 백로그를 팀과 나눠 잡았다.

feat보다 fix가 많았고, 커밋 메시지에 제발·rollback이 등장한 게 이 주다.

특히 발표 전날 밤 비밀번호 파트를 붙잡던 시간이 힘들었던 기억이 난다.

여기서 배운 게 있다: 막판에 몰아서 합치면 반드시 터진다.

브랜치를 파트별로 격리한 덕분에 그나마 피해를 줄였고, "안 되면 되돌린다"는 판단이 살렸다.

다음 프로젝트에서는 통합을 훨씬 자주, 짧은 주기로 하기로 마음먹었다.

---

결과

---

📊 전체 요약

내 주별 커밋

주차	추이	커밋 건 수	내용
1~2주차	░░░░░░░░░░░░░░░░░░░░	0건	아이디어 회의 (구미 지역 특화 제안)
3주차	░░░░░░░░░░░░░░░░░░░░	1건 (2%)	기획 확정·환경 구축
4주차	██░░░░░░░░░░░░░░░░░░	3건 (5%)	얼굴 등록·벡터 암호화
5주차	███████░░░░░░░░░░░░░	13건 (21%)	결제 엔진·POS
6주차	███░░░░░░░░░░░░░░░░░	6건 (10%)	FCM·관리자 페이지
7주차	████████████████████	38건 (62%)	버그 대응·OCR·카드·비밀번호

feat 28 : fix 29 — 개발 커밋의 절반이 새 기능, 절반이 통합·버그 대응이었다.

내 핵심 기여 정리

영역	구현 기능
기획	페이스페이 + 구미 지역 특화 아이디어 제안
결제 엔진	Redis 기반 결제 요청 상태 머신(TTL), 단말기 폴링 API, 계좌이체 연동, 결제 시나리오, 중복 거래 방지
얼굴 결제	얼굴 등록 중계 API, 얼굴 벡터 암호화 저장·해석
매장/포인트	매장 조회 API(Store 도메인), 포인트 관련 처리
알림(FCM)	결제 완료·공지사항·축제 푸시, 관리자 공지 CRUD
AI	신분증 OCR(PaddleOCR) 튜닝
인증	비밀번호 변경·찾기 로직
Frontend	POS 웹(React/Vite) 결제 화면, 맛집·포인트·구미시 소식 등 앱 UI

마무리하며

약 7주(아이디어 회의 2주 + 개발 5주)라는 짧은 기간에 얼굴 결제라는 도전적인 주제를 끝까지 밀어붙여 데모까지 성공시킨 것 자체가 값진 경험이었다.

블록체인을 넣을지 말지부터 시작해 랜선 집사·자취생 예산·지문페이까지 온갖 아이디어를 저울질한 끝에 페이스페이로 좁혀갔고, 내가 낸 구미 지역 특화 페이스페이 아이디어가 최종 콘셉트가 된 것도 기억에 남는다.

나는 이 프로젝트에서 결제 엔진을 맡았다.

결제 요청을 Redis 상태 머신으로 설계하고, 그 위에 팀원들의 FDS·얼굴검증·RBA 인증이 붙어 하나의 결제 파이프라인이 되는 과정을 지켜본 게 뿌듯했다.

결제 엔진은 테스트를 함께 쌓아둔 덕에 막판까지 안 무너졌고, 테스트 없이 급하게 만든 카드·OCR·비밀번호 파트가 발표 직전에 무너졌다.

이 뚜렷한 대비가 이번 프로젝트의 가장 큰 교훈이다.

반성할 점도 분명하다.

API 명세를 처음부터 확실히 확정하지 못해 카드·OCR에서 응답 형태에 계속 끌려다녔고, 막판에 통합을 몰아서 하는 바람에 rollback 커밋을 남겼다.

그리고 각자가 BE·FE·AI를 다 건드린 건 풀스택 경험이었지만, 그만큼 어느 하나도 깊게 다지기 어려웠다.

다음 프로젝트에서는 ① API 명세를 Request/Response body까지 먼저 확정하고, ② 테스트를 처음부터 쌓고, ③ 통합을 짧은 주기로 자주 하기로 마음먹었다.