쉼표가 바꾼 아리랑 음표 45개의 시작 박
아리랑에서 음 길이만 이어 붙였을 때 시작 시각이 최대 1.04초 어긋났습니다. 원래 시작 박을 전달하고, 악보 데이터가 시드까지 보존되는지 확인한 과정입니다.
분류
Backend
이 주제로 남긴 기록 42편
Spring 테스트 53개 실패와 MySQL 연결 한도
얼쑤의 MySQL 통합 테스트 174개 중 53개가 실패한 기록을 바탕으로, Spring이 캐시한 컨텍스트의 연결 풀이 어떻게 DB 한도에 닿는지 살펴봅니다.
1.76MB 곡 목록에서 악보 덜어내기
111곡 목록에서 악보 본문을 분리한 이유와 Nginx gzip 적용 뒤 운영 응답의 전송량을 확인한 방법을 정리했습니다.
녹음 재분석에서 결과가 섞이지 않게
얼쑤에서 같은 녹음으로 분석을 재시도하고, 시도 번호와 마감 조건으로 늦은 결과가 새 시도를 덮지 않게 한 과정을 소개합니다.
API 명세 68페이지에서 팀 수정 148곳 지키기
공유 API 명세를 대량 교정하며 현재 문구와 교정 전 문구를 대조하고, 저장한 결과를 다시 읽어 누락과 오타를 찾았습니다.
고치기 전에 실패해야 증거가 되는 테스트
테스트가 통과했다고 버그가 고쳐졌다고 말할 수 있을까요? 얼쑤의 연주 비교 기능을 고치며 배운, 테스트를 먼저 실패시켜 보는 습관을 정리했습니다.
학습의 첫 완료 시각 지키기
완료 표시가 겹쳐도 첫 시각을 유지하도록 MySQL의 중복 키 분기와 저장 뒤 재조회를 설계했습니다.
저장한 녹음을 30일 삭제에서 빼기
R2의 일괄 만료를 서버 정리 작업으로 옮기고, 조건부 갱신으로 저장 요청과 파일 삭제의 순서를 정한 과정입니다.
없는 행과 NULL 값 구분하기
녹음 경로가 없는 행의 삭제와 악보 버전이 달라 번호를 매길 수 없는 결과를 각각 보존한 방법입니다.
녹음 재생 API가 내부 주소를 반환한 이유
앱이 열 수 없는 내부 녹음 주소를 반환하던 문제를 고치고, 저장소별 응답과 만료 시각을 검증했습니다.
곡 목록에 페이지를 추가할 시점
공개 곡 네 개에서 서버 검색과 페이지를 보류하고, 데이터 크기와 화면 요구로 재검토 조건을 정했습니다.
MySQL 행 잠금 대기로 요청 경합 확인
연습 기록을 저장하는 동안 삭제가 기다리는지, 고정 지연 대신 MySQL이 보고한 행 잠금 대기로 확인했습니다.
Jackson 3에서 JSON 배열과 누락 필드 읽기
학습 단계와 채점 악보를 읽는 파서에서 배열 변환과 필수 필드 검사를 분리하고, 작은 JSON으로 검증한 과정을 설명합니다.
회원 한 행이 막은 테스트 준비
가입 테스트가 남긴 회원이 기본 악기를 참조했습니다. 그 상태를 한 행으로 재현하고, 악기 행을 삭제하던 픽스처를 같은 ID의 값을 갱신하는 방식으로 바꿨습니다.
연주 분석 60초의 시작점
연주 분석의 저장 마감, AI HTTP 대기, 다운로드 읽기 제한을 나누고 첫 실행 준비가 전체 시간에 들어가는 위치를 살폈습니다.
업무 결과를 HTTP 응답으로 바꾸기
평가 조회와 녹음 분석 재시도에서 조회·업무 판단·HTTP 응답의 역할을 나누고, 각 경계의 검증 결과를 살펴봅니다.
단독 MockMvc에서 JWT가 비어 500이 난 이유
단독 컨트롤러 테스트에서 발생한 500의 원인을 찾고, 인자 해석·공통 오류·실제 서명 쿠키 검사의 범위를 나눴습니다.
녹음 업로드 202 이후 앱이 기다리는 것
녹음 접수와 평가 완료를 분리하고, 앱이 2초마다 상태를 묻다가 멈추는 조건을 가짜 시계로 확인했습니다.
MySQL 한글이 물음표로 보일 때
MySQL 조회에서 보이는 물음표가 저장된 값인지, 결과를 내보내는 연결에서 생긴 것인지 나눠 봅니다.
형식이 맞는 날짜가 500을 낸 이유
연습 통계 API에서 날짜 파싱을 통과한 극단값이 500을 내는 이유와, 입력 범위를 검사해 400으로 돌려준 과정을 정리했습니다.
한국 시간으로 집계하고 UTC 인덱스 쓰기
한국 시간 자정의 양쪽에 있는 연습 기록을 구분하고, 회원 50명과 연습 구간 2만 건을 넣은 MySQL에서 인덱스가 선택되는지 확인했습니다.
트랜잭션 커밋 경계 테스트
저장 도중 실패한 변경은 DB에서 되돌아가고, 커밋에 실패한 업로드에서는 분석을 시작하지 않는지 각각 검사했습니다.
타임아웃 뒤 ffprobe 종료 확인하기
녹음 검사의 외부 프로세스가 시간 초과와 스레드 중단에서 남지 않도록 하고, 가짜 실행 파일이 남긴 PID로 종료까지 확인했습니다.
지난달과 연속 연습일 계산하기
지난달과 직전 같은 일수는 언제 다른지, 오늘 연습하기 전에는 어디서부터 연속 일수를 세는지 정리했습니다.
악보 체류 기록의 재전송 오류 구분
같은 기록을 계속 대기열에 남길 수 있던 두 가지 500을 찾아 401과 400으로 구분하고, 임시 MySQL에서 저장 결과를 확인했습니다.
악보 이벤트 오타가 음표 번호를 밀면
악보를 채점용 음표 목록으로 바꾸기 전에 이벤트 종류를 검사합니다. 오타를 조용히 건너뛸 때 음표 번호가 어긋나는 이유와 이를 구별하는 테스트를 살펴봅니다.
서비스 검사를 꺼도 통과한 테스트 8개
서비스와 가짜 저장소에 같은 거절 규칙이 있어 오류가 가려지는 상황을 재현하고, 저장소를 호출하지 않는 조건을 검사에 추가했습니다.
분석 제출에 실패하면 이미 커밋한 시도는?
재시도 상태를 커밋한 뒤 작업 제출이 실패했을 때 같은 시도만 닫고, 정리 중 발생한 오류와 원래 실패를 함께 보존했습니다.
분석 실행기를 공용 Bean으로 등록하지 않은 이유
아직 준비되지 않은 녹음 분석을 앱 기동에서 분리하고, 전용 실행기가 기본 실행기와 작업 수명에 미치는 영향을 살펴봤습니다.
만료 배치에서 인덱스가 잠금 범위를 바꾸는 이유
녹음 업로드 만료 UPDATE가 실제로 바꾸는 행과 InnoDB가 찾아가는 범위가 어떻게 다른지 검토한 사례입니다.
동시 요청 네 건, 연습 세션 한 개
연습 세션을 만드는 요청을 네 스레드에서 같은 키로 보냈습니다. 응답 네 건의 세션 ID가 같고 MySQL에는 한 행만 남도록 만든 과정을 정리했습니다.
동시 업로드에서 접수된 녹음만 남기기
같은 세션에 동시에 녹음을 올려도 DB가 접수한 원본이 남도록, 요청별 객체 키와 조건부 갱신을 조합해 검증했습니다.
녹음 정보 한 칸이 비어도 CHECK가 통과한 이유
SQL의 UNKNOWN을 만나 부분적으로 비어 있는 녹음 정보가 저장됐습니다. DB 제약과 파일 검사에서 각각 허용 범위를 정했습니다.
같은 조건의 연주만 비교한 이유
성장 화면에서 첫 연주와 최근 연주를 비교할 때 악보 버전, 채점 모델, BPM과 단위를 맞춘 이유입니다.
SQL 조건을 빼도 테스트가 통과한 이유
테스트 데이터가 두 조건에 동시에 걸리면 그중 하나가 빠져도 결과가 같습니다. 성취도 조회의 SQL 조건을 각각 검사하도록 데이터를 바꾼 과정입니다.
JDBC로 바꾼 값을 MyBatis가 다시 읽지 못한 이유
같은 테스트 트랜잭션에서 JDBC가 갱신한 행을 MyBatis가 옛 값으로 돌려줬습니다. 검사 목적에 맞춰 픽스처를 나눴습니다.
HTTP 테스트에서만 수신 시각 고정하기
서버 수신 시각이 결과를 바꾸는 체류 기록 HTTP 테스트에서 시계를 고정하고, 다른 업무의 시계와 적용 범위를 나눈 방법입니다.
HTTP 406에도 공통 오류 본문 적용하기
Spring이 만든 406의 상태와 헤더를 보존하면서 앱이 읽는 JSON 오류 본문을 돌려주고, 실제 HTTP에서 확인했습니다.
96.7 BPM이 96으로 바뀐 이유
정수만 받는 연습 API가 96.7을 96으로 바꾼 뒤 성공했습니다. JSON 토큰을 변환 전에 검사하고 잘못된 요청이 DB에 남는지까지 확인했습니다.
3바이트 업로드가 175바이트가 된 이유
실제 AWS SDK가 보낸 요청을 로컬 HTTP 대역에서 받았습니다. 175바이트의 서명 청크를 풀어 원본 3바이트와 대조한 과정입니다.
21MiB와 26MiB가 받은 서로 다른 413
녹음 파일의 20MiB 한도와 요청 본문의 25MiB 한도를 나누고, 21MiB와 26MiB 요청을 실제 Nginx로 보내 확인했습니다.
1초 늦는 저장소로 SDK 타임아웃 검증
저장소의 재시도까지 한 시간 예산으로 묶었습니다. 1초 뒤에 답하는 로컬 대역을 두고 짧은 제한에서 예외가 먼저 오는지 확인했습니다.
