저는 생업으로 AI 제품을 만들고 있으며, 모델들이 무엇을 잘하는지 말씀드리겠습니다. 모델들은 저의 CRUD 엔드포인트, Terraform, 테스트 스캐폴딩(test scaffolding)을 작성하며, 제가 문제 설명을 읽는 것보다 더 빠르게 대부분의 LeetCode 중간 난이도 문제들을 해결합니다. 하지만 모델들이 단 한 번도 해내지 못한 것은, 제가 그들의 결정에 반대할 때 그 결정을 방어하는 일입니다. 모델에게 "왜 여기서 Postgres가 아니라 Kafka를 사용해야 하는가?"라고 묻고, 그 답변을 두 번 정도 공격해 보십시오. 그러면 모델은 조심스럽게 선택지들을 나열하는 식의 답변으로 물러납니다. 심문(interrogation) 상황에서도 엔지니어링적 입장을 고수하는 능력, 즉 그 간극이야말로 AI가 당신을 대신해 해줄 수 없는 기술 인터뷰의 마지막 부분입니다. 그리고 그것이 바로 시스템 디자인(system design) 라운드가 테스트하는 핵심입니다.

따라서 채용 기준이 변하고 있습니다. 만약 당신의 인터뷰 준비가 여전히 80%의 알고리즘 연마와 전날 밤에 확장성(scalability) 블로그를 훑어보는 20%로 이루어져 있다면, 당신은 5년 전의 인터뷰를 준비하고 있는 것입니다.

코딩 스크린(coding screen)은 더 이상 예전과 같은 것을 측정하지 않는다

과제 전형(take-home)이나 감독 없는 코딩 스크린은 과거에 다음과 같은 실제적인 질문에 답했습니다: "이 사람이 약간의 압박 속에서도 작동하는 코드를 작성할 수 있는가?" 이제 그것은 주로 다른 질문에 답합니다: "이 사람이 Copilot 구독을 하고 있는가?" 제가 아는 모든 엔지니어는 보일러플레이트(boilerplate) 작성을 위해 AI를 사용하며, 제가 대화해 본 모든 채용 담당자도 그 사실을 알고 있습니다. 일부 기업들은 더 엄격한 감독으로 대응합니다. 더 똑똑한 기업들은 도움이 되지 않는 라운드로 비중을 옮김으로써 대응하며, 디자인 라운드가 그중 가장 큰 비중을 차지합니다.

이러한 변화는 합리적입니다. AI가 구문(syntax)을 작성한다면, 희소한 기술은 무엇을 만들 것인지, 무엇을 포기(trade-off)할 것인지, 그리고 그 결과와 함께 살아가는 법을 결정하는 것입니다. 디자인 인터뷰는 그 직무를 45분 동안 시뮬레이션하는 것입니다. 면접관은 당신이 캐시(cache)의 존재를 아는지 평가하는 것이 아닙니다. 당신이 아키텍처(architecture)에 전념할 수 있는지, 그 비용이 무엇인지 설명할 수 있는지, 그리고 제약 조건이 변경되었을 때 조정할 수 있는지를 평가합니다.

이는 LeetCode 준비의 가치가 하락하는 바로 그 순간에 시스템 디자인 인터뷰 준비의 가치가 상승했음을 의미합니다. 하지만 오직 한 종류의 디자인 준비만이 그렇습니다.

왜 LLM은 패턴을 암송하면서도 설득력을 잃는가

불편한 진실이 여기 있습니다. 대부분의 사람들이 표준 플레이북(playbook)을 암기하며 시스템 디자인을 준비하는 방식은 LLM(Large Language Model)의 답변과 구별할 수 없는 결과물을 만들어냅니다. "로드 밸런서(load balancer)를 추가하고, 읽기 작업은 캐싱(cache)하며, 데이터베이스를 샤딩(shard)하고, 쓰기 작업 앞에는 큐(queue)를 배치하세요." 모델은 이를 완벽한 형식과 Mermaid 다이어그램과 함께 단 2초 만에 말할 것입니다.

패턴 회상(Pattern recall)은 이제 비용이 들지 않습니다. 그것은 아무런 신호도 주지 못합니다.

모델이 할 수 없는 것, 그리고 면접관들이 점점 더 파고드는 것은 다음 세 가지로 요약됩니다:

• 의사결정 (Commitment). LLM은 트레이드오프(trade-off) 표를 제공하고 선택은 당신에게 맡깁니다. 하지만 면접에서는 한쪽을 선택하고 그에 대한 책임을 져야 합니다. "Postgres로 시작하겠으며, 초당 1만 건의 쓰기 작업 부근에서 이 부분을 재검토하게 될 것임을 인지하고 있습니다"는 하나의 입장(position)입니다. 반면 "요구사항에 따라 다릅니다"는 어깨를 으쓱하며 회피하는 태도일 뿐입니다.
• 맥락 민감도 (Context sensitivity). 표준 패턴은 화이트보드에 적힌 특정 제약 조건에 대해 틀린 경우가 많습니다. 첫날부터 "확장성을 위해 샤딩을 한다"는 3인 규모의 스타트업은, 모든 문장이 교과서적으로 정확했을지라도 면접에서 탈락한 것입니다.
• 후속 질문 견디기 (Surviving the follow-up). 면접은 설계상 대립적(adversarial)입니다. "무엇이 가장 먼저 깨집니까?" "큐가 한 시간 동안 쌓인다면 어떻게 됩니까?" "면접관이 방금 예산을 절반으로 줄였다면, 무엇을 포기하겠습니까?" 암기된 답변은 두 번째 후속 질문에서 산산조각 납니다. 진정한 이해는 유연하게 대응하며 계속 나아갑니다.

저는 이 테이블의 양쪽 모두에 앉아 보았고, 그 차이는 항상 동일했습니다. 답변을 암기한 지원자는 컴포넌트(components) 단위로 말하지만, 시스템을 이해하는 지원자는 결과(consequences) 단위로 말합니다.

다이어그램이 아니라 심문을 준비하라

실질적인 변화는 이것입니다: 아키텍처를 수집하는 데 시간을 덜 쓰고, 그것을 방어하는 데 더 많은 시간을 쓰십시오. 근육을 실제로 길러줄 네 가지 훈련법입니다.

1. 기능(feature)을 정의하기 전에 실패 모드(failure mode)를 작성하라. 공부하는 모든 디자인에 대해, "새벽 3시에 누군가 이 시스템을 사용한다면 어떤 페이지가 터질까?"라는 질문에 스스로 답하도록 강제하십시오. 부하(load) 상황에서 가장 먼저 깨지는 것을 말할 수 없다면, 당신은 디자인을 이해한 것이 아니라 그저 본 것뿐입니다.

2. 지루한 옵션을 옹호하십시오 (Argue for the boring option). Kafka, Cassandra, 또는 서비스 메시 (service mesh)를 지향하는 어떤 디자인을 가져오더라도, Postgres, cron job, 그리고 모놀리스 (monolith)를 사용하는 방안을 진지하게 방어해 보십시오. 절반의 경우에는 지루한 버전이 승리하며, 그 지루한 버전이 언제 더 이상 승리하지 못하는지를 정확히 아는 것이 핵심 기술입니다. 면접관들은 후보자가 "단일 Postgres 인스턴스가 대략 X까지는 이를 처리할 수 있으며, 그 지점에 도달했을 때의 마이그레이션 경로는 다음과 같습니다"라고 말할 때 눈을 반짝입니다.

3. 모든 것에 숫자를 붙이십시오 (Attach numbers to everything). 모호한 디자인은 취약한 논리를 숨깁니다. 대략적인 계산 (Back-of-envelope math)은 이를 (긍정적인 방식으로) 드러냅니다:

알림 서비스 (Notification service), 대략적인 규모 산정:
  50M 사용자 x 일일 알림 5개 = 250M/일
  250M / 86,400초 ≈ 초당 평균 2,900개
...

이러한 산술 계산을 하는 30초는 10분 동안 박스와 화살표를 그리는 것보다 당신의 신뢰성을 높여줍니다. 왜냐하면 문제를 해결하기 전에 문제의 규모를 먼저 산정했다는 것을 보여주기 때문입니다.

4. 범위를 줄이는 연습을 소리 내어 하십시오 (Practice cutting scope out loud). 면접관들은 답변 도중에 제약 조건을 바꾸는 것을 좋아합니다. 다음과 같은 문장 구조를 연습하십시오: "일정이 절반으로 줄어든다면, 저는 X를 제외하고, Y는 유지하며, Z를 알려진 리스크 (known risk)로 수용하겠습니다." 당신이 수용하는 리스크가 무엇인지 명시하는 것이 시니어다운 답변과 방어적인 답변을 가르는 차이점입니다.

약한 답변과 강한 답변의 비교

질문: "당신의 알림 서비스는 다음 분기에 트래픽이 10배 증가해야 합니다. 어떻게 하시겠습니까?"

약한 답변 (모델이 내놓을 법한 답변): "내구성을 위해 Kafka를 도입하고, Redis 캐시를 추가하며, 사용자 ID별로 데이터베이스를 샤딩 (shard)하고, 워커 (worker)를 수평 확장 (scale horizontally)하겠습니다." 각각의 단어는 개별적으로는 방어 가능합니다. 하지만 이는 레시피가 없는 재료 목록일 뿐이며, 첫 번째 후속 질문("그중 무엇을 가장 먼저 수행할 것이며, 그 이유는 무엇입니까?")이 나오는 순간 답변은 무너집니다.

훌륭한 답변: "먼저 현재의 병목 지점(bottleneck)을 찾겠습니다. 서류상에서의 10배 성능 향상은 보통 특정 하나의 컴포넌트에서 발생하는 10배 향상인 경우가 많기 때문입니다. 만약 알림 테이블(notifications table)의 쓰기 처리량(write throughput)이 문제라면, 스키마(schema)를 건드리기 전에 인서트(insert)를 배치(batch) 처리하고 팬아웃(fan-out)을 큐(queue)로 옮기겠습니다. 샤딩(Sharding)은 모든 읽기 경로(read path)를 복잡하게 만들기 때문에 여기서는 최후의 수단으로 남겨두겠습니다. 피크 시 초당 15,000건(15k/sec) 수준이라면 샤딩이 필요하기까지는 아직 한 자릿수(one order of magnitude) 정도의 여유가 있을 것입니다. 변경 후 제가 주시할 부분은 큐 지연(queue lag)입니다. 백로그(backlog)가 한 시간 동안 조용히 쌓인다는 것은 사용자가 어젯밤의 알림을 오전 9시에 받게 된다는 뜻이며, 알림 서비스에서는 이는 알림을 누락하는 것보다 더 나쁜 상황이기 때문입니다."

훌륭한 답변에 포함되어 있지만, 부족한 답변에는 없는 요소들을 주목하십시오. 처방을 내리기 전의 진단, 우선순위 설정, 인기 있는 패턴을 피하기 위해 명시한 이유, 그리고 구체적이고 사용자에게 직접적으로 드러나는 실패 모드(failure mode)입니다. 이 중 그 어느 것도 설계를 암기하는 것에서는 나오지 않습니다. 이 모든 것은 방어(defense)를 연습하는 과정에서 나옵니다.

AI를 대본이 아닌 스파링 파트너로 만드세요

아이러니하게도 코딩 테스트를 대체하고 있는 이 도구는, 그 역할을 뒤집기만 한다면 여러분이 얻을 수 있는 최고의 설계 코치입니다. AI에게 "URL 단축기(URL shortener)를 설계해줘"라고 정답을 묻지 마십시오. 대신 여러분의 설계를 제시하고 다음과 같이 지시하십시오. "당신은 회의적인 스태프 엔지니어(staff engineer)입니다. 여기서 가장 취약한 결정 세 가지를 찾아내고, 내가 인정하거나 당신을 설득할 때까지 각각에 대해 나를 심문하십시오." 그런 다음 실제 면접장에서 해야 하는 것처럼, 완전한 문장으로 소리 내어 답변하십시오. 이러한 세션을 열 번 수행하는 것이 아키텍처 기술서를 수동적으로 백 번 읽는 것보다 훨씬 낫습니다.

제 입장에서 솔직한 주의 사항을 하나 말씀드리자면, 설계 면접 단계에 도달하지 못한다면 이 모든 것은 의미가 없습니다. 그리고 그 단계에 도달하기 위해서는 여전히 채용 담당자의 7초 스캔을 견뎌낼 수 있는 이력서가 필요합니다. 저는 Roleframe을 만들고 있기에 편향될 수 있지만, 제가 집중하고 있는 부분은 바로 이 지점입니다: 채용 공고를 붙여넣으면 해당 역할에 맞춰 이력서를 조정하고 실제 경험을 바탕으로 면접 준비를 도와줍니다. 이를 통해 준비 시간은 이력서의 불렛 포인트(bullets)를 다시 쓰는 대신 트레이드오프(trade-offs)를 방어하는 데 쓰일 수 있습니다.

해자(Moat)는 압박 속에서 표현되는 판단력입니다

AI는 무언가를 아는 것의 가치를 압축해 버렸습니다. 하지만 무언가를 결정하고, 누군가가 그 결정의 허점을 파고드는 동안 그 결정 뒤에 서 있는 것의 가치에는 손을 대지 못했습니다. 그것이 바로 시스템 디자인 인터뷰 (system design interview)가 측정하는 것이며, 당신의 10년, 혹은 고군분투했던 2년의 실제 시스템 운영 경험이 그 어떤 도구도 흉내 낼 수 없는 방식으로 드러나는 유일한 단계입니다.

이번 주에는 당신이 실제로 운영해 본 것, 아주 작은 서비스라도 좋습니다, 그것으로 시작해 보세요. 그 서비스가 구현하고 있는 세 가지 결정 사항을 적고, 각 결정을 정당화하는 수치 하나와 각 결정이 수용하는 장애 모드 (failure mode)를 적어보세요. 그런 다음, 인간이든 아니든 당신이 찾을 수 있는 가장 혹독한 면접관 앞에서 그 세 가지를 소리 내어 방어해 보세요. 그것이 복리로 쌓이는 준비 과정입니다.