면접 - 프로젝트 질문과 CS 질문에 답하는 구조

이 장에서 배우는 것

앞 장에서 이력서와 포트폴리오에 적은 결정과 기여는 면접 답변의 재료가 된다. 문서에는 “예약 기능 구현”이라고 짧게 적었더라도, 면접에서는 어떤 문제를 맡았고 왜 그렇게 구현했으며 어디까지 확인했는지를 설명해야 한다. 답변의 목적은 프로젝트를 크게 보이게 만드는 데 있지 않다. 자신이 한 일과 아는 범위를 상대가 확인할 수 있게 만드는 데 있다.

이 장에서는 팀 프로젝트로 만든 공간 예약 서비스를 예로 삼는다. Java와 Spring으로 서버를 만들고 JavaScript로 예약 화면을 연결했으며 SQL로 예약 정보를 저장했다고 가정한다. 다른 주제의 프로젝트를 했다면 예약을 주문, 게시글, 일정 등 자신이 구현한 기능으로 바꾸면 된다.

• 자기소개와 지원 동기를 경험, 기여, 지원 직무의 연결로 구성한다.
• 기술 선택 질문에 요구사항, 선택 근거, 확인 결과, 한계 순서로 답한다.
• 프로젝트 질문에서 이어지는 컴퓨터 과학(CS) 질문에 구현 사실과 일반 원리를 구분해 답한다.
• 모르는 질문과 국비 과정에 대한 질문에 자신의 학습 방식과 확인 가능한 경험으로 답한다.
• 고정한 시드로 모의 면접 순서를 만들고 답변 구조를 점검하는 도구를 실행한다.

문제 상황

면접관이 “예약 기능에서 왜 트랜잭션을 사용했나요?”라고 묻는다. 지원자는 “데이터를 안전하게 처리하려고 사용했습니다”라고 답한다. 이어서 “그러면 같은 시간에 두 요청이 들어와도 중복 예약이 막히나요?”라는 질문을 받는다. 지원자는 잠시 멈춘 뒤 “트랜잭션이 있으니 막힐 것 같습니다”라고 말한다.

이 답변의 문제는 용어를 적게 외운 데 있지 않다. 실제로 적용한 기능, 그 기능이 보장하는 성질, 아직 확인하지 않은 동작을 한 문장에 섞었다는 데 있다. 트랜잭션을 적용했다는 사실만으로 모든 동시 요청 상황에서 중복 예약이 방지된다고 결론 내릴 수 없다. 테이블 제약과 격리 수준, 쿼리와 잠금 방식에 따라 확인할 내용이 달라진다.

자기소개에서도 비슷한 문제가 생긴다. “성실하고 소통을 잘합니다”라고 말하면 면접관은 그 말을 판단할 재료를 얻기 어렵다. 반대로 팀 일정이 밀렸을 때 자신이 맡은 화면과 서버의 연결 조건을 정리하고, 팀원과 확인하여 기능을 마무리한 경험을 말하면 행동이 보인다. 같은 경험이라도 답변의 구조에 따라 확인할 수 있는 정보가 달라진다.

모의 면접에서는 질문에 대답했다는 사실만 기록하지 않는다. 답변 속 어느 문장이 사실이고, 어느 문장이 판단이며, 어떤 자료로 확인할 수 있는지를 남긴다. 녹음이나 답변 메모를 다시 보면서 이 구분을 연습하는 것이 이번 주의 과제다.

자기소개와 지원 동기를 경험에 연결한다

자기소개는 맡길 수 있는 일을 보여 준다

자기소개는 자신의 이력 전체를 시간순으로 읽는 자리가 아니다. 지원 직무와 관련된 경험 하나를 중심으로, 어떤 일을 맡아 본 사람인지 알려 주는 짧은 설명이다. 처음에는 약 1분 분량으로 작성하고 녹음해 본다. 말하는 속도에 따라 분량은 조절하되, 사례가 여러 개라서 핵심 기여가 흐려지지 않게 한다.

