Step 296. CTF 복기 블록 A + 팀 전략 점검: 운영 개선 — 기술이 아닌 마찰을 줄이는 것도 점수다

Level 3 — CTF 실전과 공격 스킬 심화 | 난이도 ★★☆☆☆ | 예상 소요 시간 2일 (복기 반나절 + 운영 회의·헌장 작성 1일)

전제: Step 293~295의 대회 #8·#9 완료, Step 281의 팀 협업 규칙(상태표·스왑) 운영 경험.

준비물: 최근 대회의 채팅 로그(디스코드보내기 등), 상태표 기록, 팀 전원이 모이는 90분, 파이썬 실행 환경. 이 챕터의 로그 분석 스크립트는 여러분의 채팅 로그로 직접 돌리는 실측 도구이고, 회의 장면은 출력 예시입니다.
⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다. 채팅 로그 분석은 팀 전원의 동의가 있는 우리 팀 로그에만 수행하고, 로그에 포함된 개인정보는 회의 자료로 옮길 때 가공합니다.
이 챕터는 정리입니다 — 새 공격 기법은 없고, 9개 대회의 데이터로 팀의 운영 자체를 점검합니다.

대회 9회차가 되면 팀에는 규칙과 도구가 쌓여 있습니다 — 상태표, 스왑 규칙, 단서 공유 규칙, 디스코드 채널, 공유 문서. 그런데 질문 하나를 던져 보세요. 그 규칙들, 지금 지켜지고 있습니까? 상태표 갱신은 1시간마다 되는지, 단서가 채팅에 묻히지는 않는지, 스왑 규칙이 대회 중엔 유명무실해지지는 않는지.

기술 스킬이 점수를 만든다면, 운영의 마찰은 점수를 샙니다. 85분 동안 아무도 반응하지 않은 단서 하나가 그 대회의 300점이었을 수 있습니다. 오늘은 복기 블록 A를 마친 뒤, 팀 운영 회고 프레임(Keep/Problem/Try)으로 마찰의 좌표를 찾고, 팀 헌장 v1으로 규칙을 정리합니다. 기술이 아닌 곳에서 점수를 회수하는 날입니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

채팅 로그에서 단서 반응 시간·묻힌 단서·상태표 갱신 간격 같은 운영 지표를 추출한다
Keep/Problem/Try 프레임으로 팀 운영 회고를 진행하고 안건을 구조화한다
지표의 이상 신호를 "규칙 개정 또는 도구 교체"의 구체적 개선안으로 변환한다
점수에 직결되는 규칙만 남기는 기준으로 팀 헌장 v1을 작성한다
팀의 구멍 분야를 데이터로 확인하고 영입 필요 여부를 논의한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	파이썬 3(로그 분석), 디스코드보내기 텍스트, 공유 문서 도구
오늘의 명령	`python ops_audit.py` — 채팅 로그에서 운영 지표 추출
필요한 개념	KPT 회고(Keep/Problem/Try), 운영 지표, 팀 헌장, 규칙의 최소화
오늘의 산출물	운영 지표표 + KPT 회의록 + 팀 헌장 v1

2-1. 왜 운영인가 — 마찰도 점수다

9개 대회의 복기를 거치면서 여러분은 기술적 약점은 데이터로 잡아왔습니다(Step 284, 288). 그런데 복기표에 기술로 설명 안 되는 손실이 섞여 있습니다 — "그 단서, 내가 채널에 올렸는데 아무도 안 봤어", "상태표가 하도 안 갱신돼서 같은 문제를 두 명이 잡았어". 이것은 실력 부족이 아니라 운영의 마찰입니다.

마찰의 무서운 점은 누적된다는 것입니다. 대회 1회에 새는 30분은 작지만, 그 손실이 9회 반복됐다면 그 총량은 Medium급 문제 하나 분량입니다. 반대로 마찰을 줄이는 개선은 이후 모든 대회에 복리로 적용됩니다. 기술 특훈이 특정 유형의 점수를 회수한다면, 운영 개선은 모든 유형의 점수를 회수합니다.

