수료 직후 위치 확인 - 배운 것·한 것·모르는 것 나누기

이 장에서 배우는 것

국비 과정을 마친 직후에는 배운 것이 많아서 오히려 자신의 위치를 설명하기 어렵다. 언어 문법, 웹 요청 처리, 데이터베이스 연결, 팀 프로젝트 발표까지 끝냈지만 빈 폴더에서 같은 기능을 다시 만들려 하면 손이 멈추기도 한다. 이는 과정 전체를 다시 들어야 한다는 뜻이 아니다. 수업에서 접한 것과 팀의 도움으로 해낸 것, 혼자 다시 할 수 있는 것이 아직 한 목록에 섞여 있다는 뜻이다.

짧은 기간에 실제로 돌아가는 서비스를 팀으로 만들고 마감에 맞춰 제출한 경험은 남는다. 이제 그 경험을 취업 준비의 출발점으로 바꾸려면 기술 이름보다 행동과 증거를 살펴봐야 한다. 이 장에서는 자신을 평가하는 말을 늘리는 대신, 확인할 수 있는 작은 작업으로 현재 위치를 기록한다. 점수는 지원 자격이나 취업 가능성을 판정하는 숫자가 아니라 다음 점검 대상을 고르는 도구다.

과정에서 배운 기술과 혼자 재현할 수 있는 작업을 구분한다.
팀 프로젝트에서 자신의 구현, 공동 작업, 참고한 부분을 나누어 설명한다.
언어·DB·웹·Git·CS·테스트·배포의 빈칸을 같은 기준으로 확인한다.
자가 진단 응답을 Python 프로그램에 넣어 영역별 점수와 보완 순서를 출력한다.
이번 주에 남길 완료 증거를 정하고 이후 점검의 기준점을 만든다.

문제 상황

수료 발표를 마친 지 사흘이 지났다. 이력서에는 Java, Spring, JavaScript, SQL, Git을 적었다. 팀 프로젝트는 예약 서비스이며 본인은 예약 조회 화면과 조회 기능 일부를 맡았다. 그런데 “사용자가 조회 버튼을 누르면 어떤 순서로 데이터가 화면에 나타나는가”라는 질문에 화면 파일 이름만 떠오른다. 조회 조건은 직접 만들었지만 오류 응답은 다른 팀원이 작성했고, 배포는 팀장이 진행했다.

이 상태에서 기술 목록을 더 길게 만드는 것은 문제를 풀지 못한다. 반대로 “나는 혼자 만든 것이 없다”라고 적으면 직접 해결한 조회 조건과 화면 연결까지 지워 버린다. 필요한 일은 프로젝트 전체를 소유했다고 말하는 것도, 자신의 기여를 없애는 것도 아니다. 어느 경계를 직접 다뤘는지 찾아내는 일이다.

프로젝트 저장소를 열고 예약 조회 요청 하나를 따라가 보자. 입력값을 받는 코드, 요청을 처리하는 코드, 조회문, 반환값, 화면 갱신 지점을 순서대로 찾는다. 직접 작성한 부분에는 작성 이유를 적고, 다른 사람이 작성한 부분에는 현재 설명할 수 있는 범위를 적는다. 이 기록에서 멈춘 지점이 다음 학습의 후보가 된다.

실무에서도 비슷한 상황을 만난다. 기존 기능의 오류를 고치려면 전체 서비스를 새로 만들 수 있는지보다 수정할 지점을 찾고 영향 범위를 설명할 수 있는지가 먼저 필요하다. 따라서 첫 진단은 기술 이름을 얼마나 기억하는지가 아니라 작은 요청을 어디까지 따라갈 수 있는지를 확인하는 방식으로 진행한다.

배운 기술을 재현 가능한 행동으로 바꾸기

“배웠다”는 말은 학습 이력을 나타낸다. “해봤다”는 말은 수행 경험을 나타낸다. “혼자 다시 할 수 있다”는 말은 현재의 재현 가능성을 나타낸다. 셋은 서로 다른 정보다. 수업에서 다룬 기술은 배운 목록에 남기되, 현재 능력의 근거로 사용할 때는 작업 조건과 결과를 함께 적는다.

