팀 용어집과 전환 — 고칠 곳만 골라 실제로 정착시키기

개념

아는 것과 바뀌는 것은 다르다

여기까지 오면 무엇이 어긋나 있는지 전부 안다. 크로스 브라우저는 적응성이고, 호환성은 공존성·상호운용성이고, 버그는 결함이고, Critical은 심각도다.

그런데 아는 사람이 한 명 생겼다고 조직이 바뀌지는 않는다. 이 레슨은 그 간극을 다룬다.

전면 교정이 실패하는 이유

용어를 배운 사람이 흔히 저지르는 순서가 있다.

1. 전사 공지: "앞으로 버그 대신 결함이라고 씁시다"
2. 위키에 용어집 페이지 생성
3. 회의에서 틀린 용어를 지적
4. 2주 뒤: 아무도 안 지킴. 지적하는 사람만 피곤한 사람이 됨

실패 원인은 셋이다.

① 범위가 너무 넓다. 일상 대화까지 포함하면 지킬 수 없다. ② 이득이 안 보인다. "왜 바꿔야 하죠"에 답이 없으면 안 바꾼다. ③ 강제할 지점이 없다. 말은 강제할 수 없다. 문서와 도구만 강제된다.

대신 이렇게 한다 — 좁게, 강제 지점에만

[고칠 곳 — 여기만 한다]
  ① 대외 문서 (성적서·제안서·인증 산출물·계약 부속서)
  ② 품질 특성 분류표 (검증 항목 커버리지)
  ③ 결함 리포트 본문 구조 (제목=실패, 원인=결함)
  ④ 지표 정의 (무엇을 센 숫자인가)
  ⑤ 도구 필드 (심각도·우선순위 분리)
 
[안 고치는 곳 — 그대로 둔다]
  · 슬랙·회의의 구어
  · 이슈 타입 이름("Bug")
  · 팀 내부 메모

강제 지점은 템플릿과 도구 설정이다. 템플릿에 칸이 있으면 채우고, 필드가 필수면 입력한다. 공지문은 며칠이면 잊히지만 템플릿은 매번 눈앞에 뜬다.

산출물 ① — 매핑표

가장 먼저 만들 문서다. 한 장을 넘기지 않는다.

"어디서 바꿔 쓰나" 칸이 이 표의 핵심이다. 이 칸이 없으면 사람들이 모든 곳에서 바꿔야 하는 줄 알고 부담을 느낀다.

산출물 ② — 용어집

매핑표가 "이건 저거다"라면, 용어집은 "이 말이 무슨 뜻이냐"다. 항목마다 네 칸이면 충분하다.

용어      결함 (defect)
정의      실행될 때 실패를 일으킬 수 있는 산출물의 결점
근거      ISO/IEC/IEEE 24765
쓰는 곳   결함 리포트 원인 칸, 대외 문서, 지표 정의
혼동 주의 '버그'는 결함·실패·이상을 모두 가리키는 구어

'혼동 주의' 칸이 실제로 가장 많이 읽힌다. 사람들은 정의를 읽으러 오지 않고 헷갈려서 온다.

담을 항목은 이 모듈이 다룬 것들로 시작한다 — 호환성·공존성·상호운용성· 적응성·오류·결함·실패·이상·심각도·우선순위. 열 개면 충분하고, 늘리고 싶은 욕심을 참는 것이 정착률을 높인다.

용어집이 살아 있는 조건 — 한 줄 형식

용어집이 죽는 이유는 내용이 틀려서가 아니라 고치는 비용이 커서 다. 항목 하나가 문단이면 아무도 손대지 않는다. 그래서 추가와 수정이 한 줄로 끝나는 형식 을 쓴다.

표준어        실무어            쓰는 자리             판
적응성        호환성 테스트      성적서·분류표          25010:2023
상호운용성    연동 테스트        성적서·계약 응답        25010:2023
결함          버그              리포트 원인 칸         24765
심각도        (Jira) Priority   도구 필드·릴리즈 판정    IEEE 1044-2009

네 칸 중 '판' 칸이 가장 자주 빠지고 가장 비싸게 빠진다. 판이 없으면 몇 년 뒤 그 줄이 어느 판의 이름인지 알 수 없다(레슨 2).

살아 있게 유지하는 조건은 둘이다.

소유자·최종 점검일 같은 문서 운영 장치의 일반론은 모듈 7 레슨 7 에 있다. 용어집에 고유한 것은 두 번째 줄 이다 — 용어집은 주기 점검으로 자라지 않고 사고가 날 때마다 자란다. 그래서 "지난달에 한 줄이라도 늘었나" 가 관리 상태를 가장 빨리 보여준다.

