포트폴리오·이력서 - 결과보다 결정과 기여를 쓰기

이 장에서 배우는 것

팀 프로젝트를 끝냈다는 사실과 그 프로젝트에서 자신이 어떤 개발자로 일했는지는 서로 다른 정보다. 짧은 기간에 동작하는 서비스를 만들고, 팀원과 작업을 나누고, 마감에 맞춰 기능을 연결한 경험은 지원서에 담을 만한 강점이다. 다만 사용한 기술과 완성한 기능만 나열하면 그 강점이 읽히기 어렵다. 자신이 발견한 문제, 선택한 방법, 확인한 결과를 구체적인 문장으로 바꿔야 한다.

앞 장에서 정리한 테스트·README·배포 기록은 이번 장의 재료다. 이번에는 기능을 더 만드는 대신, 그 기록에서 자신의 판단과 기여를 찾아 공고의 요구 역량에 연결한다. 완성 코드에서는 가상의 공고 문장과 이력서 문장을 비교해 키워드 대응표를 출력한다. 이 표는 지원 적합성을 판정하는 점수가 아니라, 사람이 다시 읽어 볼 문장을 찾는 도구다.

• 직무 공고의 기술 이름과 실제로 요구하는 행동을 나누어 읽는다.
• 프로젝트 경험을 문제·내 결정·결과·배운 것으로 정리한다.
• 팀 성과와 개인 기여를 구분하고, 확인할 수 있는 숫자만 사용한다.
• 깃허브(GitHub)와 블로그를 이력서의 근거를 확인하는 경로로 정리한다.
• Python으로 공고와 이력서 문장의 키워드 대응표를 만들고 그 한계를 해석한다.

문제 상황

수료를 앞둔 지원자가 일정 관리 서비스를 포트폴리오에 넣었다. 이력서에는 “Java, Spring, SQL 사용, 일정 등록·조회·수정·삭제 구현”이라고 적었다. 서비스는 실제로 동작하지만, 이 문장만으로는 테이블을 설계했는지, 이미 만들어진 API를 연결했는지, 오류를 찾아 수정했는지 알기 어렵다. 팀원 모두 같은 문장을 쓸 수도 있다.

지원하려는 가상의 공고에는 “SQL을 활용한 데이터 조회 기능 개발”, “자동화 테스트 작성”, “Git을 활용한 협업”이 적혀 있다. 지원자는 세 가지를 모두 경험했다고 생각한다. 그러나 프로젝트 기록을 열어 보니 테스트는 팀원이 작성했고, 자신은 실행 결과를 확인한 뒤 누락된 조건을 제안했다. 조회 기능에서는 중복 행이 발생하는 원인을 찾아 조건을 수정했다. 협업에서는 변경 범위가 큰 작업을 나누고 검토 의견을 반영했다.

이 차이를 숨길 필요는 없다. 직접 작성한 코드, 검토에 기여한 내용, 팀 전체가 달성한 결과를 구분하면 오히려 설명이 명확해진다. “테스트 작성”이라는 단어를 넣기 위해 사실을 넓히는 대신, “조회 조건별 테스트 항목을 제안하고 실패 결과를 재확인했다”라고 적으면 된다. 직접 작성 경험이 부족하다는 사실도 다음 보완 작업의 기준이 된다.

이 장에서는 이 지원자가 남긴 기록을 바탕으로 문장을 다시 만든다. 공고를 보고 자신을 다른 사람처럼 포장하는 작업이 아니다. 실제 경험 중 지원 직무와 관련 있는 부분을 앞에 배치하고, 확인할 수 있는 근거를 연결하는 작업이다.

공고를 기술 이름과 행동으로 나누기

공고를 읽을 때 기술 이름에만 표시하면 요구 역량을 좁게 이해하기 쉽다. “SQL 경험”과 “조회 결과의 정확성을 확인하며 SQL을 작성한 경험”은 요구하는 설명의 깊이가 다르다. 기술 이름 옆에 동사를 함께 적으면 준비할 자료가 분명해진다. “작성”, “분석”, “검토”, “운영”, “개선” 가운데 무엇을 요구하는지 먼저 읽는다.

