Amazon AI 코딩 테스트 OA 가이드 2026: 레포 버그·AI 프롬프트·히든 테스트

낯선 레포지토리가 열려 있고, 여러 테스트가 실패하고 있으며, AI 어시스턴트가 지시를 기다리고 있습니다. 진짜 어려운 것은 AI에게 "코드를 고쳐 줘"라고 요청하는 일이 아닙니다. 시스템을 충분히 이해한 뒤 무엇을 물어야 하는지, 답이 맞는지, 히든 테스트가 무엇을 더 드러낼 수 있는지를 스스로 판단하는 일이 어렵습니다.

2026년 여러 Amazon 지원자 후기에서 이야기하는 새로운 과제가 바로 이것입니다. Amazon은 AI 지원 OA의 단일 공통 형식을 공개한 적이 없으므로, 이 가이드는 공식 안내와 후기로 전해지는 경험을 구분하고, 정확한 제한 시간이나 레포지토리, 버그 개수가 달라져도 계속 쓸 수 있는 준비 방법을 알려 드립니다.

먼저 PracHub의 실제 Amazon 면접 문제, 특히 최신 소프트웨어 엔지니어링 기초 및 코딩 후기를 살펴보세요. 그런 다음 아래 워크플로를 사용해 그 문제들을 레포지토리 단위의 디버깅 연습으로 바꿔 보세요.

뛰어난 지원자는 원인 진단, AI가 생성한 diff, 최종 검증 근거를 끝까지 스스로 통제합니다.

한눈에 보는 결론

Amazon의 AI 지원 코딩 과제는 프롬프트 작성 대회가 아니라, AI 도구를 함께 쓰는 디버깅 테스트로 대비하세요. 최근 지원자 후기에는 낯선 코드베이스, 제대로 동작하지 않는 기능, 내장 어시스턴트, 공개 또는 히든 테스트가 나옵니다. 정확한 구성은 직무와 지역에 따라 다른 것으로 보입니다.

가장 좋은 루프는 이렇습니다. 실패를 재현하고, 코드 경로를 추적하고, 가설을 세우고, 범위가 좁은 질문을 하나 던지고, diff를 확인하고, 테스트를 돌리고, 문제 조건(입력·출력·제약)을 직접 검증합니다.

테스트에서 명시적으로 제공하거나 허용한 도구만 사용하세요. Amazon의 현재 대학 지원자용 OA 안내에 따르면 브라우저 활동이 기록될 수 있고, 복사·붙여넣기 행위에 대해 경고하고 있습니다. 최종 기준은 초대 메일과 테스트 환경에 적힌 지침입니다.

Amazon AI 지원 코딩 OA란?

Amazon의 공식 SDE 평가 페이지는 지금도 직무에 따라 코딩 테스트가 다르다고 설명하며, 정확한 구성은 초대 메일에서 확인하라고 안내합니다. 대학 지원자용 페이지는 국가별로 형식이 다를 수 있다고 하고, SDE II 페이지는 더 전통적인 두 문제짜리 코딩 테스트를 설명합니다.

별도로, 2026년 여러 지원자 후기에는 내장 AI 어시스턴트가 있는 새로운 레포지토리 과제가 나옵니다. 후기에는 기존 애플리케이션의 여러 버그를 고치는 것과 테스트 스위트를 통과하는 것이 자주 언급됩니다. 일부 지원자는 전통적인 알고리즘 문제와 레포지토리 과제를 함께 받았고, 다른 지원자는 순서, 제한 시간, 테스트 개수가 달랐다고 전합니다.

실전 결론: 후기로 전해지는 레포지토리 형식에 대비하되, 한 지원자의 숫자를 외우지는 마세요. 초대 메일을 테스트 명세서로 읽으세요.

일반적인 DSA 문제와 무엇이 다른가

일반적인 코딩 문제는 간결한 문제 조건을 주고 알고리즘을 설계하라고 합니다. 레포지토리 과제는 일부만 동작하는 시스템을 주고, 안전하게 수정하기 전에 문제 조건부터 스스로 파악하라고 합니다.

알고리즘 공부를 놓지 마세요. 후기에 따르면 새로운 과제가 일반 코딩 문제와 함께 나올 수 있고, 이후 Amazon 면접에서도 코딩 기초는 여전히 평가합니다. PracHub의 Amazon 소프트웨어 엔지니어 코딩 문제로 이 영역도 꾸준히 연습하세요.

이 과제가 평가하는 것으로 보이는 역량

Amazon은 후기로 전해지는 이 형식의 채점 기준을 공개한 적이 없습니다. 과제 설계, 견고하고 잘 테스트된 코드를 강조하는 공식 입장, 반복되는 지원자 설명을 바탕으로 볼 때, 아래 역량은 확정된 배점이 아니라 준비 목표로 삼을 만한 항목입니다.

