국비 출신의 강점을 말로 만들기 - 짧은 기간·팀 프로젝트·이전 경력

이 장에서 배우는 것

국비 과정을 수료하고 경험을 설명하려 하면 “짧게 배워서 아는 것이 부족하다”는 말부터 나올 수 있다. 그러나 짧은 기간에 새로운 언어와 도구를 익히고, 팀으로 서비스를 만들고, 정해진 날에 시연한 경험도 개발 업무와 연결된다. 중요한 것은 수료 사실에 의미를 덧붙이는 일이 아니라, 실제로 한 일을 상대가 확인할 수 있는 문장으로 바꾸는 일이다.

앞 장에서 배운 것·한 것·모르는 것을 나눴다면, 이제 ‘한 것’에서 강점을 꺼낼 차례다. 이 장에서는 일정 안에 끝낸 경험, 협업과 발표 경험, 이전 직무에서 익힌 행동을 상황·행동·결과 구조로 정리한다. 부족한 부분은 감추거나 크게 부풀리지 않고 현재 수준과 보완 방법을 함께 말한다. 마지막에는 경험 기록에서 빈 항목을 찾아 주는 작은 Python 도구를 만든다.

• 일정 안에 서비스를 완성한 경험에서 범위 조정과 우선순위 판단을 찾아낸다.
• 팀 성과와 자신의 기여를 구분하고 협업·발표 경험을 구체적인 행동으로 설명한다.
• 이전 직무의 경험을 개발 업무에서 다시 사용할 수 있는 행동으로 연결한다.
• 약점을 현재 수준·보완 행동·확인 방법으로 정리한다.
• 경험 문장의 필수 항목을 코드로 점검하고, 내용의 타당성은 직접 검토한다.

문제 상황

수료 발표를 마친 뒤 자신의 경험을 소개하는 자리가 생겼다고 하자. “어떤 부분에 기여했는가”라는 질문에 “팀 프로젝트에서 예약 기능을 맡았고 협업 능력을 길렀다”고 답한다. 틀린 말은 아니지만, 듣는 사람은 당시 문제가 무엇이었고 어떤 판단을 했는지 알기 어렵다. 기능 이름과 성격에 대한 평가만 있고, 그 평가를 뒷받침하는 행동이 빠져 있기 때문이다.

추가 질문이 이어진다. “일정이 부족할 때 어떻게 했는가”, “팀원과 의견이 달랐던 일은 무엇인가”, “발표 준비에서 직접 한 일은 무엇인가.” 기억에는 많은 일이 남아 있지만 답변은 길어지고, 팀 전체가 한 일과 자신이 한 일이 섞인다. 결국 “다 같이 열심히 했다”는 문장으로 끝난다. 경험이 없어서가 아니라 경험을 꺼내는 기준이 없어서 생기는 문제다.

이전 직무 이야기도 비슷하다. 매장에서 주문을 처리했던 사람은 개발과 관계없는 경력이라고 생각해 지워 버릴 수 있다. 반대로 “고객을 응대했으므로 사용자 요구를 잘 안다”고 넓게 주장할 수도 있다. 두 경우 모두 실제 경험의 쓰임을 놓친다. 누락된 주문을 어떻게 확인했는지, 인수인계 때 어떤 정보를 남겼는지를 살피면 개발 업무에 연결할 행동이 나온다.

이 장의 목표는 모든 경험을 좋은 이야기로 포장하는 것이 아니다. 설명할 수 있는 사실과 아직 확인하지 못한 주장을 나누는 것이다. 잘 정리된 경험 문장은 질문을 피하게 해 주는 문장이 아니라, 다음 질문에 기록을 보며 답할 수 있게 해 주는 문장이다.

짧은 기간의 경험을 상황·행동·결과로 바꾸기