요구사항과 우대사항도 공고에 적힌 구분대로 보존한다. 우대사항을 모두 갖추지 못했다는 이유로 곧바로 지원을 포기하거나, 요구사항의 빈칸을 키워드 반복으로 가리지 않는다. 자신이 가진 근거와 설명이 필요한 부분을 나누어 판단한다. 여러 공고에서 비슷한 표현이 나와도 각 공고의 업무 맥락이 같다고 가정하지 않는다.

공고의 표현을 경험을 찾는 질문으로 바꾸는 방법

가상 공고 문장	핵심 행동	내 기록에서 찾을 것	해석할 때 주의할 점
SQL을 활용한 데이터 조회 기능 개발	조회 조건 작성과 결과 확인	쿼리 변경, 예상 결과, 테스트 기록	SQL 사용만으로 성능 개선 경험을 주장하지 않는다.
자동화 테스트 작성	검증 조건을 코드로 작성	내가 추가한 테스트와 실행 결과	수동 확인과 자동화 테스트 작성을 구분한다.
Git을 활용한 협업	변경 공유와 검토 반영	커밋, 변경 요청, 검토 대화	저장소를 만들었다는 사실만으로 협업을 설명하지 않는다.

공고 원문과 자신이 해석한 문장을 따로 남겨 두는 편이 좋다. 원문에는 없는 조건을 자신이 추가했는지 확인할 수 있기 때문이다. 지원 날짜와 공고를 확인한 날짜도 기록한다. 공고 내용이 바뀌거나 게시가 종료되더라도 어떤 문장을 기준으로 지원서를 작성했는지 되짚을 수 있다.

이전 경력도 같은 방식으로 연결한다. 고객 요청을 정리한 경험이 있다면 요구사항을 확인한 질문과 합의한 범위를 설명할 수 있다. 여러 사람의 일정을 조율했다면 팀 프로젝트의 작업 순서를 조정한 사례와 연결할 수 있다. 다만 이전 직무 경험을 개발 실무 경력처럼 적지 않는다. 어떤 행동이 이어졌고, 개발 작업에서 무엇을 새로 익혔는지 구분한다.

프로젝트를 문제·내 결정·결과·배운 것으로 쓰기

프로젝트 소개에는 서비스의 목적을 짧게 쓰고, 자신이 맡은 사례를 골라 자세히 쓴다. 모든 기능을 같은 분량으로 설명할 필요는 없다. 선택의 이유와 검증 과정을 말할 수 있는 사례가 유용하다. 다음 네 항목을 먼저 메모한 뒤 이력서에는 핵심 문장만 남긴다.

• 문제: 어떤 상황에서 무엇이 기대와 달랐는지 적는다.
• 내 결정: 자신이 선택한 방법과 그 이유를 적는다.
• 결과: 변경 후 무엇을 어떤 조건으로 확인했는지 적는다.
• 배운 것: 다음 작업에서 적용할 판단 기준을 적는다.

예를 들어 “조회 기능 개선”이라는 메모를 다음과 같이 펼칠 수 있다. 문제는 일정 목록에 같은 일정이 여러 번 표시되는 일이었다. 내 결정은 조회 결과를 화면에서 지우는 대신, 관련 테이블을 연결하는 조건과 기대 결과를 먼저 확인하는 것이었다. 결과는 준비한 입력에서 중복 여부를 재검사한 기록이다. 배운 것은 쿼리 변경 전에 결과 행의 의미를 먼저 정해야 한다는 점이다.

이를 이력서에는 “SQL 조회에서 중복 행이 생기는 조건을 찾아 쿼리를 수정하고, 준비한 입력으로 결과를 확인했다”라고 줄일 수 있다. 포트폴리오에는 당시 조건, 고려한 대안, 관련 변경 기록을 붙인다. 배운 것을 모두 이력서 한 문장에 넣으려 하면 길어지므로 상세 설명으로 옮긴다.

팀 전체의 결과와 자신의 행동은 문장을 나누어 쓰면 구분하기 쉽다. “팀은 일정 관리 서비스를 배포했다. 나는 일정 조회 API의 조건 수정과 결과 검증을 맡았다”처럼 쓴다. 함께 해결한 작업이라면 “팀원과 원인을 분석했고, 나는 재현 입력과 수정 후 확인을 담당했다”라고 적는다. 공동 작업을 모두 자신의 구현으로 바꾸거나, 반대로 자신의 기여를 “팀으로 진행했다” 한마디로 지울 필요가 없다.