구조는 현재의 방향, 대표 경험, 자신의 기여, 앞으로의 연결로 잡는다. 다음 예시는 가상의 경험이므로 문장을 그대로 외우기보다 각 문장의 역할을 살펴본다.

저는 사용자의 요청이 서버와 데이터베이스에서 어떻게 처리되는지 확인하며 기능을 만드는 서버 개발자를 준비하고 있습니다. 국비 과정의 공간 예약 프로젝트에서는 예약 등록과 취소를 맡았습니다. 예약 저장 중 오류가 나면 일부 정보만 남는 상황을 확인했고, 관련 저장 작업을 하나의 트랜잭션으로 묶은 뒤 실패 상황을 다시 점검했습니다. 이 경험을 바탕으로 기능 구현과 오류 확인을 함께 맡는 개발자로 일하고 싶습니다.

이 소개를 사용하려면 실제로 실패 상황을 확인한 기록이 있어야 한다. 경험이 다르다면 내용을 바꿔야 한다. 화면 오류를 재현한 경험, 팀원이 사용할 요청 형식을 정리한 경험, 배포 과정의 누락을 찾아낸 경험도 재료가 된다. 행동의 크기보다 자신의 역할을 구체적으로 설명할 수 있는지가 중요하다.

지원 동기는 업무와 경험의 접점을 말한다

지원 동기를 “배울 기회가 많아 보여서”로 끝내면 자신이 얻을 것만 남는다. 지원할 업무에서 관심을 가진 지점, 그 관심을 뒷받침하는 경험, 입사 후 기여하고 싶은 일을 이어서 말한다. 확인하지 않은 조직 문화나 내부 기술 환경을 추측해서 넣지는 않는다.

예를 들어 채용 공고에 예약·일정 관리 기능의 유지보수 업무가 명시되어 있다면, 상태가 바뀌는 기능을 구현하면서 오류 처리에 관심을 갖게 된 경험을 연결할 수 있다. “예약 상태 변경을 구현하며 취소 시점에 따라 처리 결과가 달라지는 문제를 다뤘습니다. 공고에 나온 일정 관리 업무에서도 이런 상태 변화를 이해하고 수정하는 일에 기여하고 싶습니다”처럼 말한다. 실제 지원에서는 해당 업무가 공고에 있는지부터 확인한다.

이전 경력도 같은 방식으로 연결한다. 고객 응대 경험이 있다면 “소통을 잘한다”보다 문의 내용을 재현 조건으로 정리했던 행동을 말한다. 다른 업종에서 일정과 인수인계를 관리했다면 누락을 줄인 방법을 설명한다. 이전 경력이 개발 실력을 대신하지는 않지만, 협업 상황에서 이미 익힌 행동을 보여 줄 수는 있다.

기술 선택과 CS 질문을 같은 근거로 답한다

“왜 이 기술을 썼나요?”라는 질문에는 기술의 장점을 나열하기 쉽다. 그러나 면접관은 그 장점이 해당 프로젝트에서 필요했는지, 지원자가 직접 판단한 범위가 어디까지인지 물을 수 있다. 답변은 결론을 먼저 말한 뒤 요구사항, 선택 근거, 확인 결과, 한계로 이어 간다.

예를 들어 “예약과 예약 상세 정보가 함께 저장되어야 해서 트랜잭션을 적용했습니다”라고 먼저 답한다. 다음으로 “두 번째 저장에서 오류가 나면 첫 번째 저장도 취소되어야 했습니다”라고 요구사항을 설명한다. 이어서 실제 적용 위치와 실패 확인 방법을 말한다. 마지막에는 “동시 예약 충돌은 별도 문제로 보고 있으며, 현재 구현이 이를 막는지는 아직 검증하지 못했습니다”라고 범위를 밝힌다.