상황·행동·결과 구조는 경험에서 설명에 필요한 정보를 골라내는 틀이다. 상황에는 당시 목표와 제약을 쓴다. 행동에는 그 조건에서 자신이 무엇을 했는지 쓴다. 결과에는 행동 뒤에 확인된 변화를 쓴다. 여기에 완료 증거를 붙이면 기억에만 의존하던 설명을 다시 확인할 수 있다. 증거는 네 번째 사건이 아니라 앞의 세 항목을 뒷받침하는 기록이다.

“촉박한 일정에도 프로젝트를 끝냈다”는 문장부터 살펴보자. 촉박했다는 느낌만으로는 판단 과정을 알 수 없다. “시연까지 사흘 남았는데 예약 취소 화면이 연결되지 않았다”라고 쓰면 상황이 보인다. 이어서 “남은 작업을 필수 흐름과 추가 기능으로 나누는 안을 제안하고, 합의한 필수 흐름의 연결을 맡았다”라고 쓰면 자신의 행동이 드러난다.

결과는 “성공적으로 마무리했다”보다 확인한 상태를 쓰는 편이 낫다. “예약 생성부터 취소까지 정해 둔 시연 순서를 끝냈고, 추가 알림 기능은 후속 작업 목록에 남겼다”라고 쓸 수 있다. 이 문장은 모든 기능을 완성했다고 주장하지 않으면서도, 일정 안에 무엇을 끝냈는지 보여 준다. 시연 목록과 작업 기록이 남아 있다면 그 내용을 증거로 연결한다.

일정 안에 끝내는 힘은 단순히 오래 앉아 있었던 시간과 다르다. 남은 작업을 보이게 만들고, 끝내야 할 범위를 합의하고, 막힌 부분을 일찍 공유하는 행동에서 드러난다. 밤늦게까지 작업했다는 사실보다 어떤 선택으로 완료 가능성을 높였는지를 설명해야 한다. 다만 당시 하지 않은 범위 조정이나 회의를 나중에 했던 것처럼 넣어서는 안 된다.

경험을 설명할 때 각 항목이 답해야 하는 질문

항목	확인 질문	예약 프로젝트 예시
상황	목표와 제약이 무엇이었는가	시연 사흘 전, 취소 화면 연결이 남아 있었다.
행동	내가 무엇을 판단하고 실행했는가	필수 흐름 구분을 제안하고 합의 뒤 화면 연결을 맡았다.
결과	어떤 상태를 실제로 확인했는가	정해 둔 예약·취소 시연 순서를 끝냈다.
증거	무엇을 보면 설명을 확인할 수 있는가	작업 목록, 변경 기록, 시연 순서가 남아 있다.

결과에 반드시 숫자를 넣을 필요는 없다. 측정하지 않았는데 “처리 속도가 크게 개선됐다”거나 임의의 비율을 적으면 근거가 약해진다. 숫자 대신 “누락되던 오류 안내가 화면에 표시되는 것을 재현 절차로 확인했다”처럼 관찰한 사실을 쓸 수 있다. 수치를 사용한다면 무엇을 어떤 조건에서 셌는지도 설명할 수 있어야 한다.

행동 뒤에 좋은 결과가 나오지 않았더라도 정리할 가치가 있다. 예를 들어 외부 연결 문제를 늦게 공유해 시연 범위를 줄였다면, 그 사실과 이후 바꾼 행동을 적는다. “협업의 중요성을 배웠다”에서 멈추지 않고 “연결 작업이 막히면 재현 조건과 현재 상태를 작업 기록에 남기기로 합의했다”까지 내려가야 다음 작업에 사용할 수 있는 경험이 된다.

협업·발표와 이전 직무에서 내 행동 찾기

팀 성과 옆에 자신의 담당 범위를 둔다

팀 프로젝트는 혼자 만든 결과물처럼 설명할 필요가 없다. 팀이 무엇을 만들었는지 먼저 밝히고, 그 안에서 자신이 맡은 범위를 나누면 된다. “팀은 예약 서비스를 만들었고, 나는 예약 취소 요청 처리와 화면 연결을 맡았다”는 식이다. 다른 사람이 만든 로그인이나 배포 작업을 자신의 성과에 섞지 않아도 담당 부분의 판단과 실행을 충분히 설명할 수 있다.

