내 코드와 자료구조 설명
55분 안팎
학습 목표
변수·함수·자료구조·실패 처리를 근거로 설명합니다.
개념
설명을 재실행 가능한 근거로 바꿉니다
인계받은 동료가 “왜 딕셔너리인가요”라고 물었을 때 “빠르기 때문입니다”로 끝내면 어떤 기능에 필요한 선택인지 알 수 없습니다. 좋은 설명은 해결할 문제, 코드 위치, 작은 입력에서 값이 바뀌는 순서, 검증 근거와 한계를 연결합니다. 신입에게 모든 내부 구현을 암기하도록 요구하기보다 자신이 맡은 작은 프로그램의 경계를 설명하도록 교육합니다. 이 레슨은 앞 레슨에서 얻은 실행 근거를 여섯 면접 질문의 답으로 정리합니다.
docs/interview.md에 트랙의 신입 질문 여섯 개를 질문 그대로 제목으로 쓰고 각 질문 아래 답안을 작성합니다. 답안마다 실제 함수 이름, 입력 사례, 연결할 테스트 이름, 그 테스트가 확인하지 않은 범위를 넣습니다. 답을 외워 적기보다 파일을 열어 호출 순서를 따라갑니다. 문서 검사기는 제목과 일정 길이의 본문, 대표 코드 표기를 확인합니다. 내용이 길다고 설명이 맞는 것은 아니므로 함수와 테스트를 사람이 읽어 대조해야 합니다.
변수는 그 시점의 역할로 설명합니다
handoff.add_saved의 path는 저장 대상 경로입니다. store는 load_store가 반환한 ID별 기록이고 status는 add_record의 검증 결과 문자열입니다. candidate는 검증 중인 임시 자료를 뜻하며 저장이 끝났다는 표시가 아닙니다. status가 OK인 시점에는 메모리 후보가 바뀌었고 save_store 성공 뒤에야 파일이 교체됩니다. “store는 데이터입니다”보다 “파일에서 읽어 추가 검증에 전달하는 ID별 후보입니다”라고 설명하면 흐름을 구분할 수 있습니다.
독서 쪽수와 구입 금액은 입력 경계에서는 문자열이고 검증 이후에는 정수입니다. 사용자에게 받은 ‘7’과 JSON에 저장된 7은 자료형이 다릅니다. parsing.parse_cost가 허용한 값을 records.add_record가 기록에 넣습니다. 함수를 설명할 때 매개변수의 종류와 반환 상태를 분리합니다. print는 화면 출력이며 return은 호출자에게 결과를 돌려줍니다. store.add_record는 상태를 반환하고 CLI는 그 값을 표시하는 역할을 맡습니다.
함수 호출과 데이터 흐름을 함께 그립니다
정상 한 건 추가는 load_store → store.add_record → records.add_record → parsing 검사 → save_store 순서로 따라갑니다. 같은 add_record 이름이 두 파일에 있으므로 파일 이름까지 말합니다. store.py는 ID 검증과 중복 확인을 담당하고 records.py는 제목·쪽수·금액·완료 여부를 담당합니다. import 별칭 validate_and_append를 보면 두 책임이 어떻게 연결되는지 알 수 있습니다. 같은 이름이 헷갈린다고 이미 검증된 함수를 새로 복사하지 않습니다.
중복 ID는 제목 검사보다 먼저 확인됩니다. 중복 b01과 빈 제목을 동시에 주면 ERR_DUPLICATE_ID가 나옵니다. 이는 실패 우선순위가 코드 순서에 의해 정해진 예입니다. 답안에는 정상 입력 한 건뿐 아니라 조건이 겹치는 사례도 연결하면 판단 근거가 드러납니다. 잘못된 입력을 만나면 후보를 저장하지 않고 현재 상태를 반환합니다. CSV에서 발생한 ValueError는 파일 CLI가 ERR_FILE|ValueError와 종료 코드 2로 요약하므로 함수 내부 예외와 외부 표시를 구분합니다.
자료구조 선택에는 사용 목적을 붙입니다
store.py의 저장소는 ID를 키로 기록을 찾는 딕셔너리입니다. 제목이 같은 서로 다른 책을 허용할 수 있으므로 제목을 키로 쓰지 않습니다. list_records는 출력과 저장에 쓸 목록을 만들며 공개 보고서는 SQL ORDER BY id로 순서를 정합니다. 기록 입력 순서와 보고서 정렬 순서는 별개의 요구입니다. 딕셔너리가 모든 작업에서 리스트보다 낫다는 설명 대신 ID 조회와 순서 있는 출력에 각각 어떤 형태를 썼는지 말합니다.
find_record는 record.copy를 반환합니다. 이는 저장소 내부 객체를 그대로 수정하는 실수를 줄이려는 얕은 복사입니다. 현재 기록 필드는 문자열과 정수라 이 선택이 요구에 맞습니다. 나중에 태그 목록 같은 중첩 자료가 들어오면 얕은 복사만으로 내부 목록의 공유가 사라지지 않습니다. 지금 없는 기능을 이미 안전하다고 주장하지 않고 스키마가 바뀌면 복사 계약도 다시 검사해야 한다고 적습니다. 기존 tests/test_store.py와 현재 필드 목록이 이 판단의 근거입니다.
메모리와 디스크의 경계를 사례로 답합니다
한 프로세스의 딕셔너리는 프로그램 실행이 끝나면 다음 실행의 초기 값으로 자동 이어지지 않습니다. JSON 저장을 성공시킨 뒤 다른 프로세스에서 load_store로 읽어야 기록이 이어집니다. 최종 흐름 테스트는 같은 메모리 객체를 조회하는 대신 subprocess로 file_cli.py lookup을 실행합니다. 이 선택을 설명하면 단순히 “디스크는 오래 남습니다”라는 말보다 저장 호출 누락을 어떻게 발견했는지 보여 줄 수 있습니다.
save_store는 같은 부모 폴더의 임시 파일을 작성하고 대상 경로를 교체합니다. read_csv는 전체 입력 검증이 끝난 후보만 넘깁니다. 이런 구현은 이번 입력 실패 때 부분 저장을 피하려는 근거입니다. 동시 사용자 갱신 충돌이나 정전 이후 내구성까지 해결했다는 뜻은 아닙니다. 파일 바이트 보존 테스트는 준비한 실패 입력의 결과를 확인합니다. 운영 수준의 트랜잭션이라고 이름 붙이기보다 단일 사용자 파일 프로젝트의 제한을 정확히 설명합니다.
경로와 통신 질문은 관찰 위치를 명시합니다
경로 오류 질문에는 현재 작업 디렉터리 확인, 명령 인자의 상대 경로 해석, 파일 존재와 철자, traceback의 실패 지점이라는 순서를 적습니다. file_cli.py의 사용자 인자는 작업 디렉터리 기준이고 reporting.py의 기본 SQL은 파일 위치 기준입니다. 오류를 해결하려고 자신의 절대 홈 경로를 코드에 박아 넣으면 다른 컴퓨터에서 다시 실패합니다. tests/test_cli.py의 다른 작업 위치 실행과 clean_run.py의 새 폴더 검사를 답안에 연결합니다.
주소부터 HTTP 응답까지 질문에는 DNS·IP·HTTP 역할을 분리합니다. 이름을 주소로 찾는 과정과 목적지 주소로 연결하는 과정, HTTP 요청과 응답의 상태를 구분합니다. 로컬 실습은 127.0.0.1을 직접 사용하므로 외부 DNS 조회를 관찰했다는 답을 쓰지 않습니다. GET /report.json의 상태 200, /missing의 404, 의도적 오류 경로의 500은 응답을 받은 사례입니다. 연결 자체가 실패한 경우에는 HTTP 상태가 없다는 점을 함께 설명합니다.
자동 테스트의 응답 검사는 브라우저 개발자 도구를 직접 관찰한 증거와 다릅니다. docs/demo.md에는 자동 HTTP 검사 수행 여부와 브라우저 관찰 수행 여부를 별도로 적습니다. 사람이 확인할 때 요청 방법, 경로, 상태, Content-Type, 응답 필드를 같은 요청에서 읽습니다. 실패 응답의 본문을 성공 보고서로 처리하지 않는 이유도 설명합니다. 수행하지 않은 단계는 미수행으로 남기고 이전 모듈의 문서를 읽었다는 사실을 관찰 완료로 바꾸지 않습니다.
면접 답안은 짧은 주장과 증거로 구성합니다
여섯 질문은 경로 오류, 메모리·디스크, 지출의 잘못된 입력, 딕셔너리 선택, HTTP 흐름, 다른 사람의 실행 준비입니다. 각 답을 첫 문장으로 요약한 뒤 함수나 명령 하나를 근거로 들고 입력 사례를 설명합니다. 마지막에는 제한 한 가지를 덧붙입니다. 예를 들어 문자 금액을 0으로 바꾸지 않는 이유는 실제 0원과 입력 오류를 구분하기 위해서입니다. 근거는 parse_cost와 실패 후 바이트 보존 테스트로 연결합니다.
설명 중 함수 이름이나 오류 문자열이 실제 파일과 다르면 먼저 코드를 다시 확인합니다. AI가 작성한 설명이든 자신의 오래된 메모든 같은 기준을 적용합니다. 설명에서 확신이 없는 부분은 질문으로 남기고 작은 입력을 실행하여 해결합니다. 동료에게 답안을 읽게 할 때 “이해했나요”보다 “이 입력이 어디서 거절되나요”처럼 추적 가능한 질문을 줍니다. 이 레슨의 제출물은 여섯 답과 근거 목록이며 일반적인 코드 읽기 방법은 더 읽기로 이어갑니다.
따라하기
질문의 근거 위치 정하기
docs/interview.md를 열어 질문별 함수·입력·테스트·한계 네 항목을 적습니다. 첫 질문에는 작업 디렉터리와 코드 자원 경로의 차이를 씁니다.
상태 반환과 화면 출력 구별
함수의 반환값을 받은 뒤 화면에 표시하는 흐름을 분리해 읽습니다. 실제 프로그램에서 상태를 반환하는 것은 store.add_record이고 file_cli.py는 화면 출력과 종료 코드를 담당합니다.
def validate_title(raw):
return "ERR_TITLE" if not raw.strip() else "OK"
status = validate_title(" ")
print("returned", status)
print("may_save", status == "OK")실행 결과
returned ERR_TITLE may_save False
얕은 복사의 현재 계약 확인
문자열·정수 필드의 복사본을 수정해도 원본 정수는 바뀌지 않습니다. 중첩 필드를 추가하면 별도 검증이 필요하다는 제한을 답안에 붙입니다.
record = {"id": "b01", "pages": 7}
copy = record.copy()
copy["pages"] = 99
print("original", record["pages"])
print("copy", copy["pages"])실행 결과
original 7 copy 99
여섯 답을 동료 질문으로 점검
제목 여섯 개 아래 자신의 답을 완성합니다. 동료에게 중복 ID와 빈 제목을 함께 주면 어느 오류가 먼저 나오는지 물어보고 store.py의 조건 순서와 비교합니다. 미수행 검토는 완료라고 표시하지 않습니다.
확인 문제
실습
docs/interview.md에 신입 질문 여섯 개를 그대로 제목으로 적고 각 답에 함수 위치·입력 사례·검증 근거·한계를 연결합니다. 동료가 실제 코드에서 그 근거를 찾을 수 있어야 합니다. 자동 형식 검사와 설명의 사실 확인을 구분합니다.
더 읽기
면접 질문
- 리스트 대신 딕셔너리를 선택하는 사례를 설명합니다.
- 지출 합계 프로그램의 잘못된 입력 처리 방식을 설명합니다.
- 주소 입력부터 HTTP 응답까지의 흐름을 설명합니다.