이렇게 답하면 꼬리 질문이 들어와도 출발점이 생긴다. “원자성이 무엇인가요?”에는 작업 묶음이 모두 반영되거나 모두 취소되는 성질이라고 설명하고, 자신의 저장 작업과 연결한다. “동시 요청은요?”에는 트랜잭션 적용 사실만으로 충돌 방지를 단정할 수 없다고 답한 뒤, 현재 제약 조건과 처리 방식을 설명한다. 모르는 구현 세부 사항은 확인 과제로 남긴다.

프로젝트 질문을 원리와 확인 자료로 연결하는 방법

시작 질문	이어질 원리	답변에 쓸 자료	구분할 범위
왜 트랜잭션을 썼나	원자성과 동시 실행	저장 코드와 실패 확인 기록	실패 시 취소와 중복 예약 방지
왜 인덱스를 만들었나	검색 경로와 쓰기 비용	조회 조건과 실행 계획	예상 효과와 실제 측정 결과
왜 상태 코드를 나눴나	요청과 응답의 의미	응답 예시와 화면 처리	현재 처리와 빠진 예외
왜 이 자료구조를 썼나	조회·추가·삭제 비용	사용 위치와 입력 특성	일반적 성질과 현재 규모

모든 선택을 자신이 주도했다고 말할 필요는 없다. 교육에서 정한 기술 조합이나 팀의 공통 결정을 사용했다면 그렇게 설명한다. “과정에서 사용하는 서버 기술이어서 도입했습니다. 제가 직접 판단한 부분은 예약 등록과 취소의 처리 경계입니다”라고 말할 수 있다. 최초 도입 이유와 자신이 이후에 이해하고 수정한 범위를 나누면 답변이 명확해진다.

성능 질문에서도 측정하지 않은 수치를 만들지 않는다. “인덱스로 빨라졌습니다”라고 말하려면 어떤 데이터와 쿼리로 비교했는지 설명할 수 있어야 한다. 측정하지 않았다면 “조회 조건을 보고 후보로 선정했지만 비교 측정은 하지 않았습니다”라고 답한다. 이어서 실행 계획과 같은 조건의 실행 시간을 비교하겠다고 설명한다. 확인 계획은 수행 결과와 구별해서 말한다.

모르는 질문과 국비 과정 질문에 답한다

아는 범위를 밝힌 뒤 확인 경로를 설명한다

질문의 뜻이 불분명하면 먼저 범위를 확인한다. “현재 프로젝트의 설정을 말씀드리면 될까요, 일반적인 동작 원리를 설명하면 될까요?”처럼 질문의 대상을 좁힐 수 있다. 다만 시간을 벌기 위해 확인 질문을 반복하지는 않는다.

모르는 내용은 모른다고 밝히되, 답변을 그 말에서 끝낼 필요는 없다. 알고 있는 범위, 불확실한 부분, 확인할 방법을 짧게 말한다. 예를 들어 “교착 상태가 발생할 수 있다는 점은 알고 있지만, 현재 데이터베이스의 감지 방식은 정확히 설명하기 어렵습니다. 사용 중인 버전의 공식 문서를 확인하고, 두 연결에서 잠금 순서를 다르게 두는 실험으로 관찰하겠습니다”라고 답할 수 있다. 실제로 설명할 수 있는 범위 안에서 말해야 한다.

추론이 가능하다면 “여기부터는 추론입니다”라고 경계를 표시한다. 추론은 외운 답을 대신하는 장식이 아니다. 어떤 전제를 놓고 어떤 결과를 예상하는지 설명하는 과정이다. 면접관이 전제를 바꾸면 자신의 결론도 수정할 수 있어야 한다. 질문이 끝난 뒤에는 기억이 흐려지기 전에 원문에 가까운 질문과 막힌 지점을 기록한다.

국비 과정의 경험을 행동으로 설명한다