숫자는 측정 조건과 함께 남긴다

숫자는 문장을 구체적으로 만들지만, 근거가 없으면 확인할 수 없는 주장도 만든다. “응답 속도 80% 개선”이라고 적으려면 변경 전후 값, 측정 방법, 입력 데이터, 실행 환경을 설명할 수 있어야 한다. 로컬에서 한 번 확인한 시간을 실제 운영 환경의 성과처럼 쓰지 않는다. 서로 다른 조건에서 얻은 값을 비교해 개선율을 계산하지도 않는다.

측정하지 않았다면 숫자 없이 관찰한 사실을 쓴다. “조회 속도를 크게 개선했다” 대신 “중복 조회를 제거하고 같은 입력에서 반환 결과를 확인했다”처럼 적는다. 테스트 개수도 자신이 추가한 항목인지 기존 항목을 포함한 전체 개수인지 구분한다. 커밋 수와 코드 줄 수는 활동 기록일 수 있지만 기여의 크기나 코드 품질을 직접 증명하지는 않는다.

기억이 불확실한 수치는 일단 빼고 원본 기록부터 확인한다. 기록을 찾지 못하면 추정값을 사실처럼 복구하지 않는다. 지금 다시 측정할 수 있다면 새 측정 날짜와 조건을 붙이고, 당시 확인한 결과와 구분한다. 숫자가 없는 경험도 문제와 결정과 검증이 분명하면 설명할 내용이 충분하다.

이력서에서 근거까지 길을 연결하기

이력서, 포트폴리오, 깃허브, 블로그가 같은 내용을 모두 반복할 필요는 없다. 이력서는 관련 경험을 빠르게 찾게 하고, 포트폴리오는 판단 과정을 설명하며, 저장소와 글은 근거를 확인하게 한다. 독자가 문장을 읽고 다음에 어디를 열어야 할지 알 수 있도록 연결한다.

깃허브에서는 대표 프로젝트가 무엇인지, 어디서 실행 방법을 확인하는지, 자신이 맡은 부분이 어디에 설명되어 있는지 정리한다. 앞 장에서 만든 README의 실행·테스트·배포 기록으로 연결하고, 이력서 사례와 관련된 변경 기록도 찾을 수 있게 한다. 대표 저장소의 첫 화면에 기술 이름만 길게 나열하기보다 프로젝트 목적과 개인 기여를 먼저 배치한다.

블로그에는 공부한 내용을 전부 전시하기보다 이력서 문장의 판단을 뒷받침하는 글을 연결한다. “중복 행이 생긴 이유와 조회 조건을 바꾼 과정”처럼 문제와 확인 과정을 담은 글이 한 사례를 설명하는 데 도움이 된다. 다른 자료를 참고했다면 자신의 실험 결과와 참고한 사실을 구분하고 출처를 표시한다. 책이나 문서의 문장과 예제를 옮겨 자신의 해결 기록으로 삼지 않는다.

공개 전에 로그, 화면, 설정 파일에 비밀번호나 개인정보가 포함되어 있는지 확인한다. 팀원의 이름이나 대화 내용을 그대로 공개해야만 협업을 증명할 수 있는 것은 아니다. 공개할 수 있는 변경 설명과 자신의 작업 기록을 중심으로 구성한다. 링크는 로그아웃한 상태에서도 열어 보고, 접근 권한이 필요한 자료를 공개 자료처럼 안내하지 않는다.

서재 자료는 문장을 꾸미는 용도가 아니라 설명이 막히는 부분을 확인하는 데 쓴다. 조회 조건의 이유가 불분명하면 《데이터베이스 개론》과 SQL 연구소에서 관련 개념과 자신의 실험을 대조한다. 코드 구조를 바꾼 이유는 《클린 코드 노하우》, 검토 의견을 반영한 과정은 《코드 리뷰 실무》와 연결해 정리한다. 성능이나 동시 처리의 설명이 막히면 《개발자를 위한 컴퓨터 사이언스》와 《비전공자를 위한 컴퓨터공학 지도》에서 해당 개념을 찾아본다.

