문제

동아리 상세 조회 시 조회수 증가가 read-modify-write(findById → viewCount += 1)라, 동시 요청에서 증가분이 유실됐다. 100 VU 부하에서 유실률이 90.14%였다.

원인

• 읽은 값에 1을 더해 쓰는 방식이라 동시 트랜잭션이 같은 값을 읽고 서로를 덮어썼다 (Lost Update).
• 공지 도메인은 이미 원자적 UPDATE(NoticeRepository.increaseViewCount())로 같은 문제를 풀고 있어, 동아리 도메인도 같은 방식으로 통일했다.
• PostgreSQL은 UPDATE가 잡은 행 배타 락을 문장 종료가 아니라 커밋까지 유지한다. 그래서 증가를 앞에 두면 뒤따르는 상세 조회 쿼리 2개가 모두 락 구간에 들어간다.

구조

sequenceDiagram
  participant A as 요청 A
  participant DB as PostgreSQL (동아리 행)
  participant B as 요청 B
  Note over A,B: 변경 전 — read-modify-write
  A->>DB: SELECT view_count → 10 (예시)
  B->>DB: SELECT view_count → 10
  A->>DB: UPDATE view_count = 11
  B->>DB: UPDATE view_count = 11
  Note over DB: 두 요청 중 하나의 증가분 유실
  Note over A,B: 변경 후 — 원자적 UPDATE를 트랜잭션 맨 끝에
  A->>DB: 상세 조회 쿼리 2개 (락 없음)
  A->>DB: UPDATE view_count = view_count + 1 (행 락 획득)
  B->>DB: UPDATE … (A의 커밋까지 대기)
  A->>DB: COMMIT (락 해제)
  B->>DB: 이어서 +1 반영 후 COMMIT
  Note over A,DB: 락 보유 구간이 UPDATE~COMMIT으로 줄어 처리량 1.84배

고민한 방법

측정 조건(로컬): 100 VU / 5,000 요청, 워밍업 2,000 요청 후 측정, 각 변형 1회.

결과

• 유실률 90.14% → 0%, 처리량 311.7 → 601.4 RPS (1.93배)
• 같은 원자적 UPDATE라도 증가를 마지막에 두는 것만으로 327.3 → 601.4 RPS (1.84배)
• 요청당 SELECT 1회 감소 (findById 제거). 스키마 변경 없음.
• 측정 메모: 같은 코드라도 콜드(RPS 220.9 / p99 4,867ms)와 웜(RPS 454.4 / p99 475.8ms) 상태의 차이가 커서, 워밍업 없이 잰 지연 수치는 전부 폐기하고 다시 측정했다. 유실률은 콜드/웜과 무관하게 재현됐다(89.92% vs 90.14%).

근거

• PR: https://github.com/SMU-TtokTtok/backend/pull/347
• 측정 리포트: load-test/results/issue-a/REPORT.md (같은 저장소)

문제

운영 환경이 EB(앱) + RDS(PostgreSQL) + ElastiCache(Redis) + S3/CloudFront(파일)로 나뉘어 있었고, 이를 자체 우분투 서버 한 대의 docker-compose 스택으로 통합해야 했다. main의 배포 워크플로우는 EB 기준(runs-on: ubuntu-latest, beanstalk-deploy)이었다.