공동 작업이라면 기여의 경계를 더 구체적으로 적는다. “팀원과 함께 오류를 해결했다” 다음에 “나는 실패 요청을 재현하고 요청값을 비교했으며, 팀원은 서버의 검사 조건을 수정했다”를 붙인다. 원인을 처음 발견한 사람, 수정한 사람, 수정 뒤 확인한 사람이 다를 수 있다. 역할을 정확히 나누는 설명은 협업의 흔적을 지우지 않으면서 자신의 행동을 보여 준다.

의견 차이를 다룬 경험에서는 누가 옳았는지만 강조하지 않는다. 서로 무엇을 우려했는지, 어떤 기준으로 선택했는지, 결정 뒤 누가 무엇을 했는지를 적는다. “내 의견으로 팀을 설득했다”보다 “남은 시간과 시연 필수 흐름을 기준으로 두 안을 비교했고, 팀이 선택한 안에 맞춰 취소 화면을 연결했다”가 작업 과정을 더 잘 전달한다.

발표는 자료 제작보다 전달과 확인의 경험이다

발표 자료를 만든 경험도 개발 업무와 연결할 수 있다. 다만 “발표를 맡아 소통 능력이 좋아졌다”는 결론만으로는 부족하다. 청중이 이해하기 어려웠던 부분을 어떻게 발견했고 무엇을 바꿨는지 살핀다. 시연 순서를 사용자 행동 순으로 바꿨는지, 실패 상황을 설명하는 화면을 준비했는지, 질문에 답하지 못한 내용을 확인해 기록했는지가 행동이 된다.

예를 들어 첫 연습에서 기능 설명이 길어 예약 취소 시연을 끝내지 못했다면, 설명과 시연이 중복되는 구간을 표시하고 자료를 줄인 행동을 적을 수 있다. 결과는 “발표를 잘했다”가 아니라 “다음 연습에서 준비한 시연 순서를 끝냈다”가 된다. 연습 자료의 수정본과 점검표가 남아 있다면 결과를 확인하기도 쉽다.

이전 경력은 같은 행동이 다시 필요한 지점을 찾는다

이전 직무와 개발 직무를 잇는 기준은 직업 이름의 유사성이 아니다. 정보를 확인하고, 우선순위를 정하고, 다른 사람에게 현재 상태를 전달하는 행동이 어디에서 다시 필요한지 찾는 것이다. 주문 확인, 일정 조율, 문서 관리, 장비 점검 같은 경험에도 이런 행동이 들어 있을 수 있다. 먼저 실제로 했던 절차를 적고 개발 업무와 닿는 부분을 고른다.

매장에서 인수인계를 담당했다면 “고객 중심 사고를 갖췄다”보다 “처리가 끝나지 않은 주문을 담당자·현재 상태·다음 확인 시점으로 나눠 전달했다”가 구체적이다. 이 행동은 개발 중인 작업의 진행 상태를 공유할 때 활용할 수 있다. 다만 그 경험만으로 장애 대응이나 요구사항 분석 능력을 이미 갖췄다고 결론 내리지는 않는다. 전환할 수 있는 습관과 새로 익혀야 할 기술을 구분한다.

이전 직무에서 쓰던 용어는 처음 듣는 사람도 이해할 수 있게 풀어 쓴다. 내부 약어나 서식 이름보다 어떤 누락을 막기 위해 무엇을 확인했는지가 중요하다. 당시 기록에 고객 정보나 내부 자료가 들어 있다면 그대로 공개하지 않는다. 개인과 조직을 식별하는 내용을 뺀 설명이나 새로 만든 빈 양식으로 작업 방식을 보여 주고, 재구성한 자료라는 사실을 밝힌다.

