Amazon SDE 인터뷰 후기 — 라운드 1

최근 Amazon SDE Round 1 인터뷰를 치렀습니다.

인터뷰는 약 60분 동안 진행되었습니다.

먼저 간단한 자기소개로 시작했습니다. 면접관은 제 배경과 최근에 어떤 작업을 했는지 물어봤습니다.

그다음 DSA(자료구조 및 알고리즘) 문제로 넘어갔습니다.

문제 1 — 연결 리스트 (Linked List)

첫 번째 문제는 연결 리스트를 기반으로 했습니다. 노드를 조작하면서 올바른 포인터 참조를 유지해야 하는 연결 리스트 문제가 주어졌습니다.

저는 먼저 간단한 접근 방식을 설명했고, 이후 상수 추가 공간(O(1) extra space)을 사용하여 단일 순회(single traversal)로 문제를 해결하도록 최적화했습니다.

면접관은 엣지 케이스(edge cases)와 관련하여 몇 가지 후속 질문을 했습니다:

• 리스트가 비어있으면 어떻게 할까요?
• 노드가 하나만 있으면요?
• 포인터를 변경할 때 참조를 잃지 않도록 어떻게 보장하나요?
• O(1)의 추가 공간으로 해결할 수 있나요?

저는 최적화된 솔루션을 코딩하고 몇 가지 테스트 케이스를 직접 따라가며 설명했습니다.

시간 복잡도: O(n)
공간 복잡도: O(1)
문제 2 — 이진 탐색 (Binary Search)

두 번째 문제는 이진 탐색을 기반으로 했습니다.

이 문제에 바로 이진 탐색을 적용할 수 있다는 것이 명확하지 않았습니다. 저는 처음에 무차별 대입 방식(brute-force approach)을 설명했습니다. 제약 조건들을 살펴본 후, 검색 공간이 단조성(monotonic property)을 가진다는 점을 발견했고, 따라서 '답에 대한 이진 탐색 (Binary Search on Answer)'을 사용할 수 있다는 것을 깨달았습니다.

면접관은 저에게 다음 사항들을 설명해 달라고 요청했습니다:

• 정확히 검색 공간이 무엇인지
• 왜 조건이 단조적인지
• 왼쪽 또는 오른쪽으로 이동할지 어떻게 결정했는지
• 하한(lower)과 상한(upper) 경계를 어떻게 선택했는지

그 후 저는 최적화된 솔루션을 구현했습니다.

경계 조건, mid 계산 시 정수 오버플로우, 그리고 몇 가지 엣지 케이스와 관련된 추가 질문들이 있었습니다.

특히 한 질문은 다음과 같았습니다:
“여기서 이진 탐색이 왜 작동하나요?”

단순히 이것이 이진 탐색 문제라고 말하는 대신, 매 반복마다 검색 공간의 절반을 제거할 수 있게 해주는 단조적 속성(monotonic property)에 대해 설명했습니다.

프로젝트 토론

DSA 질문들이 끝난 후, 면접관은 제 이력서로 넘어갔습니다.

가장 먼저 논의된 내용은 Sugar Labs에서 진행했던 2026 Google Summer of Code 프로젝트였습니다.

면접관은 제가 GSoC 기간 동안 실제로 무엇을 구축했는지 설명해달라고 요청했습니다.

저는 사용자들이 다양한 AI 모델 제공업체를 사용하여 활동(activity)을 생성, 미리 보기, 개선 및 내보낼 수 있는 Python/GTK3 스튜디오를 구축했다고 이야기했습니다.

그러자 면접관은 아키텍처에 대해 더 깊이 파고들기 시작했습니다.

그는 다음과 같은 질문들을 했습니다:

“UI가 멈추지 않도록 모델 요청을 어떻게 처리했나요?”

저는 처음에 이것이 중요한 문제였다고 설명했습니다. 왜냐하면 모델 요청에는 시간이 걸릴 수 있고, 이를 GTK의 메인 UI 스레드에서 직접 실행하면 애플리케이션이 멈출(freeze) 것이기 때문입니다.

그래서 저는 사용자 인터페이스를 반응성 있게 유지하면서 해당 요청들을 백그라운드 워커로 옮겼습니다.

그러자 그는 다음과 같이 물었습니다:

“생성된 코드가 잘못되면 어떻게 되나요?”

저는 제가 구축한 검증 파이프라인을 설명했습니다.

시스템은 생성된 변경 사항을 적용하기 전에 다음 등의 작업을 수행했습니다:

• AST(추상 구문 트리) 유효성 검사
• GTK 런타임 체크
• 코드 유효성 검사
• 트랜잭션 패치

