MySQL 복제가 끊기면 원본 쓰기를 막아야 할까?
5초간 MySQL 복제를 끊어 쓰기 차단의 효과를 비교하고, 운영에서는 저장을 유지하기로 한 이유를 정리했습니다.
블로그
얼쑤를 만드는 Team Edo의 개발 기록
전체 글
113편
백엔드 무중단 배포
얼쑤의 Compose·Nginx 블루그린 배포가 요청과 악보 변환을 어떻게 이어가는지, 격리 시험과 운영 전환에서 무엇을 확인했는지 설명합니다.
컨테이너에서만 타임아웃 난 MySQL SSH 터널 추적기
호스트에서는 응답하던 SSH DB 터널이 복제 컨테이너에서만 시간 초과될 때 연결을 구간별로 확인한 기록입니다.
APK는 받을 수 있는데 QA 목록 제목은 왜 비었을까
얼쑤의 Android QA 목록에서 제목과 작성자가 비어 있는 문제를 추적하고, 조회를 작은 묶음으로 나눠 운영에서 복구한 과정을 소개합니다.
Docker 로그 6종 중 4종만 파일에 남은 이유
얼쑤에서 Docker의 로그 전송 설정, 수신 규칙, 날짜별 파일을 대조해 기록이 어디서 끊겼는지 확인한 과정을 소개합니다.
Docker 용량 조회 하나가 점검표의 네 칸을 비웠다
Docker의 마지막 용량 조회만 실패시켜 기존 점검표와 앞선 값을 보존하는 개선안을 비교했습니다.
글씨를 키워도 연습을 이어갈 수 있을까?
큰 글씨 설정에서 악보와 운지를 읽을 수 있도록 Compose 연습 화면의 가용 높이와 글자 크기를 함께 계산한 과정입니다.
서버 두 대로 어디까지 장애를 견딜 수 있을까
얼쑤에서 배포 중단과 서버 장애를 나눠 보고, 두 서버에서 Kubernetes가 맡을 수 있는 일과 접속·데이터 복구에 필요한 조건을 검토했습니다.
악기 이름을 못 불러와도 내 점수는 볼 수 있어야 한다
선택한 연주의 평가가 맞는지 확인하고, 추천 구간이나 악기명 조회가 실패해도 점수와 오류를 보여준 프론트엔드 설계입니다.
읽기 전용 컨테이너에서 Gunicorn이 기동 오류를 남긴 이유
HTTP 요청은 정상이었지만 기동 때마다 오류가 남던 블로그 편집 API에서 Gunicorn 제어 소켓을 원인으로 좁히고, 읽기 전용 설정을 유지한 채 해결한 과정을 정리했습니다.
절쑤가 뛰어도 그림자는 바닥에
그림자까지 함께 그려진 마스코트 일러스트로 움짤을 만들며, 그림자를 바닥 레이어로 떼어 내고 발을 축으로 흔들리게 만든 과정입니다.
팀 채팅에서 서버 상태만 읽게 한 방법
Mattermost의 슬래시 명령을 서버별 읽기 전용 점검으로 제한하고, 응답이 실제로 확인한 범위를 표시한 과정을 소개합니다.
폐기용 MySQL을 실행 단위로 분리한 이유
MySQL 통합 테스트의 데이터와 접속 경로를 실행마다 분리하고, DB가 종료된 뒤 데이터 폴더를 정리하는 절차를 설명합니다.
한글을 쳤는데 Enter가 동작하지 않았다
Compose 웹의 정간보 편집기에서 한글 조합과 Enter 등록을 다루고, 미리보기와 오류 안내가 나타나는 시점을 분리했습니다.
1.76MB 곡 목록에서 악보 덜어내기
111곡 목록에서 악보 본문을 분리한 이유와 Nginx gzip 적용 뒤 운영 응답의 전송량을 확인한 방법을 정리했습니다.
10초 AAC를 4.62초만 읽고 성공한 FFmpeg
AAC 녹음을 패킷 경계에서 자른 실험에서 컨테이너가 보고한 길이와 실제 디코딩 길이를 비교해 끝 잘림을 잡았습니다.
120초 녹음 분석에 약 3GiB가 든 이유
60초와 120초 합성 녹음의 처리 시간과 메모리를 비교하고, 두 시간축의 길이로 DTW 요청의 메모리를 추정한 과정입니다.
Spring 테스트 53개 실패와 MySQL 연결 한도
얼쑤의 MySQL 통합 테스트 174개 중 53개가 실패한 기록을 바탕으로, Spring이 캐시한 컨텍스트의 연결 풀이 어떻게 DB 한도에 닿는지 살펴봅니다.
쉼표가 바꾼 아리랑 음표 45개의 시작 박
아리랑에서 음 길이만 이어 붙였을 때 시작 시각이 최대 1.04초 어긋났습니다. 원래 시작 박을 전달하고, 악보 데이터가 시드까지 보존되는지 확인한 과정입니다.
녹음 재분석에서 결과가 섞이지 않게
얼쑤에서 같은 녹음으로 분석을 재시도하고, 시도 번호와 마감 조건으로 늦은 결과가 새 시도를 덮지 않게 한 과정을 소개합니다.
1.5.2·1.5.5·1.5.6 코드 탐색 결과와 검증 넘기기
계획 단계에서 확인한 경로와 심볼을 구현에 넘기는 범위를 실험으로 좁히고, 소스가 바뀔 때 다시 확인하는 규칙과 현재 검증만 리뷰에 넘기는 기준을 추가했습니다.
1.5.4 작성자와 썸네일 고르기
팀 캐릭터의 외형 기준은 블로그에 두고, COCO에는 작성자와 장면을 정하고 실제 화면에서 확인하는 절차를 넣었습니다.
1.5.1·1.5.3 개인 메모에서 글감 찾기
로컬 TIL 전체에서 작성자의 경험을 찾아 글감을 고르고, 재검증을 마친 문제 해결 과정을 별도 사례로 남기는 두 변경을 소개합니다.
Flyway 선실행과 배포 롤백
Flyway를 앱 교체 직전에 실행하도록 배포를 바꾸고, 이전 앱이 새 스키마에서도 동작하도록 적용 범위와 실패 처리를 정한 과정입니다.
백엔드는 자동, 웹은 검증한 SHA로 배포
웹 배포를 전용 수동 잡으로 나누고, 검증한 소스 SHA와 운영 웹 릴리스가 일치하는지 확인했습니다.
테스트한 JAR을 이미지에 그대로 넣기
CI에서 만든 JAR을 이미지 빌드에 재사용하고, 이미지에서 꺼낸 바이트를 SHA-256으로 대조한 과정입니다.
틀린 음을 불었는데, AI는 왜 맞다고 했을까?
짧은 옥타브 오류를 놓친 채점기를 살펴보며 음높이 추정과 악보 정렬의 관계를 알아봅니다.
Jenkins Wasm 최적화 956초에서 237초로
Jenkins의 단계별 시간으로 실행기 대기와 Wasm 최적화 병목을 구분하고, 같은 입력에서 최적화 시간과 파일 크기를 비교했습니다.
파일 교체 뒤에도 남은 컨테이너 설정
Nginx 설정을 파일 단위로 마운트한 환경에서 inode를 유지하며 변경을 반영하고, 컨테이너와 HTTP 응답에서 확인했습니다.
1.5.0 스킬 목차 검사
COCO 스킬 30개의 진입점에 목차를 두고, 본문의 제목을 바꿀 때 목차도 함께 갱신되는지 패키지 검사로 확인했습니다.
1.4.2 종료 코드는 0, 리뷰어는 빈칸
PR·MR에 담당자, 리뷰어, 라벨을 넣는 작업에서 명령의 종료 코드와 저장된 결과를 따로 확인했습니다.
1.4.1 썸네일은 실제 카드에서
coco-blog에 썸네일 후보 선택과 데스크톱·모바일 미리 보기를 넣고, 이미지 업로드를 별도 단계로 뒀습니다.
206 응답 뒤에 숨은 CORS 오류
음원 API의 302를 따라간 브라우저 요청이 실패한 지점을 찾고, R2의 CORS 정책을 바꾼 뒤 실제 Range 응답으로 확인했습니다.
API 명세 68페이지에서 팀 수정 148곳 지키기
공유 API 명세를 대량 교정하며 현재 문구와 교정 전 문구를 대조하고, 저장한 결과를 다시 읽어 누락과 오타를 찾았습니다.
Flyway 체크섬의 줄바꿈과 공백
후보 JAR의 SQL을 Flyway 이력과 대조하면서 줄바꿈, BOM, 후행 공백을 구별하는 CRC32 검사를 운영 이력으로 검증했습니다.
Play 배포판의 App Links가 빠진 이유
운영 서버는 정상인데 Play 배포판만 App Links 문서에서 빠졌던 상황과, 공개 JSON에서 패키지 두 항목을 확인한 과정을 정리했습니다.
곡 목록은 200, 콘솔 오류는 어디서 왔나
곡 목록의 응답과 같은 시점에 찍힌 콘솔 오류를 대조해, 브라우저 확장과 문서 UI가 남긴 오류의 출처를 구분했습니다.
문서 주소 없이 FastAPI 계약 검증
내부 분석 API의 OpenAPI 문서를 앱에서 생성하고, 문서용 응답 모델과 실제 JSON이 일치하는지 검사했습니다.
백업 도구를 바꿔도 남은 오류
새 백업 도구 설치 직후의 오류를 같은 호스트에서 이전 버전으로 비교하고, 백업을 받는 쪽에서 상태를 확인했습니다.
업로드 재시도에서 기존 파일 지키기
키에 객체가 없을 때만 저장하는 PUT을 기본값으로 삼고, SDK가 보낸 HTTP 요청 세 건으로 원본 보존과 명시적 교체를 확인했습니다.
테스트 결과에서 재현 절차 찾기
완료 조건과 재현 단계, 수행 결과를 같은 번호로 연결하고 경계값의 기대 결과가 빠진 시나리오를 찾았습니다.
고치기 전에 실패해야 증거가 되는 테스트
테스트가 통과했다고 버그가 고쳐졌다고 말할 수 있을까요? 얼쑤의 연주 비교 기능을 고치며 배운, 테스트를 먼저 실패시켜 보는 습관을 정리했습니다.
Git 브랜치 갱신 전 확인할 것
로컬 브랜치의 현재 값과 커밋 관계를 검사해 빨리 감기하고, Push는 명시적인 refspec으로 목적지를 정했습니다.
Jackson 3에서 JSON 배열과 누락 필드 읽기
학습 단계와 채점 악보를 읽는 파서에서 배열 변환과 필수 필드 검사를 분리하고, 작은 JSON으로 검증한 과정을 설명합니다.
MySQL 행 잠금 대기로 요청 경합 확인
연습 기록을 저장하는 동안 삭제가 기다리는지, 고정 지연 대신 MySQL이 보고한 행 잠금 대기로 확인했습니다.
곡 목록에 페이지를 추가할 시점
공개 곡 네 개에서 서버 검색과 페이지를 보류하고, 데이터 크기와 화면 요구로 재검토 조건을 정했습니다.
녹음 재생 API가 내부 주소를 반환한 이유
앱이 열 수 없는 내부 녹음 주소를 반환하던 문제를 고치고, 저장소별 응답과 만료 시각을 검증했습니다.
약관 배포와 시행 사이의 시차
약관 문서 배포와 시행 시각을 따로 관리하면서 생긴 4시간 반의 차이를 살펴봅니다.
없는 행과 NULL 값 구분하기
녹음 경로가 없는 행의 삭제와 악보 버전이 달라 번호를 매길 수 없는 결과를 각각 보존한 방법입니다.
저장한 녹음을 30일 삭제에서 빼기
R2의 일괄 만료를 서버 정리 작업으로 옮기고, 조건부 갱신으로 저장 요청과 파일 삭제의 순서를 정한 과정입니다.
학습의 첫 완료 시각 지키기
완료 표시가 겹쳐도 첫 시각을 유지하도록 MySQL의 중복 키 분기와 저장 뒤 재조회를 설계했습니다.
1.4.0 코드 질문과 조사를 한곳에서
coco-askme에 기술 조사와 요청 시 진행하는 퀴즈를 모으고, 대화 맥락을 얼마나 복구할지 정했습니다.
1.3.0 작업 폴더를 지워도 남는 TIL
세션에서 배운 내용을 개념별로 기록하고, linked worktree의 수명과 TIL의 저장 위치를 분리했습니다.
1.2.0 개발 노트를 공개 초안으로
coco-blog가 원본 개발 노트를 보존하면서 독자가 읽을 원고를 만들고, 저장소마다 다른 게시 절차를 따르게 했습니다.
Android SDK 없이 녹음 업로드 검증
Wasm에서 실행한 녹음 업로드 공통 테스트와 Android 파일 구현의 제한된 JVM 검사를 분리해, 각 결과가 확인한 범위를 정리했습니다.
Docker 내부망으로 연결한 분석 서버
분석 서버의 포트를 호스트에 게시하지 않고, 백엔드에서 보낸 빈 요청과 외부 연결 검사로 접근 범위를 확인했습니다.
Jenkins가 새 Compose 파일을 못 읽은 이유
root의 Compose 검사는 통과하고 Jenkins는 같은 파일을 읽지 못했던 장애를 재현하고, 실제 실행 계정으로 검사하는 설치 절차를 만들었습니다.
Lax 쿠키에 Origin·JSON 검사를 더한 이유
앱에서 쓰는 쿠키 인증에 출처 검사와 본문 규칙을 적용하고, HTTP 403과 415가 각각 무엇을 검증했는지 살펴봅니다.
MySQL 한글이 물음표로 보일 때
MySQL 조회에서 보이는 물음표가 저장된 값인지, 결과를 내보내는 연결에서 생긴 것인지 나눠 봅니다.
녹음 업로드 202 이후 앱이 기다리는 것
녹음 접수와 평가 완료를 분리하고, 앱이 2초마다 상태를 묻다가 멈추는 조건을 가짜 시계로 확인했습니다.
단독 MockMvc에서 JWT가 비어 500이 난 이유
단독 컨트롤러 테스트에서 발생한 500의 원인을 찾고, 인자 해석·공통 오류·실제 서명 쿠키 검사의 범위를 나눴습니다.
단소 악보 4곡의 DB 시드 검증
승인된 단소 악보를 재변환해 초기 DB 데이터와 대조하고, 음표 수 하나를 틀리게 만든 사본에서 검사기가 실패하는지 확인했습니다.
상태 조회가 대기 녹음을 지울 수 있던 이유
업로드 대기 녹음을 보관하는 도중 상태 조회가 파일을 지울 수 있었습니다. 정리 시점을 옮기고, 파일 이동과 기록 저장 사이에 조회를 끼워 넣어 검증했습니다.
업무 결과를 HTTP 응답으로 바꾸기
평가 조회와 녹음 분석 재시도에서 조회·업무 판단·HTTP 응답의 역할을 나누고, 각 경계의 검증 결과를 살펴봅니다.
연주 분석 60초의 시작점
연주 분석의 저장 마감, AI HTTP 대기, 다운로드 읽기 제한을 나누고 첫 실행 준비가 전체 시간에 들어가는 위치를 살폈습니다.
원격 명령은 어디서 막혔을까
zsh 변수 확장과 SSH 자동 포워딩을 거치며 명령이 예상보다 일찍 실패한 세 기록을 묶었습니다.
회원 한 행이 막은 테스트 준비
가입 테스트가 남긴 회원이 기본 악기를 참조했습니다. 그 상태를 한 행으로 재현하고, 악기 행을 삭제하던 픽스처를 같은 ID의 값을 갱신하는 방식으로 바꿨습니다.
−20센트 합성음에서 나온 −15센트 추정
얼쑤 분석 API의 합성음 검증과 단소 녹음 다섯 건을 바탕으로, 음높이 추정과 조율 보정의 숫자를 읽는 법을 정리했습니다.
1초 늦는 저장소로 SDK 타임아웃 검증
저장소의 재시도까지 한 시간 예산으로 묶었습니다. 1초 뒤에 답하는 로컬 대역을 두고 짧은 제한에서 예외가 먼저 오는지 확인했습니다.
21MiB와 26MiB가 받은 서로 다른 413
녹음 파일의 20MiB 한도와 요청 본문의 25MiB 한도를 나누고, 21MiB와 26MiB 요청을 실제 Nginx로 보내 확인했습니다.
3바이트 업로드가 175바이트가 된 이유
실제 AWS SDK가 보낸 요청을 로컬 HTTP 대역에서 받았습니다. 175바이트의 서명 청크를 풀어 원본 3바이트와 대조한 과정입니다.
96.7 BPM이 96으로 바뀐 이유
정수만 받는 연습 API가 96.7을 96으로 바꾼 뒤 성공했습니다. JSON 토큰을 변환 전에 검사하고 잘못된 요청이 DB에 남는지까지 확인했습니다.
Docker가 Mac의 여유 공간과 파일을 못 본 이유
Mac에서 Docker 이미지와 저장소 대역을 검증하며 VM 디스크 부족과 파일 공유 범위를 따로 확인했습니다.
FFmpeg를 유지하며 Python 3.12로 맞추기
분석 이미지에서 Python과 FFmpeg의 버전을 맞추고, 실행 파일뿐 아니라 설치된 디코딩 라이브러리까지 확인했습니다.
Flyway를 끈 운영 프로필에서 API 켜기
운영 프로필에서 등록되지 않던 업무 API를 연결하고, 미리 마이그레이션한 MySQL에서 약관 HTTP 200과 Flyway 빈의 부재를 확인했습니다.
Git 병합 뒤 DB 테스트를 한 이유
작업 트리를 바꾸지 않는 병합 검사와, 실제 병합 뒤 스키마 제약까지 확인하는 DB 테스트를 구분했습니다.
HTTP 406에도 공통 오류 본문 적용하기
Spring이 만든 406의 상태와 헤더를 보존하면서 앱이 읽는 JSON 오류 본문을 돌려주고, 실제 HTTP에서 확인했습니다.
HTTP 테스트에서만 수신 시각 고정하기
서버 수신 시각이 결과를 바꾸는 체류 기록 HTTP 테스트에서 시계를 고정하고, 다른 업무의 시계와 적용 범위를 나눈 방법입니다.
JDBC로 바꾼 값을 MyBatis가 다시 읽지 못한 이유
같은 테스트 트랜잭션에서 JDBC가 갱신한 행을 MyBatis가 옛 값으로 돌려줬습니다. 검사 목적에 맞춰 픽스처를 나눴습니다.
Jira 작업 생성 뒤 다시 읽는 이유
생성 요청의 400, 요청과 달랐던 담당자, 7초 차이로 생긴 중복 작업을 살펴보고 실제 저장 상태를 확인한 방법을 정리했습니다.
MR 병합 뒤에도 운영 확인이 남았다
병합 직후 완료로 표시됐지만 운영에서는 404였던 약관 API를 계기로, 작업 상태와 실제 완료 조건을 따로 확인한 사례입니다.
MySQL 모니터링 계정에 회원 테이블 9개 열만 허용
DB 전체 조회 권한을 회수하고 회원 테이블의 필요한 열 9개만 허용했습니다. 운영 Grafana의 패널 쿼리와 보호된 열의 접근 거부를 함께 확인했습니다.
SQL 조건을 빼도 테스트가 통과한 이유
테스트 데이터가 두 조건에 동시에 걸리면 그중 하나가 빠져도 결과가 같습니다. 성취도 조회의 SQL 조건을 각각 검사하도록 데이터를 바꾼 과정입니다.
같은 조건의 연주만 비교한 이유
성장 화면에서 첫 연주와 최근 연주를 비교할 때 악보 버전, 채점 모델, BPM과 단위를 맞춘 이유입니다.
녹음 정보 한 칸이 비어도 CHECK가 통과한 이유
SQL의 UNKNOWN을 만나 부분적으로 비어 있는 녹음 정보가 저장됐습니다. DB 제약과 파일 검사에서 각각 허용 범위를 정했습니다.
동시 업로드에서 접수된 녹음만 남기기
같은 세션에 동시에 녹음을 올려도 DB가 접수한 원본이 남도록, 요청별 객체 키와 조건부 갱신을 조합해 검증했습니다.
동시 요청 네 건, 연습 세션 한 개
연습 세션을 만드는 요청을 네 스레드에서 같은 키로 보냈습니다. 응답 네 건의 세션 ID가 같고 MySQL에는 한 행만 남도록 만든 과정을 정리했습니다.
만료 배치에서 인덱스가 잠금 범위를 바꾸는 이유
녹음 업로드 만료 UPDATE가 실제로 바꾸는 행과 InnoDB가 찾아가는 범위가 어떻게 다른지 검토한 사례입니다.
분석 실행기를 공용 Bean으로 등록하지 않은 이유
아직 준비되지 않은 녹음 분석을 앱 기동에서 분리하고, 전용 실행기가 기본 실행기와 작업 수명에 미치는 영향을 살펴봤습니다.
분석 오류 응답과 로그에서 서명 URL 숨기기
필수 필드가 빠졌을 때 요청 전체가 오류 응답에 들어가는 문제와 HTTP 클라이언트의 URL 로그를 막고, 실제 HTTP 요청과 회귀 테스트로 확인했습니다.
분석 제출에 실패하면 이미 커밋한 시도는?
재시도 상태를 커밋한 뒤 작업 제출이 실패했을 때 같은 시도만 닫고, 정리 중 발생한 오류와 원래 실패를 함께 보존했습니다.
빈 로그에서도 통과하는 비밀값 검사
루트에 전달되지 않는 모듈 로그를 caplog로 직접 받아, 필요한 이벤트가 기록되면서 민감한 값은 빠졌는지 확인했습니다.
서비스 검사를 꺼도 통과한 테스트 8개
서비스와 가짜 저장소에 같은 거절 규칙이 있어 오류가 가려지는 상황을 재현하고, 저장소를 호출하지 않는 조건을 검사에 추가했습니다.
스테레오 평균 테스트가 놓친 합산
스테레오 두 출력의 RMS 비율이 공통 배율을 지워 버리는 문제를 재현하고, 같은 사인파의 모노 원본을 기준으로 테스트를 고쳤습니다.
악보 이벤트 오타가 음표 번호를 밀면
악보를 채점용 음표 목록으로 바꾸기 전에 이벤트 종류를 검사합니다. 오타를 조용히 건너뛸 때 음표 번호가 어긋나는 이유와 이를 구별하는 테스트를 살펴봅니다.
악보 체류 기록의 재전송 오류 구분
같은 기록을 계속 대기열에 남길 수 있던 두 가지 500을 찾아 401과 400으로 구분하고, 임시 MySQL에서 저장 결과를 확인했습니다.
인증 추가 뒤 자동 배포가 10번 실패한 이유
인증을 추가한 뒤 배포 검사에 쓰던 404가 401로 바뀌었습니다. 후보의 liveness와 운영의 readiness를 나눠 배포를 검증한 과정입니다.
잡음 다섯 프레임은 0점일까
잡음 다섯 프레임 때문에 0점이 나오던 녹음을 모든 음표의 판정으로 걸러내고, 일부만 연주하거나 틀린 음을 연주한 경우와 구분했습니다.
재실행 중 덮어쓴 배포 백업
같은 설치 명령을 다시 실행해 이전 사본을 덮은 경험에서, 재실행 전에 확인할 조건과 원본을 보존하는 방법을 정리했습니다.
정답인데 2~4번째 음이 박자 오류로 찍힌 이유
정확한 박자로 만든 합성음이 조각 MP4를 거치자 세 음에서 박자 오류가 났습니다. 앱과 같은 방식으로 테스트 파일을 만들어 판정이 돌아오는지 확인했습니다.
지난달과 연속 연습일 계산하기
지난달과 직전 같은 일수는 언제 다른지, 오늘 연습하기 전에는 어디서부터 연속 일수를 세는지 정리했습니다.
컨테이너 기동 후 첫 분석 요청이 500인 이유
분석 컨테이너의 첫 요청에서 Numba 캐시 오류를 재현하고, 실행 계정의 권한을 유지한 채 캐시 경로를 바꿔 확인했습니다.
타임아웃 뒤 ffprobe 종료 확인하기
녹음 검사의 외부 프로세스가 시간 초과와 스레드 중단에서 남지 않도록 하고, 가짜 실행 파일이 남긴 PID로 종료까지 확인했습니다.
트랜잭션 커밋 경계 테스트
저장 도중 실패한 변경은 DB에서 되돌아가고, 커밋에 실패한 업로드에서는 분석을 시작하지 않는지 각각 검사했습니다.
한국 시간으로 집계하고 UTC 인덱스 쓰기
한국 시간 자정의 양쪽에 있는 연습 기록을 구분하고, 회원 50명과 연습 구간 2만 건을 넣은 MySQL에서 인덱스가 선택되는지 확인했습니다.
형식이 맞는 날짜가 500을 낸 이유
연습 통계 API에서 날짜 파싱을 통과한 극단값이 500을 내는 이유와, 입력 범위를 검사해 400으로 돌려준 과정을 정리했습니다.
녹음 저장소를 바꿔도 지킨 15분 읽기 권한
구현 전에 녹음 저장소를 GCS에서 R2로 다시 골랐습니다. 분석 서버에 주는 15분 읽기 권한은 그대로 두고 실제 만료와 삭제를 확인했습니다.
악보는 29분 30초, 연습은 10분
화면이 보인 시간에서 자리 비움과 백그라운드를 빼고, 앱이 종료되면 마지막 저장 시점까지 기록을 복구하는 과정을 정리했습니다.
1.1.0 구현 전에 합의할 것
사람이 정할 제품 규칙을 코드보다 먼저 확인하고, 다음 작업자가 합의와 검증 근거를 이어받도록 만든 COCO 1.1.0의 설계 기록입니다.
1.0.0 시작 안내가 오래 걸린 이유
실제 사용 기록에서 과한 작업을 찾아 줄이고, 프로젝트별로 스킬을 설치할 수 있게 한 COCO 1.0.0의 변경을 살펴봅니다.
0.2.0 팀 규칙은 어디에 둘까
Team Edo가 공통 개발 절차와 Jira·Git 규칙을 나누고, 실제 작업에서 검증 근거를 이어 간 사례를 정리했습니다.
0.1.0–0.1.2 흩어진 스킬을 한곳에
세 개발 스킬 모음에서 출발해, 원본의 근거를 추적할 수 있는 COCO를 만들고 첫 npm 패키지를 검증한 과정입니다.
얼쑤 기술 블로그를 시작합니다
Team Edo의 얼쑤 기술 블로그를 여는 첫 글입니다.
이 분야의 글을 준비하고 있어요.