약점은 현재 수준과 보완 행동으로 말하기

강점을 정리한다고 해서 모르는 부분까지 능숙하게 말할 필요는 없다. “아직 부족하지만 열심히 하겠다”는 표현은 태도는 전하지만 다음 행동을 알려 주지 않는다. 현재 어디까지 가능한지, 무엇을 더 확인해야 하는지, 어떤 작업으로 보완할지 나누면 부족한 부분도 구체적으로 설명할 수 있다.

예를 들어 “SQL을 못한다”는 평가 대신 “기본 조회는 작성했지만, 여러 테이블을 연결한 조회는 결과가 맞는 이유를 충분히 설명하지 못한다”라고 범위를 좁힌다. 이어서 “프로젝트의 예약·회원 테이블로 조회 예시를 다시 작성하고, 예상 결과와 실제 결과를 비교한 기록을 남기겠다”라고 보완 행동과 확인 방법을 붙인다. 아직 실행하지 않았다면 계획으로 말하고, 이미 마친 일처럼 표현하지 않는다.

보완 계획의 크기는 현재 설명하려는 약점에 맞춘다. 한 번의 질문에 답하지 못했다고 운영체제 전체를 다시 공부하겠다고 약속하면 무엇을 확인할지 흐려진다. 이번 경험과 연결되는 질문 하나를 골라 설명을 써 보고, 모르는 용어를 찾아 정리하는 정도로 시작할 수 있다. 구체적인 주간 배치는 다음 장에서 다루므로 여기서는 보완 행동과 완료 조건까지만 정한다.

서재의 자료도 약점의 종류에 맞춰 고른다. 개념의 위치가 혼란스럽다면 《비전공자를 위한 컴퓨터공학 지도》로 관련 주제를 찾고, 설명이 막힌 개념은 《개발자를 위한 컴퓨터 사이언스》에서 확인한다. 조회 결과를 설명하지 못한다면 《데이터베이스 개론》과 SQL 연구소를 보완 활동에 연결한다. 문제 풀이 과정이 막힌 경험이라면 《논리로 푸는 알고리즘》과 코드패스를 사용할 자리를 적어 둔다.

자신이 수정한 이유를 설명하기 어렵다면 《클린 코드 노하우》를, 공동 변경에서 주고받은 의견을 돌아보려면 《코드 리뷰 실무》를 참고할 수 있다. 정리한 경험에 이어질 질문을 찾아볼 때는 《개발자 실무 면접》을 연결한다. 이 장에서 해당 자료의 학습 내용을 모두 시작할 필요는 없다. 어느 빈칸에 어떤 자료를 사용할지만 정하고, 실제로 참고하거나 실행한 내용만 기록한다.

완성 코드

다음 프로그램은 경험 문장을 상황·행동·결과와 증거로 나눠 저장하고, 비어 있는 항목을 출력한다. 입력을 받거나 파일을 읽지 않으므로 실행 결과가 일정하다. 예시를 자신의 경험으로 바꿀 때도 같은 항목을 유지하면 된다. macOS 또는 Linux의 Python 3.12 이상에서 외부 패키지와 네트워크 없이 실행한다.

코드는 문장의 사실 여부나 강점의 크기를 판단하지 않는다. “열심히 했다”처럼 내용이 모호해도 글자가 있으면 빈칸으로 보지 않는다. 따라서 결과 문구도 ‘합격’이나 ‘좋은 문장’ 대신 ‘필수 항목 채움’으로 표시한다. 도구의 판정 범위를 좁혀야 사람이 해야 할 검토가 가려지지 않는다.

main.py

REQUIRED_FIELDS = (
    ("situation", "상황"),
    ("action", "행동"),
    ("result", "결과"),
    ("evidence", "증거"),
)

