자비스에 노드 다섯을 세워 홈페이지를 고치고, 그 검수기를 다시 쟀습니다

소개

시도하고자 했던 것과 그 이유를 알려주세요.

이번 주 과제는 세 갈래였습니다. 하네스 터미널(자비스)을 설치해 마스터와 CSO와 인스펙터가 무엇을 하는지 보고, 내 도메인에 맞는 검수 워크스페이스를 만들고, PKM을 설계하고, 검수 기준을 계속 쌓는 것입니다. 강의 마지막에 이런 안내가 있었습니다.

그대로 쓰기보다 구조가 왜 잘 돌아가는지를 보고 자기 것에 옮기는 쪽이 이번 주의 목표다.

그래서 시연을 따라 하는 대신 실제 일감 하나를 자비스에 통째로 맡겨 봤습니다. 제 개인 홈페이지 개편입니다. "배색이 마음에 들지 않는다"는 한 줄에서 시작해 테마 전환, 사진 처리, 접근성, 논문 배열, 문안까지 갔고 커밋 다섯 개로 공개까지 마쳤습니다.

노드는 다섯을 세웠습니다. 결과부터 적으면 검수 판정 8건 중 통과는 두 건뿐이었고 나머지 여섯 건이 수정과 반려였습니다. 그리고 반나절을 엉뚱한 데서 잃었습니다.

이 글은 조직을 굴려 본 기록입니다. 무엇을 어떤 명령으로 굴렸는지, 검수자가 무엇을 잡아냈는지, 그 검수기가 믿을 만한지를 어떻게 쟀는지를 함께 적습니다. 저처럼 "설치는 했는데 왜 안 굴러가지" 하실 분이 있을 것 같아서입니다.

진행 방법

1. 자비스를 어떻게 세웠나

설치는 강의 안내대로 받아서 워크스페이스에 풀고 셋업을 돌렸습니다. 제 환경은 cys 0.14.10, macOS입니다. 명령 이름은 환경마다 다를 수 있으니 동작하는 방식만 보시면 됩니다.

세운 편성은 이렇습니다. 노드마다 다른 모델을 붙일 수 있다는 점을 실제로 썼습니다.

두 가지를 규칙으로 걸었습니다.

마스터는 직접 일하지 않습니다. 마스터가 구현에 손대면 그동안 다른 노드의 회신을 못 받아 조직 전체가 멈춥니다. 실제로 한 줄 수정을 직접 하려다 그 사이 회신이 수십 건 밀린 적이 있습니다.

리뷰어를 둘로 나누고 벤더도 다르게 뒀습니다. 하나는 반증을 시도하고 하나는 감사합니다. 나중에 알았는데 이 편성이 스터디 공식 용어의 INSPECTOR와 CRITIC에 그대로 대응했습니다. 인스펙터는 자비스의 노드 이름이 아니라 독립 외부모델 리뷰의 역할 이름이었습니다.

경계가 흐려진 자리도 있었습니다. CSO가 워커에 작업을 배분했고, 워커에게 감사를 시킨 적이 있습니다. 둘 다 정정했습니다. 노드 관리와 작업 배분은 다른 일이고, 감사는 리뷰어 역할입니다.

2. 지시를 어떻게 주고받았나

여기가 처음에 제일 헷갈린 자리라 명령까지 적습니다.

대기열이 항상 안전한 것은 아닙니다. 리뷰어에 검증 의뢰를 대기열로 보냈다가 한 시간을 놀렸습니다. 바로 착수해야 하는 것은 직접 전송에 확정 키를 붙이는 편이 확실합니다.

본문 규칙도 둘 세웠습니다. [티켓], [보고], [리뷰]처럼 라벨로 시작하면 수신 노드가 사람이 친 문장과 구별합니다. 그리고 600자 이내로 압축합니다. 긴 본문은 배달이 끊깁니다. 실제로 한 노드가 "앞 보고가 658자라 재발신함"이라고 알려 온 적이 있습니다.

노드가 무엇을 하고 있는지는 보고를 기다리지 않고 실측으로 봤습니다.

cys status --json          # 역할별 큐 깊이와 유휴 시간
cys queue list --surface surface:2   # 마스터 자기 수신함
cys read-screen --surface surface:8 | tail -15   # 노드 화면 직접 읽기

3. 무엇을 만들었나

한 줄 요청이 어떻게 나뉘어 내려갔는지를 단계별로 적습니다. 이 표가 이번 과제에서 자비스가 실제로 한 일입니다.