용어집에 넣지 않을 것

전부 넣으면 아무도 안 본다. 항목이 늘면 검색은 되지만 읽히지 않고, 읽히지 않는 용어집은 합의의 근거로 인용되지 않는다.

네 번째 줄이 가장 많이 발견된다. "Flexibility — 유연성 / 융통성 / 탄력성" 처럼 후보가 셋 적힌 항목은 쓸 때마다 다시 고민하게 만들어 문서를 쓰는 사람을 멈춰 세운다. 안 쓸 것을 정해 피로를 막는 원리는 모듈 7 레슨 7과 같으나, 용어집에서는 안 고른 것을 남겨두는 것 이 특히 비싸다 — 용어집의 존재 이유가 고르는 수고를 없애는 것이기 때문이다.

산출물 ③ — 판(edition) 기준 결정문

레슨 2에서 미뤄둔 결정을 여기서 확정한다.

[우리 조직 표준 기준]
품질 특성 분류   ISO/IEC 25010:2023
정량 측정량     ISO/IEC 25023:2016
              (25010:2011 기준으로 작성되어 상위 특성명이 일부 다름:
               이식성 → 유연성. 부특성명은 동일)
결함 용어       ISO/IEC/IEEE 24765
이상 분류       IEEE 1044-2009
예외           계약·발주처가 특정 판을 요구하면 그것을 우선한다

이 다섯 줄을 문서 템플릿의 '적용 표준' 절에 넣는다.

전환 순서 — 어디부터 손대나

한꺼번에 하지 않는다. 효과가 크고 마찰이 적은 순서로 간다.

1주차  매핑표 + 용어집 초안 (한 장씩)
       → 팀 리뷰. 이 단계에서 반대 의견을 다 받는다
 
2주차  결함 리포트 템플릿 수정
       → 제목/원인/영향 3단 구조 도입
       → 가장 빨리 체감되는 개선. 성공 경험을 먼저 만든다
 
3~4주차 도구 필드 분리 (레슨 7)
       → Severity 추가, Priority 값 변경, 참조처 점검
       → 가장 위험한 단계. 참조처 목록을 반드시 먼저 만든다
 
5~6주차 품질 특성 분류표 재작성 (레슨 3·4)
       → 오분류 걷어내기, 빈 칸 드러내기
       → 여기서 나온 빈 칸이 다음 분기 계획의 입력이 된다
 
이후    대외 문서 템플릿 (레슨 5)
       → 성적서·제안서 양식에 병기 형식과 적용 표준 절 반영
 
상시    신규 입사자 온보딩 자료에 용어집 포함

2주차를 먼저 하는 이유 는 성공 경험 때문이다. 결함 리포트 구조 개선은 개발자가 바로 체감한다. "요즘 리포트 보기 편해졌다"는 말이 나오면 그다음 변경에 대한 저항이 줄어든다.

이행 계획 — 참조처를 먼저 센다

이름을 바꾸는 일은 개념 작업처럼 보이지만 실제로는 설정 작업 이다. 그래서 계획서의 첫 줄은 일정이 아니라 참조처 수 다.

세는 데 반나절, 고치는 데 며칠 이 보통이다. 레슨 7의 사례에서 참조처가 17곳이었고 그것이 작업량의 대부분이었다.

세고 나면 계획이 저절로 정해진다. 참조처가 다섯 곳 미만 이면 한 주에 끝내고, 열 곳을 넘으면 전환일을 따로 잡아 한 번에 간다. 애매하게 나누면 옛 이름과 새 이름이 동시에 살아 있는 기간 이 길어지는데, 그 기간이 가장 위험하다 — 두 이름 중 어느 것으로 센 숫자인지 아무도 모른다.

전환 기록 한 장 — 전환일과 과거 데이터

레슨 2는 분류 축 을 바꿀 때 추세가 끊기는 문제를, 레슨 7은 등급 체계 를 바꿀 때 과거 값을 어떻게 다룰지를 각각 다뤘다. 이행 단계에서는 그 둘이 한 장의 기록 으로 합쳐진다. 바꾸는 사람과 보고서를 뽑는 사람이 다르기 때문이다.