2-2. 운영 지표 — 회고에도 데이터가 필요하다

운영 회고가 "요즘 소통이 좀 아쉽지 않아?"로 시작하면 결론은 분위기로 납니다. 기술 복기에 복기표가 있듯, 운영 복기에는 지표가 필요합니다. 채팅 로그에서 뽑을 수 있는 핵심 지표는 네 가지입니다.

지표	계산법	이상 신호
단서 공유 건수	"단서:"로 시작하는 메시지 수	너무 적으면 공유 규칙 사장
첫 반응 시간	단서 메시지 → 타인의 다음 메시지	30분 이상이면 사실상 묻힘
묻힌 단서	끝까지 반응 없는 단서 수	1건이라도 있으면 규칙 점검
상태표 갱신 간격	갱신 메시지 사이의 시간	규칙(1시간)의 2배 이상 공백

이 지표들이 좋으면 소통 규칙은 건강한 것이고, 나쁘면 "느낌"이 아니라 숫자로 어디가 고장 났는지 알 수 있습니다.

2-3. KPT 회고 프레임 — Keep / Problem / Try

팀 운영 회고의 표준 프레임입니다. 세 칸의 화이트보드에 팀원이 포스트잇을 붙이듯 진행합니다.

Keep(유지): 이번에 잘 작동한 것 — 점수로 환산된 운영 습관. "컨설팅 요청이 빨랐다", "키크오프 예측표가 방향을 잡아줬다".
Problem(문제): 마찰이 관찰된 것 — 반드시 지표 또는 사건과 함께 씁니다. "소통이 아쉽다"(✗)가 아니라 "단서 첫 반응 평균 18분, 최장 85분"(○).
Try(시도): 다음 대회에 시험할 개선안 — 규칙 개정이나 도구 교체. 측정 방법이 있어야 합니다. "반응이 없으면 15분 뒤 멘션"처럼요.

KPT의 힘은 회의를 감정 정리가 아니라 버전 관리로 만드는 데 있습니다 — Try는 다음 대회라는 테스트 케이스가 있고, 결과는 다음 KPT의 Keep이나 Problem으로 회수됩니다.

2-4. 팀 헌장 — 규칙은 덜어내는 것이 정비다

규칙이 늘어나면 팀은 답답해지고, 답답해진 팀은 규칙을 무시하기 시작합니다 — 무시가 관성이 되면 규칙 전체가 죽습니다. 그래서 헌장 작성의 첫 원칙은 "점수에 직결되는 규칙만 남기고 덜어내기"입니다.

판별법은 간단합니다 — "이 규칙이 깨졌을 때 점수 손실 사례를 최근 대회에서 댈 수 있는가?" 댈 수 있으면 Keep, 댈 수 없으면 삭제 후보입니다. "인사는 합시다" 같은 규칙은 헌장이 아니라 문화의 영역입니다. 헌장은 짧을수록 강합니다 — 한 페이지를 넘기면 안 됩니다.

3. 따라 하기

3-1. 복기 블록 A 먼저 — 운영 회의는 복기 뒤에

대회 #9의 복기 블록 A(틀린 문제 끝까지 파기)를 먼저 완료합니다. 순서가 중요합니다 — 기술 복기가 끝나야 "그 문제, 사실 운영 탓이었어"와 "순수하게 실력이 부족했어"가 구분되기 때문입니다. 복기표의 "그걸 알려면 뭐가 필요했나" 칸에 "단서가 묻히지 않았다면 알 수 있었다"가 등장하면, 그것은 기술 과제가 아니라 운영 안건입니다.

복기가 끝나면 팀 운영 회의를 소집합니다 — 90분, 전원 참석, 안건은 미리 공유합니다.

운영 회의 안건 (90분):
1. 운영 지표 리뷰 (20분) — 로그 분석 결과를 같이 읽는다
2. KPT 브레인스토밍 (30분) — 칸별 포스트잇, Problem은 지표 첨부
3. 개선안 확정 (20분) — Try를 다음 대회 규칙/도구로 번역
4. 헌장 v1 + 영입 논의 (20분) — 규칙 덜어내기와 구멍 분야