마스터인 저는 이 중 아무것도 직접 하지 않았습니다. 제가 한 일은 요청을 단계로 나누고, 3안 중 하나를 고르고, 두 리뷰어가 갈린 건을 판정하고, 규격 밖 변경을 승인하거나 물린 것입니다.

조건부 승인 사례를 하나 적어 둡니다. 워커가 주석에 the navy she wears라고 썼는데 오너 성별을 단정하는 표현이라, 인칭 없이 색의 출처만 담게 했습니다. 최종 문구는 navy drawn from the portrait입니다.

4. 인스펙터에 무엇을 붙였나

판정을 자유 서술로 받으면 통과 여부가 흐려집니다. 네 가지로 고정하고 증거 규칙을 함께 걸었습니다.

증거 규칙은 이렇습니다. 주장마다 파일과 행 번호를 달고, 재현 명령과 그 출력을 함께 내고, 확인 못 한 것은 미확인으로 남기고, 판정문 자체를 파일로 저장한다.

마지막 항목이 나중에 저를 살렸습니다. 배달이 막혀도 파일을 직접 읽으면 됐습니다.

적용 직전에 통과해야 하는 하드 게이트도 아홉 항목 두었습니다. 미승인 변경 0건, 접근성 전수 재계산, 새 색의 대비, 포커스 표시, 상태 전환 시 레이아웃 동일성, 저장소 차단 시 폴백, 죽은 코드, 이미지 여백, 스크립트의 보안 정책입니다. 실제로 이 게이트가 규격에 없는 변경 세 건을 잡아 워커가 스스로 멈추고 저에게 판정을 요청했습니다.

5. 검수자가 제 근거를 무너뜨렸습니다

가장 값진 대목이었습니다. 잡힌 것 대부분이 "결론이 틀렸다"가 아니라 "그 결론을 그 근거로 말할 수 없다"였습니다.

검증 방법 자체가 무효였습니다. 워커가 "사용처를 한 줄도 안 건드렸다"를 var() 참조 총계가 131건으로 같다는 것으로 증명했습니다. 리뷰어가 토큰별로 갈라 세어 보니 --ink-3이 13에서 14로, --rule이 18에서 17로 실제로 바뀌어 있었습니다. 1대1 치환이라 총계가 보존됐고, 그래서 검증이 변경을 통째로 놓쳤습니다.

존재하는 것만 세고 "전부"라 선언했습니다. "CSS 참조 160건 전부 존재"라고 보고했는데 전수는 172건이었고 결측 12건을 표본에서 뺀 뒤 내린 결론이었습니다. 리뷰어가 이렇게 짚었습니다. "결함은 파일이 아니라 판정문의 표본에 있다."

인과를 잘못 돌렸습니다. 접근성 미달 13곳이 해소된 것을 "보조 텍스트 색을 3.48:1에서 4.71:1로 올려서"라고 보고했고 저도 그대로 오너에게 전했습니다. 리뷰어가 반사실로 계산해 보니 옛 색을 그대로 두고 지면만 어둡게 해도 5.04:1로 이미 통과였습니다. 원인은 배경 반전이었고 새 색은 오히려 여유를 줄인 선택이었습니다. 3.48은 밝은 지면, 4.71은 어두운 지면 기준인데 서로 다른 배경의 수치를 한 줄에 놓고 비교한 것이었습니다.

재현 절차라면서 남의 손에서 안 돌았습니다. "측정 절차를 제출하라"는 지적에 워커가 스크립트를 냈는데, 리뷰어가 자기 환경에서 돌리니 0바이트로 실패했습니다.

같은 종류의 지적이 네 번 반복됐습니다. 개별 실수가 아니라 습관이라 규칙으로 올렸습니다.

6. 검수자끼리도 갈렸습니다

리뷰어 1이 "시안 파일에 자동 전환 코드가 남아 규격 위반"이라 잡았고, 리뷰어 2가 반증했습니다. 그 코드가 손대는 것은 홈페이지 색이 아니라 비교 보고서 문서 자체의 겉모습이었습니다.

제가 판정했습니다. 금지 범위를 "사이트 스타일시트와 사이트 미리보기"로 한정하고 보고서 성격 문서는 예외로 두되 상단에 그 사실을 밝히게 했습니다.

다수결이나 평균이 아니라 마스터의 독립 판정으로 결착한다는 원칙이 이때 자리 잡았습니다.