[전환 기록]
무엇을        결함 분류 필드 '이식성' → '유연성'
전환일        2026-10-01 (분기 경계)
옛값→새값     이식성→유연성, 사용성→상호작용성+사용자 지원(판정 기준 별첨)
과거 데이터   소급 안 함. 2026-09-30 이전 건은 옛 축으로 읽는다
참조처 점검   완료 2026-09-26 (쿼리 6, 저장 필터 9, 알림 2)
읽는 법       추세 그래프의 2026-10-01 각주를 함께 본다

마지막 줄이 이 기록의 목적이다. 전환 전후를 구분해 읽는 법이 적혀 있지 않으면 반년 뒤 그래프를 본 사람은 꺾인 지점을 품질의 변화로 읽는다. 그래서 이 기록은 대시보드 각주와 분기 리포트 머리에 같은 문장으로 둔다. 한쪽에만 두면 대시보드를 보는 사람과 보고서를 받는 사람이 다른 사실을 믿는다.

합의를 만드는 방법 — 지시가 아니라 함께 체크한다

전환이 지켜지는지는 설득력이 아니라 누가 "아니오" 를 봤는가 로 갈린다. QA 혼자 진단해 제안하면 설득이 필요하고, 팀과 함께 체크하면 결론이 이미 공유된다(모듈 7 레슨 6의 자체 진단과 같은 효과).

15분이면 되는 문항이다.

• 지금 열린 결함 세 건의 심각도 판정 근거 를 서로 같게 말할 수 있나
• 최근 성적서의 시험항목명을 표준 분류로 다시 지을 수 있나
• "성능 테스트를 했다" 가 무엇을 쟀다는 뜻인지 두 사람의 답이 같은가
• 우리 용어집에 지난달에 한 줄이라도 늘었나
• 템플릿의 칸 이름과 용어집의 '쓰는 자리' 가 서로 맞나

네 번째 문항이 가장 많은 것을 알려준다. 한 줄도 안 늘었다면 용어집이 쓰이지 않는 것이고, 그때 필요한 것은 교육이 아니라 추가되는 계기 를 만드는 일이다.

외부 조직과의 용어 합의

팀 안의 합의는 계약 상대에게는 효력이 없다. 발주처·협력사와는 문서로 합의한다. 들어갈 자리는 품질합의서(품질보증계획서·SLA)의 용어 부속서 한 장이다.

세 번째와 네 번째가 실제로 분쟁을 막는다. 등급 이름이 같아도 뜻이 다르고, 같은 "결함 건수" 가 이상 접수 건수인지 확정 결함 건수인지로 갈린다. 부속서 한 장이 검수 회의 여러 번 을 줄인다. 그리고 구두 합의는 상대 담당자가 바뀌는 순간 사라진다.

정착을 확인하는 지표

바뀌었는지 아닌지를 느낌으로 판단하지 않는다.

마지막 지표가 흥미롭다. 호환성 칸 항목이 줄어드는 것이 개선이다. 오분류를 걷어냈다는 뜻이기 때문이다.

온보딩에 넣는다

가장 효율이 좋은 정착 수단이다. 신규 입사자는 기존 습관이 없어서 처음부터 바르게 배운다. 1년이 지나면 팀의 상당수가 처음부터 바르게 배운 사람이 된다.

온보딩 자료에 넣을 것:

• 매핑표 한 장
• 용어집 열 개 항목
• 결함 리포트 3단 구조 예시 두 건 (좋은 예·나쁜 예)
• 심각도 값 정의와 판정 근거 세 가지
• 적용 표준 기준 결정문

반대에 답하는 법

전환을 제안하면 반드시 나오는 말들이 있다. 미리 답을 준비해둔다.

마지막 답이 가장 자주 쓰인다. 전부 하자고 하면 거절당하고, 두 주만 하자고 하면 대개 승인된다.

사례 — 48항목 용어집이 조회 11회로 끝난 반년

실패. SI 품질팀이 위키에 48항목 용어집을 올리고 전사 공지를 두 번 냈다. 6개월간 그 페이지 조회가 11회 였고, 성적서·제안서에서 용어집을 인용한 문서는 0건 이었다. 같은 기간 성적서 보완 요구는 3건 으로 전년과 같았다.

원인. 셋이었다.

바꾼 것. 항목을 9개로 줄였다(대외 문서 등장 7개 + 트리아지 이견이 반복된 2개). 성적서와 결함 리포트 템플릿의 칸 이름을 용어집 표기로 교체하고, 참조처 14곳 을 먼저 세어 고친 뒤 전환일을 분기 경계로 잡았다. 소유자는 이름 한 명으로 바꿨고, 추가 규칙을 "보완 요구나 발주처 질의가 오면 그날 한 줄 추가" 로 정했다.