EXPERIENCES = [
    {
        "title": "일정 안에 끝낸 경험",
        "situation": "시연 사흘 전 예약 취소 화면 연결이 남아 있었다.",
        "action": "필수 흐름 구분을 제안하고 합의 뒤 화면을 연결했다.",
        "result": "예약 생성과 취소 시연을 정해 둔 순서로 끝냈다.",
        "evidence": "작업 목록과 시연 점검표",
    },
    {
        "title": "발표 준비 경험",
        "situation": "첫 연습에서 설명이 길어 취소 시연을 끝내지 못했다.",
        "action": "설명과 시연이 중복되는 구간을 표시하고 자료를 줄였다.",
        "result": "   ",
        "evidence": "발표 자료 수정본",
    },
    {
        "title": "이전 직무 경험",
        "situation": "교대 때 미처리 주문의 전달이 필요했다.",
        "action": "담당자와 현재 상태, 다음 확인 시점을 적어 전달했다.",
        "result": "다음 근무자가 기록을 보고 확인할 주문을 구분했다.",
        "evidence": "개인정보 없이 재구성한 인수인계 양식",
    },
]


def missing_fields(experience):
    missing = []
    for key, label in REQUIRED_FIELDS:
        value = experience.get(key, "")
        if not value.strip():
            missing.append(label)
    return missing


def print_report(experiences):
    complete_count = 0
    print("경험 문장 점검")
    for number, experience in enumerate(experiences, start=1):
        missing = missing_fields(experience)
        if missing:
            status = "보완 필요: " + ", ".join(missing)
        else:
            status = "필수 항목 채움"
            complete_count += 1
        print(f"{number}. {experience['title']} | {status}")
    print(f"필수 항목 채움: {complete_count}/{len(experiences)}")
    print("사람이 확인: 내 행동인가 / 결과를 확인했는가 / 증거가 맞는가")


if __name__ == "__main__":
    print_report(EXPERIENCES)

예시 데이터는 프로그램의 동작을 보여 주기 위해 새로 구성한 사례다. 자신의 기록을 넣을 때는 항목 값을 모두 문자열로 작성한다. 아직 결과를 확인하지 못했다면 빈 문자열로 남겨도 된다. 빈칸을 없애려고 추측한 결과를 쓰는 것보다 확인이 필요한 상태를 드러내는 편이 도구의 목적에 맞는다.

줄별 해설

빈 줄을 포함한 코드의 1~6행은 필수 항목을 정의한다. 각 묶음의 첫 값은 데이터에서 사용할 이름이고 두 번째 값은 출력에 사용할 한국어 표시다. 검사할 항목과 표시 순서를 이곳에서 함께 정하므로, 경험마다 서로 다른 순서로 누락 항목을 보여 주는 일을 피할 수 있다.

8~30행은 세 경험을 담은 목록이다. 각 경험은 제목과 네 개의 필수 항목을 가진 사전으로 표현한다. 사전은 키에 해당하는 값을 찾는 데 사용하고, 바깥 목록은 경험의 출력 순서를 유지한다. 이 프로그램은 입력한 순서대로 점검하므로 경험의 우열을 매기거나 결과에 따라 순서를 바꾸지 않는다.

20행의 결과 값에는 공백 세 칸만 들어 있다. 화면에서는 비어 보이지만 Python에서는 길이가 있는 문자열이다. 단순히 문자열이 존재하는지만 검사하면 이 값을 놓친다. 이 예시는 공백만 입력한 항목도 누락으로 처리하는지 확인하기 위해 넣었다.

33~39행의 missing_fields 함수는 경험 하나를 받아 누락 항목의 표시 이름을 목록으로 돌려준다. 36행의 get은 키가 없으면 빈 문자열을 사용한다. 따라서 result 항목을 지운 경우에도 같은 누락 검사로 이어진다. 다만 값으로 숫자나 None을 넣는 상황까지 처리하는 함수는 아니다. 이 예제의 입력 규칙은 모든 항목을 문자열로 작성하는 것이다.