공통점은 엔지니어링을 스스로 통제하는 능력입니다. AI는 탐색 속도를 높여 줄 수 있지만, 진단과 제출하는 코드에 대한 책임은 여전히 본인에게 있습니다.

7단계 레포지토리 디버깅 루프

근거, 변경, 결과를 서로 연결할 수 있을 만큼 한 사이클을 작게 유지하세요.

1. 구현보다 먼저 문제 조건을 읽습니다

과제 설명, README, 테스트 실행 명령, 프로젝트 구조, 공개 테스트를 훑어보세요. 기대하는 동작을 한 문장으로 적어 두세요. 실패한 테스트는 하나의 근거일 뿐, 항상 요구사항 전체는 아닙니다.

2. 실패 하나를 재현합니다

관련 있는 가장 작은 테스트나 동작을 실행하세요. 정확한 assertion, 예외, 상태 코드, 상태 불일치를 기록하세요. 모든 것이 실패한다면 어시스턴트에게 레포지토리 전체를 고치게 하지 말고 대표적인 경로 하나를 고르세요.

3. 실행 경로를 추적합니다

요청이나 함수 호출을 따라가며 진입점에서 데이터 접근까지 살펴보세요. 실패한 심볼, 관련 모델 필드, 인접한 테스트를 검색하세요. route -> controller -> service -> repository 같은 짧은 경로를 그려 보세요.

4. 가설을 세웁니다

무엇이 잘못되었다고 생각하는지, 어떤 관찰 결과가 나오면 그 가설이 틀렸다고 볼 수 있는지 적으세요. 이렇게 하면 무작위 수정을 막을 수 있고, AI 어시스턴트에게도 범위가 한정된 조사를 시킬 수 있습니다.

5. 한 가지 일만 시키는 프롬프트를 씁니다

어시스턴트에게 특정 경로를 살펴보게 하거나, 조건을 설명하게 하거나, 가장 작은 패치를 제안하게 하세요. 요구사항, 관찰한 실패, 관련 파일, 제약을 함께 적으세요. 테스트를 통과시키려고 테스트를 바꾸라고 시키지 마세요.

6. diff를 검토합니다

바뀐 모든 줄을 확인하세요. 공개 동작이 바뀌었는지, 에러를 삼키는지, 로직이 중복되는지, 관련 없는 리팩터링이 섞였는지, 존재하지 않는 API를 만들어 냈는지, 지나치게 넓은 예외 처리가 있는지 보세요. 설명할 수 없는 변경은 되돌리세요.

7. 좁게 검증한 뒤 넓게 검증합니다

먼저 원래 실패했던 테스트를 다시 돌리세요. 그다음 주변 테스트를, 시간이 되면 전체 스위트를 돌리세요. 마지막으로 예제에 보이지 않던 경계 조건 하나를 테스트하세요.

이런 사고방식을 더 연습하려면 PracHub의 기존 코드베이스 면접 가이드를 활용하세요.

AI 프롬프트를 더 잘 쓰는 방법

좋은 프롬프트는 판단을 넘겨주지 않으면서 불확실성을 줄여 줍니다. 나쁜 프롬프트는 내 추론을 숨기고, 검토하기 어려운 큰 패치를 불러옵니다.

반복해서 쓸 수 있는 프롬프트 형식은 맥락 + 기대 동작 + 관찰한 근거 + 범위 + 요청 작업 + 제약입니다. 응답을 받은 뒤에는 직접 코드를 확인하세요. 그럴듯한 설명이 증거는 아닙니다.

예제: AI가 쉽게 잘못 진단하는 버그

대출에 자금을 대는 서비스가 있다고 가정해 봅시다. 공개 테스트는 일반적인 이체만 확인하지만, 히든 테스트는 금액 0, 남은 대출 잔액을 넘는 금액, 한쪽 레코드는 저장에 성공하고 다른 쪽은 실패하는 경우를 시도할 수 있습니다.

async function fundLoan(userId: string, loanId: string, amount: number) {
  const user = await users.find(userId);
  const loan = await loans.find(loanId);

  if (user.balance < amount) throw new Error("insufficient balance");

  user.balance -= amount;
  loan.funded += amount;
  await users.save(user);
  await loans.save(loan);
}

눈에 띄는 검사는 들어 있지만 문제 조건은 불완전합니다. 뛰어난 지원자는 이렇게 묻습니다. amount가 0이나 음수일 수 있는가? 대출의 남은 금액을 넘겨서 자금을 댈 수 있는가? 둘 중 한 엔티티가 없으면 어떻게 되는가? 두 번의 쓰기는 원자적이어야 하는가?