결과. 다음 반기에 용어집을 인용한 대외 문서가 17건 이 되고, 항목이 9개에서 14개 로 늘었으며 성적서 보완 요구는 3건에서 1건 이 됐다. 늘어난 5항목은 전부 실제 질의에서 온 것 이다.

• 항목 수를 줄이는 것이 조회 수를 늘린다 — 48항목은 사전이고, 9항목은 합의문이다. 사전은 인용되지 않는다
• 용어집은 읽히는 문서가 아니라 인용되는 문서다. 템플릿 칸 이름을 바꾸지 않으면 인용할 자리 자체가 생기지 않는다
• 소유자는 팀이 아니라 사람이어야 한다 — 조직명이 적힌 칸은 빈 칸과 같다

실무에서 왜 필요한가

지식이 조직 자산이 된다

한 사람이 아는 것은 그 사람이 떠나면 사라진다. 매핑표·용어집·템플릿은 남는다. 이 모듈에서 배운 것을 조직에 남기는 마지막 단계 가 이 레슨이다.

신규 입사자의 학습 곡선이 짧아진다

용어가 정리된 팀에서는 새로 온 사람이 "여기서 Critical은 무슨 뜻이지"를 눈치로 배우지 않는다. 문서에 적혀 있다.

다음 감사·심사가 쉬워진다

용어와 분류가 정리된 조직은 심사 준비가 자료 수집에 그친다. 정리 안 된 조직은 심사 때마다 문서를 다시 쓴다.

채용시장에서의 위치

용어집과 이행은 경력 3~5년 이후 에 들어오는 질문이다. 용어를 아는지가 아니라 조직을 한 번이라도 움직여 봤는지 가 바로 드러난다.

두 번째가 가장 변별력이 크다. 공지와 교육을 말하는 답과 참조처를 센다 는 답 사이에 경험의 차이가 그대로 드러난다. 용어를 실제로 바꿔 본 사람은 알림이 조용히 멈춘 적 이 있고, 그래서 일정을 말하기 전에 센다. 이 답은 면접관이 QA 출신이 아니어도 통한다 — 설정 변경이 어디에 걸리는지는 개발·운영 쪽이 더 잘 안다.

세 번째도 변별력이 있다. "전부 다시 분류한다" 는 답은 성실해 보이지만 비용과 리스크를 둘 다 모르는 답 이다. 소급 재분류는 당시의 판정 근거를 덮어쓰는 일이고, 감사와 분쟁에서 필요한 것은 최신 이름이 아니라 그 시점의 근거 다.

공고 표현으로는 "QA 프로세스 표준화", "품질 문서 체계 수립", "품질합의서· SLA 작성", "QA 온보딩 체계 구축" 이 이 레슨에 걸린다. 그리고 인원이 빠르게 늘어나는 조직 일수록 이 능력을 찾는다 — 사람이 늘면 가장 먼저 어긋나는 것이 용어다.

실습 과제

과제 1 — 매핑표 만들기

본문의 매핑표를 우리 조직 표현으로 다시 만든다. 우리가 실제로 쓰는 말을 왼쪽에 넣는 것이 핵심이다 — 본문의 예시를 그대로 베끼면 안 된다.

레슨 1 과제 1에서 센 표현들을 여기에 반영한다.

과제 2 — 용어집 10항목 작성

네 칸(용어·정의·근거·쓰는 곳) + 혼동 주의 칸으로 열 개 항목을 쓴다. 열 개를 넘기지 않는다.

과제 3 — 적용 표준 기준 결정문 확정

본문의 다섯 줄 형식으로 우리 조직 기준을 확정한다. 레슨 2 과제 4와 레슨 5 과제 4의 결과를 합친다.

결정할 수 없는 항목이 있으면 "미정 — 결정권자·결정 시점"을 적는다. 비워두지 않는다.

과제 4 — 결함 리포트 템플릿 수정안

현재 템플릿을 가져와 3단 구조를 반영한 수정안을 만든다. 변경 전후를 나란히 두고, 무엇이 왜 바뀌는지 한 줄씩 적는다.

이 문서를 팀 리뷰에 올린다.

과제 5 — 전환 계획서 한 장

본문의 순서를 우리 상황에 맞게 조정해 6주 계획을 만든다. 각 주차에 담당자와 산출물 을 명시한다.

3~4주차(도구 필드)의 참조처 점검 목록 (레슨 7 과제 5)을 선행 작업으로 반드시 넣는다.