37행의 strip은 문자열 양끝의 공백을 제거한 값을 반환한다. 그 결과가 빈 문자열이면 not 조건이 참이 되어 누락 목록에 표시 이름을 추가한다. 검사 과정에서 원래 경험 사전의 값을 바꾸지는 않는다. 내용에 포함된 공백을 정리해서 저장하는 기능과, 공백만 있는지 확인하는 기능은 구분한다.

42~54행의 print_report 함수는 전체 결과를 출력한다. complete_count는 네 항목이 모두 채워진 경험의 수다. 45행의 enumerate는 경험과 함께 1부터 시작하는 번호를 제공한다. 검사 결과가 있으면 join으로 누락 이름을 이어 붙이고, 없으면 채움 상태를 표시하면서 개수를 하나 늘린다.

53행은 채워진 경험 수와 전체 경험 수를 함께 보여 준다. 이 비율은 준비 수준이나 채용 가능성을 뜻하지 않는다. 현재 입력에서 필수 항목을 채운 기록의 개수일 뿐이다. 54행은 자동 검사 뒤에 남는 사람의 검토를 출력한다. 자신의 행동인지, 확인한 결과인지, 증거가 설명을 뒷받침하는지 다시 읽어야 한다.

57~58행은 이 파일을 직접 실행할 때 보고서 함수를 호출한다. 별도 입력을 기다리는 구문이 없고, 반복문도 목록의 세 경험을 확인하면 끝난다. 같은 데이터와 코드로 실행하면 같은 출력이 나오며, 실행 과정에서 원본 파일이나 다른 파일을 수정하지 않는다.

실행 결과

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

python3 main.py

예상 출력은 다음과 같다. 발표 준비 경험은 결과에 공백만 있으므로 보완 대상으로 나온다.

경험 문장 점검
1. 일정 안에 끝낸 경험 | 필수 항목 채움
2. 발표 준비 경험 | 보완 필요: 결과
3. 이전 직무 경험 | 필수 항목 채움
필수 항목 채움: 2/3
사람이 확인: 내 행동인가 / 결과를 확인했는가 / 증거가 맞는가

두 번째 경험의 결과를 채우기 전에 실제로 다음 발표 연습을 했는지부터 확인한다. 했다면 당시 점검표에서 관찰한 결과를 가져온다. 하지 않았다면 결과는 빈칸으로 두고 확인할 행동을 별도로 적는다. 보고서의 보완 표시는 잘못된 경험이라는 평가가 아니라 설명에 필요한 정보가 아직 없다는 표시다.

실무에서 자주 틀리는 것

공백만 있는 값도 작성한 것으로 센다

다음 코드는 문자열에 공백만 들어 있어도 누락이 아니라고 판단한다. 입력한 흔적과 설명할 내용이 있는 상태를 혼동한 경우다.

value = experience.get("result", "")
if not value:
    print("결과 누락")

양끝 공백을 제거한 값으로 검사하면 공백만 있는 항목을 찾을 수 있다. 문자열만 받는다는 입력 규칙도 함께 유지한다.

value = experience.get("result", "")
if not value.strip():
    print("결과 누락")

빈칸 검사 결과를 문장의 품질 판정으로 바꾼다

다음 문구는 코드가 확인한 범위를 넘어선다. 모든 칸에 “열심히 했다”를 넣어도 이 조건을 통과하므로, 제출 가능 여부를 판단할 근거가 없다.

if not missing:
    status = "제출해도 좋은 경험 문장"

자동 판정의 이름을 실제 검사와 맞춘다. 이후 사람은 담당 범위와 근거를 직접 읽는다. 코드가 확인하지 않은 의미를 출력 문구에 더하지 않는 것이 중요하다.

if not missing:
    status = "필수 항목 채움"

팀 결과를 자신의 행동 칸에 넣는다

문법상 실행되는 코드라도 데이터의 구분이 틀릴 수 있다. 다음 기록은 팀의 완성 사실을 개인 행동으로 적고, 결과에는 확인 기준이 없는 평가를 넣었다.