범위를 좁힌 프롬프트는 이런 모습일 수 있습니다. "자금 지원 서비스는 정상 경로는 통과하지만, 문제 조건상 금액은 양수여야 하고, 초과 지원은 안 되며, 부분적인 상태 업데이트도 없어야 합니다. 이 메서드와 리포지토리 API를 살펴보고, 테스트를 바꾸지 않고 이 불변 조건을 지키는 가장 작은 변경을 제안해 주세요."

그런 다음 제안받은 패치를 amount = 0, 음수 금액, 남은 잔액과 정확히 같은 금액, 그보다 1 큰 금액, 사용자 자금 부족, 엔티티 없음, 시뮬레이션한 저장 실패 상황에서 검증하세요. 어시스턴트는 코드를 제안할 수 있지만, 확신을 주는 것은 직접 돌린 테스트뿐입니다.

히든 테스트가 주로 확인하는 것

모든 요구사항을 최소한 정상 케이스, 경계 케이스, 실패 케이스 하나씩으로 옮겨 보세요.

히든 테스트는 대체로 수수께끼가 아닙니다. 공개 예제가 다 다루지 못하는 요구사항과 엔지니어링 불변 조건을 담고 있을 뿐입니다. PracHub의 코딩 테스트 히든 테스트 케이스 가이드에서 더 폭넓은 경계 조건 체크리스트를 볼 수 있습니다.

시간을 가장 많이 낭비하는 다섯 가지 실수

재현하기 전에 프롬프트부터 쓰기. 실제 실패 내용이 없으면 어시스턴트는 겉으로 드러난 패턴만 보고 추측합니다.

한 번에 너무 많이 바꾸기. 여러 파일에 걸친 리팩터링은 어떤 수정이 버그를 고쳤고 어떤 수정이 회귀를 일으켰는지 가리기 어렵게 만듭니다.

코드에 맞춰 테스트를 고치기. 과제에서 테스트가 틀렸다고 명시하지 않는 한, 테스트와 문서화된 문제 조건은 없애야 할 장애물이 아니라 충족해야 할 근거입니다.

통과한 공개 테스트를 믿기. 정상 경로 위주의 스위트는 권한, 롤백, 경계, 멱등성 실패를 놓칠 수 있습니다.

연습 문제: Debug a Node.js car-rental backend: leaked cars, missing new cars, lost edits(Node.js 렌터카 백엔드 디버깅: 노출된 차량, 누락된 신규 차량, 사라진 수정 내용) (Amazon · 소프트웨어 엔지니어)

허용되지 않은 외부 도구 사용하기. 연습할 때는 합법적인 도구라면 무엇이든 써도 되지만, 실제 OA에서는 Amazon과 평가 제공업체가 허용한 자료만 사용하세요. 비공개 테스트 내용을 외부 서비스에 붙여 넣지 마세요.

7일 준비 계획

진단과 알고리즘 연습에는 PracHub의 Amazon 문제 허브를 활용하세요. 이후 행동 면접 단계를 위해서는 기술 준비와 함께 Amazon 리더십 원칙 질문과 Amazon OA 워크 시뮬레이션 가이드도 함께 준비하세요.

PracHub의 실제 문제로 연습하기

아래는 모두 Amazon 문제 모음에 실제로 저장된 기록이며, 내가 볼 테스트에 나올 문제를 예측하는 것이 아닙니다. OA를 언급한 후기 출처를 우선하고, 그다음 PracHub에 저장된 기술 스크리닝, 온사이트, 과제 전형 라운드를 사용합니다. 표에는 저장된 라운드를 그대로 표시해, 근거가 다른 이름으로 바뀌지 않도록 했습니다.

문제가 실제로 묻는 것

Q1. Highest Average-Salary Team in an Org Chart
문제 모음 근거: Amazon, 기술 스크리닝, 중간. 조직도에서 평균 급여가 가장 높은 팀 회사의 보고 체계는 하나의 계층 구조입니다. 모든 직원은 고유한 정수 id, 이름, 정수 급여, 그리고 managerid(자신이 보고하는 사람의 id)를 가집니다. 정확히 한 명의 직원(CEO)만 managerid = null이며, 이는 상위 관리자가 없다는 뜻입니다.

Q2. Merge Overlapping Time Ranges
문제 모음 근거: Amazon, 기술 스크리닝, 중간. 겹치는 시간 구간 병합 공유 회의실의 예약 백엔드를 만들고 있습니다. 지금까지 들어온 각 예약은 정수 타임스탬프(epoch 초)의 쌍 [start, end]로 기록되며, start <= end입니다.

Q3. Caesar Cipher with Translation-Table Optimization
문제 모음 근거: Amazon, 기술 스크리닝, 중간. 카이사르 암호를 구현하세요. 문자열 text와 정수 shift가 주어지면, 모든 알파벳 문자를 자신의 대소문자 범위 안에서 shift칸만큼 앞으로 회전시키고 알파벳 끝에서는 처음으로 돌아가는 새 문자열을 반환하세요. 알파벳이 아닌 문자는 그대로 둡니다.