국비 과정에 대한 질문에는 짧은 기간에 배운 범위와 팀으로 완수한 경험을 함께 말한다. “기간이 짧아서 아는 것이 없습니다”처럼 경험 전체를 낮출 필요도 없고, “실무와 같습니다”라고 범위를 넓힐 필요도 없다. 제한된 일정 안에서 서비스를 완성하며 자신이 반복한 행동을 제시한다.

과정에서 서버, 화면, 데이터베이스를 연결하며 팀 프로젝트를 완성했습니다. 저는 예약 기능을 맡았고, 화면 담당자와 요청 항목을 맞추면서 변경 내용을 문서로 남겼습니다. 운영 중인 서비스의 장기 유지보수는 아직 경험하지 못했습니다. 대신 제가 맡은 코드의 오류를 다시 재현하고 수정 이유를 설명하는 연습을 이어 가고 있습니다.

“혼자서도 할 수 있나요?”라는 질문에는 팀 전체 결과를 자신의 결과로 바꾸지 않는다. 혼자 다시 구현하거나 수정해 본 범위가 있다면 그 범위를 말한다. 없다면 현재 혼자 설명하고 수정할 수 있는 부분을 제시한다. 일정 안에 끝낸 힘, 역할 간 연결을 맞춘 경험, 이전 직장에서 익힌 업무 정리 방식이 구체적 사례와 만날 때 강점이 된다.

읽은 내용을 자신의 질문으로 되돌린다

《개발자 실무 면접》은 모의 면접에서 막힌 주제를 다시 정리하는 연결 자료로 사용한다. 답변 문장을 가져와 외우기보다 자신의 질문 기록과 관련된 주제를 읽고, 책을 덮은 뒤 프로젝트 사례로 다시 설명한다. 아래 자료도 필요한 빈칸이 생겼을 때 선택한다. 이번 주에 모두 읽는 계획을 세우지는 않는다.

답변에서 발견한 빈칸에 따라 사용할 학습 자료

자료	사용할 때	남길 결과
《개발자 실무 면접》	답변의 근거와 범위를 정리할 때	자기 사례로 다시 쓴 답변
《개발자를 위한 컴퓨터 사이언스》	프로젝트에서 원리로 설명이 이어지지 않을 때	기능과 원리를 연결한 메모
《비전공자를 위한 컴퓨터공학 지도》	질문이 어느 분야인지 잡기 어려울 때	자료구조·DB·네트워크·운영체제 분류
《데이터베이스 개론》·SQL 연구소	쿼리와 저장 동작을 확인할 때	직접 실행한 쿼리와 관찰 결과
《논리로 푸는 알고리즘》·코드패스	풀이 과정 설명이 막힐 때	입력·접근·비용을 말한 기록
《클린 코드 노하우》	코드를 바꾼 이유를 설명할 때	변경 전후와 판단 근거
《코드 리뷰 실무》	협업 중 받은 의견을 정리할 때	의견·판단·수정 결과 기록

완성 코드

다음 프로그램을 main.py로 저장한다. 예상 질문 여섯 개에서 하나씩 뽑아 모의 면접 순서를 만들고, 모든 답변에 공통으로 적용할 구조 점검표를 출력한다. 질문별로 확인할 초점도 함께 표시한다. 입력과 외부 파일이 필요 없으며 실행 후 바로 끝난다.

시드(seed)는 순서를 재현하기 위한 시작값이다. 여기서는 계산 과정을 직접 따라갈 수 있는 작은 의사 난수 생성 규칙을 사용한다. 아직 뽑지 않은 질문 목록에서만 선택하므로 질문이 중복되지 않는다. 면접 연습용 순서를 정하는 용도이며, 보안이나 통계 실험에 사용할 생성기는 아니다.

