개념
배운 것과 해 본 것은 다르다
여기까지 온 사람은 이미 꽤 많은 것을 읽었다. 요구사항을 능동적으로 읽는 법(모듈 2), 입력을 몇 개의 대표값으로 줄이는 동등 분할(모듈 3 레슨 1 — 같은 결과가 나오는 입력들을 한 묶음으로 보고 그 묶음에서 하나씩만 시험하는 기법), 재현 절차가 살아 있는 결함 리포트 쓰기(모듈 6 레슨 2). 그런데 이것들을 따로따로 알고 있는 상태와, 제품 하나를 잡고 처음부터 끝까지 이어 본 상태는 전혀 다르다.
면접에서 갈리는 지점도 정확히 거기다. "동등 분할 아세요?"라고 묻는 면접관은 드물다. 대신 이렇게 묻는다. "최근에 테스트해 본 것 하나만 이야기해 주세요. 무엇부터 보셨어요?" 이 질문에 답하려면 한 바퀴 돌아 본 경험 이 하나는 있어야 한다.
이 레슨은 그 한 바퀴를 12주짜리 실습 계획으로 만든 것이다. 개념을 새로 배우지 않는다. 이미 배운 것을 순서대로 꺼내 쓰게 한다.
원칙 하나 — 산출물이 사슬처럼 이어진다
이 실습에는 규칙이 하나뿐이다. 앞 주의 산출물이 다음 주의 입력이 된다. 중간에 하나를 건너뛰면 다음 것을 만들 재료가 없어진다.
① 제품 이해 메모 누가, 무엇을 하려고 이 제품을 쓰는가
↓ (여기서 "이건 어떻게 동작해야 정상이지?"가 나온다)
② 요구사항 질문 목록 문서·도움말을 읽고 빈틈에 던진 질문 20개
↓ (질문의 답이 곧 테스트할 조건이다)
③ 테스트 설계서 조건을 기법으로 케이스로 바꾼 표
↓ (케이스를 실제로 돌린다)
④ 실행 기록 언제·어떤 환경에서·무엇이 통과하고 실패했는가
↓ (실패한 것을 정보로 만든다)
⑤ 결함 리포트 재현 절차·실제 결과·기대 결과·증거
↓ (한 바퀴를 돌아보고 다음 바퀴를 고친다)
⑥ 회고 메모 무엇이 잘 됐고, 무엇을 다르게 할 것인가여섯 개가 다 모이면 그게 곧 포트폴리오다. 레슨 6에서 말한 "목표 역할의 결과물을 이미 만들 수 있다는 증거"가 이 사슬이다.
대상 제품 고르기 — 네 가지 조건
아무 앱이나 고르면 3주차에 막힌다. 다음 네 조건을 모두 만족하는 제품을 고른다.
- 누구나 무료로 쓸 수 있다 — 결제나 회사 계정이 필요하면 남에게 보여 줄 수 없다
- 공개된 문서가 있다 — 사용자 도움말·매뉴얼이 요구사항 대신 읽을 원문이 된다
- 상태가 남는다 — 데이터를 저장하고 불러오고 동기화하는 기능이 있어야 경계·중복·순서 같은 재미있는 결함이 나온다
- 공개 이슈 트래커가 있다 — 이슈 트래커란 결함과 요청을 번호 붙여 관리하는 공개 게시판이다. 내가 찾은 것이 이미 알려진 문제인지 검색해 볼 수 있다
이 레슨에서는 예시 제품 하나를 끝까지 끌고 간다. Joplin 이다. 무료 오픈소스 노트·할 일 앱으로 Windows·macOS·Linux·Android·iOS와 브라우저 확장(웹 클리퍼)까지 제공하고, 공식 도움말
문서(joplinapp.org/help)와 GitHub 공개 저장소가 있다. 네 조건을 모두 만족한다. 노트 작성·체크박스 할 일·태그·검색·노트북 이동·동기화·내보내기처럼 입문자가 화면만 보고도 시험할 수 있는
기능 과, 동기화 충돌처럼 머리를 써야 하는 기능 이 한 제품 안에 같이 있다는 점이 특히 좋다.
Joplin이 마음에 들지 않아도 된다. 위 네 조건을 만족하는 다른 무료 오픈소스 제품으로 바꿔도 이 계획은 그대로 돌아간다. 다만 한 번 고르면 12주 동안 바꾸지 않는다. 제품을 갈아타면 사슬이 끊어지고, 남는 것은 얕은 메모 여러 개뿐이다.
12주 계획 — 혼자 하는 사람과 갓 입사한 사람
같은 사슬을 만들지만 출발 조건이 다르다. 취업을 준비하며 혼자 하는 사람은 제품을 자유롭게 고를 수 있지만 피드백을 줄 사람이 없다. 갓 입사한 사람은 피드백을 줄 사람이 많지만 회사 제품이 복잡하고 기밀이라 밖에 못 쓴다. 그래서 계획을 갈라 쓴다.
| 주차 | 만드는 산출물 | 혼자 하는 사람(취업 준비) | 갓 입사한 사람 |
|---|---|---|---|
| 1~2 | ① 제품 이해 메모 | Joplin을 실제 업무에 2주간 직접 쓴다. 사용자 유형 3가지와 핵심 흐름 5개를 적는다 | 담당 제품을 사용자 계정으로 2주간 써 본다. 사수에게 "이 제품 주 사용자가 누구인가"를 묻고 답을 메모에 적는다 |
| 3~4 | ② 질문 목록 | 공식 도움말에서 기능 3개를 골라 읽고 "문서가 답하지 않는 질문" 20개를 적는다 | 기획서·요구사항 문서를 읽고 질문 20개를 적어 기획자·개발자에게 실제로 던진다. 답을 옆 칸에 기록한다 |
| 5~6 | ③ 테스트 설계서 | 질문의 답을 조건으로 바꾸고 동등 분할·경계값 분석(경계 근처 값이 오류를 부르므로 경계와 그 양옆을 시험하는 기법)으로 케이스 40개 안팎을 만든다 | 기존 팀 테스트 케이스를 먼저 읽고, 내가 맡은 기능 하나에 대해 새로 설계한다. 사수에게 리뷰를 요청한다 |
| 7~8 | ④ 실행 기록 | 케이스를 두 환경(예: 데스크톱·모바일)에서 실행하고 결과를 표로 남긴다 | 첫 릴리스 테스트에 참여해 실행 기록을 남긴다. 회귀 테스트(이미 되던 기능이 다시 깨지지 않았는지 확인하는 시험)가 무엇인지 몸으로 익힌다 |
| 9~10 | ⑤ 결함 리포트 | 실패 건을 리포트로 쓰고, 공개 이슈 트래커에서 같은 문제가 이미 있는지 검색해 결과를 메모한다 | 팀 이슈 트래커에 실제로 등록한다. 반려되거나 수정된 리포트의 사유를 모아 둔다 |
| 11 | 되돌아 확인 | 수정판이 나왔다면 재시험. 아니면 설계서에서 빠진 조건을 찾아 케이스를 보강한다 | 수정된 결함을 재시험하고 주변 기능까지 확인한다 |
| 12 | ⑥ 회고 메모 | 여섯 산출물을 한 폴더로 묶고 공개 가능한 형태로 정리한다 | 회고를 쓰고 사수와 1:1에서 공유한다. 다음 분기 목표를 하나 정한다 |
산출물 여섯 개의 최소 형식
"잘 쓰는 법"보다 끝까지 쓰는 것 이 먼저다. 아래 최소 형식만 채워도 충분하다.
① 제품 이해 메모 (한 장)
제품: Joplin 3.x (데스크톱 macOS / Android)
이 제품이 대신해 주는 일: 흩어진 메모와 할 일을 한 곳에 모으고 기기 간에 맞춰 준다
사용자 유형 3: (a) 혼자 쓰는 학생 (b) 웹 자료를 모으는 연구자 (c) 여러 기기를 쓰는 직장인
핵심 흐름 5: 노트 작성 → 노트북 분류 → 태그 → 검색 → 동기화
돈/신뢰가 걸린 지점: 동기화 충돌로 내용이 사라지는 것. 사용자가 가장 못 참는 실패다
아직 모르는 것: 동기화 대상(파일 시스템/클라우드)마다 동작이 다른가?② 요구사항 질문 목록 (표)
| # | 읽은 문장(출처) | 질문 | 왜 문제인가 | 답 |
|---|---|---|---|---|
| 1 | 도움말 "노트는 태그를 여러 개 가질 수 있다" | 태그 개수 상한이 있는가? 있으면 넘겼을 때 어떻게 되는가 | 상한이 없다면 성능, 있다면 경계값 시험 대상 | 확인 필요 |
| 2 | 도움말 "검색은 제목과 본문을 대상으로 한다" | 첨부파일 이름도 포함인가? 대소문자·한글 자모 분리는? | 검색은 "안 나오는 것"이 결함인데 판정 기준이 모호하다 | 확인 필요 |
질문은 20개 를 목표로 한다. 15개쯤 되면 손이 멈추는데, 그때부터 나오는 질문이 좋은 질문이다. 질문을 만드는 요령은 모듈 2 레슨 3(모호함과 누락 찾아내기)의 기준을 그대로 쓴다.
③ 테스트 설계서 (표)
| ID | 테스트 조건 | 적용 기법 | 입력·조작 | 기대 결과 |
|---|---|---|---|---|
| TC-TAG-01 | 태그 이름 길이 경계 | 경계값 분석 | 1자 / 최대 허용 길이 / 최대+1자 | 1자·최대는 저장, 최대+1자는 막히고 안내 문구 표시 |
| TC-SYNC-03 | 두 기기에서 같은 노트를 동시 수정 | 상태 전이 | A기기 수정 → 동기화 전에 B기기 수정 → 양쪽 동기화 | 내용 유실 없이 충돌본이 별도 노트로 보존 |
기법 칸을 비워 두지 않는 것이 핵심이다. 기법을 적으면 왜 이 값을 골랐는지 를 설명할 수 있고, 면접에서 그 설명이 곧 실력으로 읽힌다.
④ 실행 기록 (표)
| 일시 | 환경 | TC ID | 결과 | 비고 |
|---|---|---|---|---|
| 09-14 14:10 | macOS 15 / Joplin 3.x | TC-TAG-01 | Pass | 최대+1자에서 입력 자체가 막힘 |
| 09-14 14:25 | Android 14 / Joplin 3.x | TC-SYNC-03 | Fail | 충돌본이 생기지 않고 한쪽 수정이 사라짐 → DEF-002 |
⑤ 결함 리포트 는 모듈 6 레슨 2의 형식을 그대로 쓴다. 제목 한 줄, 환경, 재현 절차(번호), 실제 결과, 기대 결과, 증거(스크린샷·로그), 재현율.
⑥ 회고 메모 (한 장) — 잘된 것 3, 어려웠던 것 3, 다음 바퀴에 바꿀 것 1. 하나만 바꾸는 것이 중요하다. 열 개를 바꾸겠다고 적으면 하나도 안 바뀐다.
30·60·90일 점검 기준
날짜가 아니라 손에 쥔 것 으로 점검한다. 비어 있으면 앞 구간으로 돌아간다.
| 시점 | 이때쯤 나와 있어야 하는 것 | 아직 없어도 괜찮은 것 | 비어 있으면 |
|---|---|---|---|
| 30일 | 제품 이해 메모 1장, 답이 달린 질문 10개 이상, 용어 목록 20개 | 테스트 케이스, 결함 | 제품을 "읽기"만 하고 "쓰지" 않은 것이다. 실제 사용 시간을 늘린다 |
| 60일 | 기법이 명시된 케이스 30개 이상, 두 환경 실행 기록, 결함 리포트 3건 이상 | 자동화, 성능·보안 시험 | 설계까지 하고 실행을 미룬 것이다. 케이스를 줄여서라도 끝까지 돌린다 |
| 90일 | 여섯 산출물 전부, 재시험 기록 1건 이상, 회고 1장, "한 바퀴" 3분 설명 | 팀 프로세스 개선 제안 | 회고가 없으면 경험이 다음 바퀴로 넘어가지 않는다. 한 장이라도 쓴다 |
갓 입사한 사람은 여기에 한 칸이 더 붙는다. 30일에는 질문의 개수, 60일에는 남의 도움 없이 끝낸 업무의 개수, 90일에는 남이 나에게 물어보기 시작한 영역 이다. 세 번째가 온보딩이 끝났다는 가장 확실한 신호다.
혼자 하는 사람이 반드시 대체해야 할 한 가지
회사에 있으면 저절로 생기는데 혼자 하면 절대 생기지 않는 것이 있다. 리뷰 다. 내가 쓴 질문이 좋은 질문인지, 내 결함 리포트가 개발자에게 전달 가능한지 아무도 말해 주지 않는다.
대체 수단은 세 가지다.
- 공개 이슈 트래커의 잘 쓰인 리포트와 내 것을 나란히 놓고 비교 한다. 같은 제품의 실제 리포트가 가장 좋은 교본이다
- 결함 리포트를 읽은 사람이 내 화면 없이 재현할 수 있는지 를 기준으로 스스로 채점한다. 친구에게 리포트만 주고 재현시켜 보면 빈틈이 바로 드러난다
- 1주일 뒤의 나에게 리뷰받는다. 쓴 직후에는 안 보이던 빠진 전제가 일주일 뒤에는 보인다
실무에서 왜 필요한가
신입이 회사에서 가장 자주 듣는 말은 "이거 한번 봐 주세요"다. 문서는 낡았고, 사수는 바쁘고, 기능은 이미 만들어져 있다. 이때 필요한 것은 지식이 아니라 순서 다. 무엇부터 보고, 무엇을 묻고, 무엇을 적을지 아는 사람과 모르는 사람의 첫 달 차이는 크다.
한 바퀴를 미리 돌아 본 사람은 회사에서 세 가지를 빨리 한다. 첫째, 문서가 없어도 질문 목록 부터 만든다. 둘째, 케이스를 적을 때 기법 칸 을 채우므로 리뷰에서 "왜 이 값이죠?"에 막히지 않는다. 셋째, 결함을 등록할 때 재현 절차가 이미 몸에 배어 있어 반려되는 횟수가 적다.
또 이 실습은 자기 진도를 측정 가능하게 만든다. "열심히 공부했다"는 증명되지 않지만 "질문 20개, 케이스 42개, 결함 5건, 재시험 2건"은 증명된다. 레슨 5에서 본 전환의 원칙 — 결과물이 먼저다 — 이 신입에게도 똑같이 적용된다.
채용시장에서의 위치
경력 없는 지원자의 서류에서 면접관이 실제로 읽는 칸은 딱 하나다. "직접 해 본 것" 칸이다. 자격증과 수료증은 같은 기수 지원자 전부가 가지고 있어서 변별력이 없다. 반면 "무료 오픈소스 노트 앱을 대상으로 12주간 요구사항 질문 20개 → 케이스 42개 → 결함 5건 → 재시험까지 한 바퀴를 돌린 기록"은 지원자 사이에서 거의 유일하다.
면접에서는 산출물 전체를 보여 주지 못한다. 대신 3분 설명 을 준비한다. 어떤 제품을 왜 골랐는가(30초), 문서에서 무엇이 모호해서 어떤 질문을 던졌는가(60초), 그 질문이 어떤 케이스가 됐는가(60초), 가장 좋은 결함 하나와 그것을 찾은 경로(30초). 이 네 토막이면 충분하다. 면접관이 궁금해지면 알아서 더 묻는다.