3-2. 운영 지표 추출 — 로그를 숫자로

디스코드 채널 로그를 텍스트로보낸 뒤(개인정보는 가공), 형식을 [HH:MM] 닉: 내용으로 정리합니다. 우리 팀 규칙상 단서는 "단서:"로, 상태표 갱신은 "상태표 갱신" 문구로 시작하니 정규식으로 잡을 수 있습니다. ops_audit.py로 저장하세요.

# ops_audit.py — 대회 채팅 로그 운영 지표 추출기
# 로그 형식: [HH:MM] 닉네임: 내용  ("단서:" / "상태표 갱신" 키워드 기반)
import re
from datetime import datetime
from pathlib import Path

log = (Path(__file__).parent / "chat_log_sample.txt").read_text(encoding="utf-8")
line_re = re.compile(r"^\[(\d{2}:\d{2})\] (\S+): (.*)$", re.M)
events = []
for m in line_re.finditer(log):
    t = datetime.strptime(m.group(1), "%H:%M")
    events.append((t, m.group(2), m.group(3)))

clues = [(t, u, msg) for t, u, msg in events if msg.startswith("단서:")]
status = [(t, u) for t, u, msg in events if "상태표 갱신" in msg]

first_reply, buried = [], 0
for t, u, msg in clues:
    reply = next((t2 for t2, u2, _ in events if t2 > t and u2 != u), None)
    if reply is None:
        buried += 1
    else:
        first_reply.append((reply - t).seconds // 60)

print(f"채팅 {len(events)}줄 분석 결과")
print(f"단서 공유: {len(clues)}건")
if first_reply:
    avg = sum(first_reply) / len(first_reply)
    print(f"첫 반응까지: 평균 {avg:.0f}분 (최장 {max(first_reply)}분)")
print(f"반응 없이 묻힌 단서: {buried}건")
print(f"상태표 갱신: {len(status)}회")
gaps = [(status[i+1][0] - status[i][0]).seconds // 60 for i in range(len(status)-1)]
if gaps:
    print(f"갱신 간격: 평균 {sum(gaps)/len(gaps):.0f}분, 최장 공백 {max(gaps)}분")

샘플 로그(대회 후반 10시간, 16줄로 압축·가공한 것)에 대한 실행 결과입니다 — 실측입니다:

$ python ops_audit.py
채팅 16줄 분석 결과
단서 공유: 6건
첫 반응까지: 평균 18분 (최장 85분)
반응 없이 묻힌 단서: 0건
상태표 갱신: 5회
갱신 간격: 평균 146분, 최장 공백 190분

읽는 법: 표면은 나쁘지 않습니다 — 묻힌 단서 0건. 그러나 숫자 두 개가 경고등입니다. ① 첫 반응 최장 85분 — 샘플에서 15:40의 "JWT alg=none 테스트 필요" 단서가 17:05까지 반응이 없었습니다. 묻히진 않았지만, 대회 중 85분은 Medium급 하나의 생사입니다. ② 상태표 갱신 최장 공백 190분 — 규칙은 1시간인데 세 시간 넘게 비었습니다. "규칙이 있다"와 "규칙이 작동한다"는 다른 상태이고, 그 차이는 이렇게 숫자로만 드러납니다.

여러분의 로그로 바꿔치기해 돌려 보세요. 파일명만 chat_log_sample.txt를 우리 로그로 바꾸면 됩니다.

3-3. KPT 회의 — 지표를 안건으로

3-2의 지표를 들고 KPT를 진행합니다. Problem 칸에는 지표가 붙은 항목만 올립니다.

출력 예시 (KPT 화이트보드):

Keep
- 컨설팅 요청 문화 (로테이션 대회에서 지식 전수 잘 작동)
- 4시간 점검의 서면 3줄 — 몰입 안 끊기고 진행됨

Problem
- 단서 첫 반응 최장 85분 (지표 ①) — 야간 시간대에 집중
- 상태표 갱신 공백 최장 190분 (지표 ②) — 규칙은 1시간
- 디스코드에 페이로드가 스크롤에 묻힘 — 재사용하려면 검색해야 함

Try (다음 대회에 시험)
- 단서 메시지에 "확인" 리액션 의무화 — 15분 무리액션 시 당번이 멘션
- 상태표 갱신을 알람봇(또는 순번제)으로 — 사람 기억에 맡기지 않기
- 페이로드/스크립트는 채팅 대신 팀 Git 저장소에 — 채팅엔 링크만

읽는 법: Try의 세 항목이 전부 "규칙 추가"가 아니라 장치 추가인 것을 보세요. "상태표 열심히 갱신하자"는 다짐은 다음 대회에 또 무너집니다 — 알람봇이나 순번제처럼 사람의 기억에 의존하지 않는 장치로 바꾸는 것이 운영 개선의 문법입니다.

3-4. 팀 헌장 v1 — 한 페이지의 규칙들

KPT의 결론을 반영해 헌장을 씁니다. 기존 규칙(Step 281~293에서 쌓인 것)을 전부 모은 뒤, 2-4의 판별법으로 덜어냅니다.

출력 예시 (팀 헌장 v1):

== 우리 팀 헌장 v1 ==

목표: 시즌 2(대회 #11~#20) — 상위 30% 안착

역할
- 분야 고정 분업 기본 + 대회당 1개 문제는 로테이션 (대회 #8 실험 확정안)
- 당번제: 상태표 갱신 당번, 단서 확인 당번 (대회마다 교대)

규칙 (점수 직결만)
1. 단서는 "단서:" 접두사로. 15분 무리액션 시 당번이 멘션한다
2. 상태표 1시간 갱신 — 당번이 알람을 소유한다
3. 한 문제 2시간 — 넘기면 스왑, 연장은 팀 합의로만
4. 코드·페이로드는 Git에, 채팅엔 링크만
5. 대회 종료 48시간 안에 담당 문제 Write-up 초고

벌칙 (재미 요소)
- 규칙 위반 누적 시 회식비 담당 — 기록은 상태표 시트에

삭제된 규칙: "매일 스크럼"(대회 기간 외엔 점수 무관), "읽씹 금지"(문화 영역)

읽는 법: 맨 아래 "삭제된 규칙" 칸이 헌장의 핵심입니다 — 덜어낸 것을 명시해야 나중에 "이 규칙 왜 없어?"가 되살아나지 않습니다. 벌칙 칸은 재미 요소이지만 실은 준수율 장치입니다 — 가벼운 벌칙이 있는 규칙은 위반이 "공개 기록"이 되고, 공개 기록은 다짐보다 강합니다.

3-5. 구멍 분야와 영입 논의

마지막 안건은 인원입니다. 9개 대회의 분야별 득점률 표(Step 284의 형식)를 다시 열어, 늘 0점이거나 담당자가 1명뿐인 분야를 확인합니다.

분야별 커버리지 점검 (화면 예시):
- web: 담당 2명, 득점률 80% — 여유
- pwn: 담당 1명, 득점률 30% — 담당자 결석 시 0점 위험 ★ 구멍
- crypto: 담당 1명, 득점률 50% — 복기로 성장 중
- rev/forensics: 겸업 — 대회당 1문제 커버 수준

결론: pwn 세컨드 영입 검토 — 커뮤니티 활동자 중 힙 특훈에 관심 있는 인재 탐색

영입의 기준은 실력만이 아닙니다 — 우리 헌장의 규칙(상태표·48시간 초고)을 받아들일 사람인가가 더 중요합니다. 운영 문화가 맞지 않는 에이스는 점수를 더하기보다 마찰을 곱합니다.

4. 미션과 연습문제

미션 — 운영 회의 + 팀 헌장 v1

대회 #9의 복기 블록 A를 먼저 완료하고, 복기표에서 "운영 탓"이었던 항목을 별도 표시합니다.
최근 대회 채팅 로그를 텍스트로보내 가공한 뒤, ops_audit.py로 운영 지표를 추출합니다.
지표를 안건으로 KPT 회의(90분)를 진행합니다 — Problem에는 반드시 지표 또는 사건을 첨부합니다.
Try 항목을 다음 대회에 시험할 규칙·장치로 확정하고, 측정 방법을 함께 적습니다.
기존 규칙 전체를 모아 "점수 직결 여부"로 심사하고, 팀 헌장 v1(한 페이지)을 작성합니다 — 삭제된 규칙 칸 포함.
분야별 커버리지 표로 구멍 분야를 확인하고, 영입 필요 여부와 기준을 회의록에 남깁니다.

연습문제

문제 1. 운영 회고에서 Problem 항목에 "지표 또는 사건의 첨부"를 요구하는 이유는 무엇인가요? 첨부가 없을 때 회의가 어떻게 흐르는지 포함해 답해 보세요.

문제 2. "묻힌 단서 0건"인데도 "첫 반응 최장 85분"이 문제로 올라온 이유는 무엇인가요? 두 지표가 측정하는 것의 차이를 설명해 보세요.

문제 3. 운영 개선안이 "다짐"이 아니라 "장치"여야 하는 이유를, 상태표 갱신 규칙의 사례로 설명해 보세요.

문제 4. 팀 헌장에 "삭제된 규칙" 칸을 두는 이유는 무엇인가요? 규칙 최소화 원칙과 연결해 답해 보세요.

5. 모범 답안과 완료 기준

미션 모범 답안

검증 기준으로 확인하세요.

순서 준수: 기술 복기(블록 A)가 운영 회의보다 먼저 완료됐고, 복기표에서 운영 원인 항목이 분리 표시됐는가.
지표의 실측성: 네 지표(단서 건수·첫 반응·묻힌 단서·갱신 간격)가 스크립트 출력으로 확보됐고, 회의에서 함께 읽었는가.
KPT의 품질: Problem 전 항목에 지표·사건이 첨부됐고, Try 전 항목에 측정 방법이 있는가.
헌장의 분량: 한 페이지 이내이고, 각 규칙에 "점수 손실 사례"를 댈 수 있으며, 삭제된 규칙 칸이 존재하는가.
장치 전환: 새 규칙 중 최소 1개가 사람의 기억에 의존하지 않는 장치(알람·당번·봇)로 설계됐는가.
영입 논의: 커버리지 표에 근거한 결론(영입/유지)과 문화 적합 기준이 회의록에 있는가.

연습문제 해답

문제 1 해답. 지표가 없는 Problem은 사람에 대한 평가로 미끄러지기 때문입니다. "소통이 아쉽다"는 곧 "누가 아쉽다"가 되어 회의가 원인 분석 대신 방어와 해명의 장이 됩니다. 지표가 첨부되면 대상이 사람에서 구조로 바뀝니다 — "반응이 85분 걸렸다"는 누구의 잘못이 아니라 "반응을 담보하는 장치가 없다"는 구조의 결함으로 읽힙니다. 팀 회고가 인간관계를 갉아먹지 않고 반복 가능하게 작동하려면, 문제는 항상 숫자와 사건의 형태로 제출되어야 합니다.

문제 2 해답. "묻힌 단서"는 최종 생사를, "첫 반응 시간"은 지연의 비용을 측정하기 때문입니다. 묻히지 않았다는 것은 결국 누군가 받았다는 뜻이지만, 85분의 지연은 대회 중 다른 팀과의 상대 속도 손실입니다 — 특히 그 단서가 다른 문제의 열쇠였다면 지연은 연쇄적으로 번집니다. 샘플의 85분이 야간 시간대에 몰린 것처럼, 반응 지연은 시간대·인원 배치 같은 운영 패턴을 드러냅니다. 0건이라는 결과에 안심하지 않고 분포의 꼬리까지 보는 것이 지표 읽기입니다.

문제 3 해답. 다짐은 의지를 자원으로 쓰고, 의지는 대회 후반에 가장 먼저 고갈되는 자원이기 때문입니다. "상태표 1시간 갱신하자"는 다짐은 대회 3시간 차의 몰입 앞에서 무너집니다 — 실제로 샘플 로그에서 190분 공백이 관측됐습니다. 같은 규칙을 당번제+알람으로 바꾸면, 규칙의 실행 주체가 "각자의 기억"에서 "시계와 순번"으로 옮겨갑니다. 장치는 피곤하지 않고, 몰입하지 않고, 체면을 구기지 않습니다. 운영 개선의 문법은 규칙을 세우는 것이 아니라 규칙의 실행을 사람의 의지에서 분리하는 것입니다.

문제 4 해답. 규칙은 한번 만들어지면 삭제 근거를 잃어 좀비처럼 남기 때문입니다. "삭제된 규칙" 칸은 덜어낸 것과 그 이유를 기록해 두어, 나중에 누군가 같은 규칙을 다시 제안할 때 "그거, 점수 무관해서 뺐어"라고 되찾을 수 있게 합니다. 규칙 최소화의 목적은 규칙의 총량이 아니라 각 규칙의 위상을 지키는 것입니다 — 규칙이 적을수록 하나하나가 "진짜로 지켜야 하는 것"으로 읽히고, 위반의 벌칙도 작동합니다. 헌장이 한 페이지를 넘는 순간 규칙은 권위를 잃기 시작합니다.

완료 기준 체크리스트

[ ] 대회 #9 복기 블록 A를 운영 회의보다 먼저 완료했다
[ ] 채팅 로그에서 운영 지표 4종을 스크립트로 추출했다
[ ] KPT 회의록이 있다 — Problem에 지표/사건 첨부, Try에 측정 방법
[ ] 개선안 중 1개 이상이 장치(알람·당번·봇)로 설계됐다
[ ] 팀 헌장 v1이 한 페이지로 완성됐다 (삭제된 규칙 칸 포함)
[ ] 분야별 커버리지 표로 구멍 분야를 확인했다
[ ] 영입 논의 결과(필요 여부·기준)가 회의록에 남았다

6. 흔한 실수와 해결

벽 1. 로그 파일을 못 찾아서 스크립트가 죽어요

증상:

    return io.open(self, mode, buffering, encoding, errors, newline)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '...tmp_test\\chat_log_sample.txt'

원인: 로그 파일이 스크립트와 같은 폴더에 없거나 파일명이 다릅니다. 스크립트는 자신이 있는 폴더의 chat_log_sample.txt를 엽니다 (실측).

해결: 스크립트와 로그를 같은 폴더에 두거나, 코드의 파일명을 여러분의 로그 파일명으로 바꾸세요. 디스코드보내기 원본은 형식이 제각각이므로, 먼저 [HH:MM] 닉: 내용 형식으로 정리(정규식 치환 또는 수작업)해야 합니다 — 이 정리 과정에서 개인정보도 함께 가공합니다.

벽 2. KPT 회의가 칭찬 대회가 돼요 — Problem이 안 나와요

증상: Keep만 10개, Problem은 "없었던 것 같아요".

원인: 팀 분위기가 좋을수록 문제 제기가 관계의 리스크로 느껴집니다 — 정상적인 심리입니다.

해결: 진행자가 지표를 먼저 화면에 띄우세요. "85분"과 "190분"이 스크린에 있는데 Problem이 없다고 말하기는 어렵습니다. 그래도 안 나오면 질문을 바꿉니다 — "뭐가 문제였나?"가 아니라 "다음 대회에서 같은 숫자가 또 나오면 우리는 뭘 바꿀까?". 미래형 질문은 비난이 아니라 설계라서 입이 열립니다.

벽 3. 헌장을 쓰다 보니 규칙이 15개가 됐어요

증상: 좋은 규칙을 계속 발견해서 페이지를 넘깁니다.

원인: 대회 9회의 경험이 전부 규칙 후보로 보입니다 — 그러나 경험의 교훈과 규칙은 다릅니다.

해결: 각 규칙 옆에 "최근 대회에서 이것이 깨져 점수를 잃은 사건"을 적으세요. 사건을 못 대는 규칙은 헌장이 아니라 플레이북이나 치트시트로 보냅니다 — 그것들의 자리는 규범이 아니라 참고 문서입니다. 헌장에는 살아남는 규칙만 남습니다. 목표는 7개 이하입니다.

벽 4. "도구를 바꾸자"는 안건이 회의를 삼켜요

증상: CTF 전용 협업 플랫폼 검토가 한 시간을 씁니다.

원인: 도구 비교는 재미있고 결론이 안 나는 주제의 대표입니다 — 기능표를 읽다 보면 목적을 잃습니다.

해결: 도구 교체의 전제 질문 하나만 물으세요 — "지금 도구에서 관측된 손실이 뭔가?" 우리 지표에서 디스코드의 문제는 "페이로드가 묻힌다" 하나였으니, 필요한 것은 플랫폼 교체가 아니라 Git 저장소 규칙이었습니다. 손실이 관측되지 않은 교체는 비용만 듭니다 — 마이그레이션과 재학습이 새로운 마찰이 됩니다.

벽 5. 영입 이야기에 기존 팀원 표정이 안 좋아요

증상: "pwn 세컨드 영입" 안건에 담당자가 위축됩니다.

원인: 영입이 "너는 부족하다"로 들릴 수 있습니다 — 데이터의 언어로도 관계는 관리가 필요합니다.

해결: 안건의 이름을 바꾸세요 — "구멍 메우기"가 아니라 "결석 리스크 헷지". 지표의 언어는 그대로입니다 — 담당 1명인 분야는 담당자가 결석하는 대회에 0점이 된다는 것은 인신평가가 아니라 산수입니다. 그리고 영입 기준에 "헌장 수용"을 명시해 두면, 기존 팀원에게도 신규 팀원에게도 문화가 기준이 됨이 분명해집니다.

7. 정리

오늘의 개념

개념	한 줄 설명
운영의 마찰	기술로 설명 안 되는 점수 손실 — 누적되고, 줄이면 복리로 돌아온다
운영 지표 4종	단서 건수·첫 반응·묻힌 단서·갱신 간격 — 운영 복기의 복기표
KPT	Keep/Problem/Try — 회고를 감정 정리에서 버전 관리로
장치 전환	규칙의 실행을 사람의 의지에서 시계·순번·봇으로 옮기기
팀 헌장	점수 직결 규칙만 한 페이지 — 삭제된 규칙도 기록
결석 리스크	담당 1명 분야 = 그 사람이 빠지면 0점 — 영입의 산수적 근거

오늘의 도구·명령어

도구·명령	하는 일
`python ops_audit.py`	채팅 로그에서 운영 지표 4종 추출
`[HH:MM] 닉: 내용` 형식	로그 분석 전 정리 규격 — 가공도 이 단계에서
KPT 화이트보드	90분 회의의 골격 — Problem엔 지표 첨부
헌장 양식	목표·역할·규칙·벌칙·삭제된 규칙의 다섯 칸
커버리지 표	분야별 담당 수·득점률 — 구멍 탐지기

명령어보다 중요한 감각

9개 대회를 거치며 팀은 실력만큼 관성도 쌓았습니다. 잘 작동하는 관성(컨설팅 문화)과 녹슨 관성(사람 기억에 맡긴 갱신)이 섞여 있고, 오늘 같은 점검이 없으면 둘은 구분되지 않은 채 다음 10회로 이월됩니다.

시즌 2를 앞둔 지금, 팀의 진짜 자산은 라이브러리도 순위도 아니라 "자기 운영을 데이터로 점검할 수 있는 능력"입니다. 기술은 개인이 쌓지만, 운영은 팀이 쌓습니다 — 그리고 대회라는 시계 위에서는 후자가 전자의 출력을 결정합니다. 헌장 v1은 끝이 아니라 첫 커밋입니다. 다음 KPT에서 갱신될 자리를 비워 두세요.

전부 체크되면 Step 296 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.