예를 들어 “SQL을 배웠다”는 기록을 “예약 번호와 회원 이름을 함께 조회하는 문장을 작성했다”로 바꾼다. 여기에 “기존 조회문을 참고했다” 또는 “빈 편집기에서 작성하고 예상 행과 비교했다”를 붙이면 현재 위치가 더 분명해진다. 같은 결과를 만들었더라도 도움의 종류가 다르면 다음에 점검할 지점도 달라진다.

혼자 한다는 말이 모든 문법을 외운다는 뜻은 아니다. 함수 이름이나 명령 옵션을 확인하는 일과 완성된 해결 코드를 복사하는 일은 구별해야 한다. 이 장에서는 문법 참고 자료를 보더라도 작업 순서를 스스로 정하고, 결과를 검사하고, 선택한 이유를 설명할 수 있으면 독립 수행의 근거로 인정한다. 반면 예제의 변수 이름만 바꾸어 실행했다면 도움을 받은 수행으로 기록한다.

같은 학습 이력을 행동과 증거로 바꾸는 방법
배운 항목	확인할 행동	남길 증거
Java 또는 JavaScript	입력 목록에서 조건에 맞는 항목을 걸러낸다	작성 코드와 빈 목록을 넣은 실행 결과
SQL과 DB	두 테이블을 연결하고 결과 행을 예상한다	조회문, 예상 결과, 실제 결과 비교
웹 요청 처리	요청 하나가 화면까지 돌아오는 경로를 찾는다	파일 위치와 전달값을 적은 흐름 메모
Git	작은 변경을 분리하고 변경 내용을 설명한다	커밋 식별값과 변경 이유

확인 작업은 작아야 한다. “게시판을 다시 만든다”는 여러 능력을 한꺼번에 요구하므로 어디에서 막혔는지 알아내기 어렵다. “조회 결과가 없을 때 빈 목록을 반환한다”처럼 한 번의 실행으로 결과를 관찰할 수 있게 줄인다. 한 작업을 수행하는 데 시간이 많이 걸렸다면 성공 여부와 별도로 막힌 지점과 사용한 도움을 적는다.

배운 기술은 작은 재현 작업과 결과 증거를 거쳐 현재 능력의 기록이 된다

진단할 때마다 조건이 달라지면 점수를 비교하기 어렵다. 이번 주에는 각 영역에서 아래 표의 작업 하나를 확인 대상으로 삼는다. 확인 전부터 답을 알고 있는 작업을 골라도 괜찮지만, 코드를 보지 않은 상태에서 시작했는지와 어떤 자료를 참고했는지는 남긴다. 진단을 위한 작업이므로 자신의 능력을 증명하려고 범위를 키울 필요는 없다.

이 책의 도구는 Python으로 만들지만, 언어 영역의 진단 대상은 자신이 과정에서 사용한 Java 또는 JavaScript로 잡는다. 진단 도구를 이해하는 일과 취업에 사용할 언어를 점검하는 일을 혼동하지 않는다. Python 문법이 낯설다면 먼저 응답 숫자만 바꿔 실행하고, 채점 흐름은 줄별 해설을 따라 확인하면 된다.

팀 프로젝트의 기여를 경계와 결정으로 설명하기

팀 프로젝트의 결과물은 공동 작업이다. 화면 하나에도 다른 사람이 만든 인증 처리, 공통 응답 형식, 테이블 구조가 연결된다. 따라서 자신의 기여를 설명할 때 파일 수나 작성한 줄 수만 세면 실제 역할이 잘 드러나지 않는다. 맡은 요구사항, 직접 바꾼 범위, 선택한 이유, 확인한 결과를 한 묶음으로 정리하는 편이 낫다.