Q4. Detect and Break a Cycle in a Singly Linked List
문제 모음 근거: Amazon, 기술 스크리닝, 중간. 단일 연결 리스트의 head가 주어집니다. 리스트에는 사이클이 있을 수도, 없을 수도 있습니다. 리스트 어딘가에서 한 노드의 next 포인터가 앞쪽 노드를 다시 가리켜 루프를 만들 수 있습니다. 두 가지를 하세요. 1. 리스트에 사이클이 있는지 탐지합니다. 2.

실제 테스트처럼 이 세트를 풀어 보세요

1. 네 문제를 먼저 모두 읽으세요. 각 문제의 난이도를 가늠하고 코딩하기 전에 푸는 순서를 정하세요.
2. 풀이는 가리세요. 에디터를 열기 전에 불변 조건, 목표 복잡도, 엣지 케이스 세 가지를 적으세요.
3. 타이머는 하나만 쓰세요. 마지막 5분은 경계, 동점, 규모, 출력 형식 테스트용으로 남겨 두세요.
4. 실패 유형을 기록하세요. 문제 제목만 적지 말고, 깨진 불변 조건이나 놓친 엣지 케이스를 기록하세요.

Amazon AI 지원 코딩 OA FAQ

AI 지원 레포지토리 과제가 이제 모든 Amazon SDE OA에 나오나요?

그렇다고 확인해 주는 Amazon 공개 페이지는 없습니다. 2026년 여러 지원자가 SDE I, 신입(graduate), 인턴, 일부 SDE II 전형을 포함해 이 과제를 받았다고 전하지만 형식은 제각각입니다. 초대 메일에 적힌 구성을 따르세요.

버그와 히든 테스트는 몇 개인가요?

지원자 후기마다 버그와 테스트 개수가 다릅니다. 숫자 하나에 맞춰 준비하지 마세요. 레포지토리에 결함이 두 개든 여러 개든 통하는, 반복 가능한 디버깅·검증 루프를 훈련하세요.

내장 어시스턴트는 Amazon Q인가요?

그렇다고 단정하지 마세요. Amazon Q Developer에 대한 공개 문서는 있지만, 그것이 테스트에 내장된 어시스턴트의 정체나 기능을 입증하지는 않습니다. 테스트에서 제공하는 인터페이스와 도움말을 따르세요.

OA 중에 ChatGPT, Claude 같은 외부 AI를 써도 되나요?

테스트 지침에서 명시적으로 허용한 경우에만 가능합니다. Amazon의 대학 지원자용 OA 안내에 따르면 브라우저 사용 내역이 기록될 수 있고 복사·붙여넣기 행위에 대해 경고합니다. 안전한 원칙은 내 테스트에서 명시적으로 허용한 내장 어시스턴트와 자료만 사용하는 것입니다.

AI가 만든 패치가 공개 테스트를 통과하면 어떻게 하나요?

diff를 검토하고 문제 조건을 직접 테스트하세요. 잘못된 입력, 경계, 저장, 권한, 재시도, 인접 동작을 확인하세요. 일부를 도구가 생성했더라도 제출한 구현에 대한 책임은 본인에게 있습니다.

모든 테스트를 통과하면 면접이 보장되나요?

Amazon은 이 과제에 대해 공통된 합격선이나 가중치를 공개하지 않습니다. 공식 OA 페이지는 코딩, 문제 해결, 업무 스타일, 그 밖에 직무에 따른 섹션이 포함될 수 있는 더 폭넓은 평가를 설명합니다. 필수 섹션을 모두 꼼꼼히 마치세요.

마무리

2026년 Amazon AI 지원 코딩 OA는 인터페이스를 바꿨을 뿐 엔지니어링 기준을 바꾸지는 않았습니다. 요구사항을 이해하고, 낯선 코드를 탐색하고, 결함을 분리하고, 작고 설명 가능한 변경을 하고, 정상 경로를 넘어서도 동작함을 증명할 수 있어야 합니다.

두 가지 영역을 함께 연습하세요. 알고리즘 속도는 PracHub의 Amazon 코딩 문제로 키우고, 디버깅, 테스트, 전체 면접 과정에서의 판단력은 최신 Amazon 면접 후기와 풀이로 훈련하세요. 목표는 AI가 유능해 보이게 만드는 것이 아닙니다. 내가 끝까지 통제하는 엔지니어임을 보여 주는 것입니다.

출처 및 추가 자료

• Amazon Jobs: Online Assessment Prep for SDE Roles
• Amazon Jobs: SDE II Online Assessment Prep
• Amazon Jobs: Software Development Interview Topics
• 지원자 토론: Amazon SDE I AI 지원 레포지토리 형식
• 지원자 후기: SDE I 신입 OA, 런던, 2026년 7월