이관 검증 중 "배포는 성공인데 서비스가 죽는" 결함을 찾아냈다 (#376). 블루-그린 전환 구간은 정상이었지만 구 색 컨테이너를 정리하는 순간부터 1180건 연속 502가 났고, 파이프라인은 성공으로 끝나 결함이 드러나지 않았다.

원인

검증 중 발견한 결함 3건의 원인 (이슈 원문 기준):

• #376 upstream.conf 바인드 마운트 단절: setup.sh가 install로 파일을 배치하는데, install은 덮어쓰지 않고 교체해 inode가 바뀐다(실증: inode 8870 → 8871, > 리다이렉트는 inode 유지). 단일 파일 바인드 마운트는 옛 inode를 물고 있어서, 이후 deploy.sh의 truncate-write가 컨테이너에 닿지 않았다. 전환 절차(nginx -t / reload / state 갱신 / 구 색 정리)가 전부 성공을 보고하므로 조용히 실패한다. 또 upstream.conf는 설정이 아니라 런타임 상태(현재 활성 색)인데 setup.sh 재실행 때마다 blue로 되돌아갔다.
• #372 앱 컨테이너 기동 실패: Alpine adduser -S가 UID를 자동 할당해, 호스트 설정 파일의 소유자와 맞지 않았다. Spring Boot 기본 탐색 경로가 optional:file:./config/라 읽기 실패를 예외 없이 건너뛰고, 한참 뒤 jwt.secret 플레이스홀더에서 터져 원인과 증상이 멀었다.
• #374 스모크 테스트 간헐 실패: 러너 PC의 systemd-resolved 업스트림 2개 중 하나가 SERVFAIL이라, 캐시 만료 후 고장난 쪽을 고르면 curl exit 6(Could not resolve host)으로 실패했다. 서비스는 정상(200)이었다.

구조

sequenceDiagram
  participant CI as Actions 러너
  participant D as deploy.sh
  participant New as 새 색 컨테이너
  participant N as Nginx
  participant Old as 기존 색 컨테이너
  CI->>D: 이미지 빌드 후 배포 시작
  D->>New: 비활성 색으로 기동
  D->>New: 헬스체크
  alt 헬스체크 실패
    D-->>CI: 전환 없이 실패 (기존 색이 계속 서비스)
  else 통과
    D->>N: upstream을 새 색으로 바꾸고 reload
    D->>N: 컨테이너 안에서 바뀐 upstream이 보이는지 확인 (이슈 376 방어)
    alt 어긋남
      D-->>CI: 기존 색을 살린 채 배포만 실패
    else 일치
      D->>Old: 드레인 후 정리
      CI->>N: 스모크 테스트
    end
  end

고민한 방법

결정이 여러 개라 결정별로 정리했다 (이슈 #354·#372·#374·#376 기준):

결과

측정 조건(운영 환경 검증): 컷오버 전, 운영용 자체 서버에서 develop 기준 배포를 실행해 이슈 #354의 인수 조건("프록시에 지속 요청을 걸어둔 상태로 배포 실행 → 비200 응답 0")을 확인 (PR #378).

• 무중단 전환 (green → blue, 전환 전·중·후 및 구 색 드레인/제거 구간 전체 7분): 총 요청 12,995건 전부 200, 비200 0건
• 워크플로우 8단계(시크릿 배치, 이미지 빌드, 블루-그린 배포, 스모크 테스트 등) 전부 success
• DB 21 테이블 / 423행 (EB 덤프와 일치), Flyway 16개 적용 v25
• MinIO 오브젝트 151개 전부 HTTPS 200, 버킷 리스팅 / PUT 모두 403
• HTTPS: Let's Encrypt 체인 검증 Verify return code: 0, HTTP/2, HSTS. 인증서 자동 갱신과 만료 감시(메일 경고)
• 메일: Postfix 릴레이 실발송 status=sent, 오픈릴레이 차단 확인
• AWS(EB / RDS / S3 / SES) 의존 전부 제거, EB 환경 종료
• 참고: 이전 단계 PR #356의 무중단 전환 검증은 1084 요청 / 비200 0건이었다. #378의 12,995건은 구 색 드레인/제거 구간까지 포함한 측정이다 (#376은 바로 이 구간에서 터졌다).

근거

• PR: https://github.com/SMU-TtokTtok/backend/pull/378
• 이관 이슈(설계 결정): https://github.com/SMU-TtokTtok/backend/issues/354
• 결함 이슈: https://github.com/SMU-TtokTtok/backend/issues/372 , https://github.com/SMU-TtokTtok/backend/issues/374 , https://github.com/SMU-TtokTtok/backend/issues/376
• #376 수정 PR: https://github.com/SMU-TtokTtok/backend/pull/377
• 이전 단계 검증(1084 요청): https://github.com/SMU-TtokTtok/backend/pull/356

문제

• 모델 호출을 API 키 과금 대신 이미 구독 중인 Claude Code·Codex CLI로 하기로 했다.
• CLI는 외부 Ubuntu 서버에 로그인돼 있고, 무거운 데모 스택과 운영 계정 자격증명은 GitHub 러너에 있다. 둘을 잇는 호출 경로가 필요했다.
• 저장소가 공개라 Actions 로그를 누구나 읽는다. 오류 메시지에 서버 경로·주소·사용자명이 섞이면 그대로 노출된다.
• 리허설에서 codex 다듬기가 "codex 가 이미지를 만들지 않았다"로 실패했다. 로컬(Windows)에서는 같은 지시문으로 3장 모두 성공했었다.

원인

• 다듬기 실패: codex는 종료 코드 0으로 끝났고 이미지도 만들어 ~/.codex/generated_images/<세션ID>/에 저장했다. 그런데 그 파일을 작업 폴더 out/으로 옮기는 셸 명령이 모두 bwrap: No permissions to create a new namespace로 실패했다.
  • 서버 커널이 비특권 user namespace를 막아 codex 샌드박스(bubblewrap)가 셸을 띄우지 못했다. 로컬(Windows)에는 이 제약이 없어 재현되지 않았다.
• 원인이 바로 보이지 않았던 이유: 보안 때문에 codex 이미지 요청에는 글 응답을 돌려주지 않게 해 두어서, codex가 남긴 "환경 오류로 out/ 폴더에 저장하지 못했습니다"가 에이전트까지 오지 않았다. 서버에 일회성 디버그 스크립트를 보내 같은 요청을 재현해 확인했다.

구조

sequenceDiagram
  participant R as Actions 러너 (에이전트)
  participant S as CLI 서버 (sshd)
  participant G as gole_llm_gateway.py
  participant CLI as claude / codex CLI
  R->>S: SSH 접속 (호스트 키 고정) + 요청 JSON을 stdin으로
  S->>G: 게이트웨이 단독 파일 실행
  G->>G: 요청별 임시 폴더 생성, 잠금으로 1건씩
  G->>CLI: claude -p (첨부 읽기만) / codex exec (작업 폴더 쓰기만)
  CLI-->>G: 결과 (codex 이미지는 generated_images/세션ID/에서 회수)
  G->>G: 임시 폴더 삭제, 오류 상세는 서버 로그에만
  G-->>R: 필요한 필드만 담은 응답 JSON을 stdout으로

고민한 방법

호출 경로

codex 결과 유실

결과

• 게이트웨이(gole_llm_gateway.py): 요청마다 본인만 접근 가능한 임시 폴더를 쓰고 지움, 잠금으로 1건씩, claude는 첨부 폴더 읽기만·codex는 작업 폴더 쓰기만, 오류 상세는 서버 로그에만, model은 영숫자로 시작하는 이름만·system은 파일로(옵션 주입 차단), codex 이미지 요청에는 글을 돌려주지 않음.
• 실서버 SSH 리허설(로컬 e2e 검토 큐로 제출, 지난 로컬 캡처 9장 재사용):
  • 수정 전: 113초에 제출됐지만 다듬기가 실패해 원본으로 대체됐다.
  • 수정 후(REF=18e91b70 재설치): 85초에 제출. 다듬은 이미지(1254×1254)와 원본(1440×1024)이 검토 패널에 나란히 표시됐다.
• 홍보 테스트 63건 통과(샌드박스 회귀 1건 추가).

근거

• PR: https://github.com/GoLe-by-Colding/GoLe/pull/166 (본문 "무엇을 했는가", "왜 이렇게 했는가", "검증" — 실제 SSH 리허설)
• 스펙: .kiro/specs/promotion-review/spec.md D20, D22 (PR 본문 "관련 스펙")

문제

• 운영 VM의 gole-promotion-agent.timer는 켜져 있었지만 9/24~9/29 6회 모두 실패했고, 초안 제출과 모델 호출로 이어지지 못했다.

원인

• 직접 원인: /etc/gole/promotion-agent.env가 0바이트라 시작하자마자 PROMOTION_AGENT_ADMIN_EMAIL_REQUIRED로 종료됐다.
• 구조적 원인: 운영 VM은 컨테이너 mem_limit 합계가 8,192 MB 중 6,784 MB라 실효 여유가 900 MB 안팎이었다. Chromium 하나가 400 MB~1 GB를 쓰므로 상주는 불가능하고 잠깐 빌려 쓰는 일회성 컨테이너만 가능했다.
  • 그 결과 OOM 중단을 전제로 한 체크포인트·재개·3단 제출 체인이 필요해졌고, 설계가 무거워졌다.
  • 타이머 구조라 관리자 버튼으로 즉시 실행할 수도 없었다.

구조

flowchart TB
  T1[CD 성공<br/>main 배포] --> F
  T2[월·수·금 10:00<br/>크론] --> F
  T3[수동 실행] --> F
  F{사전 필터<br/>웹 변경 없음·초안 있음·<br/>검토 대기 5건 이상이면 중단}
  subgraph R[GitHub Actions 러너]
    S[대상 SHA로<br/>데모 스택 기동] --> C[Playwright 캡처]
    C --> L[LLM<br/>화면 선택·캡션·다듬기]
  end
  F -->|기능 홍보| S
  F -->|서비스 소개| A[(지난 릴리스 캡처<br/>아티팩트 재사용)]
  A --> L
  L --> Q[운영 API<br/>PENDING_REVIEW 제출]
  Q --> H[관리자 검토·승인]
  H --> P[publish-next 규칙<br/>6시간 간격 발행]

고민한 방법

결과

• 트리거가 경로를 정한다: CD 성공(main 배포) → 기능 홍보, 월·수·금 10:00 KST → 서비스 소개, 수동 실행(SHA 또는 서비스).
• 실행 전에 코드로 거른다: 웹 변경이 없는 릴리스, 이미 초안이 있는 릴리스, 검토 대기 5건 이상이면 모델을 부르지 않는다.
• 운영 자격증명은 production 환경(배포 브랜치 main 전용) 시크릿으로만 두고, 체크포인트·재개·LangGraph 루프는 걷어냈다.
• 검증(로컬): 로컬 e2e 스택에서 공개 화면 9장 캡처 → 3장 선택·캡션 → 3장 다듬기 → PENDING_REVIEW 제출까지 확인했다.

근거

• PR: https://github.com/GoLe-by-Colding/GoLe/pull/166 (본문 "배경", "왜 이렇게 했는가", "검증")
• 스펙: .kiro/specs/promotion-review/spec.md D10, D16, D20, D21 (PR 본문 "관련 스펙")