예약 조회를 맡았다면 “예약 기능 개발”이라고만 쓰지 않는다. “회원이 자신의 예약을 조회하는 기능에서 조회 조건과 결과 화면을 연결했다. 다른 회원의 예약이 섞이지 않도록 회원 식별값을 조건에 포함했고, 예약이 없는 경우도 확인했다”처럼 적는다. 실제로 확인하지 않은 보안 효과나 성능 향상은 덧붙이지 않는다. 아직 확인하지 못했다면 그 사실도 다음 점검 항목으로 남긴다.

공동 작업은 기여에서 제외할 대상이 아니다. 팀원과 반환 형식을 맞추거나 충돌한 변경을 조정한 경험도 설명할 수 있다. 다만 “함께 결정한 내용”과 “내가 구현한 내용”을 나눠 적는다. 예를 들어 응답 구조는 함께 정했고 조회 조건은 직접 구현했다면 두 사실을 한 문장에 뭉개지 않는다.

기억이 흐릿할 때는 변경 이력을 참고한다. 커밋(commit)은 변경 묶음과 작성 시점을 찾는 단서다. 하지만 이름이 남았다는 사실만으로 모든 줄을 혼자 설계했다고 볼 수는 없다. 공동 작성, 코드 이동, 합쳐진 변경이 있을 수 있으므로 당시 메모와 실제 코드를 함께 읽는다. 반대로 자신의 이름이 없는 변경이라도 함께 검토하고 해결한 과정은 별도로 기록할 수 있다.

기여 메모에는 네 가지 질문에 답한다. 어떤 요구사항을 맡았는가, 어떤 파일이나 데이터 경계를 바꿨는가, 왜 그 방법을 택했는가, 무엇으로 동작을 확인했는가다. 답을 쓰다가 다른 팀원이 작성한 부분에 도달하면 그 경계를 표시한다. 설명이 끊기는 지점을 숨기지 않아야 자신의 구현을 다시 읽을 출발점이 생긴다.

증거를 찾지 못한 기억은 임시 기록으로 둔다. “오류를 줄였다”는 기억만 있다면 어떤 입력에서 어떤 오류가 났는지부터 찾아본다. 재현할 수 없다면 성과로 단정하지 않고 “당시 오류 처리를 수정했으나 재현 기록은 남아 있지 않다”라고 적는다. 이 구분은 자신을 낮추는 표현이 아니라 이후 설명의 신뢰도를 지키는 방법이다.

빈칸 진단표와 보완 순서 정하기

영역별 응답은 0, 1, 2 중 하나로 통일한다. 0은 아직 확인하지 못했거나 시도했지만 끝내지 못한 상태다. 1은 완성 예제나 다른 사람의 안내를 따라 수행한 상태다. 2는 작업 순서를 스스로 정해 재현하고 결과와 이유를 설명한 상태다. 아직 시도하지 않은 것과 실패한 것은 메모에서는 구별하되, 우선순위를 계산할 때는 둘 다 확인이 필요한 상태로 다룬다.

숫자를 고를 때 느낌보다 최근 증거를 먼저 본다. “이 정도는 알 것 같다”는 예상만 있으면 2로 올리지 않는다. 반대로 오래 걸렸더라도 스스로 원인을 찾고 결과를 확인했다면 시간만으로 1로 내리지 않는다. 수행 시간과 참고 자료는 점수 옆의 관찰 기록에 남길 정보다.

일곱 영역에서 한 가지 행동씩 확인하는 빈칸 진단표
영역	이번에 확인할 행동	확인 증거	응답
언어	조건에 따라 목록을 걸러내는 함수를 작성한다	일반 입력과 빈 입력의 결과	0·1·2
DB	프로젝트 테이블 두 개의 연결 결과를 설명한다	조회문과 예상 행 비교	0·1·2
웹	요청 하나의 입력부터 응답까지 따라간다	처리 순서와 파일 위치 메모	0·1·2
Git	작은 변경을 커밋하고 차이를 설명한다	변경 전후와 커밋 식별값	0·1·2
CS	프로젝트에서 쓴 목록 구조의 선택 이유를 말한다	다른 선택과 비교한 짧은 메모	0·1·2
테스트	기능 하나의 정상 조건과 경계 조건을 검사한다	예상값과 실제값을 적은 결과	0·1·2
배포	프로젝트의 실행 명령과 필요한 설정을 찾는다	민감한 값을 제외한 실행 절차	0·1·2

이 표의 응답은 영역 전체의 숙련도를 대표하지 않는다. DB에서 조회문을 설명했다고 트랜잭션까지 이해했다고 판단할 수는 없다. 여기서는 한 가지 대표 행동을 통해 더 살펴볼 영역을 고른다. 새 행동을 추가하면 진단 범위가 바뀌므로 이전 총점과 그대로 비교하지 않는다.

아래 프로그램은 응답 0·1·2를 각각 0·50·100점으로 표시한다. 보완 순서는 응답이 낮은 영역부터 정하며, 동점이면 진단표에 적힌 순서를 따른다. 이는 학습의 필수 선후 관계가 아니라 출력 순서를 고정하는 규칙이다. 배포 점수가 낮다고 지금 바로 외부 서버를 준비할 필요는 없다. 우선 실행 명령과 설정을 찾는 작은 확인부터 하면 된다.

출력에는 낮은 점수를 받은 영역만 보완 대상으로 나타난다. 모든 영역이 2이면 같은 범위의 반복 점검 대신 진단 행동을 하나씩 넓히라는 문장을 출력한다. 총점은 기록을 간단히 비교하기 위한 값이며 합격선은 두지 않는다. 어떤 영역의 증거가 빠졌는지는 총점보다 영역별 결과에서 확인한다.

빈칸을 찾은 뒤에는 서재의 자료도 질문에 맞춰 펼친다. CS 설명이 끊긴 지점은 《비전공자를 위한 컴퓨터공학 지도》에서 관련 주제의 위치를 잡고 《개발자를 위한 컴퓨터 사이언스》로 확인한다. DB는 《데이터베이스 개론》과 SQL 연구소를 자신의 테이블 관계를 검토할 때 연결한다. 지금은 넓게 읽는 계획보다 확인하려는 질문 하나를 적는 편이 낫다.

언어로 작은 함수를 다시 만드는 데 막혔다면 코드패스에서 해당 문법을 확인하고 원래 작업으로 돌아온다. 풀이 이유를 설명하기 어렵다면 《논리로 푸는 알고리즘》을 이후 연습에 연결할 후보로 적는다. 자신의 변경 이유를 읽기 어렵다면 《클린 코드 노하우》, 다른 사람의 변경과 경계를 확인하려면 《코드 리뷰 실무》를 참고할 질문을 남긴다. 《개발자 실무 면접》은 이번에 작성한 기여 설명에서 답이 끊기는 질문을 찾는 데 연결한다. 이 장에서는 이 자료들의 내용을 새 학습 과제로 모두 펼치지 않는다.

완성 코드

다음 코드를 main.py에 저장한다. 자가 진단표에서 고른 응답은 RESPONSES에 입력한다. 실행할 때 키보드 입력을 기다리지 않고 이 응답을 받아 계산하므로 python3 main.py만으로 바로 끝난다. 예제 응답을 그대로 두면 아래 실행 결과와 같은 내용이 나온다. 자신의 응답으로 바꾸면 같은 응답에 대해서는 항상 같은 결과를 출력한다.

각 응답은 영역 이름과 정수의 짝이다. 순서는 바꿔도 되지만 이름을 빠뜨리거나 중복하면 오류로 처리한다. 범위를 벗어난 숫자와 문자열도 받아들이지 않는다. 결과를 자동으로 파일에 쓰지는 않으므로 출력과 근거 메모는 독자가 따로 보관한다.

AREAS = (
    ("언어", "조건에 맞는 목록 함수를 다시 작성한다"),
    ("DB", "두 테이블의 연결 결과를 확인한다"),
    ("웹", "요청 하나의 처리 경로를 기록한다"),
    ("Git", "작은 변경을 커밋하고 차이를 설명한다"),
    ("CS", "목록 구조를 선택한 이유를 적는다"),
    ("테스트", "정상 조건과 경계 조건을 검사한다"),
    ("배포", "실행 명령과 필요한 설정을 기록한다"),
)

RESPONSES = (
    ("언어", 2),
    ("DB", 1),
    ("웹", 2),
    ("Git", 1),
    ("CS", 0),
    ("테스트", 0),
    ("배포", 1),
)


def validate(responses):
    expected = {name for name, _ in AREAS}
    answers = {}
    for name, value in responses:
        if name not in expected:
            raise ValueError(f"알 수 없는 영역: {name}")
        if name in answers:
            raise ValueError(f"중복 영역: {name}")
        if type(value) is not int or value not in (0, 1, 2):
            raise ValueError(f"{name}: 응답은 정수 0, 1, 2만 허용한다")
        answers[name] = value
    missing = [name for name, _ in AREAS if name not in answers]
    if missing:
        raise ValueError("누락 영역: " + ", ".join(missing))
    return answers


def build_report(responses):
    answers = validate(responses)
    lines = ["자가 진단 결과", "기준: 0=미확인, 1=도움받아 수행, 2=독립 수행"]
    for name, _ in AREAS:
        lines.append(f"{name}: {answers[name] * 50}점")
    total = sum(answers.values())
    maximum = len(AREAS) * 2
    lines.append(f"응답 합계: {total}/{maximum}")
    pending = [
        (answers[name], order, name, action)
        for order, (name, action) in enumerate(AREAS)
        if answers[name] < 2
    ]
    pending.sort(key=lambda item: (item[0], item[1]))
    lines.append("보완 우선순위")
    if not pending:
        lines.append("보완 대상 없음: 진단 행동의 범위를 하나씩 넓힌다.")
    for rank, (_, _, name, action) in enumerate(pending, start=1):
        lines.append(f"{rank}. {name}: {action}")
    return "\n".join(lines)


def main():
    try:
        report = build_report(RESPONSES)
    except ValueError as error:
        print(f"입력 오류: {error}")
        return
    print(report)


if __name__ == "__main__":
    main()

줄별 해설

AREAS는 영역 이름과 다음 행동을 묶어 둔 튜플(tuple)이다. 내용을 나열한 순서가 영역별 출력 순서이자 동점 처리 순서가 된다. 뒤의 점수 계산에서 별도의 영역 이름을 다시 나열하지 않고 이 값을 사용하므로, 표시 순서와 보완 순서의 기준이 어긋날 가능성을 줄인다.

RESPONSES는 실제 진단 응답이다. 처음부터 사전으로 만들지 않은 이유가 있다. 같은 이름을 사전에 두 번 쓰면 앞의 값이 나중 값으로 덮여 중복 입력을 발견하기 어렵다. 여기서는 이름과 값의 짝을 차례로 검사한 뒤 사전(dictionary)인 answers로 옮긴다.

validate의 첫 줄은 허용할 영역 이름을 집합으로 만든다. 이 집합은 이름이 존재하는지 검사할 때만 사용한다. 집합을 출력 순서의 근거로 쓰지 않는다. 이어서 각 응답의 이름이 허용 목록에 있는지, 이미 처리한 이름인지, 값이 허용 범위의 정수인지 차례로 확인한다.

type(value) is not int는 이번 도구가 정수 응답만 받는다는 조건을 그대로 검사한다. Python의 True와 False는 일부 정수 검사에서 통과할 수 있으므로 여기서는 자료형을 직접 비교한다. 검사에 실패하면 ValueError로 이유를 전달하고 계산을 진행하지 않는다.

missing을 만드는 줄은 전체 영역을 순서대로 돌면서 응답에 없는 이름을 찾는다. 누락 이름도 진단표 순서로 표시된다. 누락이 없으면 검사를 통과한 사전을 반환한다. 따라서 이후 계산은 일곱 영역의 값이 모두 존재하고 범위도 맞는다는 조건에서 진행된다.

build_report는 검사를 먼저 실행하고 출력할 문장들을 lines에 모은다. 각 영역의 응답에 50을 곱해 점수로 표시하고, 원래 응답의 합계를 최대 합계와 함께 붙인다. 예제에서는 2가 두 개, 1이 세 개, 0이 두 개이므로 합계는 7이며 최대 합계는 14다.

pending에는 응답이 2보다 작은 영역만 담는다. 각 항목의 첫 값은 응답이고 두 번째 값은 enumerate가 붙인 원래 순서다. 정렬 기준을 두 값의 짝으로 지정했으므로 응답이 낮은 영역이 앞에 오고 동점이면 진단표 순서를 따른다. 영역 이름의 문자 순서에는 의존하지 않는다.

보완 대상이 없을 때는 안내 문장을 추가한다. 대상이 있으면 1부터 순위를 붙여 다음 행동을 적는다. 마지막의 "\n".join(lines)는 문장 사이에 줄바꿈을 넣어 하나의 문자열로 만든다. 계산 함수 안에서 바로 출력하지 않으므로 결과 문자열을 확인하기도 쉽다.

main은 결과를 출력하는 역할을 맡는다. 잘못된 응답이면 오류 문장을 한 번 출력하고 끝낸다. 파일 마지막의 조건은 이 파일을 직접 실행했을 때만 main을 호출한다. 외부 패키지, 현재 날짜, 임의의 값, 네트워크를 사용하지 않으므로 실행 환경의 시각이나 연결 상태가 결과를 바꾸지 않는다.

실행 결과

Python 3.12 이상이 설치된 macOS 또는 Linux에서 파일이 있는 디렉터리로 이동해 실행한다. 아래 출력은 완성 코드의 예제 응답을 바꾸지 않았을 때의 결과다.

python3 main.py

자가 진단 결과
기준: 0=미확인, 1=도움받아 수행, 2=독립 수행
언어: 100점
DB: 50점
웹: 100점
Git: 50점
CS: 0점
테스트: 0점
배포: 50점
응답 합계: 7/14
보완 우선순위
1. CS: 목록 구조를 선택한 이유를 적는다
2. 테스트: 정상 조건과 경계 조건을 검사한다
3. DB: 두 테이블의 연결 결과를 확인한다
4. Git: 작은 변경을 커밋하고 차이를 설명한다
5. 배포: 실행 명령과 필요한 설정을 기록한다

이 결과에서 CS가 먼저 나온 이유는 취업 준비에서 언제나 CS가 최우선이기 때문이 아니다. 예제 응답에서 CS와 테스트가 0이고, 진단표에서 CS가 앞에 있기 때문이다. DB·Git·배포는 모두 1이므로 원래 순서대로 이어진다. 결과를 읽을 때는 숫자 옆에 적어 둔 실제 증거를 함께 본다.

이 파일은 표준 라이브러리도 따로 불러오지 않는 작은 프로그램이다. 실행 전 문법 검사를 별도로 하려면 다음 명령을 사용할 수 있다. 정상적인 파일이면 명령은 별도 문장 없이 끝난다. 문법 검사를 통과했다는 사실은 채점 기준이 학습자의 모든 능력을 설명한다는 뜻은 아니다.

python3 -W error -m py_compile main.py

실무에서 자주 틀리는 것

누락한 응답을 0으로 바꾸기

0은 미확인 상태를 선택한 유효한 응답이다. 누락은 응답 자체를 작성하지 않은 입력 오류다. 둘을 합치면 실수로 빠뜨린 영역이 실제 진단 결과처럼 보고된다. 아래의 잘못된 코드는 두 상태를 구분하지 못한다. 조각 코드는 각각 해당 이름이 준비된 상황을 가정한다.

# 틀린 코드
score = answers.get(name, 0) * 50

# 고친 코드
if name not in answers:
    raise ValueError(f"누락 영역: {name}")
score = answers[name] * 50

완성 코드에서는 출력 전에 모든 누락을 한 번에 검사한다. 이렇게 하면 사용자가 하나를 고친 뒤 다시 실행해 다음 누락을 발견하는 반복도 줄일 수 있다.

영역 이름으로 동점을 정렬하기

점수와 이름으로 정렬하면 동점일 때 이름의 문자 순서가 기준이 된다. 오류는 아니지만 이 장에서 약속한 진단표 순서와는 다르다. 동점 규칙도 결과의 일부이므로 의도를 코드에 드러낸다.

# 틀린 코드: 동점에서 영역 이름을 사용한다
pending.sort(key=lambda item: (item[0], item[2]))

# 고친 코드: 동점에서 원래 순서를 사용한다
pending.sort(key=lambda item: (item[0], item[1]))

나중에 다른 기준을 도입한다면 코드와 설명을 함께 바꿔야 한다. 예를 들어 지원할 직무에 맞춰 순서를 바꿨다면 이전 결과와 비교할 때 그 변경 사실도 남긴다.

범위를 확인하지 않고 계산하기

입력값을 곧바로 점수로 바꾸면 3을 입력했을 때 150점이 나온다. 문자열을 넣으면 곱셈이 문자열 반복으로 처리될 수도 있다. 계산 직전의 자료형과 범위 검사가 결과의 의미를 지킨다.

# 틀린 코드
score = value * 50

# 고친 코드
if type(value) is not int or value not in (0, 1, 2):
    raise ValueError("응답은 정수 0, 1, 2만 허용한다")
score = value * 50

이 도구에서는 사용자가 응답을 코드에 직접 쓰므로 입력 실수를 발견할 경로가 필요하다. 잘못된 값을 임의로 반올림하거나 허용 범위로 끼워 맞추지 않는다.

총점으로 지원 가능 여부를 판정하기

이 진단표는 채용 결과와 연결해 검증한 척도가 아니다. 임의의 합격선을 만들면 영역별 빈칸을 찾으려는 목적이 흐려진다. 결과 문장은 관찰한 응답과 다음 확인 행동 안에서 작성한다.

# 틀린 코드
message = "지원 가능" if total >= 10 else "지원 불가"

# 고친 코드
needs_review = [
    name for name, _ in AREAS
    if answers[name] < 2
]
message = "다음 점검: " + (
    ", ".join(needs_review) if needs_review else "진단 범위 확대"
)

점수가 낮다는 이유만으로 모든 지원을 미루거나, 점수가 높다는 이유로 증거 확인을 끝내지 않는다. 지원 판단은 이후에 다루며 여기서는 현재 작업 범위만 기록한다.

한눈에 보기

현재 위치를 기록할 때 지킬 구분
기록 대상	확인할 질문	남길 내용
배운 것	과정에서 무엇을 접했는가	기술 이름과 사용한 프로젝트
한 것	내가 어떤 변경을 맡았는가	요구사항, 변경 범위, 공동 작업 경계
혼자 할 수 있는 것	작업 순서와 결과를 설명하는가	재현 코드, 실행 결과, 선택 이유
모르는 것	어디에서 설명이나 실행이 멈추는가	멈춘 지점과 다음 확인 행동

이번 주에는 일곱 영역을 모두 깊이 공부하려 하지 않는다. 대표 행동을 한 번씩 확인하고, 응답과 근거를 함께 남기는 데 집중한다. 시간이 부족해 수행하지 못한 영역은 0으로 기록하되 “시간 부족으로 미시도”라고 적는다. 이것을 이해 부족으로 단정하지 않으면서도 다음 점검에서 빠뜨리지 않을 수 있다.

이번 주에 할 일과 완료 증거
확인	이번 주에 할 일	완료 증거
□	수업에서 배운 기술과 사용한 곳을 나란히 적는다	기술별 프로젝트 사용 위치 목록
□	팀 프로젝트에서 맡은 기능 하나를 따라간다	입력·처리·저장·응답 경로 메모
□	일곱 영역의 대표 행동을 확인한다	응답, 참고한 도움, 결과를 적은 진단표
□	자가 진단 도구에 자신의 응답을 넣는다	응답이 담긴 main.py와 출력 기록
□	가장 먼저 확인할 행동 하나를 고른다	예상 결과와 확인 방법을 적은 짧은 메모

완료 증거는 기술 목록, 기여 메모, 응답 근거가 있는 진단표, 프로그램 출력이다. 출력만 저장하면 왜 그 점수를 골랐는지 나중에 알기 어렵다. 각 영역에 코드 위치나 결과 기록을 연결하고, 확인하지 못한 경우에는 그 이유를 한 줄 남긴다. 기록 날짜를 메모에 적으면 다음 점검과 비교하기 쉽고, 프로그램의 출력에는 날짜를 넣지 않아 같은 응답의 결과를 그대로 재현할 수 있다.

다음 장에서는 이 기록에서 강점을 설명할 재료를 고른다. 짧은 기간에 서비스를 완성한 경험, 팀과 조정한 경험, 이전 경력에서 이어진 관점을 말로 만들기 전에 이번 장의 경계를 먼저 확인한다. 자신이 한 일을 구체적으로 알면 강점을 과장하지 않고도 설명할 근거가 생긴다.

연습 문제

과정에서 배운 기술 세 가지를 고르고 각각 “배웠다”를 작은 확인 행동으로 바꿔라. 작업 조건, 허용할 도움, 완료 증거를 함께 적어라.
예제 응답에서 CS와 테스트를 각각 1로 바꾸고 나머지는 유지하라. 응답 합계와 보완 우선순위를 실행 전에 예상한 뒤 실제 결과와 비교하라.
DB 응답을 하나 더 추가해 중복 입력을 만들어라. 이어서 중복을 제거하고 배포 응답을 삭제하라. 두 경우에 어떤 오류가 출력되는지 확인하고, 처음부터 사전으로 응답을 작성하면 중복 발견이 어려운 이유를 설명하라.
일곱 응답을 모두 2로 바꿔라. 보완 대상이 없는 경우의 출력을 확인하고, 이것이 모든 기술을 익혔다는 뜻이 아닌 이유와 다음에 넓힐 진단 행동 하나를 적어라.

정답과 해설

예를 들어 언어는 “예약 목록에서 취소 상태를 제외하는 함수를 작성한다”, DB는 “회원과 예약 테이블을 연결해 예상한 두 행이 나오는지 확인한다”, Git은 “문구 변경 하나를 커밋하고 변경 내용을 다시 읽는다”로 바꿀 수 있다. 문법표 참고는 허용하되 완성 함수 복사는 하지 않는 식으로 도움의 경계를 적는다. 증거는 함수와 두 입력의 결과, 조회문과 결과 비교, 커밋 식별값과 변경 이유가 된다. 정답의 핵심은 기술 이름을 관찰 가능한 행동으로 바꾸는 데 있다.
응답 합계는 9/14다. 0인 영역이 없어지고 DB·Git·CS·테스트·배포가 모두 1이 된다. 따라서 보완 순서는 DB, Git, CS, 테스트, 배포다. 언어와 웹은 2이므로 보완 목록에 포함되지 않는다. 이전 실행과 순서가 달라진 이유는 응답이 바뀌었기 때문이며, 동점 처리 규칙 자체는 그대로다.
다른 항목이 유효한 상태에서 DB를 중복 추가하면 입력 오류: 중복 영역: DB가 출력된다. 중복을 제거하고 배포를 삭제하면 입력 오류: 누락 영역: 배포가 출력된다. 사전은 같은 키의 값을 하나만 보관하므로 사전을 만드는 과정에서 앞의 DB 값이 덮일 수 있다. 완성 코드는 응답 쌍을 먼저 검사해 이 정보를 잃지 않는다.
모든 영역은 100점이고 합계는 14/14다. 보완 우선순위 아래에는 보완 대상 없음: 진단 행동의 범위를 하나씩 넓힌다.가 출력된다. 이 점수는 정해 둔 대표 행동을 독립 수행했다고 응답했다는 뜻이다. 예를 들어 DB의 다음 행동을 “두 테이블 연결”에서 “연결할 행이 없는 경우의 결과 설명”으로 넓힐 수 있다. 범위가 바뀌면 새 진단으로 기록하고 이전 총점과 같은 척도처럼 비교하지 않는다.