experience = {
    "action": "팀이 예약 서비스를 완성했다.",
    "result": "협업 능력을 인정받았다.",
}

자신이 실제로 수행한 일을 행동에 넣고, 확인한 변화를 결과에 넣는다. 다음 내용 역시 실제 작업 기록이 있을 때만 사용할 수 있다. 다른 팀원의 수정까지 자신이 했다고 적지 않는다.

experience = {
    "action": "취소 요청의 실패 조건을 재현하고 화면 안내를 연결했다.",
    "result": "실패 조건에서 안내 문구가 표시되는 것을 확인했다.",
}

하려던 일을 이미 나온 결과로 적는다

발표 자료를 줄였다는 행동만으로 발표 시간이 맞아졌다고 결론 내릴 수는 없다. 다음 코드는 확인하지 않은 결과를 만들어 빈칸을 없앤 경우다.

experience["result"] = "자료를 줄였으므로 발표를 제시간에 끝냈다."

확인 전에는 결과를 비워 두고 다음 행동을 별도로 적는다. 이 next_step 항목은 완성 코드의 필수 검사 대상이 아니다. 추후 할 일을 결과와 구분해 기억하려고 추가한 메모다.

experience["result"] = ""
experience["next_step"] = "다음 연습에서 시연 종료 여부를 기록한다."

한눈에 보기

경험의 종류별로 찾아야 할 행동과 확인할 기록

경험	찾아낼 행동	확인할 기록
일정 안에 완료	우선순위 제안, 범위 합의, 막힘 공유	작업 목록, 합의 내용, 시연 점검표
협업	재현 조건 전달, 역할 분담, 결정 실행	논의 기록, 변경 내역, 담당 범위
발표	설명 순서 조정, 시연 준비, 질문 확인	자료 수정본, 연습 기록, 질문 메모
이전 직무	누락 확인, 상태 전달, 인수인계	식별 정보를 뺀 설명, 재구성한 양식
부족한 부분	현재 범위 확인, 보완 행동 실행	설명 초안, 비교 결과, 확인 목록

완료 증거는 많이 모으는 것보다 설명과 맞게 연결하는 것이 중요하다. 변경 기록 하나로 팀 전체의 결정을 증명할 수는 없고, 발표 자료만으로 실제 발표 결과까지 확인할 수도 없다. 각 증거가 무엇을 보여 주고 무엇은 보여 주지 못하는지 함께 살핀다. 기록이 없다면 당시 기억에 근거한 설명이라고 구분하고, 과거 날짜의 기록처럼 새로 만들지 않는다.

이번 주에 할 일과 끝났다고 판단할 완료 증거

확인	할 일	완료 증거
□	일정·협업·발표·이전 직무에서 경험 세 개를 고른다.	경험 제목과 선정 이유를 적은 목록
□	각 경험을 상황·행동·결과로 나누고 팀과 내 역할을 표시한다.	항목별 초안 세 개와 개인 담당 범위
□	각 설명을 뒷받침하는 기록의 위치를 확인한다.	증거 위치와 확인 가능한 내용을 적은 목록
□	약점 하나에 현재 범위·보완 행동·확인 방법을 붙인다.	아직 실행 전인지 실행 후인지 표시한 보완 메모
□	자신의 경험으로 프로그램을 실행하고 결과를 다시 읽는다.	main.py, 실행 출력, 사람이 검토한 수정 메모

모든 항목을 억지로 채워야 이번 주 작업이 끝나는 것은 아니다. 확인하지 못한 결과를 빈칸으로 표시하고 그 이유와 다음 확인 행동을 남겼다면 점검은 수행한 것이다. 반대로 출력에 ‘필수 항목 채움’이 표시돼도 내 행동과 팀 행동이 섞여 있다면 내용 수정이 남아 있다. 완료 증거에는 실행 출력뿐 아니라 사람이 무엇을 고쳤는지도 포함한다.

연습 문제