만약 무언가 실패하면, 활동을 손상된 상태로 남겨두는 대신 마지막으로 작동했던 버전으로 롤백할 수 있었습니다.

그는 또한 애플리케이션이 충돌하거나 재시작될 경우 어떻게 상태를 유지하는지도 물었습니다.

저는 세션, 작업(jobs), 리비전 히스토리(revision history)를 재시작에 걸쳐 보존하기 위해 원자적 JSON 영속성(atomic JSON persistence)을 사용했다고 설명했습니다.

우리는 제가 단순히 어떤 기술을 사용했는지보다는 왜 그러한 아키텍처 결정을 내렸는지에 대해 많은 시간을 할애하여 논의했습니다.

그러고 나서 그는 VengeanceUI로 넘어갔습니다.

그는 이 프로젝트가 1,000개 이상의 GitHub 스타와 약 4만 개의 월간 방문자 수를 가지고 있다는 것을 알아차렸고, 그래서 첫 번째 질문은 기본적으로 다음과 같았습니다:

“이것을 직접 만드셨나요?”

저는 원래 VengeanceUI v1을 출시했고, 사용자 피드백을 바탕으로 그 상당 부분을 v2로 재구축했다고 설명했습니다.

면접관은 이어서 물었습니다:

“v1과 v2 사이에 무엇이 바뀌었나요?”

저는 문서 아키텍처를 Nextra/MDX에서 Next.js App Router로 옮기고, 타입이 지정된 카탈로그 데이터(typed catalog data)를 도입했으며, 재사용 가능한 서버/클라이언트 컴포넌트를 생성한 방법을 설명했습니다.

이후 논의는 성능(performance) 쪽으로 넘어갔습니다.

그가 다음과 같이 질문했습니다:

“웹사이트에 애니메이션 컴포넌트가 많이 보이는데, 이 모든 것이 동시에 실행되는 것을 어떻게 방지하나요?”

저는 IntersectionObserver와 Page Visibility API를 사용했다고 설명했습니다.

애니메이션 미리보기는 다음 조건일 때만 마운트(mount)됩니다:

• 미리보기 탭이 활성화되었을 때
• 뷰포트(viewport) 근처에 있을 때
• 브라우저 탭 자체가 보일 때

따라서 한 페이지에 수십 개의 컴포넌트 데모가 있어도, 모든 애니메이션을 불필요하게 실행하지 않습니다.
이후 그는 코드 미리보기(code previews)에 대해 질문했습니다.
저는 컴포넌트 소스 코드가 즉시 가져와지지 않는다고 설명했습니다.

소스 요청은 사용자가 실제로 Code 또는 Manual 뷰를 열 때까지 지연되며, 구문 강조(syntax highlighting)는 브라우저 내부에서 모든 초기 처리를 하는 대신 서버 측 Shiki API를 사용하여 처리합니다.

또한 VengeanceUI가 약 27개의 문서화된 컴포넌트에서 75개로 어떻게 성장했는지, 그리고 레지스트리(registry)가 85개에서 132개 항목으로 확장된 방법에 대해서도 이야기했습니다.

마지막에는 좀 더 제품 중심적인 질문을 했습니다:

“사람들이 실제로 사용하기 시작하게 만든 것은 무엇인가요?”

이것은 오픈 소스(open source), 사용자 피드백, 문서화(documentation), 개발자 경험(developer experience) 그리고 제가 어떤 컴포넌트를 다음에 구축할지 결정한 방법에 대한 논의로 이어졌습니다.

또한 VengeanceUI 컴포넌트를 Cursor나 Claude 같은 도구와 함께 사용하는 데 제가 구축한 MCP 툴링에 대해서도 간략하게 이야기했습니다.

전반적으로 이 라운드는 다음과 같았습니다:

DSA → GSoC 기술 심층 분석(technical deep dive) → VengeanceUI 아키텍처/제품 논의

DSA 질문들은 아주 어렵지는 않았습니다.
프로젝트 논의가 실제로는 훨씬 더 깊었습니다.

면접관이 관심 가졌던 것은 다음과 같은 것이 아니었습니다:

“저는 Next.js를 사용했어요.”

그는 다음을 알고 싶어 했습니다:

“왜 그것을 사용했나요?”

“어떤 문제를 해결하고 있었나요?”

“무엇이 고장 났었나요(What broke)?”

“어떻게 고쳤나요(How did you fix it)?”

“사용량이 증가하면 어떻게 되나요(What happens when usage increases)?”

아마도 이것이 제가 이 라운드에서 얻은 가장 큰 교훈일 것입니다.

만약 무언가가 당신의 이력서에 적혀 있다면, 불렛 포인트보다 몇 단계 더 깊게 설명할 준비가 되어 있어야 합니다.