QUESTIONS = (
    ("자기소개", "자기소개를 해 주세요.",
     "대표 경험과 본인 기여를 구분했는가"),
    ("지원 동기", "이 업무에 지원한 이유는 무엇인가요?",
     "확인한 업무와 자신의 경험을 연결했는가"),
    ("기술 선택", "예약 저장에 왜 트랜잭션을 썼나요?",
     "요구사항, 선택 근거, 확인 결과를 말했는가"),
    ("CS 연결", "트랜잭션만으로 중복 예약을 막을 수 있나요?",
     "원자성과 동시 요청 처리를 구분했는가"),
    ("모르는 질문", "설명하기 어려운 기술 질문을 받으면 어떻게 하나요?",
     "아는 범위, 불확실성, 확인 방법을 밝혔는가"),
    ("국비 경험", "국비 과정에서 얻은 강점은 무엇인가요?",
     "일정, 협업, 본인의 행동을 사례로 말했는가"),
)

CHECKLIST = (
    "질문의 핵심에 먼저 답했다.",
    "본인 기여와 팀의 결과를 구분했다.",
    "사실, 판단, 추론을 구분했다.",
    "코드나 기록 등 확인 근거를 말했다.",
    "미확인 범위나 경험의 한계를 밝혔다.",
)

SEED = 7


def make_order(size, seed):
    remaining = list(range(size))
    order = []
    state = seed % 17
    while remaining:
        state = (state * 5 + 3) % 17
        index = state % len(remaining)
        order.append(remaining.pop(index))
    return order


def main():
    order = make_order(len(QUESTIONS), SEED)
    print(f"모의 면접 | seed={SEED}")
    for number, index in enumerate(order, start=1):
        category, question, focus = QUESTIONS[index]
        print(f"{number}. [{category}] {question}")
        print(f"   점검: {focus}")
    print()
    print("답변마다 확인할 구조 점검표")
    for item in CHECKLIST:
        print(f"[ ] {item}")
    print()
    print("완료 증거: 답변 기록 6개와 보완할 질문 2개")


if __name__ == "__main__":
    main()

이 도구는 답변을 자동 평가하지 않는다. 빈칸에 표시하는 주체는 답변을 다시 읽거나 듣는 사람이다. 점검 항목을 모두 말했더라도 내용이 틀릴 수 있으므로, 사실 확인과 구조 확인을 별도로 수행한다.

줄별 해설

1. 1~14행의 QUESTIONS는 질문 자료를 담은 튜플이다. 질문 하나는 분류, 질문 문장, 점검 초점 세 값으로 구성된다. 긴 문장을 다음 행에 나누어 적어도 괄호 안이므로 같은 항목으로 처리된다. 자신의 프로젝트에 맞게 바꿀 때는 세 값의 순서를 유지한다.

2. 16~22행의 CHECKLIST는 모든 답변을 다시 볼 때 사용할 기준이다. 지원 동기에도 확인 근거가 필요하고, 자기소개에도 본인 기여의 구분이 필요하다. 미확인 범위는 해당하는 내용이 있을 때 밝혔는지 확인하며, 모든 답변에 억지로 한계 문장을 붙이지는 않는다.

3. 24행의 SEED는 시작값을 고정한다. 질문 자료와 시드, 계산 규칙이 같으면 실행할 때마다 같은 순서가 나온다. 다음 연습에서 순서를 바꾸려면 시드를 바꾸되, 답변 기록에도 그 값을 함께 적는다. 다른 시드가 항상 다른 순서를 만드는 것은 아니다.

4. 27~30행은 순서 생성 함수를 정의하고 남은 질문 번호, 선택한 번호, 현재 상태를 준비한다. range(size)는 0부터 size 직전까지의 번호를 만든다. list로 변환한 remaining에서 번호를 제거하므로 원본 질문 자료는 바뀌지 않는다.

5. 31~35행은 질문이 남아 있는 동안 반복한다. 상태에 5를 곱하고 3을 더한 뒤 17로 나눈 나머지를 새 상태로 삼는다. 다시 남은 질문 수로 나눈 나머지를 선택 위치로 사용한다. 첫 상태는 4이므로 여섯 항목 중 위치 4, 즉 다섯 번째 질문이 먼저 선택된다.

