노드 넷이 일을 끝냈는데 제게는 아무것도 오지 않았습니다

소개

이번 주 과제는 하네스 터미널을 설치해 굴려 보고, 마스터와 CSO와 인스펙터가 무엇을 하는지 보고, 인스펙터에 내 검수 기준을 붙이는 것이었습니다. 강의 마지막에 이런 안내가 있었습니다.

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

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

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

이 글은 조직을 굴려 본 기록입니다. 잘 돌아간 자리와 제 쓰임에서 보완이 필요했던 자리를 함께 적습니다. 저처럼 "다 되는 줄 알았는데 왜 안 되지" 하실 분이 있을 것 같아서입니다.

진행 방법

1. 편성

노드마다 다른 모델을 붙일 수 있다는 점을 실제로 썼습니다.

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

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

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

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

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

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

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

적용 직전에 통과해야 하는 하드 게이트도 아홉 항목 두었습니다. 실제로 이 게이트가 규격에 없는 변경 세 건을 잡아 워커가 스스로 멈추고 저에게 판정을 요청했습니다.

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

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

검증 방법 자체가 무효였습니다. 워커가 "사용처를 한 줄도 안 건드렸다"를 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바이트로 실패했습니다.

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

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

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

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

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

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

결과와 배운 점

공개까지 마쳤습니다

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

그다음에 기준을 수치로 검증했습니다

검수자가 잡아낸 것들이 대화 안에만 있어서, 그 기준을 파일로 고정하고 실제로 재현되는지 쟀습니다.

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

그런데 그것만으로는 재현성이 생기지 않았습니다. 같은 결함 주장을 세 번씩 다시 판정시켰더니 최종 판정이 42.9% 확률로 뒤집혔습니다. 판정 단계는 코드라 결정론인데 입력인 등급이 흔들리고 있었습니다. 위에 적은 다섯 번째 자리, 등급 정의가 어디에도 없던 것이 원인이었습니다.

등급 정의를 글로 적어 다시 쟀습니다.

이어서 결함을 일부러 심어 놓고 잡히는지 쟀습니다. 1주차 세법 위키 발표에서 틀린 노트를 심어 검증하신 방식을 따랐습니다. 지시문을 두 번 보강한 끝에 재현율 1.000, 정밀도 0.833이 나왔습니다.

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

배운 점

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

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

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

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

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

남은 것

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

• 정밀도가 0.833에서 멈췄습니다. 세 지시문 모두 같은 세 문단을 잘못 지목합니다

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

도움 받은 글 (옵션)

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

• 1주차 세법 LLM 위키 발표. 일부러 틀린 노트를 심어 검증하는 방식을 골드셋에 그대로 가져왔습니다. claim 단위로 나눠 검증하는 구성도 참고했습니다

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

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

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