알고리즘 선택을 프로젝트 사례에 넣을 때는 《논리로 푸는 알고리즘》과 코드패스에서 남긴 풀이 기록을 참고하되, 문제 풀이 기록을 프로젝트 적용 경험과 구분한다. 《개발자 실무 면접》은 완성한 문장을 질문으로 바꾸어 점검할 때 연결한다. 이번 장에서는 근거까지 정리하고, 답변을 구성하는 방법은 다음 장에서 다룬다.

이번 주에 할 일과 완료 증거

시점	할 일	완료 증거
주 초	□ 지원하려는 공고의 원문과 요구 행동을 나누어 적는다.	확인 날짜가 있는 공고 분석표
주 중	□ 프로젝트 사례를 문제·내 결정·결과·배운 것으로 쓴다.	개인 역할과 공동 작업을 구분한 사례 카드
주 중	□ 숫자와 성과 표현의 근거를 확인한다.	측정 조건이 있는 기록 또는 수정한 문장
주 후반	□ 이력서에서 저장소와 설명 글로 가는 링크를 점검한다.	로그아웃 상태의 링크 확인 기록
주 말	□ 대응표를 실행하고 빠진 표현과 실제 경험을 대조한다.	실행 출력과 사람이 검토한 수정 메모

이번 주의 완료 기준은 문서 개수가 아니다. 선택한 공고의 요구사항을 읽고, 관련 이력서 문장에서 자신의 행동을 찾고, 그 행동을 확인할 근거까지 따라갈 수 있으면 된다. 대응표에 빈칸이 남아 있어도 실제로 하지 않은 일을 추가해 채우지 않는다.

완성 코드

다음 내용을 main.py로 저장한다. 파일을 읽거나 네트워크에 접속하지 않으며, 코드 안에 적힌 가상 공고와 이력서 예시만 처리한다. Python 3.12 이상에서 표준 라이브러리만 사용한다. 입력 순서대로 출력하므로 실행할 때마다 결과가 같다.

키워드는 세 가지로 제한한다. 영문 표기는 대소문자를 구분하지 않으며, Git이 GitHub의 일부라는 이유로 일치하지 않도록 경계를 확인한다. 한국어 “테스트”는 명시한 문자열의 포함 여부로 찾는다. 증거 이름은 예시 식별자이며, 프로그램이 실제 파일이나 내용의 진실성을 검사하는 것은 아니다.

import re

KEYWORDS = {
    "SQL": ("sql",),
    "테스트": ("테스트", "test"),
    "Git": ("git",),
}

POSTINGS = [
    ("P1", "SQL을 활용한 데이터 조회 기능 개발"),
    ("P2", "자동화 테스트 작성"),
    ("P3", "Git을 활용한 협업"),
]

RESUME = [
    (
        "R1",
        "SQL 조회에서 중복 행이 생기는 조건을 찾아 쿼리를 수정했다.",
        "E1 조회 조건 수정 기록",
    ),
    (
        "R2",
        "Git 변경 요청을 나누고 검토 의견을 반영했다.",
        "E2 변경 요청과 검토 기록",
    ),
    (
        "R3",
        "테스트 실패 조건을 재현하고 수정 뒤 결과를 확인했다.",
        "",
    ),
]


def contains(text: str, alias: str) -> bool:
    if alias.isascii():
        pattern = rf"(?<![A-Za-z0-9_]){re.escape(alias)}(?![A-Za-z0-9_])"
        return re.search(pattern, text, flags=re.IGNORECASE) is not None
    return alias in text


def keywords(text: str) -> list[str]:
    return [
        name
        for name, aliases in KEYWORDS.items()
        if any(contains(text, alias) for alias in aliases)
    ]


def main() -> None:
    print("공고 문장과 이력서 문장의 키워드 대응표")
    print("공고 | 키워드 | 이력서 | 증거 표기")
    for posting_id, posting_text in POSTINGS:
        required = keywords(posting_text)
        if not required:
            print(f"{posting_id} | 사전 키워드 없음 | - | 사람이 검토")
            continue
        for keyword in required:
            matches = [
                (resume_id, evidence)
                for resume_id, text, evidence in RESUME
                if keyword in keywords(text)
            ]
            if not matches:
                print(f"{posting_id} | {keyword} | - | 관련 문장 없음")
                continue
            for resume_id, evidence in matches:
                label = evidence if evidence.strip() else "미등록"
                print(f"{posting_id} | {keyword} | {resume_id} | {label}")
    print("주의: 키워드 일치는 역량 충족이나 증거 검증을 뜻하지 않는다.")