6. 35행의 pop은 선택한 번호를 반환하면서 남은 목록에서 제거한다. append는 그 번호를 결과 뒤에 붙인다. 질문을 뽑을 때마다 남은 목록의 길이가 하나씩 줄어들어 반복이 종료된다. 질문 수가 0이면 반복 없이 빈 목록을 반환한다.

7. 39~45행은 순서를 만든 뒤 질문을 출력한다. enumerate의 start=1은 화면에 표시하는 차례를 1부터 시작하게 한다. 저장된 질문 번호는 여전히 0부터 시작한다. 세 변수에 질문 자료를 나눠 담아 각 값의 역할을 드러낸다.

8. 46~52행은 공통 점검표와 완료 증거 안내를 출력한다. 55~56행은 파일을 직접 실행했을 때 main을 호출한다. 질문을 추가하면 반복문은 그대로 사용할 수 있지만, 마지막 완료 증거의 답변 개수 안내도 함께 수정해야 한다.

이 생성 규칙은 가능한 순열을 균등하게 제공하지 않는다. 이번 도구의 목적은 같은 질문을 같은 순서로 다시 연습할 수 있게 하는 것이다. 질문 수를 크게 늘려 다양한 순서를 얻으려면 표준 라이브러리의 random.Random에 고정 시드를 주고 섞는 방법을 검토할 수 있다. 이때는 실행 환경과 실제 출력도 다시 확인한다.

실행 결과

main.py를 저장한 디렉터리에서 실행한다. 아래 순서에서 첫 질문은 모르는 질문에 대처하는 방법이고 마지막 질문은 국비 과정의 강점이다. 같은 파일을 다시 실행하면 동일한 결과가 나온다.

$ python3 main.py
모의 면접 | seed=7
1. [모르는 질문] 설명하기 어려운 기술 질문을 받으면 어떻게 하나요?
   점검: 아는 범위, 불확실성, 확인 방법을 밝혔는가
2. [지원 동기] 이 업무에 지원한 이유는 무엇인가요?
   점검: 확인한 업무와 자신의 경험을 연결했는가
3. [자기소개] 자기소개를 해 주세요.
   점검: 대표 경험과 본인 기여를 구분했는가
4. [기술 선택] 예약 저장에 왜 트랜잭션을 썼나요?
   점검: 요구사항, 선택 근거, 확인 결과를 말했는가
5. [CS 연결] 트랜잭션만으로 중복 예약을 막을 수 있나요?
   점검: 원자성과 동시 요청 처리를 구분했는가
6. [국비 경험] 국비 과정에서 얻은 강점은 무엇인가요?
   점검: 일정, 협업, 본인의 행동을 사례로 말했는가

답변마다 확인할 구조 점검표
[ ] 질문의 핵심에 먼저 답했다.
[ ] 본인 기여와 팀의 결과를 구분했다.
[ ] 사실, 판단, 추론을 구분했다.
[ ] 코드나 기록 등 확인 근거를 말했다.
[ ] 미확인 범위나 경험의 한계를 밝혔다.

완료 증거: 답변 기록 6개와 보완할 질문 2개

각 질문에 먼저 메모를 보지 않고 답한다. 그다음 답변 기록에서 근거가 없는 문장에 표시하고, 고칠 문장 하나를 작성한다. 두 번째 연습에서는 같은 순서로 답해 설명이 달라졌는지 비교한다. 답변을 외웠는지보다 근거를 더 정확하게 제시했는지를 살펴본다.

실무에서 자주 틀리는 것

선택한 항목을 남겨 두어 질문이 중복된다

다음 코드는 선택한 번호를 결과에만 추가한다. 남은 목록이 줄어들지 않아 반복이 끝나지 않으며 같은 질문도 다시 선택될 수 있다.

# 틀린 코드
while remaining:
    state = (state * 5 + 3) % 17
    index = state % len(remaining)
    order.append(remaining[index])