스스로 뒤집은 것도 있었습니다. 워커가 "표시 190px라 레티나 2배에 389px가 모자라다"고 보고했다가 실측 후 필요한 것이 380px라 이미 충분하다고 정정했습니다. 리뷰어는 자기가 낸 픽셀 수치가 텍스트와 레이아웃 변화까지 섞인 오염값이었다며 폐기하고, 폐기 사실을 지우지 않고 증거에 남겼습니다.

7. 기준을 수치로 검증했습니다

검수자가 잡아낸 것들이 대화 안에만 있어서, 그 기준을 파일로 고정하고 실제로 재현되는지 쟀습니다. 강의에서 나온 골드셋과 정밀도·재현율이 여기 걸립니다.

먼저 판정 권한을 코드로 옮겼습니다. 리뷰어는 심각도와 근거만 내고 통과와 정지는 스크립트가 계산하게 했습니다. 강의에서 나온 결정성 경계입니다.

blocking ≥ 1 → BLOCK
major ≥ 1    → REVISE
minor ≥ 1    → REVISE
issue 0건    → ACCEPT

그것만으로는 재현성이 생기지 않았습니다. 판정문 7건에서 나온 issue 24건을 하나씩 독립 세션에 던져 등급만 다시 받았습니다. 원래 등급과 판정은 가리고, 산출물도 열어 보지 못하게 했습니다. 세 번씩 돌리니 최종 판정이 42.9% 확률로 뒤집혔습니다. 판정 단계는 코드라 결정론인데 입력인 등급이 흔들리고 있었습니다.

원인은 뒤에 적을 다섯 번째 자리, 등급 정의가 어디에도 없던 것이었습니다. 그래서 blocking과 major와 minor의 뜻을 글로 적어 판정자에게 함께 줬습니다. 새로 지어내지 않고 리뷰어들이 실제로 쓴 용법을 관찰해 정의했습니다.

정의가 갈리는 자리가 하나 있었습니다. 적용되지 않는 패치를 blocking으로 볼지 major로 볼지입니다. 토론으로 정하지 않고 두 안을 각각 24건씩 세 번 돌려 재현성을 비교했고, "그 결함이 실제로 공개를 막았는가"라는 사실 확인을 더해 골랐습니다.

이어서 결함을 일부러 심어 놓고 잡히는지 쟀습니다. 1주차 세법 위키 발표에서 틀린 노트를 심어 검증하신 방식을 따랐고, 한 가지를 더했습니다. 같은 문단을 결함 없는 판과 결함 심은 판으로 나눠 짝으로 넣었습니다. 서로 다른 문단을 양성과 음성으로 쓰면 판정자가 내용이 아니라 문체 차이로 구분할 수 있기 때문입니다. 음성은 지어내지 않고 ACCEPT 판정을 받은 산출물의 검증된 주장을 그대로 가져왔습니다.

처음 놓친 것이 모두 논리가 어긋난 종류라, 결함 정의를 넷에서 여섯으로 늘리고 판정 전에 밟을 단계를 두 개 넣었습니다. 보강한 지시문이 원래 골드셋에만 맞춰지지 않도록 아직 쓰지 않은 주장으로 홀드아웃을 따로 만들어 옛 지시문과 나란히 돌렸습니다.

확정한 지시문으로 잰 결과입니다. 집합이 다르면 분모도 다르니 한 쌍으로 묶지 않고 나란히 적습니다.

원 골드셋에서는 심어 둔 결함이 전부 잡혔습니다. 대신 결함 없는 문단 일곱 개를 결함이라 지목했습니다. 그 일곱 건을 하나씩 읽어 보니 전부 오탐은 아니었습니다. 셋은 판정자가 틀렸고, 셋은 판단이 갈릴 여지가 있었고, 하나는 제가 붙인 "결함 없음" 라벨이 틀렸습니다. 정밀도를 두 벌 적은 이유가 그것입니다. 음성 라벨은 "결함이 없음이 증명됐다"가 아니라 "알려진 결함이 없다"는 뜻입니다.

지시문을 고를 때 날 수치만 보면 잘못 고릅니다. 정밀도만 보면 앞 판이 0.778로 더 높은데, 그 정밀도는 맞는 지적 셋을 놓쳐서 나온 값이었습니다. 순수 오탐만 세면 순서가 뒤집힙니다.

이 과정에서 제가 만든 정답지에서 결함이 세 건 나왔습니다. 결함 없다고 라벨을 붙인 문단 하나에 실제로 결함이 있었고, 심어 놓은 결함 둘은 사실 결함이 아니었습니다. 검수기를 검증하려고 만든 정답지가 검수 대상이 됐습니다.

기준은 대화에 남기지 않고 REVIEW.md로 고정했습니다. 역할 정의, 심각도, 결정성 경계, 게이트 3층, 증거 규칙, 하드 게이트 10항목, 반복해서 나온 함정 7종을 담았습니다.

8. PKM 스키마를 함께 설계했습니다

과제의 두 번째 갈래입니다. 논문 5,000건에서 30,000건 규모의 서베이 지식베이스를 만들려는데, 요구된 품질 요건이 둘이었습니다. 반환 성공률이 높을 것, 그리고 카테고라이징이 자동일 것입니다.

두 요건 모두 검색 기술이 아니라 관계 스키마가 먼저 있어야 충족됩니다. 관계를 정해 두지 않고 자동 생성에 맡기면 잘못된 관계가 오류를 구조로 굳힙니다. 그래서 도메인, 클래스, 속성, 관계, 책임 순서로 v0을 적었습니다.

Claim을 따로 둔 것이 핵심입니다. 논문 단위로만 저장하면 "이 주장의 근거가 어느 논문 어느 절인지"를 되짚을 수 없습니다. 반박한다와 뒷받침한다를 관계에 넣은 이유도 같습니다. 논문을 따로따로 쌓으면 서로 어긋나는 주장이 나란히 저장되고 마는데, 이 두 관계가 있어야 충돌을 찾아낼 수 있습니다.

품질 요건도 재는 법까지 적어 뒀습니다. 반환 성공률은 테스트 질의 20~30개에 정답을 붙여 재고, 자동 분류는 표본 100건을 사람 분류와 대조합니다. 근거가 없으면 답하지 않고 기권하게 만드는 것이 여기서도 같은 요지입니다.

결과와 배운 점

공개까지 마쳤습니다

접근성은 정성이 아니라 계산으로 판정했습니다. 대비 4.5:1 기준에 최소 여유가 4.707과 4.701로 나왔고 리뷰어가 독립 계산으로 재현했습니다.

마지막 판정도 REVISE였습니다. 두 검수자 모두 공개된 결과물 자체는 건전하다고 하면서도 문서 표기 오류를 이유로 통과시키지 않았습니다.

제 쓰임에서 보완이 필요했던 자리

여기부터가 이 글을 쓰는 이유입니다. 설치하고 나면 바로 술술 굴러갈 줄 알았는데 그러지 않았고, 왜 그런지 알아내는 데 시간이 걸렸습니다. 같은 자리에서 막히실 분을 위해 적습니다.

1. 회신이 저에게 오지 않았습니다.

한 번은 노드 넷이 모두 작업을 끝냈는데 산출물이 하나도 안 보였습니다. 화면을 열어 보니 전부 완료 표시가 있었고, 제 수신함에는 회신 37건이 배달되지 못한 채 쌓여 있었습니다.

원인은 셋이 겹쳤습니다. 대기열 배달이 글자만 넣고 확정을 못 넣는 것, 제가 계속 작업 중이라 데몬이 배달할 틈을 못 찾는 것, 회신 본문이 길면 배달이 끊기는 것입니다.

실험으로 확인한 해소법은 이렇습니다. 확정 키만 넣어서는 안 풀리고 입력줄을 먼저 비워야 합니다.

cys send-key --to <역할> C-a C-k   # 입력줄 비우기
cys send-key --to <역할> Return    # 확정

이걸 손으로 계속 하기 어려워 상주 작업 두 개를 만들어 걸었습니다. 큐가 막힌 것을 미는 장치(unstick)와, 끝났는데 회신을 안 하는 것을 깨우는 장치(nudge)입니다. 두 번째가 핵심이었습니다. 첫 번째는 큐에 메시지가 있을 때만 작동하는데, 노드가 회신을 아예 안 보내면 큐가 0이라 발동하지 않습니다. 그 사각지대에서 반나절을 잃었습니다.

회신 규칙도 문구를 바꿔야 들었습니다. 노드 넷이 모두 작업을 끝내고 결과를 자기 화면에만 쓴 뒤 멈췄습니다. "화면에 답을 쓰는 것은 회신이 아니다"를 지시문에 넣고 나서 나아졌습니다.

2. 그 장치들이 마스터를 대상에서 빠뜨리고 있었습니다.

