OPIcnic
OPIc 말하기 연습 서비스답변을 녹음하면 등급과 고친 문장을 주고, 쌓인 답변에서 반복되는 버릇을 찾아 시험일까지 할 일을 정해 줍니다.
라이브 데모 →
사이트의 "로그인 없이 둘러보기"로 같은 화면을 볼 수 있습니다. 예시 기록도 실제 채점 파이프라인으로 만든 결과입니다.
목차
소개
OPIc은 배경설문으로 고른 주제와 정해진 출제 규칙으로 15문항이 나오고, 채점자가 전체 답변을 듣고 등급을 매기는 시험입니다. 준비하면서 영어 자체보다 번거로웠던 건 주제를 뭘 고를지, 오늘 뭘 연습할지, 내 답의 무엇이 문제인지를 매번 직접 판단하는 일이었습니다.
OPIcnic은 이 판단들을 대신 내려 줍니다. 답변마다 등급과 고친 문장을 주고, 답변이 쌓이면 반복되는 버릇을 찾고, 그 기록으로 시험일까지 할 일을 정합니다.
주요 기능
1. 문항 피드백
답변마다 등급(IM2, IH 등)을 알려 주고, 약한 문장을 인용해 고친 문장을 붙입니다. 모범 답안은 새로 지은 답이 아니라 내 답을 한 단계 위 수준으로 다시 쓴 것이고, 듣고 따라 말할 수 있습니다.
2. 학습 패턴 분석
답변이 쌓이면 여러 답변에 반복되는 버릇(감정 없이 사실만 나열하기 등)과 유형별 약점, 이번 주 과제를 정리합니다.
버릇은 3개 이상의 답변에서 반복된 것만 "12개 중 8개 답변"처럼 횟수와 실제 문장을 붙여 보여 줍니다. 예상 등급은 실제 시험처럼 IH 이상이면 롤플레이 문제 해결(12번), AL이면 비교와 이슈(14, 15번)에서도 그 수준이 나와야 인정합니다. 등급 기준을 잡은 과정은 채점 보정 기록에 있습니다.
3. 시험 준비
시험일을 정하면 남은 기간과 쌓인 기록으로 하루 목표를 정하고, 기록이 적거나 점수가 낮은 콤보와 유형, 오래 안 한 유형을 먼저 추천합니다.
4. 주제 선택과 출제
온보딩에서 고득점에 불리한 배경설문 선택지(직업 관련 등)는 처음부터 빼고, 남은 21개 주제를 준비 부담과 함께 보여 줍니다. 목표 등급을 고르면 연습 난이도도 맞춰집니다.
연습은 아래 단위 중에서 고르고, 어떤 단위든 실제 시험 출제 규칙대로 문제가 나옵니다.
| 단위 | 구성 |
|---|
| 콤보 | 한 주제로 2~3문항(묘사, 루틴, 경험 등). 실제 시험의 기본 단위 |
| 문제 유형 | 묘사, 경험, 롤플레이, 비교, 이슈 중 한 유형만 |
| 주제 | 배경설문에서 고른 주제 하나 |
| 돌발 | 배경설문에서 고르지 않은 주제(전용 23개) |
| 모의고사 | 자기소개와 콤보 5개(선택 주제 3, 돌발 2). 실제 시험과 같은 15문항 |
5. 둘러보기
로그인 없이 둘러보기를 누르면 예시 기록과 학습 패턴 분석, 3주 뒤 시험 일정이 채워진 계정으로 바로 써 볼 수 있습니다. 방문자마다 별도 계정이고 7일 뒤 지워지며, 무료 LLM 한도 때문에 채점은 하루 6문항까지입니다.
시스템 구조
- 녹음이 끝나면 브라우저가 presigned URL로 녹음 파일을 S3(Cloudflare R2)에 직접 올립니다. 서버는 파일을 받지 않습니다.
- 제출하면 서버는 채점 작업을 DB에 기록하고 바로 202로 응답합니다.
- 워커가 DB에서 문항 단위로 작업을 집어 S3의 녹음을 읽고, STT와 채점을 호출해 문항별로 저장합니다. 외부 API가 실패하면 워커가 재시도합니다.
- 브라우저는 결과를 폴링해 끝난 문항부터 보여줍니다.
녹음 파일(S3)과 채점 작업(DB)이 요청 밖에 있어서, 사용자가 화면을 떠나거나 서버가 재시작돼도 채점이 이어집니다.
설계 기준은 MAU 24만, 피크 동시 채점 30건을 가정했습니다. 목표는 접수 응답 p95 0.5초 이내, 이탈이나 재시작에도 채점 완료율 100%, 외부 API 일시 장애에도 실패 문항 0입니다(docs/performance/slo.md).
성과
앞의 셋은 로컬에서 mock 외부 API에 장애를 주입한 실험, 마지막은 실제 녹음으로 실제 외부 API를 호출해 잰 값입니다(12.9s는 문항별 처리 시간의 합).
문제 해결 과정
-
채점 비동기 전환: 녹음 파일을 서버 메모리에 올려 요청 안에서 채점하다 보니, 장애가 나면 녹음이 사라지고 재시도도 요청 시간 안에서만 할 수 있었습니다. 녹음은 S3에 직접 올리고 채점은 DB 큐의 워커가 재시도까지 맡도록 바꿔, 접수는 바로 응답하고 외부 장애는 뒤에서 흡수합니다.
문제 원인
- 음성 답변을 외부 API(STT, LLM)로 채점하며, 녹음 파일을 서버 메모리에 올려 요청 안에서 동기 처리
- 재시도와 채점 결과가 요청에 묶여 있어 요청이 끊기면 함께 사라지는 구조
- 서버 재시작이나 사용자 이탈 시 결과가 유실되고, 외부 API가 실패하면 사용자가 1분 넘는 답변을 다시 녹음
해결 과정
- 채점을 요청에서 떼어 비동기 작업으로 분리하고, 재시도와 결과 보존은 서버가 담당
- 녹음 파일은 서버 디스크나 메모리 대신 S3에 두고 presigned URL로 직접 업로드해, 서버 재시작에도 남고 서버 메모리를 거치지 않게 처리
- 채점 작업은 Kafka 같은 별도 큐 대신 DB 큐에 기록해 결과 저장과 상태 변경을 한 트랜잭션으로 처리, 워커가 문항 단위로 채점
- 사용자가 응답을 기다리지 않게 되어, 재시도 한도를 횟수(3회) 대신 접수 후 시간 기준으로 늘려 지수 백오프
- 실패를 기다리면 풀리는지로 나눠, 녹음 파일 문제는 즉시 실패, 429와 5xx, 타임아웃만 재시도
- 몇 초 늦게 보여도 되는 채점 결과라, 연결을 서버에 유지해야 하는 SSE나 롱폴링 대신 요청마다 DB를 읽는 숏폴링으로 단순하게 응답
- 테스트: 접수 직후와 채점 중 각각 서버 프로세스를 kill하고 재기동, 로컬에서 가짜 외부 API로 호출의 45%를 실패시키는 장애 주입
결과
- 채점을 비동기 작업으로 분리해 서버 재시작이나 사용자 이탈에도 채점 완료율 100%
- 외부 API 일시 장애를 서버 재시도로 흡수해 사용자가 답변을 다시 녹음하지 않도록 개선 (45% 장애 주입 시 실패 문항: 재시도 3회 제한 22.8% → 시간 기준 재시도 0%)
- 녹음 파일이 서버 메모리를 거치지 않아 힙 부담 감소 (Humongous GC 5분당 25회 → 3회)
더 자세히: 블로그 글 / 설계 기록 (ADR)
-
재시도 폭주 방지: 외부 API가 복구되는 순간 밀린 재시도가 한꺼번에 몰려 제공자 한도를 다시 넘겼습니다. full jitter 지수 백오프로 재시도 시점을 흩고 워커 동시성을 제한해, 기존 백오프 대비 복구 후 채점 완료가 270초에서 54초로, 429 비율이 33%에서 0.4%로 줄었습니다.
문제 원인
- 채점을 비동기 워커로 옮긴 뒤, 외부 API(STT, LLM)가 실패하면 워커가 지수 백오프로 재시도하는 구조
- 외부 API가 복구되는 순간 밀려 있던 재시도가 한꺼번에 몰려, 막 복구된 제공자에 다시 과부하를 줄 수 있는 구조
- 과부하로 거절된 호출(429)이 다시 재시도를 부르며 복구 뒤에도 채점 완료가 늦어질 수 있음
해결 과정
- mock 외부 API로 60초 장애 후 복구(복구 직후 초당 10건 처리)를 재현해 재시도 방식 세 가지를 비교
- 즉시 재시도: 복구 순간 처리량의 9배가 몰려 429 78%
- 2배씩 늘린 대기 + 1초 jitter: 호출은 줄었지만 대기가 60초 상한에 붙어 모든 문항이 60초마다 같은 박자로 몰림
- 대기 시간 자체가 아니라 대기 범위를 2배씩 늘리고, 실제 대기는 그 범위 안에서 무작위로 고르는 full jitter(AWS SDK 기본 재시도 방식)로 재시도 시점 분산
- 워커 동시 처리 수를 제한해 한 번에 나가는 외부 호출 상한 고정
결과
- 기존 백오프 대비 복구 후 채점 완료 270초 → 54초, 거절된 호출(429) 33% → 0.4%
- 복구 직후 초당 최대 호출 39 → 12로 제공자가 처리할 수 있는 양 안에서 고르게 분산
- 즉시 재시도 대비 외부 호출 87% 감소
(mock 외부 API로 테스트: 콤보 30건, 60초 장애 후 복구, 복구 직후 초당 10건 처리)
-
디스크 I/O 병목 제거: DB 풀 확장과 가상 스레드 pinning 가설을 1KB 격리 실험과 JFR로 하나씩 기각하고, 톰캣 멀티파트 임시파일 쓰기가 원인임을 찾았습니다. 멀티파트 임계치를 올려 디스크 쓰기를 없애 RPS 96 → 652, 평균 지연 1,100ms → 249ms(2026-04, mock 외부 API, 단일 실행). 함께 넣은 InputStream 릴레이는 6월에 재시도 때문에 되돌렸습니다(아래 접기).
여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗
