입사 후 첫 90일 - 코드 읽기·작은 수정·질문하는 법

이 장에서 배우는 것

앞 장에서 지원 기록을 남기고 면접에서 얻은 정보를 다음 행동으로 바꾸었다. 입사 뒤에도 이 방식은 이어진다. 다만 이제는 개인의 취업 준비가 아니라 동료와 함께 유지하는 서비스가 기준이 된다. 첫 90일의 목표는 코드를 많이 바꾸는 일이 아니다. 업무가 들어와서 사용자에게 전달되는 흐름을 이해하고, 범위를 합의한 수정을 검증하며, 모르는 내용을 동료가 답할 수 있는 질문으로 바꾸는 일이다.

국비 과정에서 정해진 기간 안에 서비스를 완성하고 팀원과 역할을 나눈 경험은 이 과정의 바탕이 된다. 이전 직장에서 고객 요청을 정리하거나 인수인계를 해 본 경험도 도움이 된다. 여기에 사내 규칙과 운영 환경을 하나씩 붙이면 된다. 이 장에서는 주간 업무 일지를 입력 자료로 삼아 배운 것, 막힌 것, 다음 주 목표를 출력하는 작은 Python 도구를 만든다.

• 처음 맡은 업무의 요청 배경, 완료 조건, 검증 방법을 확인한다.
• 사내 코드를 사용자 동작과 연결해 읽고 작은 수정 단위를 정한다.
• 시도한 내용과 필요한 판단을 포함해 질문하고 검토 의견을 반영한다.
• 운영 장애의 사실과 추정을 구분하고, 업무 기록에서 다음 학습 주제를 고른다.
• 업무 일지의 중복을 정리해 주간 요약과 완료 증거를 남긴다.

문제 상황

입사 둘째 주에 “주문 목록에서 취소된 주문을 숨겨 달라”는 일을 받았다고 하자. 화면에서 배열을 걸러 내면 될 것 같지만 저장소를 열어 보니 목록 화면, 요청 처리 코드, 조회 조건이 여러 곳에 흩어져 있다. 취소된 주문을 숨겨야 하는 사용자 범위도 분명하지 않다. 고객 화면과 운영 화면이 같은 조회 함수를 쓰는지도 아직 모른다.

여기서 바로 수정하면 화면에서는 사라졌지만 전체 건수에는 포함되는 문제가 생길 수 있다. 반대로 모든 파일을 이해할 때까지 읽기만 하면 질문할 시점과 작업 범위를 놓친다. 먼저 요청자에게 어느 화면에 적용하는지, 취소 이력을 볼 다른 경로가 있는지, 목록 건수도 함께 달라져야 하는지 확인해야 한다. 답을 얻은 뒤 해당 요청이 지나가는 코드만 따라가면 읽을 범위가 줄어든다.

금요일에 주간 공유를 하려는데 “코드를 읽었다”, “조회 조건을 수정했다”만 적혀 있어도 문제가 된다. 무엇을 이해했고, 어떤 조건은 아직 확인하지 못했으며, 다음에 누가 무엇을 판단해야 하는지가 보이지 않는다. 일지는 일한 시간을 증명하는 장식이 아니라 다음 행동을 이어 주는 기록이어야 한다.

첫 90일에는 업무의 흐름부터 익힌다

처음 맡는 일은 보통 요청 확인, 재현 또는 현행 동작 확인, 코드 탐색, 변경 범위 합의, 수정과 검증, 코드 리뷰(code review), 반영과 확인의 순서로 진행된다. 실제 조직에서는 담당자와 배포 절차가 다르므로 입사 첫 주에 팀의 방식을 확인한다. 저장소 접근 권한이 있다는 사실만으로 운영 데이터 변경이나 서비스 배포까지 맡았다고 해석하지 않는다.

요청을 받으면 먼저 완료 조건을 한두 문장으로 적는다. 예를 들어 “고객 주문 목록과 전체 건수에서 취소 상태를 제외하고, 운영 화면의 취소 이력 조회는 유지한다”라고 적을 수 있다. 이어서 확인할 사례를 붙인다. 취소 주문만 있는 고객, 정상 주문과 섞여 있는 고객, 주문이 없는 고객을 확인하면 이번 변경의 경계가 드러난다. 이 조건은 요청자나 업무 담당자와 맞춘다.

첫 30일에는 개발 환경을 실행하고, 작은 요청 하나가 지나가는 경로를 설명하는 데 무게를 둔다. 다음 30일에는 합의한 작은 변경을 검증과 검토까지 이어 본다. 마지막 30일에는 비슷한 업무의 범위를 스스로 제안하고, 반영 뒤 확인과 후속 기록을 챙긴다. 이 구분은 능력을 판정하는 마감표가 아니다. 업무 배정과 접근 권한에 따라 달라지는 점검 기준이다.

주 단위로는 하나의 작고 확인 가능한 결과를 고른다. 아직 수정 권한이 없다면 요청 경로 설명이나 재현 절차도 결과가 된다. 권한 밖의 일을 억지로 실행하기보다, 막힌 이유와 필요한 도움을 기록해 다음 주 계획을 조정한다.

이번 주에 할 일과 완료 증거

확인	이번 주에 할 일	완료 증거	확인받을 대상
□	맡은 요청의 대상과 완료 조건을 적는다.	적용 화면과 제외 범위가 적힌 업무 메모	업무 담당자
□	요청 하나의 실행 경로를 읽는다.	진입점부터 저장소까지 이어지는 경로 메모	해당 코드 담당자
□	작은 변경 하나를 검증하고 검토를 요청한다.	변경 이유, 검증 결과, 검토 요청 기록	검토 동료
□	막힌 항목과 학습 주제 하나를 고른다.	구체적인 질문과 다음 주 확인 방법	도움을 줄 동료
□	업무 일지를 요약한다.	주간 요약과 근거 기록의 위치	자신과 업무 공유 대상

코드는 한 요청의 경로를 따라 읽고 작게 바꾼다

실행 방법과 진입점을 먼저 찾는다

저장소를 처음부터 파일 순서대로 읽지 않는다. 먼저 실행 안내, 프로젝트 설정, 테스트 실행 방법, 환경 설정의 예시를 읽는다. 실제 비밀 값은 개인 메모나 예제 파일로 복사하지 않는다. 로컬 환경에서 실행되는 범위와 별도 승인이 필요한 연결을 구분한다. 안내와 실제 동작이 다르면 어느 명령에서 어떤 결과가 나왔는지 남긴다.

그다음 맡은 화면이나 요청의 진입점을 찾는다. Java 기반 서비스라면 요청을 받는 메서드에서 업무 처리와 데이터 접근 부분으로 이동할 수 있다. JavaScript 기반 화면이라면 사용자 동작을 받는 함수에서 요청 함수와 응답 처리로 이어질 수 있다. 이름만 보고 역할을 확정하지 말고 호출 관계, 전달 값, 반환 값, 관련 테스트를 함께 확인한다.

읽는 동안 질문을 세 가지로 좁힌다. “무엇이 들어오는가”, “어디에서 판단하거나 상태를 바꾸는가”, “무엇이 나가는가”다. 모든 보조 함수를 즉시 분석할 필요는 없다. 현재 요청과 무관한 부분은 위치와 궁금한 점만 적어 두고 돌아온다. 그 결과로 함수 이름 목록보다 입력, 판단 조건, 결과가 이어지는 짧은 설명을 남긴다.

변경의 크기는 검토 가능한 이유로 정한다

작은 수정은 줄 수가 적다는 뜻만은 아니다. 하나의 변경 이유를 설명하고 검증할 수 있다는 뜻이다. 취소 주문 제외가 목적이라면 주변 변수 이름 정리와 공통 조회 구조 개편을 함께 넣지 않는다. 읽다가 발견한 개선점은 별도 기록으로 남겨 우선순위를 상의한다. 기존 구조를 유지하는 편이 나은지 바꾸는 편이 나은지도 현재 요구와 검증 비용을 근거로 판단한다.

수정 전에는 기존 동작을 확인하고, 수정 후에는 바뀌어야 하는 사례와 유지되어야 하는 사례를 확인한다. 목록에서 항목이 빠졌다면 전체 건수와 페이지 이동도 살핀다. 테스트가 없는 영역이라면 팀과 확인 방식을 정하고, 실행한 절차와 실제 결과를 구체적으로 적는다. 자동 테스트가 통과했다는 사실과 운영 환경에서 확인했다는 사실은 구분해 쓴다.

검토 요청에는 변경 이유, 적용 범위, 검증한 사례, 아직 확인하지 못한 조건을 넣는다. 의견을 받으면 먼저 상대가 우려하는 동작을 이해한다. 수정한 위치와 재검증 결과를 답하고, 다른 의견이 있으면 요구 조건이나 실행 결과로 설명한다. 검토 과정에서 배운 팀 규칙은 다음 변경의 점검 항목으로 옮긴다.

질문과 운영 기록에서 다음 공부를 고른다

질문에는 답변에 필요한 맥락을 넣는다

“이 코드가 이해되지 않는다”보다 “고객 주문 목록에서 취소 상태를 제외하려 한다. 조회 함수 두 곳을 확인했는데 운영 화면도 같은 함수를 호출한다. 고객용 조건을 호출부에서 넘기는 방식이 팀 규칙에 맞는지 판단이 필요하다”가 답하기 쉽다. 목적, 확인한 범위, 관찰한 결과, 필요한 판단이 들어 있기 때문이다.

질문하기 전 탐색 시간은 업무의 긴급도와 팀의 응답 방식에 맞춰 정한다. 막힌 채 계속 기다리거나 같은 시도를 반복하는 대신, 합의한 시점에 현재까지의 사실을 공유한다. 일정이나 다른 사람의 작업에 영향을 주는 막힘은 일찍 알린다. 질문을 보낸 뒤 답을 기다리는 동안 할 수 있는 검증이나 문서 정리가 있으면 이어 간다.

질문에는 관련 코드 위치와 필요한 만큼의 오류 내용을 붙인다. 비밀번호, 인증 값, 고객 정보는 제거하고 사내에서 허용한 경로를 사용한다. 답을 얻으면 결론과 이유를 업무 기록에 남긴다. 같은 질문을 다시 찾을 수 있게 만드는 일도 협업의 일부다.

운영 장애는 사실과 추정을 나누어 기록한다

운영 장애를 발견하면 팀의 보고와 대응 절차를 먼저 따른다. 신입이 혼자 원인을 확정하거나 운영 상태를 바꾸는 것이 목표가 아니다. 언제 어떤 증상이 보였고, 어느 범위에 영향이 확인되었는지 전달하는 일부터 할 수 있다. 확인한 오류 기록의 시각과 기준 시간대도 함께 적으면 사건의 순서를 맞추는 데 도움이 된다.

기록에는 관찰 사실, 아직 검증하지 않은 가설, 수행한 조치와 담당자, 조치 뒤 결과, 후속 확인을 나누어 적는다. “배포 뒤 오류가 보였다”는 시간상 관찰이고 “배포가 오류를 일으켰다”는 원인 판단이다. 두 문장을 같은 의미로 쓰지 않는다. 모르는 영향 범위는 모른다고 적고, 판단 근거가 추가되면 기록을 갱신한다.

이 장의 요약 도구에는 장애 원문을 넣지 않는다. “장애 기록에서 사실과 추정을 나누는 법을 배움”처럼 학습 내용만 적는다. 상세 사건 기록과 증거는 접근 권한과 보존 규칙을 갖춘 사내 위치에 남긴다. 학습용 요약이 공식 장애 기록을 대신하지는 않는다.

이번 업무를 설명하는 데 필요한 것부터 공부한다

공부할 목록은 막힌 항목에서 고른다. 반복해서 막혔는지, 다음 업무에 필요한지, 혼자 확인할 수 있는 크기인지 살핀다. 다음 주 목표는 “데이터베이스 공부”보다 “현재 조회 조건을 설명하고 로컬 실행 결과로 확인하기”처럼 끝을 판단할 수 있게 적는다. 학습을 마치면 업무 설명이나 검증 절차가 어떻게 달라졌는지 남긴다.

조회와 잠금이 막혔다면 《데이터베이스 개론》과 SQL 연구소에서 해당 개념을 확인하고, 사내 데이터 대신 작은 가상 테이블로 실험한다. 자료구조나 처리 비용을 설명하기 어렵다면 《논리로 푸는 알고리즘》과 코드패스의 관련 학습을 활용한다. 요청 흐름, 프로세스, 네트워크의 연결이 흐릿하면 《개발자를 위한 컴퓨터 사이언스》와 《비전공자를 위한 컴퓨터공학 지도》에서 필요한 주제를 골라 읽는다.

변경 범위를 나누는 데는 《클린 코드 노하우》를, 검토 요청과 의견 반영을 정리하는 데는 《코드 리뷰 실무》를 연결한다. 《개발자 실무 면접》은 이제 질문에 대비한 암기보다, 자신이 한 결정을 근거와 함께 설명하는 연습에 쓴다. 여러 자료를 동시에 끝내려 하지 말고 이번 업무의 질문 하나에 필요한 부분을 읽고 설명으로 돌아온다.

완성 코드

다음 내용을 main.py로 저장한다. 입력 자료는 파일 안의 WEEKLY_LOG다. 실행 중 입력을 기다리지 않으며 외부 파일이나 네트워크를 사용하지 않는다. 각 항목에는 배운 것, 막힌 것, 다음 주 목표를 한 문장씩 적는다. 할 말이 없는 칸은 빈 문자열로 둔다. 이 예제의 문장은 모두 가상의 업무 기록이다.

도구는 필수 키와 문자열 자료형을 확인하고, 앞뒤 및 반복 공백을 정리한다. 같은 분류에 같은 문장이 반복되면 처음 나온 한 번만 남긴다. 문장의 뜻이 비슷한지는 판정하지 않는다. 목표의 적절성이나 실제 업무 완료 여부도 자동으로 판단하지 않는다.

FIELDS = (
    ("learned", "배운 것"),
    ("blocked", "막힌 것"),
    ("next_goal", "다음 주 목표"),
)

WEEKLY_LOG = [
    {
        "learned": "주문 조회의 요청 처리와 저장소 경로를 설명함",
        "blocked": "취소 주문의 노출 범위를 확인하지 못함",
        "next_goal": "담당자와 노출 조건을 합의하고 검증 사례를 남김",
    },
    {
        "learned": "검토 요청에 변경 이유와 검증 결과를 함께 적음",
        "blocked": "",
        "next_goal": "검토 의견을 반영하고 재검증 결과를 남김",
    },
    {
        "learned": "  주문 조회의 요청 처리와 저장소 경로를 설명함  ",
        "blocked": "취소 주문의 노출 범위를 확인하지 못함",
        "next_goal": "",
    },
]


def summarize(entries):
    summary = {key: [] for key, _ in FIELDS}
    seen = {key: set() for key, _ in FIELDS}
    for number, entry in enumerate(entries, start=1):
        if not isinstance(entry, dict):
            raise ValueError(f"{number}번째 기록은 사전이어야 한다.")
        for key, _ in FIELDS:
            if key not in entry:
                raise ValueError(f"{number}번째 기록에 {key} 키가 없다.")
            value = entry[key]
            if not isinstance(value, str):
                raise ValueError(f"{number}번째 기록의 {key} 값은 문자열이어야 한다.")
            cleaned = " ".join(value.split())
            if cleaned and cleaned not in seen[key]:
                summary[key].append(cleaned)
                seen[key].add(cleaned)
    return summary


def render(summary):
    lines = ["주간 업무 요약"]
    for key, label in FIELDS:
        lines.append(f"[{label}]")
        items = summary[key]
        if items:
            lines.extend(f"- {item}" for item in items)
        else:
            lines.append("- 기록 없음")
    return "\n".join(lines)


def main():
    try:
        summary = summarize(WEEKLY_LOG)
    except ValueError as error:
        print(f"입력 오류: {error}")
        return
    print(render(summary))


if __name__ == "__main__":
    main()

줄별 해설

빈 줄도 포함해 위 코드의 줄을 센다. 1~5행의 FIELDS는 내부 키와 출력 제목을 짝지은 튜플이다. 이 순서를 입력 검증과 출력에 함께 사용한다. 출력할 분류를 집합으로 만들지 않았으므로 실행할 때마다 배운 것, 막힌 것, 다음 주 목표의 순서가 유지된다.

7~23행의 WEEKLY_LOG는 사전 세 개를 담은 목록이다. 한 사전은 한 번의 업무 기록이다. 실제로 사용할 때는 하루 단위나 작업 단위 중 팀의 공유 방식에 맞는 기준을 정한다. 세 번째 기록에는 중복 문장과 앞뒤 공백을 의도적으로 넣었다. 비어 있는 칸과 빠진 키는 다르다. 빈 문자열은 내용이 없다는 표시이고, 키 누락은 입력 구조가 맞지 않는 상태다.

26~28행은 요약 함수를 정의하고 분류별 결과 목록과 중복 확인용 집합을 만든다. 결과는 목록에 저장하므로 첫 등장 순서를 보존한다. 집합은 문장이 이미 등장했는지 확인하는 용도로만 쓴다. 입력의 사전을 직접 고치지 않아 원래 기록과 요약을 비교할 수 있다.

29~37행은 기록을 하나씩 검사한다. enumerate의 시작 번호를 1로 지정해 오류 메시지가 사람이 세는 기록 순서와 맞도록 했다. 사전인지 먼저 확인한 뒤 필수 키와 값의 자료형을 검사한다. 숫자나 None을 무조건 문자열로 바꾸면 잘못된 입력이 정상 문장처럼 섞일 수 있으므로 오류로 알린다.

38행의 split은 구분자를 생략했으므로 연속 공백이나 줄바꿈을 기준으로 단어를 나눈다. join은 그 사이를 공백 하나로 연결한다. 업무 요약 문장의 공백을 맞추려는 처리다. 들여쓰기 자체가 의미를 갖는 소스 코드나 장애 기록 원문에는 이 처리를 그대로 적용하지 않는다.

39~42행은 정리한 문장이 비어 있지 않고 해당 분류에서 처음 등장했을 때만 추가한다. 같은 문장이 다른 분류에 있으면 각각 남긴다. 마지막에 모든 검사를 마친 요약을 반환한다. 중간 기록에서 오류가 나면 요약 결과를 반환하지 않는다.

45~54행은 요약 자료를 출력 문자열로 만든다. 분류에 항목이 없으면 “기록 없음”을 넣는다. 이는 문제가 없다는 판정이 아니라 기록된 문장이 없다는 뜻이다. 마지막 join은 줄 사이에 줄바꿈을 넣고, 마지막 줄 뒤에는 줄바꿈을 추가하지 않는다. 실제 화면의 마지막 줄바꿈은 63행의 print가 붙인다.

57~67행은 실행을 묶는다. 입력 검증에서 발생한 ValueError만 받아 설명을 출력하고 함수를 끝낸다. 다른 프로그래밍 오류까지 한꺼번에 감추지 않는다. 마지막 조건문은 이 파일을 직접 실행했을 때 main을 호출한다. 다른 파일에서 함수를 가져오는 경우에는 예제 출력이 자동으로 실행되지 않는다.

실행 결과

macOS나 Linux의 터미널에서 main.py가 있는 디렉터리로 이동해 실행한다. Python 3.12 이상에서 다음 명령과 결과를 확인한다. 세 번째 기록의 중복 문장은 제거되고, 서로 다른 문장은 입력 순서대로 남는다.

python3 main.py
주간 업무 요약
[배운 것]
- 주문 조회의 요청 처리와 저장소 경로를 설명함
- 검토 요청에 변경 이유와 검증 결과를 함께 적음
[막힌 것]
- 취소 주문의 노출 범위를 확인하지 못함
[다음 주 목표]
- 담당자와 노출 조건을 합의하고 검증 사례를 남김
- 검토 의견을 반영하고 재검증 결과를 남김

실제 주간 공유에서는 이 결과에 업무 기록과 검증 결과의 사내 위치를 연결한다. 출력에 “검증 결과를 남김”이라고 적었다고 해서 증거가 생기는 것은 아니다. 목표를 완료한 뒤에는 어떤 사례를 실행했고 무엇을 관찰했는지 별도 기록으로 확인할 수 있어야 한다. 요약 문장과 완료 증거가 연결되는지 사람이 점검한다.

실무에서 자주 틀리는 것

집합을 바로 출력해 순서를 잃는다

중복을 없애려고 목록을 집합으로 바꾸면 첫 등장 순서를 출력 규칙으로 삼을 수 없다. 주간 기록은 같은 입력에 같은 순서로 나와야 비교하기 쉽다. 다음 조각은 items에 문자열 목록이 들어 있다고 가정한다.

틀린 코드다.

unique = set(items)
for item in unique:
    print(item)

고친 코드다. 집합은 확인에만 쓰고, 출력용 목록을 따로 둔다.

unique = []
seen = set()
for item in items:
    if item not in seen:
        unique.append(item)
        seen.add(item)
for item in unique:
    print(item)

필수 키 누락을 빈 기록으로 숨긴다

선택 항목이라면 기본값이 유용하지만, 이 도구의 세 키는 필수다. 키 이름을 잘못 쓴 상태를 빈 문자열로 처리하면 작성자가 실수를 알아차리기 어렵다. 다음 조각의 entry는 사전이라고 가정한다.

틀린 코드다.

value = entry.get("learned", "")

고친 코드다. 구조 오류와 의도한 빈 값을 구분한다.

if "learned" not in entry:
    raise ValueError("learned 키가 없다.")
value = entry["learned"]
if not isinstance(value, str):
    raise ValueError("learned 값은 문자열이어야 한다.")

막힌 기록이 없다는 이유로 진행이 순조롭다고 판단한다

기록의 부재는 업무 상태의 근거가 되지 않는다. 작성하지 않았거나 질문을 미뤘을 수도 있다. 도구는 관찰한 자료의 범위 안에서만 표현해야 한다. 다음 조각의 blocked는 막힌 문장들의 목록이다.

틀린 코드다.

if not blocked:
    print("업무가 순조롭게 진행됨")

고친 코드다. 업무 판단은 실제 담당자와 확인한다.

if not blocked:
    print("막힌 것: 기록 없음")

질문을 이해할 수 없는 짧은 꼬리표로 남긴다

“조회 안 됨”만 남기면 다음 주의 자신도 무엇을 확인해야 하는지 다시 조사해야 한다. 동료가 필요한 판단을 할 수 있도록 목적과 관찰 범위를 기록한다. 실제 오류나 고객 정보 전체를 붙이는 것으로 맥락 설명을 대신하지 않는다.

틀린 코드다.

entry = {
    "blocked": "조회 안 됨",
}

고친 코드다. 문장이 길어지면 상세 근거는 사내 업무 기록에 나누어 둔다.

entry = {
    "blocked": (
        "고객 목록에서 취소 주문을 제외하려 함. "
        "공용 조회 함수의 사용처를 확인했으며 "
        "운영 화면에도 적용할지 담당자 판단이 필요함"
    ),
}

한눈에 보기

첫 90일의 행동을 결과와 증거로 연결하는 기준

주제	행동	남길 증거	주의할 경계
업무 시작	대상, 완료 조건, 제외 범위를 맞춘다.	합의한 조건과 확인 사례	요청 문장만으로 적용 범위를 추정하지 않는다.
코드 읽기	진입점에서 입력과 결과를 따라간다.	요청 경로와 판단 조건 메모	전체 저장소 이해를 시작 조건으로 삼지 않는다.
작은 수정	하나의 이유로 바꾸고 전후를 확인한다.	변경 내역과 검증 결과	관련 없는 구조 변경을 섞지 않는다.
검토와 질문	목적, 시도, 관찰, 필요한 판단을 전한다.	질문과 결론, 반영 결과	막힘을 공유할 시점을 놓치지 않는다.
운영 장애	팀 절차에 따라 사실과 추정을 나눈다.	시각, 영향, 조치, 후속 확인	관찰 순서만으로 원인을 확정하지 않는다.
계속 공부하기	업무에서 막힌 주제 하나를 고른다.	설명과 작은 실험 결과	자료를 읽은 양을 업무 완료로 바꾸어 쓰지 않는다.
주간 요약	중복을 정리하고 다음 행동을 적는다.	요약과 연결된 근거 기록	기록 없음과 문제 없음을 구분한다.

입사 후의 성장은 읽은 파일 수나 작성한 줄 수만으로 설명하기 어렵다. 이전에는 혼자 막혔던 지점을 이제 질문으로 정리할 수 있는지, 변경의 영향을 더 구체적으로 설명하는지, 검증과 후속 확인을 챙기는지가 실제 변화다. 첫 90일이 끝날 때는 이 기록을 동료와 함께 살펴보고 다음 업무에서 맡을 범위를 정한다. 수료 뒤 시작한 주간 계획은 이렇게 실제 업무를 배우는 습관으로 이어진다.

연습 문제

1. WEEKLY_LOG를 빈 목록으로 바꾸었을 때의 출력을 쓰라. 이 결과만으로 업무가 없었다고 판단할 수 있는지도 설명하라.
2. 첫 번째 기록에서 blocked 키를 삭제했을 때의 출력을 쓰라. 앞에서 읽은 learned 문장이 부분 요약으로 출력되는지도 설명하라.
3. 다음 주 목표에 같은 문장이 두 번 들어오되 한쪽에만 반복 공백이 있다. summarize가 이를 어떻게 처리하는지 설명하라. 뜻은 같고 표현만 다른 문장도 합쳐지는지 답하라.
4. “배포 후 일부 요청에서 오류가 발생했다. 배포가 원인이다”라는 메모를 사실, 가설, 후속 확인으로 나누라. 이어서 다음 주에 확인할 목표 한 문장과 완료 증거를 적으라.

정답과 해설

1. 세 분류가 모두 빈 목록이므로 다음과 같이 출력된다. 입력 기록이 없다는 뜻이며, 업무가 없었거나 문제가 없었다고 판단할 근거는 아니다.

   주간 업무 요약
   [배운 것]
   - 기록 없음
   [막힌 것]
   - 기록 없음
   [다음 주 목표]
   - 기록 없음
   

2. 출력은 다음 한 줄이다. summarize 내부 목록에 learned 문장이 일시적으로 추가되더라도 함수가 끝까지 실행되어 반환되지 않는다. main은 입력 오류를 처리한 뒤 돌아가므로 부분 요약은 출력되지 않는다.

   입력 오류: 1번째 기록에 blocked 키가 없다.
   

3. 각 문자열은 split과 join을 거치므로 반복 공백이 공백 하나로 바뀐다. 정리한 문자열이 같으면 해당 분류에서 처음 등장한 한 번만 남는다. 다른 분류의 문장은 별도로 처리한다. “노출 조건 합의”와 “표시할 상태를 담당자와 결정”처럼 뜻이 비슷해도 문자열이 다르면 둘 다 남는다. 의미상 중복은 작성자가 검토한다.

4. 사실은 “배포 뒤 일부 요청에서 오류가 관찰되었다”다. 어떤 요청에서 언제 확인했는지 근거를 보충한다. 가설은 “배포 변경이 오류에 영향을 주었을 수 있다”다. 후속 확인은 담당자와 변경 내역, 오류 발생 시각, 해당 요청의 기록을 대조하는 일이다. 다음 주 목표는 “담당자와 오류 요청의 공통 조건을 확인하고 근거와 미확인 범위를 기록한다”로 정할 수 있다. 완료 증거는 확인한 요청 범위, 대조한 기록, 담당자와 합의한 판단이 담긴 사내 업무 기록이다. 운영 환경에서 추가 조치가 필요하면 팀의 대응 절차를 따른다.