이번 주에 로그를 세어 보다 알았습니다. 제가 만든 두 스크립트의 역할 목록이 워커와 리뷰어와 CSO만 담고 있어서, 정작 회신이 쌓이는 마스터 수신함은 아무도 밀어 주지 않았습니다. 측정한 순간 마스터 큐가 54건이었고 다른 역할은 0에서 19 사이로 계속 빠지고 있었습니다.

반나절을 잃은 원인이 마스터 수신함이었는데, 정작 그 역할을 대상에서 뺀 채로 자동화를 걸어 뒀습니다. 다만 마스터는 사람이 앉는 자리라 키를 그냥 넣으면 입력 중인 문장이 지워집니다. 밀어내기가 아니라 알림만 내도록 갈라 두는 것이 제 쓰임에 맞는 보완이었습니다.

3. 미는 장치가 수렴하는지 확인하는 절차가 없었습니다.

로그를 세어 보니 1시간 46분 동안 1,225회 발동했고, 다섯 역할에 각 245회씩 완전히 균등했습니다. 26초마다 들어가는데 큐가 줄지 않았습니다. 막힌 것을 뚫는 장치라면 발동이 들쭉날쭉해야 하는데 매번 똑같이 들어가고 있었습니다.

발동한 뒤 큐가 실제로 줄었는지 확인하는 단계를 넣지 않은 것이 제 실수였습니다. 연속 실패가 쌓이면 저에게 올리고, 실패할수록 간격을 늘리는 쪽으로 고쳐야 합니다.

4. 조용히 빠져 있는 노드를 못 봤습니다.

리뷰어 하나가 두 시간 넘게 유휴 상태였는데 큐가 0이라 두 장치 모두 발동하지 않았습니다. 편성 점검은 프로세스만 보기 때문에 살아 있지만 한도가 막혀 아무 일도 못 하는 노드를 정상으로 판정했습니다.

한도 문제도 두 종류였습니다. 하나는 실제 소진이었고, 다른 하나는 계정에 한도가 남아 있는데 실행 중인 프로세스가 옛 토큰을 붙들고 있는 경우였습니다. 재로그인해도 그 프로세스는 안 풀립니다. 새 프로세스로 다시 띄워야 합니다.

5. 리뷰어 지침이 없는 파일을 가리키고 있었습니다.

판정 형식의 근거로 계약 문서를 참조하게 되어 있었는데, 제 설치본에는 그 파일이 없었습니다. 그래서 blocking과 major와 minor의 뜻이 어디에도 정의되어 있지 않았고, 리뷰어들이 정의 없이 등급을 붙이고 있었습니다.

저는 그것을 판정 7건이 나온 뒤에야 알았습니다. 산출물을 검수하기 전에 검수 지침 자체가 실재하는지 확인해야 한다는 것을 여기서 배웠습니다.

관리가 안 됐던 구간은 제 쪽 문제였습니다

오너에게 여러 번 "왜 이리 오래 걸리냐", "다른 창에서 하는 게 없어 보인다"는 지적을 받았습니다. 실제로 그랬고 원인은 도구가 아니라 저였습니다.

"마스터는 직접 일하지 않는다"는 규칙 때문에 한 줄 수정도 워커를 거쳤습니다. 오너가 "그건 네가 바로 할 수 있지 않냐"고 물었을 때 예외를 허용받았다가 다시 위임으로 돌아왔습니다. 돌아온 이유가 중요합니다. "사소한 수정을 직접 하는 게 문제가 아니라, 워커가 한 일을 파악 못 하는 게 문제"라는 지적이었습니다. 규칙을 푸는 것이 아니라 파악 수단을 만드는 것이 답이었습니다.

컨텍스트도 미리 관리해야 했습니다. 60%에서 선제 보고하고 70~80%에서 인계 문서를 쓰게 했는데, 사이클 뒤에는 대화 기억이 사라지고 디스크에 적힌 것만 이어집니다. 규격이 여러 번 바뀌어서 인계 문서에 hex 값까지 그대로 불러 줬습니다.

배운 점

1. 검수는 결론이 아니라 근거를 봅니다.
잡힌 것 대부분이 "결론이 틀렸다"가 아니라 "그 결론을 그 근거로 말할 수 없다"였습니다. 접근성 14곳에서 0곳은 사실이었고 원본 무수정도 사실이었습니다. 문제는 그 사실을 뒷받침하는 방법이 헛돌았다는 것입니다.