1. “짧은 기간에 팀 프로젝트를 완성하며 책임감을 길렀다”를 상황·행동·결과로 나눠 다시 작성하라. 실제 경험을 사용하고, 팀의 성과와 개인의 행동을 구분하라. 결과를 확인할 기록이 없다면 그 사실도 적어라.
2. 완성 코드의 발표 준비 경험에서 result 키 자체를 지우고 실행했을 때 어떤 상태가 나올지 설명하라. 이어서 result 값을 빈 문자열로 바꾼 경우와 공백 세 칸으로 바꾼 경우를 비교하라.
3. 이전 직무 또는 학업·동아리·생활에서 상태를 다른 사람에게 전달한 경험 하나를 골라라. 개발 업무에 활용할 수 있는 행동 하나와 새로 배워야 할 기술 하나를 구분해 적어라.
4. 세 경험의 필수 항목 값을 모두 “열심히 했다”로 바꿨다고 가정하라. 프로그램의 채움 개수를 예측하고, 이 결과만으로 문장을 사용할 수 없는 이유를 설명하라. 부족한 설명 하나를 골라 보완 행동과 완료 증거를 적어라.

정답과 해설

1. 경험에 따라 답은 달라진다. 예를 들어 상황은 “시연 사흘 전 취소 화면 연결이 남았다”, 행동은 “필수 흐름 구분을 제안하고 합의 뒤 연결 작업을 맡았다”, 결과는 “팀이 정한 예약·취소 시연 순서를 끝냈다”로 나눌 수 있다. 시연 완료는 팀의 결과이며, 제안과 화면 연결은 개인의 행동이다. 실제로 하지 않은 행동은 넣지 않는다. 당시 기록이 없다면 “현재 설명은 당시 기억에 근거하며 시연 점검표는 남아 있지 않다”라고 구분한다.

2. 세 경우 모두 “보완 필요: 결과”가 나온다. 키가 없으면 get이 빈 문자열을 반환한다. 빈 문자열은 strip 뒤에도 비어 있고, 공백 세 칸도 strip 뒤에는 빈 문자열이 된다. 나머지 데이터가 같다면 전체 채움 개수도 2/3으로 같다. 필수 항목을 직접 대괄호로 조회했다면 키가 없는 경우 오류가 날 수 있지만, 완성 코드는 누락 항목을 보고하기 위해 기본값을 사용한다.

3. 예를 들어 교대 근무에서 미처리 요청을 담당자·현재 상태·다음 확인 시점으로 전달했다면, 개발 작업의 진행 상황을 공유할 때 같은 정리 습관을 활용할 수 있다. 반면 오류 기록을 읽거나 변경 내용을 추적하는 기술은 별도로 익혀야 한다. 개발 경력이 없다는 이유로 전달 경험을 버릴 필요도 없고, 전달 경험만으로 기술적인 문제 분석까지 해 봤다고 주장할 필요도 없다.

4. “열심히 했다”는 공백만 있는 문자열이 아니므로 세 경험 모두 필수 항목을 채운 것으로 처리되어 3/3이 나온다. 그러나 당시 제약, 개인 행동, 확인한 결과가 드러나지 않아 경험 설명으로는 부족하다. 예를 들어 발표 결과가 모호하다면 다음 연습에서 정해 둔 시연 순서의 완료 여부를 기록하는 행동을 정할 수 있다. 완료 증거는 연습에서 사용한 순서표와 실제 확인 결과다. 연습을 하기 전에는 이를 예정된 행동으로 남긴다.

경험을 말로 만드는 작업은 자신을 크게 평가하는 일이 아니라, 자신이 한 선택과 실행을 확인할 수 있게 만드는 일이다. 여기서 정리한 경험과 보완 메모는 다음 장에서 시간을 배분할 근거가 된다. 이미 설명할 수 있는 경험은 유지하고, 비어 있는 결과와 확인할 행동은 실행 계획의 재료로 가져간다.