if __name__ == "__main__":
    main()

줄별 해설

빈 줄을 포함해 완성 코드의 첫 줄부터 센다. 출력문이 어느 데이터에서 만들어지는지 따라가며 읽는다.

• 1행: 정규 표현식을 제공하는 re를 불러온다. 외부 설치가 필요하지 않다.
• 3~7행: 출력할 대표 키워드와 허용할 표현을 묶는다. 하나짜리 튜플에도 쉼표를 붙인다. 사전에 없는 표현은 자동으로 추측하지 않는다.
• 9~13행: 공고 문장에 P1부터 P3까지 식별자를 붙인다. 식별자는 출력과 원문을 연결한다.
• 15~31행: 이력서 식별자, 문장, 증거 표기를 한 묶음으로 저장한다. R3의 빈 문자열은 증거 표기를 아직 등록하지 않았다는 뜻이다.
• 34행: contains 함수는 문장에 지정한 표현이 있는지 참 또는 거짓으로 돌려준다.
• 35~37행: 영문 표현 앞뒤에 영문자·숫자·밑줄이 붙었는지 확인하고 대소문자를 무시해 검색한다. re.escape는 사전의 표현을 정규 표현식 문법으로 오해하지 않게 한다.
• 38행: 한국어 표현은 문자열 포함 여부를 사용한다. 조사나 어미를 분석하는 기능은 없다.
• 41~46행: 사전 순서대로 키워드를 찾는다. 별칭 중 하나라도 발견되면 대표 이름을 한 번만 반환한다.
• 49~51행: main 함수에서 표 제목과 열 이름을 출력한다. 실제 데이터 행은 다음 반복문에서 만든다.
• 52~56행: 공고에서 사전 키워드를 찾는다. 찾은 것이 없어도 행을 남기므로 공고가 조용히 누락되지 않는다.
• 57~62행: 공고에서 찾은 각 키워드에 대해 같은 키워드를 포함한 이력서 문장을 모두 모은다. 하나의 요구사항에 여러 문장이 대응할 수 있다.
• 63~65행: 대응 문장이 없으면 그 사실을 출력하고 다음 키워드로 넘어간다. 경험 자체가 없다는 판정은 하지 않는다.
• 66~68행: 대응 문장마다 증거 이름을 출력한다. 비어 있거나 공백뿐이면 “미등록”으로 표시한다.
• 69행: 표의 해석 한계를 출력한다. 키워드 발견과 내용 검증은 다른 작업이다.
• 72~73행: 이 파일을 직접 실행했을 때 main을 호출한다. 실행을 마치면 추가 입력을 기다리지 않고 종료한다.

영문 경계를 직접 지정한 이유는 SQL 뒤에 한국어 조사가 붙은 “SQL을”도 찾기 위해서다. 이 규칙은 모든 기술 표기를 이해하는 언어 분석기가 아니다. 예를 들어 SQLAlchemy는 SQL과 같은 항목으로 잡히지 않는다. 자신의 공고에서 필요한 표기를 확인한 뒤 별칭을 추가하고, 그 추가가 어떤 문장까지 포함하는지 검토해야 한다.

실행 결과

main.py를 저장한 디렉터리에서 다음 명령을 실행한다.

python3 main.py

예상 출력은 다음과 같다.

공고 문장과 이력서 문장의 키워드 대응표
공고 | 키워드 | 이력서 | 증거 표기
P1 | SQL | R1 | E1 조회 조건 수정 기록
P2 | 테스트 | R3 | 미등록
P3 | Git | R2 | E2 변경 요청과 검토 기록
주의: 키워드 일치는 역량 충족이나 증거 검증을 뜻하지 않는다.

