LabHub
배우기 러닝패스 코스

FDE 캡스톤: 창고가 같은 주문을 세 번 받았다 · 빠르게를 숫자로 · 실습

평균 80ms 인데 조회 화면은 3초씩 멈췄다

LabHub 에서 이어서 보기

목표

모호한 고객 문장을 측정 가능한 기준표로 옮기고, 기준표를 읽어 요청을 보내고 증거와 판정을 남기는 인수 시험 실행기를 만든다. 정상 빌드만 인수하고 결함 있는 빌드는 해당 기준에서 떨어뜨려야 한다.

왜 중요한가

"빠르게" 는 평균으로도 p95 로도 잴 수 있고, p95 도 계산 방법에 따라 값이 달라진다. 무엇을 어떻게 재는지까지 합의하지 않으면 납품 뒤에 같은 숫자를 두고 다른 말을 하게 된다.
기준값을 코드에 적으면 기준이 바뀐 날 실행기가 조용히 틀린다. 판정만 있고 증거가 없는 보고서는 고객이 검증할 수 없다.
채점기는 가짜 견적 서버를 자기 포트에 띄워 꼬리가 느린·가끔 멈추거나 500 을 내는·금액이 1원 틀린·재조회가 흔들리는 빌드를 만들고, 기준값·사례표·변하는 필드 이름을 매번 바꿔 여러분의 실행기를 돌린 뒤 증거로 지표를 다시 계산해 보고서와 대조한다.

예상 60분이다. 기본 세션이 끝나기 전에 ＋시간으로 연장하자(최대 180분). 세션이 끝나면 /root 의 파일은 사라지니 코드는 따로 보관한다.

단계

1. 고객 메일과 회의록을 읽고 합의한 기준을 /root/accept/criteria.json 에 적는다. 구매팀장의 첫 희망 숫자가 아니라 회의에서 합의한 숫자와 측정 조건을 쓴다.
2. /root/accept/accept.py 가 기준표의 passes 만큼 사례표를 조회해 samples.jsonl 을 남기고, p95_ms(nearest-rank) 기준을 판정해 report.json 과 종료 코드 0·1 을 내게 한다.
3. accept.py 에 error_rate 를 넣는다. 200 이 아닌 응답과 timeout_ms 안에 오지 않은 응답을 오류로 세고, 증거의 status 에 "timeout" 을 남긴다.
4. accept.py 에 mismatches 를 넣는다. 1회차에서 200 을 받은 사례만 expected_total 과 비교하고 틀린 사례 id 를 mismatched_cases 로 남긴다.
5. accept.py 에 rerun_diffs 를 넣는다. 1·2회차가 모두 200 인 사례를 기준표의 ignore_fields 를 뺀 본문으로 비교하고 rerun_diff_cases 를 남긴다.
6. 네 기준을 함께 쓰는 기준표에서 op(<, <=, ==)를 그대로 따르고, 보고서의 observed·pass·metrics 가 증거로 다시 계산한 값과 같게 한다.
7. 새로 바뀐 기준표로 후보 다섯 개(정상·느린 꼬리·가끔 500·틀린 금액·흔들리는 재조회)를 돌려 정상만 인수되는지 확인한다.
8. 고객 후보 rc2 를 python3 /opt/lab/p1a-criteria/quote_server.py --port 8095 --build rc2 로 띄우고, criteria.json 과 제공 사례표로 실행해 /root/accept/rc2/ 에 report.json 과 samples.jsonl 을 남긴다.

참고

단계 8개

  1. 형용사 네 개를 숫자 네 개로
  2. 평균이 아니라 p95 로 느린 꼬리 잡기
  3. 오지 않은 응답도 오류로 세기
  4. 1원 틀린 금액 찾기
  5. 두 번 조회해서 흔들리는 사례 찾기
  6. 보고서가 증거와 같은지 스스로 맞추기
  7. 바뀐 기준표로 후보 다섯 개 가르기
  8. 고객 후보 rc2 인수 판정하기