과제 6 — 정착 지표 기준선 측정

본문의 다섯 지표를 지금 시점에 측정해 기준선을 기록한다. 전환 후 같은 방법으로 다시 재서 비교할 수 있게 측정 방법을 함께 적는다.

과제 7 — 반대 대응 준비

본문의 다섯 가지 반대 각각에 대해 우리 조직 맥락의 구체적 답 을 준비한다. 가능하면 우리 사례(보완 요구를 받은 문서, 트리아지에서 반복된 논쟁 등)를 근거로 든다.

자가 체크리스트

• 전면 교정이 실패하는 세 가지 이유를 설명할 수 있다
• 고칠 곳 다섯 군데와 안 고칠 곳을 구분할 수 있다
• 강제 지점이 템플릿과 도구 설정인 이유를 설명할 수 있다
• 매핑표에 "어디서 바꿔 쓰나" 칸이 필요한 이유를 안다
• 용어집 항목에 '혼동 주의' 칸을 두는 이유를 안다
• 적용 표준 기준 결정문에 들어갈 다섯 가지를 말할 수 있다
• 전환 순서에서 결함 리포트 템플릿을 먼저 하는 이유를 설명할 수 있다
• 도구 필드 분리가 왜 가장 위험한 단계인지 안다
• 정착 지표 다섯 개를 측정 방법과 함께 말할 수 있다
• 호환성 칸 항목 수가 줄어드는 것이 왜 개선인지 설명할 수 있다
• 온보딩에 넣는 것이 왜 효율이 좋은 정착 수단인지 안다
• 전형적인 반대 다섯 가지에 답할 수 있다
• 용어집 한 줄 형식의 네 칸(표준어·실무어·쓰는 자리·판)을 말할 수 있다
• 용어집이 주기 점검이 아니라 사고를 계기로 자란다는 것을 설명할 수 있다
• 용어집에 넣지 않을 다섯 종류를 구분할 수 있다
• 이행 계획의 첫 줄이 일정이 아니라 참조처 수인 이유를 안다
• 전환 기록 한 장에 들어갈 여섯 줄을 쓸 수 있다
• 전환 전후를 구분해 읽는 법을 어디에 적어 두는지 안다
• 합의를 만드는 체크 문항을 팀과 함께 돌리는 이유를 설명할 수 있다
• 품질합의서 용어 부속서에 들어갈 다섯 항목을 말할 수 있다

흔한 실수

용어집을 먼저 크게 만든다. 50개 항목짜리 용어집은 아무도 안 읽는다. 열 개로 시작해서 필요할 때 늘린다.

공지로 끝낸다. 전사 메일 한 통은 이틀이면 잊힌다. 템플릿과 필드를 바꾸지 않으면 아무것도 안 바뀐다.

구어까지 교정하려 한다. 피로만 쌓이고 정작 문서는 그대로다.

도구 필드부터 손댄다. 가장 위험하고 가장 저항이 큰 단계다. 리포트 템플릿으로 성공 경험을 먼저 만든 다음에 간다.

참조처 점검을 건너뛴다. 레슨 7에서 강조한 그대로다. 알림과 대시보드가 조용히 멈춘다.

정착 여부를 느낌으로 판단한다. "요즘 잘 지키는 것 같다"는 근거가 아니다. 표본 20건을 열어보면 안다.

빈 칸을 드러내놓고 아무것도 안 한다. 분류표를 바로잡는 목적은 공백을 찾는 것이다. 찾고 나서 계획에 넣지 않으면 표만 정확해진다.

옛 용어 검색 경로를 안 남긴다. 사람들은 "호환성 테스트"로 검색한다. 그 검색어로 새 문서가 찾아지게 별칭·리다이렉트를 남긴다.

소유자를 팀 이름으로 적는다. "품질팀" 이 적힌 칸은 빈 칸과 같다. 고치는 손은 한 명 이어야 한다.

항목이 늘어난 것을 성과로 본다. 지표는 항목 수가 아니라 인용된 대외 문서 건수 다. 사전은 아무도 인용하지 않는다.

참조처를 세지 않고 일정을 먼저 잡는다. 쿼리·저장 필터·알림 규칙까지 센 다음에야 한 주 일인지 한 분기 일인지 알 수 있다.

전환 기록을 대시보드에만 남긴다. 대시보드를 보는 사람과 분기 리포트를 받는 사람이 다르다. 같은 문장을 두 곳에 둔다.