선택과 제거를 함께 수행하면 질문을 한 번씩 뽑고 종료할 수 있다.

# 고친 코드
while remaining:
    state = (state * 5 + 3) % 17
    index = state % len(remaining)
    order.append(remaining.pop(index))

반복할 때마다 시드를 다시 설정한다

반복문 안에서 상태를 초기화하면 앞선 상태를 이어 계산하지 않는다. 이 코드도 재현은 가능하지만, 의도한 생성 규칙과 다른 순서가 나온다.

# 틀린 코드
while remaining:
    state = seed % 17
    state = (state * 5 + 3) % 17
    index = state % len(remaining)
    order.append(remaining.pop(index))

초기화는 반복 전에 한 번 수행한다. 다음 상태는 직전 상태에서 계산한다.

# 고친 코드
state = seed % 17
while remaining:
    state = (state * 5 + 3) % 17
    index = state % len(remaining)
    order.append(remaining.pop(index))

점검 항목 수를 면접 합격 가능성으로 바꾼다

구조 점검표는 답변에서 빠진 부분을 찾는 도구다. 체크 개수를 확률로 출력하면 근거가 없는 의미를 붙이게 된다. 항목이 모두 있어도 기술 설명이 틀리거나 사례가 질문과 맞지 않을 수 있다.

# 틀린 코드
checked = 4
total = 5
print(f"합격 가능성: {checked / total:.0%}")

관찰한 내용만 출력하고, 구조 점검과 사실 확인을 구분한다.

# 고친 코드
checked = 4
total = 5
print(f"구조 점검: {checked}/{total}개 확인")
print("기술 설명의 사실 여부는 근거 자료로 따로 확인한다.")

근거가 없는 답변에 단정적인 문구를 붙인다

면접 메모를 코드로 관리하더라도 표현의 근거를 살펴야 한다. 트랜잭션 사용 여부만 보고 동시 요청 처리 결과를 적으면 검증하지 않은 주장을 저장하게 된다.

# 틀린 코드
answer = {
    "적용": "트랜잭션",
    "결과": "동시 요청에서도 중복 예약이 발생하지 않는다.",
}

실제로 확인한 범위와 남은 질문을 별도 항목으로 둔다. 아래 확인 내용 역시 자신이 수행한 경우에만 사용한다.

# 고친 코드
answer = {
    "적용": "트랜잭션",
    "확인": "두 번째 저장 실패 시 첫 번째 저장도 취소되었다.",
    "미확인": "동시 예약 충돌 방지 여부",
}

한눈에 보기

면접 답변의 종류별로 먼저 준비할 것

답변 종류	핵심 구조	확인할 증거
자기소개	방향 → 경험 → 기여 → 연결	담당 기능과 직접 한 행동
지원 동기	업무 관심 → 관련 경험 → 기여	확인한 업무 내용과 경험 기록
기술 선택	결론 → 요구 → 근거 → 결과 → 한계	코드, 비교 기록, 실패 재현
모르는 질문	아는 범위 → 불확실성 → 확인 방법	확인할 대상과 실험 조건
국비 경험	제약 → 본인 행동 → 결과 → 보완	일정과 협업에서 남긴 기록

이번 주에 할 일과 완료를 판단할 기록

확인	시점	할 일	완료 증거
□	월요일	자기소개와 지원 동기를 작성한다.	두 답변 초안과 자기소개 녹음
□	화요일	기술 선택 하나에 꼬리 질문 세 개를 붙인다.	질문별 근거 자료 위치
□	수요일	CS 설명과 실제 구현을 대조한다.	확인 사실과 미확인 사항 메모
□	목요일	도구 순서대로 모의 면접을 한다.	시드가 적힌 답변 기록 여섯 개
□	금요일	막힌 질문 두 개를 확인하고 다시 답한다.	보완 전후 답변과 확인 근거

