재현 가능한 포트폴리오 설명

자신이 내린 판단을 보여 줍니다

포트폴리오 설명은 도구 이름이나 성공 화면을 늘어놓는 일이 아닙니다. 동아리 회원 서비스에서 어떤 기대 결과를 선택했고 어떤 실패를 어떻게 해석했는지 보여 주는 일입니다. 제공 코드와 자신이 작성한 조건을 구분하면 면접관이 실제 이해를 확인할 수 있습니다. 이번 트랙에서는 계획·cases·결함 보고서·검증 코드·회귀 비교·릴리스 의견이 연결된 자료를 사용합니다. 새로 하지 않은 실행을 했다고 설명하지 않습니다.

설명은 문제·선택·관찰·한계의 순서로 짧게 시작합니다. 예를 들어 지연과 공유 상태 때문에 조건별 실패가 있었고 동일 seed로 재현했으며 상태 대기와 key 격리를 가상 모형에서 확인했다고 말합니다. 이어서 실제 DOM·HTTP와 변경 앱 검증은 대기라고 밝힙니다. 누가 무엇을 제공했는지와 자신이 oracle에서 어떤 판정 조건을 보완했는지 설명하면 결과를 만든 범위가 분명해집니다.

기여를 크게 보이게 하려는 표현은 확인 질문에서 쉽게 흔들립니다. 전체 서비스 자동화라는 문장 대신 가상 시계 회귀 검출과 누적 요구사항 추적 문서를 완성했다고 말합니다. 실제 앱 검사를 별도로 했다면 그 증거를 붙여 범위를 넓힐 수 있습니다. 직접 수행하지 않은 앱 재검증은 대기라고 표시하는 편이 다음 사람의 판단을 돕습니다. 범위를 정확하게 말하는 능력은 QA의 중요한 직무 기술입니다.

한 줄 주장에 한 가지 증거를 고릅니다

가입 테스트 조건을 설명할 때는 cases/cases.json의 경계 입력과 spec의 인수 기준을 함께 엽니다. 왜 그 입력이 규칙의 양 끝을 확인하는지 말하고 거절 시 저장 무변경을 어떤 자료로 확인할지 설명합니다. 보고서 경로만 외우면 입력을 하나 바꿨을 때 기대 결과가 달라지는 이유에 답하기 어렵습니다. 파일을 읽으며 계약 출처와 실제 관찰 여부를 구분한 자신의 문장을 준비합니다.

재현 보고서를 설명할 때는 DEF-01의 사전 조건·세 단계·예상·실제·환경·requestId를 찾습니다. 64자 비밀번호가 왜 유효한지 당시 계약을 말하고 회원 수 증가가 없었던 관찰을 설명합니다. 이 자료는 이전 모듈의 실행 기록을 상속한 것이므로 이번에 세 번 재현했다고 말하지 않습니다. 자신이 직접 재실행했다면 별도 버전·명령·횟수와 실패 증거를 제시합니다. 과거와 현재 시점을 정확히 구분합니다.

회귀 설명에는 quality/proof/reports/proof.json을 사용합니다. seed 0은 공유 상태, seed 2는 준비 지연의 실패를 보여 주며 수정 모형은 동일 입력에서 통과합니다. 코드 해시와 재시도 0을 읽고 어떤 검사를 재현할 수 있는지 안내합니다. 이 자료를 DEF-01의 가입 결함 해결 증거로 쓰지는 않습니다. 서로 다른 문제에 같은 성공 화면을 붙이는 실수를 피하려면 주장과 증거의 대상 이름을 먼저 맞춥니다.

신입 질문 여섯 개를 자신의 자료로 답합니다

quality/interview.json은 트랙의 신입 질문 여섯 개를 담습니다. 가입 조건과 모호한 요구 대응 질문은 cases와 questions의 경로를 씁니다. 정상 동작만 적힌 요구에 오류·권한·상태 예시를 질문하고 합의 전에는 보류했다고 설명합니다. 상대가 그 보류를 왜 했는지 물으면 기대값을 추측하면 테스트 실패의 의미를 판단할 수 없기 때문이라고 자신의 프로젝트 맥락으로 답합니다.

결함 보고서 질문에는 환경·사전 조건·재현 단계·예상/실제·증거·범위를 포함합니다. API 성공 코드 질문에는 상태 코드만 성공이어도 본문이나 저장·권한이 틀릴 수 있다고 설명합니다. REQ-08의 타인 프로필 변경 무변경이 그 예입니다. 이 인수 기준을 이번 대상에서 실행하지 않았음을 덧붙여 설계 설명과 실행 주장을 분리합니다. 개념 답변과 자신의 증거 경로가 함께 있으면 후속 질문에 대응하기 쉽습니다.

고정 대기 줄이기 질문에는 준비 상태와 기대값을 제한 시간 안에서 관찰하는 조건을 말합니다. 실행 순서 질문에는 단독·정순·역순을 비교하고 같은 데이터 key가 공유됐는지 확인하는 절차를 설명합니다. 이번 증거는 가상 시계 seed의 정·역순이며 실제 UI 전체는 대기입니다. 면접 답변에 실행 횟수나 구현 범위를 넣으면 보고서의 수치·경로와 같은지 다시 대조합니다. 답변 길이보다 증거와 뜻의 일치가 중요합니다.

AI 도움과 제공 자료의 경계를 기록합니다

AI를 사용했다면 quality/ai.json의 used를 true로 바꾸고 허용 입력·요청 목적·검토 내용·직접 실행한 결과를 남깁니다. 교육용 합성 자료 사용과 실제 운영 로그 제공은 다른 권한입니다. 토큰·비밀번호·실사용자 정보는 입력 자료에 포함하지 않습니다. 권한이 있는 요약 자료만 사용하고 생성된 기대값이 계약과 맞는지 사람이 검토합니다. 구체적인 허용 범위를 기록해야 나중에 무엇을 맡겼는지 설명할 수 있습니다.

AI가 만든 코드나 문장을 검토했다고 말하려면 무엇을 비교했는지 적습니다. 예를 들어 oracle의 pass/failure 조건을 계약과 대조하고 null·누락·모순 입력으로 직접 실행했다고 기록합니다. 실행하지 않은 명령은 verified에 넣지 않습니다. 모범 답안의 used=false는 교육용 제출자 예시이므로 자신의 실제 도움 사용 이력과 다르면 바꿔야 합니다. 이 레슨을 작성한 사람의 도구 사용 이력을 대신하는 기록은 아닙니다.

제공 코드는 자신의 구현으로 세지 않지만 읽고 판단한 범위는 설명할 수 있습니다. engine과 repair가 이전 solution에서 온 사실, 최종 문서의 대기 표시를 자신이 검토한 사실, oracle의 검사 조건을 수정한 사실을 나눕니다. 외부 생성 도움을 받았더라도 책임 있는 검토와 재현은 자신의 설명 대상입니다. 파일이 있다는 것과 자신이 실행했다는 것은 다르므로 AI 기록과 README-m10의 수행 범위가 충돌하지 않게 합니다.

다른 사람이 따라 할 인계 순서를 만듭니다

README-m10 첫 화면에는 준비 도구·실행 위치·명령·확인 범위를 적습니다. 이번 미션의 bash check.sh는 상속 해시 확인, m09 합성 검사, m10 비교 도구, 최종 문서 연결 검사를 순서대로 실행합니다. 서버를 시작하지 않으며 실제 UI 실행을 포함하지 않습니다. 이전 check를 m09-check.sh로 보존한 이유는 이전 증거와 새 진입점을 구분하려는 것입니다. 대상 파일을 수정하면 INHERITED_CHANGED가 알려 주므로 이전 프로젝트를 조용히 덮어쓰지 않습니다.

결과가 다르면 오류 이름과 다음 행동을 함께 찾습니다. INTERVIEW_COUNT는 서로 다른 여섯 질문이 없다는 뜻입니다. INTERVIEW_ANSWER는 답변이 너무 짧아 제출 기준을 만족하지 못한 경우입니다. EVIDENCE_PATH는 답변에 붙인 상대 경로가 없는 경우이며 AI_RECORD는 권한·검토·확인·한계가 빠진 경우입니다. 문자열 길이를 채우기보다 질문에 답한 판단과 실제 증거를 보완합니다. 검사기는 답변의 설득력까지 평가하지 않습니다.

마지막 리뷰는 다른 사람에게 폴더를 전달하고 README-m10만 읽게 하는 방식으로 합니다. 어떤 명령을 실행했고 어떤 출력이 성공이며 어떤 영역이 아직 대기인지 찾아 달라고 요청합니다. 이어서 여섯 질문 중 하나를 골라 파일을 열며 답합니다. 혼자 외운 문장으로 답하는 것보다 실제 입력과 실패 행을 설명하면 검증 범위를 더 정확히 보여 줄 수 있습니다. 문서의 빈 연결을 보완한 뒤 전체 검사를 다시 실행합니다.

최종 산출물은 계획·추적표·회귀 보고·릴리스 보류 의견·면접 답변·AI 사용 기록입니다. 모든 요구사항에 검사 또는 미검증 후속이 연결돼 있고, 두 버전 비교의 실패와 성공을 재현할 수 있으며, 검토자가 남은 실제 앱·UI 실행을 찾을 수 있어야 합니다. 제출 완료와 제품 출시 준비를 혼동하지 않습니다. 이 트랙의 수료는 품질 근거를 정직하게 설명하고 이어서 할 검증을 구체화하는 능력을 보여 주는 단계입니다.