[팀 프로젝트-맴매] [개발 1주차] SALES에서 SOL·챗봇까지, 첫 주의 구현과 트러블슈팅

Об этом предложении

기간: 2026.09.21 ~ 09.27 (KST) 기준: 맴매 백엔드 저장소의 커밋과 이슈. 날짜는 코드 작업 기록을 기준으로 정리했다. 9월 21일, V1 매출 API DTO와 공통 응답을 만드는 커밋을 시작으로 맴매 백엔드 개발에 참여했다. 첫 주에는 토스 POS 파일을 받아 매출을 계산하는 SALES 흐름을 만들고, AI 예측·인사이트와 SOL, 챗봇으로 이어지는 접점을 붙였다. 기능이 빠르게 늘어난 만큼 설계 문서와 코드가 어긋나는 지점 을 확인하고 바로잡는 작업도 함께 진행했다. 이번 주에 진행한 일 날짜 주요 작업 9/21 토스 POS 엑셀 파서, SALES DTO·엔티티·Repository, 업로드와 기본 매출 분석, 조회 API, 전체 흐름 테스트 9/22 매출 원본 저장 키 충돌 방지, sales_uploads 엔티티와 최신 ERD 정합화 9/23 AI 매출 인사이트 요청·응답 DTO와 계약 테스트, 연동 문서 정리 9/24 매출 예측 저장 구조와 AI HTTP Adapter, SOL 엔티티·저장소·생성 계약 9/25 S3 원본 파일 저장, AI 인사이트 연동·재시도, SOL 생성·조회·저장 API 9/26 챗봇 메시지 저장·API, AI SSE 중계, 챗봇용 내부 매출 조회 API 9/27 배포 환경 점검용 QA 점주 계정 시더와 관련 테스트 첫날에는 POS 파일 파싱부터 업로드, 분석 조회까지 한 번 연결하는 데 집중했다. 실제 XLSX를 사용해 업로드 → 이력·상태 확인 → 분석 조회 흐름을 검증하는 테스트도 추가했다. 다만 당시 검증은 테스트 세션과 H2 기반이므로, 운영 MySQL 및 실제 로그인 환경에서의 동작과는 구분해야 한다. 트러블슈팅 1: 같은 파일을 다시 올릴 때 저장 키가 겹칠 위험 SALES 설계에서는 동일 파일 재업로드를 허용한다. 그런데 초기 로컬 저장 키는 매장 ID와 파일 체크섬만으로 만들었다. {storeId}/{checksum 앞 2자리}/{checksum}.xlsx 같은 파일의 체크섬은 같으므로 두 번째 업로드도 같은 객체 경로를 가리킨다. 업로드 이력마다 고유한 storage_key가 필요하다는 ERD 제약과도 충돌한다. 저장 키 수정 이슈 에서는 키에 UUID를 추가하고, 동일 파일을 연속 저장해도 다른 키를 반환하며 각각 다시 읽을 수 있는지 테스트했다. {storeId}/{checksum 앞 2자리}/{UUID}-{checksum}.xlsx 체크섬은 파일 내용의 식별·추적에 쓰고, 저장 키는 업로드 이력의 고유성 을 보장하도록 역할을 나눈 셈이다. 트러블슈팅 2: 구현 중인 엔티티와 최신 ERD가 달랐다 9월 22일에는 sales_uploads 엔티티가 최신 ERD와 다른 부분을 발견했다. 예를 들어 코드에는 applied_record_count, fail_reason과 정수형 행 수가 남아 있었고, 최신 문서는 valid_row_count, error_code와 BIGINT 행 수를 기준으로 했다. 문서와 코드 중 하나를 암묵적으로 기준 삼으면 업로드 이력 조회나 집계 쿼리에서 의미가 달라질 수 있다. 그래서 ERD 정합화 작업 에서 컬럼명·타입·제약을 맞추고 Repository의 합계 쿼리도 validRowCount 기준으로 수정했다. 기간 인덱스와 storage_key UNIQUE 제약도 반영했다. 설계 문서는 한 번 작성하고 끝나는 산출물이 아니었다. 파서와 업로드 정책이 구체화되면 ERD, 엔티티, 조회 쿼리, 테스트가 같은 의미를 가리키는지 다시 확인해야 한다. 트러블슈팅 3: AI 재시도가 매출 전체 재처리로 이어지면 안 됐다 초기 재시도 흐름에는 실패한 매출 분석을 다시 실행하는 방식이 있었다. 하지만 파일 검증과 기본 집계가 이미 완료된 상태에서 AI 인사이트만 실패했다면, 원본 파일을 다시 읽고 매출 집계를 교체할 이유가 없다. 그렇게 하면 정상 매출 데이터까지 불필요한 재처리 위험에 노출된다. 재시도 계약 교정 작업 에서는 저장된 집계 지표로 실패한 AI 인사이트만 다시 생성하도록 범위를 좁혔다. 재시도마다 새 analysis_runs를 만들고, 기존 실패 이력과 정상 집계는 보존한다. 진행 중인 중복 재시도도 별도 상태로 막는다. 이 변경으로 기본 매출의 완료 상태와 AI 결과의 상태를 따로 다뤄야 한다 는 설계 원칙이 코드 흐름에도 반영됐다. 돌아보며 첫 주는 SALES 데이터를 서비스의 기준값으로 만들고, 그 위에 AI 예측과 SOL을 연결한 기간이었다. 9월 26일에는 챗봇의 메시지 저장과 SSE 중계까지 붙여 점주가 분석 결과를 대화로 활용할 수 있는 경로도 만들었다. 가장 크게 배운 부분은 기능을 연결하는 속도만큼 경계 조건을 확인해야 한다는 점이다. 같은 파일을 다시 올릴 때 저장 키가 달라야 하는 이유, 설계 문서와 엔티티가 같은 뜻이어야 하는 이유, AI 실패가 매출 전체의 실패가 되어서는 안 되는 이유가 실제 코드 변경으로 이어졌다. 다음 주에도 새 기능의 수보다 데이터 정합성과 실패 후 복구 가능성 을 기준으로 구현을 점검하려 한다.

Детали предложения

Провайдер

velog

Источник

velog-rss