완료 증거는 잘 말했다는 소감이 아니라 다시 살펴볼 수 있는 기록이다. 이번 주에는 자기소개 녹음, 지원 동기 초안, 여섯 질문의 답변 기록, 보완한 질문 두 개와 그 근거를 남긴다. 파일이나 메모의 형식은 자유지만 질문, 첫 답변, 수정한 답변, 근거 위치를 구분한다. 다음 장에서 지원 기록을 다룰 때 이 자료를 연결하면 어떤 질문에서 설명이 나아졌는지 추적할 수 있다.

연습 문제

1. “팀 프로젝트에서 서버 기술은 과정에서 정해 주어서 썼습니다”라는 사실을 유지하면서 기술 선택 답변을 작성한다. 자신이 판단한 부분과 직접 확인한 결과를 각각 한 문장 이상 넣는다. 확인하지 않은 결과는 만들어 쓰지 않는다.

2. “트랜잭션을 적용했으니 중복 예약이 막힙니다”라는 답변을 수정한다. 구현 사실, 일반 원리, 미확인 사항을 나누고 이어질 확인 질문 하나를 작성한다.

3. 완성 코드의 SEED를 0으로 바꿨을 때 첫 번째 질문의 분류를 계산한다. 전체 순서를 외울 필요 없이 첫 상태와 선택 위치를 적는다.

4. 국비 과정에 대한 답변을 작성하고, 모의 면접 점검표로 검토한다. 짧은 일정 안에서 본인이 한 행동 하나를 넣고, 팀 성과를 자신의 성과처럼 표현한 문장이 없는지 확인한다.

정답과 해설

1. 답변 예시는 “서버 기술은 과정의 공통 환경이어서 사용했습니다. 제가 판단한 부분은 예약 등록과 상세 정보 저장을 하나의 처리 단위로 묶는 것이었습니다. 두 번째 저장에서 오류를 발생시켜 첫 번째 저장도 취소되는지 확인했습니다”다. 마지막 문장은 실제로 확인했을 때만 쓴다. 수행하지 않았다면 “현재는 정상 저장만 확인했고, 중간 실패 상황은 확인하지 못했습니다”로 바꾼다. 도입을 주도하지 않았다는 사실과 이후 자신의 판단을 함께 설명하는 것이 핵심이다.

2. “예약 저장 작업에 트랜잭션을 적용했습니다. 원자성은 작업 묶음의 전체 반영 또는 취소와 관련되지만, 그 사실만으로 동시 요청의 중복 예약 방지를 단정할 수는 없습니다. 현재 구현의 동시 요청 결과는 확인하지 못했습니다”라고 수정할 수 있다. 이어질 확인 질문은 “같은 공간과 시간을 중복 저장하지 못하게 하는 데이터베이스 제약이 있는가?”다. 제약 여부와 별개로 실제 요청이 어떤 응답을 받는지도 확인 대상이다.

3. 첫 상태는 (0 × 5 + 3)을 17로 나눈 나머지이므로 3이다. 남은 질문은 여섯 개이고 선택 위치는 3을 6으로 나눈 나머지인 3이다. 위치는 0부터 시작하므로 네 번째 항목인 “CS 연결”이 먼저 나온다. 화면의 순번 1과 질문 자료의 위치 3을 구분해야 한다.

4. 답변 예시는 “국비 과정에서 짧은 일정 안에 역할을 나누고 서비스를 연결하는 경험을 했습니다. 저는 예약 화면과 서버에서 사용하는 날짜 형식이 달라 연결이 지연되었을 때, 요청 예시를 정리하고 화면 담당자와 값을 맞췄습니다. 서비스 완성은 팀의 결과이며, 제가 기여한 부분은 예약 요청 조건을 정리하고 담당 기능을 연결한 일입니다”다. 실제 경험에 맞게 고쳐 쓴 뒤 요청 예시나 변경 기록을 근거로 남긴다. 표현이 구체적이어도 경험과 다르면 사용할 수 없다.