2. 검증 방법 자체가 검수 대상입니다.
총계 비교로 무변경을 증명하던 게이트가 실제 변경을 못 잡았습니다. 검사기를 만들면 그 검사기가 무엇을 못 잡는지도 세야 합니다.

3. 정의를 글로 적은 쪽이 코드보다 크게 움직였습니다.
판정을 코드로 옮긴 것은 필요조건이었지 충분조건이 아니었습니다. 등급 정의 한 장을 함께 준 것만으로 판정이 갈리는 비율이 42.9%에서 0%로 갔습니다.

4. 벤더를 나눈 것이 값했습니다.
같은 모델끼리 검증하면 서로 감쌀까 걱정했는데, 코덱스가 잡은 것을 클로드가 반증하고 그 반대도 있었습니다. 한 리뷰어가 한도 소진으로 죽어 같은 벤더로 임시 대체했는데, 그 노드가 매 판정문 끝에 "마스터와 워커와 나 모두 같은 모델이라 사각지대가 겹친다"를 스스로 적었습니다. 그 라벨이 판정을 읽는 데 도움이 됐습니다.

5. 조직을 굴리는 비용이 실재합니다.
노드를 여럿 세우면 일이 나뉘는 만큼 관리도 나뉩니다. 반나절을 배달 문제에 썼고 상당 부분은 제가 노드를 파악하지 못해 낭비됐습니다. 그 비용을 줄이는 것은 위임 규칙이 아니라 파악 수단이라는 것이 이번에 배운 것입니다.

6. 도구를 자기 쓰임에 맞추는 일이 절반입니다.
설치하면 바로 굴러갈 줄 알았는데, 제 작업 방식에 맞추는 데 시간이 더 들었습니다. 마스터를 어떻게 감시할지, 회신을 어떻게 강제할지, 등급을 어떻게 정의할지는 도구가 정해 주지 않고 쓰는 사람이 정해야 했습니다. 강의에서 "구조가 왜 잘 돌아가는지를 보고 자기 것에 옮기라"고 한 말이 이 뜻이었다고 이해했습니다.

남은 것

• 배달 문제의 근본 원인은 아직 모릅니다. 지금은 증상을 계속 눌러 주는 대응입니다

• 세 판의 지시문이 모두 같은 세 문단을 잘못 지목합니다. 순수 오탐으로 갈라 둔 것들이고, 지시문을 바꿔도 그대로 남습니다. 남은 개선 여지가 여기 있습니다

• 골드셋 표본이 작습니다. 유효 양성 15건이라 재현율 1.000도 한 건이 크게 흔듭니다

• 변이를 제가 만들었으니 홀드아웃이라 부르기 어렵습니다. 남이 만든 결함으로 다시 재야 합니다

• PKM은 스키마까지만 만들었습니다. 저장 기술과 청킹 단위를 정하지 않았고, 테스트 질의 20~30개도 아직입니다

도움 받은 글 (옵션)

• 3주차 강의의 인스펙터 설명. 루브릭 같은 기준을 붙여 검수와 평가를 시키는 자리라는 안내가 이번 작업의 출발점이었습니다. 노드마다 다른 모델을 붙일 수 있다는 설명도 그대로 썼습니다

• 3주차 과제 안내의 세 갈래. 도메인 워크스페이스 구축, PKM 구축, 검수 기준을 하나씩 쌓기라는 구분에 맞춰 이번 주 작업을 나눴습니다

• 1주차 세법 LLM 위키 발표. 일부러 틀린 노트를 심어 검증하는 방식을 골드셋에 그대로 가져왔습니다. claim 단위로 나눠 검증하는 구성과 원문 해시로 무결성을 확인하는 방식은 PKM 스키마에 반영했습니다

• 스터디 공식 용어 사전. 결정성 경계, 게이트 3층, 플립 레이트, 골드 Eval Set의 정의를 여기서 맞췄습니다. 인스펙터가 노드 이름이 아니라 리뷰 역할 이름이라는 것도 여기서 확인했습니다

• 2주차 강의의 정답지 이야기. 판단 기준이 있는 것은 규칙으로 못 박고 애매한 것은 사람에게 넘기며 결과 검증에는 정답지를 두라는 정리가 이번 주 내내 기준이 됐습니다

• 3주차 발표의 세션 저장 이야기. 미리 기억하라고 명령하지 않으면 처음부터 다시 한다는 공유 덕에 인계 문서를 먼저 만들었습니다