P2와 R3에는 모두 “테스트”가 들어 있다. 그러나 공고는 자동화 테스트 작성을 요구하고, R3는 실패 조건 재현과 결과 확인을 설명한다. 따라서 이 행은 요구사항을 충족했다는 뜻이 아니다. 문장을 열어 직접 작성한 테스트 코드가 있는지 확인해야 한다. 없으면 현재 기여를 그대로 적고 부족한 경험을 별도로 남긴다.

“미등록”도 거짓이라는 뜻은 아니다. 증거 이름이 비어 있다는 뜻이다. 반대로 E1이라는 문자열이 있다고 실제 증거가 존재하는 것도 아니다. 식별자에 해당하는 자료가 열리는지, 문장과 관련 있는지, 개인 역할을 뒷받침하는지는 사람이 확인한다.

실무에서 자주 틀리는 것

기술 이름의 일부만 보고 대응시키기

다음 코드는 JavaScript 경험을 Java 경험으로 잡을 수 있다. 기술 이름이 서로 포함되는 경우에는 단순 부분 문자열 검색이 원하는 뜻과 다르게 작동한다.

text = "JavaScript로 화면을 구현했다."
matched = "java" in text.lower()
print(matched)

영문 기술 이름의 경계를 확인하면 이 문장에서 Java는 일치하지 않는다. 한국어 조사 앞에서도 찾을 수 있도록 경계에 사용할 문자를 명시한다.

import re

text = "JavaScript로 화면을 구현했다."
pattern = r"(?<![A-Za-z0-9_])java(?![A-Za-z0-9_])"
matched = re.search(pattern, text, flags=re.IGNORECASE) is not None
print(matched)

이 수정도 의미를 이해하지는 않는다. “Java 경험 없음”에는 Java가 있으므로 일치한다. 부정 표현과 실제 경험 여부는 원문을 읽어 판단한다.

측정하지 않은 개선율을 문장에 넣기

다음 문장은 계산 근거가 없는 숫자를 고정값으로 넣는다. 그럴듯한 비율을 선택하는 것은 측정이 아니다.

improvement = 80
sentence = f"조회 응답 시간을 {improvement}% 줄였다."

측정 기록이 없다면 실제 확인한 행동으로 바꾼다. 이후 같은 조건에서 측정할 수 있을 때 결과와 조건을 함께 추가한다.

sentence = (
    "중복 행이 생기는 조회 조건을 수정하고 "
    "준비한 입력으로 반환 결과를 확인했다."
)

숫자를 지운 자리에 “대폭”, “획기적으로” 같은 표현을 넣으면 검증 문제는 남는다. 확인한 범위를 문장 자체에 드러내는 편이 낫다.

키워드가 있으면 요구 역량을 충족했다고 표시하기

다음 코드는 테스트라는 단어 하나로 공고의 요구사항을 충족했다고 결론 내린다. 테스트를 작성했는지 실행만 했는지 구분하지 못한다.

text = "테스트 결과를 확인했다."
status = "충족" if "테스트" in text else "미충족"

도구가 관찰한 사실만 표시하도록 바꾼다. 내용의 적합성은 공고 원문과 개인 기여 기록을 대조해 판단한다.

text = "테스트 결과를 확인했다."
status = "표현 발견: 내용 검토 필요" if "테스트" in text else "표현 없음"

증거 이름이 있으면 검증을 끝냈다고 보기

증거 필드에 글자가 있다는 사실만으로 자료가 존재하고 주장도 맞다고 판단할 수 없다. 다음 코드는 그 차이를 감춘다.

evidence = "E1 조회 조건 수정 기록"
status = "검증 완료" if evidence else "검증 실패"

표기 유무만 검사했다면 그 범위에 맞는 이름을 쓴다. 공백뿐인 값도 비어 있는 것으로 처리한다.

evidence = "E1 조회 조건 수정 기록"
status = "증거 표기 있음" if evidence.strip() else "증거 표기 미등록"

실제 확인에서는 링크 접근 여부, 관련 변경 내용, 역할 설명을 함께 읽는다. 자료가 있다는 사실과 그 자료가 해당 문장을 뒷받침한다는 사실도 구분해야 한다.

한눈에 보기

지원서 문장을 만들고 검토하는 기준

