라이브 코딩 대비, 45분을 어디에 쓰나

라이브 코딩 대비의 핵심은 "문제를 몇 개 더 푸느냐"가 아니라 "면접관이 무엇을 확인하고 싶어 하느냐"를 먼저 정하는 것이다. 정답 제출 자체는 채용 판단의 일부일 뿐이고, 실제로는 사고 과정을 소리 내 설명하고 검증까지 하는지를 본다. 이 글은 그 확인 순서를 시간 배분 기준으로 정리했다.

라이브 코딩 대비, 45분을 어디에 먼저 써야 하나?

결론부터 말하면, 나는 패턴 문제 풀이보다 "설명 가능한 사고"를 먼저 배정한다. 코딩 실력이 부족해서 떨어지는 경우보다, 접근을 말로 못 풀어서 인터뷰어가 판단 자체를 못 내리는 경우를 더 자주 봤다.

• 시간 배분은 패턴 숙지 → 시스템 디자인 → 의도적 연습 → 모의면접 → 스토리 뱅크 순으로 잡는다
• 라이브 코딩은 정답보다 접근 설명, 엣지케이스 처리, 테스트 작성 여부를 본다
• 시스템 디자인은 이제 시니어 전용이 아니라 더 넓은 role에서 기본 신호로 취급된다
• 경험면접은 STAR-L(상황-과제-행동-결과-배운점) 구조로 미리 12개 정도 준비해두는 게 안전하다
• 이력서·포트폴리오는 면접에서 파고들 "질문 저장소"로 미리 정리해둬야 한다

이 판단이 갈리는 지점은 하나다. "코딩 문제를 더 풀 것인가, 이미 아는 문제를 더 잘 설명하는 훈련을 할 것인가." 나는 후자에 무게를 둔다. 실제로 [2025 인터뷰 준비 가이드]는 45분 루틴을 새 문제 1개 접근 설명 후 코드 작성, 자동완성 없이 진행, 마지막에 엣지·속성 기반 테스트 작성으로 구성한다. 문제 개수를 늘리는 것보다 이 사이클을 반복하는 쪽이 실전 신호와 더 가깝다.

코딩 문제는 몇 개를 더 풀어야 신호가 달라지나?

문제 개수보다 "말로 설명하며 푼 횟수"가 신호를 바꾼다. 나도 처음엔 100문제, 200문제 식으로 개수를 세다가, 정작 화면 공유하고 말하면서 풀어본 적은 거의 없다는 걸 뒤늦게 깨달았다. 자동완성 없이, 소리 내어 접근을 설명하면서 문제를 푸는 연습은 조용히 혼자 푸는 것과 완전히 다른 근육을 쓴다. 말하면서 코드를 짜면 논리가 끊기는 지점이 바로 드러나고, 그 지점이 실제 면접에서 인터뷰어가 개입하는 지점과 거의 겹친다.

그래서 나는 문제 하나를 풀 때 세 단계를 강제한다. 접근 설명(2~3분) → 코드 작성(15~20분) → 엣지케이스와 테스트 작성(5~10분). 이 구조를 지키면 문제 개수는 하루 1~2개로 줄어들지만, 실제 면접 시간 구성(대개 45분)과 거의 일치한다. 개수를 늘리는 대신 이 사이클의 밀도를 높이는 쪽이, 적어도 내 경험상 실전 압박 상황에서 더 잘 작동했다.

시스템 디자인은 몇 년차부터 준비해야 하나?

연차와 무관하게 이제는 준비 항목에 넣는 게 안전하다. 예전엔 시스템 디자인을 시니어 전용 관문으로 보는 시각이 많았지만, [2026 채용 가이드]는 더 넓은 role에서도 "공개형 설계, 트레이드오프 설명, 모듈 간 상호작용"을 기본으로 확인한다고 정리한다. 주니어라 하더라도 왜 이 구조를 택했는지, 무엇을 포기했는지 설명 못 하면 감점 요인이 된다.

연습 구조는 시간 배분으로 나눠 접근하는 게 실전과 가깝다. 요구사항 수집 5~7분, 고수준 설계 10~15분, 트레이드오프와 확장 논의 5~10분. 이 세 구간을 따로 떼어 연습하면, 실제 인터뷰에서 시간에 쫓겨 결론 없이 끝나는 상황을 줄일 수 있다. 다만 이 시간 배분이 정답은 아니고, 면접 루프마다 배정 시간이 다르므로 채용 공고나 사전 안내에서 라운드 구성을 먼저 확인하는 게 우선이다.

행동면접 스토리는 몇 개를 준비해야 압박 질문에 안 흔들리나?

나는 12개를 기준으로 잡는다. 이 숫자는 임의로 정한 게 아니라, "왜 너인가", "가장 큰 실수는 무엇인가", "갈등을 어떻게 다뤘는가" 같은 추가 질문까지 커버하려면 3~4개짜리 스토리로는 부족하다는 걸 반복해서 겪었기 때문이다. [2025 인터뷰 준비 가이드]가 제안하는 STAR-L(상황-과제-행동-결과-배운점) 구조를 쓰면, 단순히 "무엇을 했다"에서 끝나지 않고 "그래서 무엇을 배웠는가"까지 답할 준비가 된다.

압박 질문은 대개 결과가 아니라 판단 과정을 파고든다. "왜 그 방법을 택했나", "다시 하면 무엇을 바꾸겠나" 같은 질문에 즉흥으로 답하면 이야기가 흔들리기 쉽다. 스토리 뱅크를 12개 정도 미리 써두면, 압박 질문이 들어와도 이미 준비된 변주 중 하나로 대응할 수 있다. 이 준비는 암기가 아니라, 같은 경험을 여러 각도로 설명할 수 있는 유연성을 만드는 작업에 가깝다.

이력서·포트폴리오는 코딩테스트 전에 정리해야 하나 후에 정리해야 하나?

나는 코딩테스트 준비와 동시에, 오히려 조금 더 먼저 정리한다. 이력서는 ATS 통과용 문서이면서 동시에 면접에서 파고들 재료이기도 하다. [2026 채용 가이드]는 단일 열 레이아웃, PDF 제출, JD 키워드 포함, 성과 수치화, 날짜 형식 통일을 권하고, 표나 복잡한 그래픽은 ATS 파싱 실패 위험이 있다고 지적한다. 화려하게 꾸미는 것보다 파싱 가능한 구조가 우선이다.

포트폴리오는 "할 수 있다"가 아니라 "실제로 만들었고 어떤 의사결정을 했는가"를 증명하는 용도다. 채용 담당자가 빠르게 확인하는 항목은 역할 명확성, 현재 스택 적합성, 도메인 친숙도, 결과 증거 네 가지로 정리된다. 나는 프로젝트마다 아키텍처를 왜 그렇게 짰는지, 가장 큰 실패는 무엇이었는지, 성능 특성(처리량·지연시간·스케일)은 어땠는지를 짧게 적어둔다. 이렇게 해두면 면접에서 "이 프로젝트 좀 더 설명해달라"는 질문이 부담이 아니라 준비된 답변으로 이어진다.

이 우선순위, 무엇을 근거로 판단했나?

이 배분 순서는 개인 취향이 아니라 채용 루프 구조에서 나온다. [2026 채용 가이드]는 5~7라운드 구조에서 데이터 구조, 시스템 디자인, 행동 판단, 디버깅, AI 도구 활용까지 라운드별로 분리해 평가한다고 정리한다. 즉 하나의 라운드에서 모든 걸 보여주려 하기보다, 각 라운드가 보는 신호를 미리 알고 거기에 맞춰 준비하는 게 시간 대비 효율이 높다.

또한 [2025 인터뷰 준비 가이드]와 [2026 채용 가이드] 모두 "기초 코딩 → 시스템 설계 → 경험/스토리 → 이력서·포트폴리오 정비" 순서를 대체로 공통되게 제시한다. 다만 2026년 기준 자료는 프로젝트를 먼저 정리한 뒤 이력서를 그에 맞춰 쓰는 역순 접근도 함께 언급하는데, 이는 프로젝트 경험이 이미 충분한 경력자에게 더 맞는 방식이라고 본다. 연차가 낮을수록 패턴 숙지에 먼저 시간을 쓰고, 연차가 높을수록 프로젝트 정리와 시스템 디자인에 더 많은 시간을 배정하는 쪽이 합리적이다.

라이브 코딩 대비에서 가장 자주 놓치는 함정은?

가장 흔한 함정은 "혼자 조용히 잘 푸는 것"과 "면접장에서 잘 푸는 것"을 같은 능력으로 착각하는 것이다. 나도 이 착각으로 한 번 크게 흔들린 적이 있다. 집에서는 문제를 빠르게 풀었는데, 막상 화면 공유하고 말하면서 풀려니 논리를 설명하는 언어 자체가 준비돼 있지 않아서 시간을 다 써버렸다. 자동완성 없이, 소리 내어 설명하며 푸는 연습을 안 하면 이 격차는 실전에서 그대로 드러난다.

두 번째 함정은 이력서와 포트폴리오를 "제출용 문서"로만 여기는 것이다. ATS 통과에만 신경 쓰다 보면 정작 면접에서 그 프로젝트를 설명할 언어를 준비하지 않은 상태로 들어가게 된다. 세 번째는 시스템 디자인을 시니어만의 영역으로 미뤄두는 것인데, 이제는 더 넓은 role에서도 기본 신호로 확인되는 만큼, "나는 아직 준비 안 해도 된다"는 판단은 감수해야 할 위험이 크다. 어떤 준비도 100% 완벽할 수 없다는 전제는 유지하되, 최소한 놓치는 영역을 미리 알고 있는 것과 모르는 것의 차이는 크다.

그래서 어떤 상황에 무엇부터 준비하나?

정리하면 이렇다. 주니어~3년차는 패턴 숙지와 소리 내어 설명하는 연습에 시간의 절반 이상을 쓰고, 시스템 디자인은 기본 구조(요구사항-설계-트레이드오프)만이라도 익혀둔다. 3~7년차는 시스템 디자인 연습 비중을 늘리고, 프로젝트별 아키텍처 이유·실패 사례·성능 특성을 미리 문서화해둔다. 7년차 이상은 스토리 뱅크와 포트폴리오 정비에 더 많은 시간을 배정하되, 코딩 감각이 떨어지지 않도록 소리 내어 설명하는 루틴은 유지한다.

• 라이브 코딩은 정답보다 설명·테스트 여부를 먼저 본다
• 시스템 디자인은 연차와 무관하게 준비 항목에 넣는 게 안전하다
• 행동면접 스토리는 12개 정도를 STAR-L 구조로 미리 써둔다
• 이력서·포트폴리오는 면접 질문 저장소로 미리 정리해둔다
• 채용 루프가 길수록 라운드별 신호가 분리되므로, 한 라운드에 모든 걸 담으려 하지 않는다

핵심 정리

• 라이브 코딩 대비의 핵심은 문제 개수가 아니라 "소리 내어 설명하며 푸는" 연습 밀도다
• 시스템 디자인은 이제 시니어 전용이 아니라 더 넓은 role에서 확인되는 기본 신호다
• 행동면접은 STAR-L 구조로 12개 스토리를 준비해 압박 질문 변주에 대비한다
• 이력서는 ATS 파싱 가능한 단순 구조, 포트폴리오는 아키텍처·실패·성능이 드러나는 질문 저장소로 정리한다
• 채용 루프가 5~7라운드로 길어질수록 라운드별로 분리된 신호에 맞춰 준비 시간을 배분한다