외부 조직과 구두로 합의한다. 검수 회의의 "그렇게 하기로 했다" 는 상대 담당자가 바뀌면 승계되지 않는다. 부속서에 박아야 남는다.

참고 자료

• ISO/IEC/IEEE 24765 — 용어집의 '근거' 칸에 채울 표준 정의의 출처
• ISTQB 용어집(Glossary) — 한국어 대역어 확인. 번역 규칙을 정할 때 기준으로 삼는다
• IEEE 1044-2009 — 이상 분류와 속성 체계. 심각도·우선순위 정의의 근거
• ISO/IEC 25010:2023 — 품질 특성 분류의 근거. 적용 표준 결정문에 판과 함께 인용한다
• 모듈 7 테스트 문서·관리 도구·프로세스 개선 — 문서 협업과 프로세스 개선의 일반 틀. 이 전환도 프로세스 개선의 한 사례다
• 모듈 26 C레벨 이해와 품질 커뮤니케이션 — 전환을 승인받기 위한 설득 자료 구성
• ISO/IEC/IEEE 29119-3 — 테스트 문서 서식. 용어 부속서를 어느 산출물에 붙일지 정할 때 참조한다

이 커리큘럼 안에서

• 모듈 30 레슨 1 — 용어 정렬 5단계. 그 다섯 번째 줄("팀 용어집에 한 줄씩")이 이 레슨이다
• 모듈 30 레슨 2 — 판 전환과 전환일. 분류 축을 바꿀 때의 추세 단절
• 모듈 30 레슨 3~4 — 호환성과 적응성. 분류표 재작성 단계의 실제 내용
• 모듈 30 레슨 5 — 측정량·성적서 항목명. 대외 문서 템플릿에 넣을 형식
• 모듈 30 레슨 6 — 버그·결함·이상. 리포트 3단 구조의 근거
• 모듈 30 레슨 7 — 심각도·우선순위 필드와 참조처 점검. 이행에서 가장 위험한 단계
• 모듈 6 레슨 1 — 결함 등급의 실무적 구분. 용어집 항목의 원본
• 모듈 6 레슨 5 — 품질 지표. 전환일 각주가 필요한 그래프들
• 모듈 7 레슨 6 — 자체 진단 문항. 합의를 만드는 방식
• 모듈 7 레슨 7 — 문서 수명·소유자·점검일과 "안 쓸 것을 정한다"
• 모듈 8 레슨 1 — 공통 언어로서의 표준. 외부와 숫자를 교환하는 자리
• 모듈 26 레슨 7 — 전환을 승인받기 위한 경영진 보고

한 줄 정리 — 용어집은 읽히는 문서가 아니라 인용되는 문서 다. 그래서 항목을 깎아 넣지 않을 것을 먼저 정하고, 템플릿 칸 이름을 용어집 표기로 바꿔 인용할 자리 를 만든다. 이름을 바꾸는 일은 개념 작업이 아니라 설정 작업이므로 참조처를 먼저 세고, 전환일과 과거 데이터 처리 방식을 전환 기록 한 장 에 남긴다. 지시는 지켜지지 않고 함께 체크한 결론만 지켜지며, 외부 조직과의 합의는 품질합의서 용어 부속서 에 박아야 남는다.

모듈 30 마무리 — 이 모듈은 한 문장을 여덟 걸음으로 풀었다. 레슨 1에서 실무어와 표준어가 어긋나 있고 그 간극은 팀 밖으로 나갈 때 비용이 된다 는 것을 봤고, 레슨 2에서 판이 바뀌면 정확히 알던 사람도 옛 용어를 쓰게 된다 는 것을, 레슨 3에서 표준의 호환성은 공존성과 상호운용성 둘뿐 이라는 것을, 레슨 4에서 크로스 브라우저는 적응성 이라는 것을 확인했다. 레슨 5는 그 분류를 측정량과 성적서 항목명 으로 옮겼고, 레슨 6은 버그라는 한 단어에 오류·결함·실패·이상 이 섞여 있음을 갈랐고, 레슨 7은 갈라낸 두 축을 도구의 필드 둘 로 만들었다. 이 레슨은 그 전부를 용어집 한 장과 전환 기록 한 장 으로 조직에 남긴다. 레슨 1의 정렬 5단계가 여기서 참조처 세기 → 전환일 → 인용 확인 이라는 실행 체계가 된 것이다. 모듈을 덮은 뒤 남길 것은 지식이 아니라 다음 성적서의 항목명 한 줄, 그리고 용어집에 늘어난 한 줄 이다.