대상	작성 기준	남길 근거	도구의 한계
공고 분석	기술과 요구 행동을 함께 읽는다.	공고 원문과 확인 날짜	등록한 키워드만 찾는다.
개인 기여	문제·내 결정·결과·배운 것을 구분한다.	변경 기록과 역할 메모	팀 성과와 개인 행동을 구별하지 못한다.
숫자	동일한 비교 조건과 출처를 적는다.	측정 방법·입력·환경·결과	수치의 진실성을 검증하지 않는다.
공개 자료	이력서에서 관련 자료까지 연결한다.	열리는 링크와 관련 설명	증거 이름만으로 접근 여부를 알 수 없다.
대응표	일치 행과 빈칸을 모두 다시 읽는다.	실행 출력과 검토 메모	역량 점수나 합격 가능성을 계산하지 않는다.

이력서 문장을 소리 내어 읽은 뒤 “어떤 문제였는가”, “내가 결정한 것은 무엇인가”, “무엇으로 확인했는가”를 짧게 덧붙여 본다. 설명이 막히면 표현을 더 강하게 바꾸기보다 기록을 다시 살핀다. 다음 장에서는 이렇게 남긴 문장과 근거를 바탕으로 질문에 답하는 구조를 만든다.

연습 문제

1. “우리 팀은 서비스를 배포했고 성능을 70% 개선했다”라는 문장을 점검한다. 개인 담당 범위와 측정 기록은 남아 있지 않다고 가정한다. 확인할 질문 세 가지를 적고, 자신이 직접 확인한 일정 조회 기능의 동작만으로 문장을 다시 쓴다.
2. 완성 코드의 RESUME에서 R3의 증거 표기를 “E3 테스트 재현 기록”으로 바꾼다. 달라지는 출력 행을 쓰고, 이 변경만으로 자동화 테스트 작성 요구사항을 충족했다고 말할 수 있는지 설명한다.
3. POSTINGS 끝에 식별자 P4와 “문서로 작업 내용을 공유한 경험”을 추가한다. KEYWORDS는 그대로 둔다. 추가되는 출력 행과 사람이 해야 할 검토를 설명한다.
4. “검증”을 “테스트”의 별칭에 추가한다. “입력값 검증 로직을 작성했다”라는 문장이 어떤 키워드로 잡히는지 예상하고, 이 별칭을 유지할지 판단한다.

정답과 해설

1. 확인할 질문은 “내가 맡은 기능과 변경은 무엇인가”, “70%의 원본 값과 계산 방법이 남아 있는가”, “비교한 입력과 환경이 같은가”로 정할 수 있다. 현재 확인한 사실만 쓰면 “팀 프로젝트의 일정 조회 기능에서 준비한 입력에 대한 반환 결과를 확인했다”가 된다. 배포에 자신의 기여가 있었는지, 성능 개선이 실제로 있었는지는 별도 확인 전까지 개인 성과로 적지 않는다.

2. 변경되는 행은 다음과 같다.

   P2 | 테스트 | R3 | E3 테스트 재현 기록

   증거 표기가 등록되었을 뿐이다. 재현 기록을 읽어도 자동화 테스트 코드를 직접 작성한 사실이 없다면 공고의 요구 행동과 차이가 남는다. 자료가 설명하는 실제 행동을 이력서에 유지해야 한다.

3. 사전에 대응하는 표현이 없으므로 다음 행이 추가된다.

   P4 | 사전 키워드 없음 | - | 사람이 검토

   문서 공유 역량이 중요하지 않다는 뜻이 아니다. 현재 사전이 그 표현을 다루지 않는다는 뜻이다. 작업 설명, README 변경, 검토를 위한 메모 등 실제 기록을 찾아 대응 문장이 있는지 읽는다. 필요하면 대표 키워드와 별칭을 추가하되, 서로 다른 행동을 너무 넓게 묶지 않는다.

4. 문장에 “검증”이 있으므로 대표 키워드 “테스트”로 잡힌다. 그러나 입력값 검증 로직을 구현한 경험과 테스트를 작성한 경험은 다르다. 이 도구의 목적에서는 “검증”을 테스트의 포괄적인 별칭으로 유지하지 않는 편이 낫다. 필요한 경우 별도 항목으로 분리하고 공고 문맥을 확인한다. 일치 항목이 늘었다는 사실만으로 대응표가 더 정확해졌다고 판단하지 않는다.