면접 예상질문

1. 1분 자기소개를 해주세요.

   이력서 태그라인("아키텍처를 정하고, 지켜지도록 도구를 만든다")과 같은 이야기로 시작하면 문서와 말이 일치한다.

   아키텍처를 정하고, 그 결정이 코드에서 지켜지도록 도구를 만들어 온 프론트엔드 개발자 인호준입니다. 여러 조직이 함께 쓰는 플랫폼과 대고객 서비스를 5년간 만들어 왔습니다.

   무신사에서 신설 조직의 프론트엔드 아키텍처를 설계해 팀 표준으로 정착시켰고, 문서로만 남으면 지켜지지 않는다고 봐서 그 규칙을 CI에서 검증하는 AI 리뷰 봇으로 이었습니다. 최근에는 백엔드가 Public API를 제공하지 않는 구조 전환에서, 프론트엔드가 직접 소유하는 BFF의 기술 선택을 실측 벤치마크로 검증해 주도했습니다. 지금은 5개 플랫폼·14개 판매지역을 다루는 크로스플랫폼 상품 어드민을 만들고 있습니다.

   (마무리는 지원 회사에 맞춰: 이 경험이 왜 이 팀에서 쓸모 있는지 한 문장)

   1. 판단 근거규칙을 문서로만 남기면 지켜지지 않는다고 보고 CI 검증으로 연결하셨다고 했는데, 그렇게 판단하게 된 근거는 무엇이었나요? KR규칙을 도구로 강제해야 한다는 판단이 겪은 상황에서 나왔는지, 일반론에서 나왔는지를 가른다.
   2. 구체화지금 만들고 있다고 하신 크로스플랫폼 상품 어드민에서 요즘 가장 많은 시간을 쓰는 작업은 무엇인가요? KR소개에서 현재 하는 일로 말한 부분이 실제 업무와 이어지는지, 세부가 바로 나오는지 본다.
   3. 명료도소개에서 말한 아키텍처 설계 경험을 더 길게 설명해야 한다면 어떤 순서로 풀어 가시겠어요?한 문장으로 요약한 경험을 듣는 사람이 따라올 수 있는 순서로 다시 풀어내는지 본다.
2. 이직을 결심한 이유는 무엇인가요? 현재 회사에 대한 불만보다, 다음에서 하고 싶은 일로 답을 끝내는 편이 안전하다.
3. 본인의 강점은 무엇이고, 그걸 보여준 사례는 무엇인가요?

   결정을 근거와 함께 남기고, 그 결정이 지켜지게 만드는 것입니다. BFF 기술 선택 때는 통념("프레임워크가 빠르면 서버도 빠르다")을 그대로 받지 않고 세 프레임워크에 동일 코드를 올려 실측했고, 결과를 ADR로 남겼습니다. 아키텍처는 문서에서 끝내지 않고 AI 룰 파일과 CI 봇으로 이어 규칙이 코드에서 검증되게 했습니다. 말이 아니라 문서·측정·도구로 증명하는 방식이 제 강점입니다.

   1. 트레이드오프규칙을 도구로 강제하면 팀원의 재량이 줄어들 수 있는데, 어디까지를 규칙으로 두고 어디부터 재량에 맡기시나요?결정이 지켜지게 만드는 강점이 팀의 자율성과 부딪히는 지점을 스스로 아는지 본다.
   2. 조건 변경근거를 모으거나 실측할 시간이 없는 상황이라면 결정을 어떤 방식으로 내리시겠어요? US근거와 측정을 앞세우는 강점이 자료가 부족한 상황에서도 작동하는지 본다.
   3. 구체화BFF 기술 선택이나 CI 봇 같은 큰 일 말고, 같은 강점이 일상 업무에서 드러난 사례를 하나 들어 주시겠어요?강점이 큰 프로젝트에서만 나타나는지, 평소 일하는 방식으로 자리 잡았는지 본다.
4. 약점 혹은 아직 부족하다고 느끼는 부분은 무엇인가요? "보완하려고 무엇을 하고 있는지"까지 붙지 않으면 그냥 약점만 남는다.
5. 앞으로 어떤 개발자가 되고 싶으신가요? 3년 뒤 모습은?
6. 저희 회사에 지원한 이유는 무엇인가요? 회사마다 다시 쓸 자리. 제품을 직접 써본 경험이 있으면 그게 가장 세다.
7. 지금까지 한 일 중 가장 어려웠던 문제는 무엇이었나요?
8. 일하면서 가장 몰입했던 순간은 언제였나요?

일하는 방식

1. 지금 개발할 때 AI를 어떻게 쓰고 계신가요? 어떤 작업에 쓰고, 어떤 작업에는 일부러 안 쓰나요?

   "써봤다"가 아니라 경계선을 그어본 사람인지를 본다. AI Native 조직에서 가장 먼저 나올 질문.

   네 갈래로 씁니다. 코드리뷰 자동화(아키텍처 준수를 CI에서 검사하는 봇), PR 생성 커맨드, 문서 작성, 그리고 스펙 주도 개발(Speckit으로 Figma·요구사항을 스펙 파일로 만들어 User Story 단위로 구현·PR 분할)입니다. 최근에는 PRD에서 PR까지 잇는 사내 도구를 직접 만들고 있습니다.

   경계선은 명확합니다. 결정론적으로 풀리는 일에는 AI를 쓰지 않습니다. 리뷰 봇에서 GitHub API 호출은 Actions 스크립트가 하고 AI는 분석만 하며, 사내 도구에서도 환경 파악 1회만 AI가 하고 타입 추출·파싱은 전부 코드로 돌립니다. AI 응답은 그대로 믿지 않고 타입가드로 검증한 뒤 씁니다.

2. AI가 생성한 코드를 어떤 기준으로 검수하나요? 이해하지 못한 채 머지한 적은 없나요?
3. AI를 썼는데 오히려 느려지거나 품질이 나빠진 경험이 있나요?

   장점만 말하면 실사용 깊이를 의심받는다. 실패 사례가 오히려 신뢰를 만든다.

   두 가지가 있습니다. 리뷰 봇 초기에 공식 예제대로 GitHub MCP 서버를 붙여 AI가 API를 직접 호출하게 했더니, 대용량 PR에서 토큰과 API 요청이 기하급수로 늘었습니다. 필요한 데이터를 미리 뽑아 넘기고 AI는 분석만 하도록 구조를 바꿨습니다. 또 PRD 분석 도구는 한 번 돌리는 데 10분 가까이 걸려 일상적으로 쓰기 어려웠습니다 — AI를 넣는 것보다 AI 호출을 줄이고 병렬화하는 설계가 실제 과제였습니다.

4. 같은 작업을 AI에게 잘 시키기 위해 본인만의 방식이 있나요? 컨텍스트를 어떻게 주나요?

   컨텍스트를 대화에 쌓지 않고 파일로 관리합니다. 아키텍처 규칙은 AI 룰 파일로 만들어 에디터·CI·리뷰 봇이 같은 파일을 참조하고(처음엔 Cursor 규칙 포맷으로 시작해 지금은 팀 공통 룰 디렉터리로 옮겼습니다), 기능 요구사항은 스펙 파일로 만들어 UI·Service·API 레이어가 같은 명세를 공유합니다. 스펙 파일은 버전 관리가 되니 변경 이력도 남고, AI 컨텍스트 길이 한계도 파일 참조로 우회됩니다.

5. AI 도구를 팀에 확산시켜본 경험이 있나요? 안 쓰려는 동료는 어떻게 설득하나요?
6. 사내 코드를 외부 LLM에 보내는 것에 대한 보안·라이선스 이슈는 어떻게 다루나요?
7. AI에 의존하면 주니어의 성장이 막힌다는 우려가 있습니다. 어떻게 보시나요?

직접 만든 AI 기능 — Architecture Keeper

1. Architecture Keeper가 뭐고, 어떤 원리로 동작하나요?

   이력서에서 가장 강한 AI 크레덴셜. 그림을 그려가며 설명할 수 있어야 한다.

   아키텍처 규칙 준수를 CI에서 검사하는 AI 코드리뷰 봇입니다. type check나 lint로는 "feature 레이어에서 API 레이어를 직접 호출하지 않는다" 같은 규칙을 잡을 수 없고, 아키텍처에 익숙한 소수가 매번 수동 리뷰로 잡는 건 지속 가능하지 않아서 만들었습니다.

   동작은 세 단계입니다. Setup이 PR 이벤트 타입에 따라 diff 범위를 정하고(처음 열리면 전체, 커밋이 추가되면 그 차이만) 변경 파일에서 영향받은 레이어를 감지해 matrix를 만듭니다. Review가 레이어별로 병렬 실행되는데, 해당 레이어의 규칙 파일과 전체 파일 컨텍스트를 포함한 diff를 환경변수로 주입해 Gemini에 넘기고, 응답은 타입가드로 필드 단위 검증해 유효한 것만 남깁니다. 마지막으로 라인 단위 리뷰 코멘트를 달고 요약을 남깁니다. 전 단계가 실패 허용이라 AI 리뷰가 CI를 막는 일은 없습니다.

2. 그 봇은 지금도 돌고 있나요?

   현재형으로 말했다가 "지금은 없다"가 드러나면 신뢰를 잃는다. 먼저 밝히는 편이 낫다.

   아니요. 4개월쯤 운영하다 제가 직접 걷어냈습니다. 처음 만들 때는 코딩 에이전트를 CI에 붙이는 표준적인 방법이 없어서, CLI를 워크플로에 물리고 프롬프트·응답 파싱·타입가드·코멘트 게시를 전부 직접 관리했습니다. 그사이 생태계가 정리되면서 같은 일을 훨씬 적은 코드로 할 수 있는 방식이 생겼고, 800줄짜리 워크플로를 유지할 이유가 없어졌습니다.

   없앨 때 기준은 하나였습니다 — 목적이 사라진 게 아니라 수단이 더 싸졌다면 갈아탄다. "아키텍처 규칙을 CI에서 검증한다"는 목적은 그대로고, 규칙 파일도 그대로 남아 다음 방식이 읽습니다. 제가 만든 것이라 아까워서 붙들고 있으면 그게 부채가 된다고 봤습니다.

   1. 선택 근거800줄짜리 워크플로를 줄여 계속 운영하는 선택지는 검토하지 않았나요? US

      갈아타기 전에 유지하는 쪽의 대안을 견주어 보았는지 확인한다.

      1. 트레이드오프표준화된 액션으로 옮기면서 직접 만든 파이프라인이 하던 일 중 포기한 것은 무엇인가요? KR·US더 싸진 대가로 잃은 것을 스스로 알고 있는지 본다.
   2. 트레이드오프이미 들인 개발 시간은 걷어낼지 정할 때 어떻게 셈에 넣었나요? US

      이미 쓴 비용에 끌려 유지하려는 판단을 어떻게 걸러 냈는지 본다.

      1. 조건 변경코딩 에이전트를 CI에 붙이는 표준적인 방식이 정리된 뒤에도 봇을 한동안 두었다면, 걷어낼 시점은 무엇을 보고 정했나요?

         표준적인 방식이 정리된 시점과 걷어낸 시점 사이에서 갈아탈 때를 무엇으로 가늠했는지, 바뀐 조건을 어떻게 알아챘는지 본다.

         1. 회고규칙 파일 말고, 4개월 운영한 봇에서 지금도 남아 쓰이는 것은 무엇인가요?걷어낸 뒤에도 남은 자산을 스스로 짚을 수 있는지 본다.
   3. 결과 검증봇이 잘못 지적한 것 말고, 지적하지 않고 지나간 위반은 운영하는 동안 어떻게 알 수 있었나요? KR·US

      AI 리뷰가 놓친 것은 결과에 드러나지 않는다는 점을 알고 이를 찾을 방법이 있었는지 본다.

      1. 실패와 장애위반이 없으면 "잘 준수했다"고 남기는 코멘트 때문에 사람 리뷰어가 그 부분을 덜 살핀 일은 없었나요? KRAI 리뷰의 통과 신호가 사람의 주의를 줄이는 부작용을 보았는지 확인한다.
   4. 협업과 이견봇을 걷어내기로 했을 때 팀에서 아쉬워하거나 반대한 사람은 없었나요?직접 걷어낸 결정에 대한 팀의 입장을 살폈는지 본다.
3. PR 봇의 프롬프트는 어떻게 설계했나요? 몇 번쯤 고쳤나요?

   핵심은 하지 말 것을 명시하는 쪽이었습니다. "+/− 마커가 붙은 변경 라인만 리뷰하라", "아키텍처 원칙 외의 컨벤션·주석은 지적하지 말라", "위반이 없으면 빈 배열을 반환하라", "출력은 raw JSON 배열만". diff는 -U99999로 뽑아 변경 라인만이 아니라 파일 전체 맥락을 함께 줬습니다 — 맥락이 없으면 오탐이 늘어서요. 규칙과 diff는 셸 이스케이프 사고를 막으려고 환경변수 블록으로 주입했습니다.

4. 봇의 판단이 맞는지 어떻게 확인했나요? 평가셋이나 회귀 테스트를 만들었나요?

   별도의 평가셋은 만들지 못했습니다. 대신 두 겹으로 방어했습니다. 형식 오류는 타입가드가 걸러냅니다 — JSON 유효성, 배열 여부, 각 항목의 파일·라인·코멘트 필드 타입까지 검증하고 실패한 항목은 버립니다. 판단 오류는 포지션으로 흡수했습니다 — 봇을 차단이 아니라 참고용으로 두어 오판 비용을 낮췄습니다. 다시 만든다면 실제 위반 사례를 모아 회귀 평가셋부터 만들 겁니다.

5. 같은 PR에 매번 다른 답을 내놓는 비결정성 문제는 어떻게 다뤘나요?

   완전히 없앨 수는 없다는 전제에서 출발했습니다. 출력 형식을 강하게 제약하고(빈 배열 규칙, raw JSON만) 타입가드로 형식 변동을 흡수해서, 비결정성이 파이프라인을 깨뜨리는 일은 막았습니다. 리뷰 내용이 달라질 수 있다는 건 참고용 포지션으로 수용했고요. 반대로 결정성이 필요한 부분 — diff 추출, 레이어 감지, 코멘트 게시 — 은 전부 AI 밖의 스크립트가 담당합니다.

6. 정적 분석 규칙(ESLint 등)으로 충분한 것과 LLM이 필요한 것을 어떻게 나눴나요?

   "AI로 풀 문제인가"를 판단할 줄 아는지 보는 질문. 전부 LLM에 맡겼다면 설계 감각을 의심받는다.

   lint와 type check로 표현할 수 있는 건 그쪽에 뒀습니다. LLM에 맡긴 건 규칙은 명확한데 정적 도구로 기술하기 어려운 영역 — 레이어 간 의존 방향, 비즈니스 로직이 어느 레이어에 있어야 하는지 같은 판단입니다. 이건 원래 아키텍처에 익숙한 소수가 수동 리뷰로 잡던 것이라, 사람의 판단을 대체하는 게 아니라 사람에게 몰리던 반복 판단을 옮긴 것에 가깝습니다.

7. 오탐이 나올 때 개발자 경험은 어떻게 지켰나요? 차단(blocking)인가요, 권고인가요?

   권고입니다. 처음부터 CI를 막지 않는 참고용으로 위치를 정했고, 모든 단계에 continue-on-error를 걸었습니다. 피로를 줄이려고 커밋이 추가될 때는 전체가 아니라 그 커밋의 diff만 다시 봅니다(증분 리뷰). 위반이 없으면 "잘 준수했다"는 코멘트 하나로 끝나고요. 봇 코멘트가 소음이 되는 순간 아무도 안 읽게 된다는 걸 가장 경계했습니다.

8. 토큰 비용과 응답 지연은 어떻게 관리했나요?

   세 가지입니다. 증분 리뷰로 호출 범위 자체를 줄였고, 공식 예제의 GitHub MCP 방식(AI가 API를 직접 호출)이 대용량 PR에서 토큰을 폭증시키는 걸 확인하고 데이터 사전 추출 + 역할 분리로 재설계해 토큰 사용량을 예측 가능하게 만들었습니다. 무료 한도(일 250회, 분당 10회) 안에서 팀 규모에 맞게 운용했고, 초과 시 응답 코드까지 문서에 남겼습니다.

9. 지금 다시 만든다면 무엇을 다르게 하시겠어요?

직접 만든 AI 기능 — 자율형 프론트엔드 엔진

1. 자율형 프론트엔드 엔진(FEFlow)이 뭔가요?

   PM이 PRD를 쓰고 디자이너가 퍼블리싱하면 GitHub PR 초안까지 만들어지는 사내 데스크톱 도구입니다. 단계마다 사람이 같은 정보를 다시 옮겨 적는 낭비를 없애는 게 목적이고, FE 개발자는 생성된 PR을 리뷰하고 비즈니스 로직을 얹는 쪽으로 이동합니다. Tauri + React로 만들었고 설계와 구현을 제가 맡았습니다.

2. AI 호출을 어떻게 설계했나요? 전부 AI가 하나요?

   비용·재현성 감각을 보는 질문. "전부 AI"라고 하면 감점.

   구조는 AI 호출을 줄이는 방향으로 잡았습니다. 디자인 시스템 환경 파악은 워크스페이스 프로파일로 한 번만 조사해 캐싱하고, 이후 단계는 그 결과를 참조만 합니다. 매 작업마다 저장소를 다시 훑지 않기 위해서입니다.

   정직하게 덧붙이면, 지금 프로덕션 경로는 제가 원래 목표한 만큼 결정론적이지는 않습니다. 타입 정의를 정규식으로 파싱해 AI 없이 컴포넌트·토큰을 뽑는 경로를 따로 구현해뒀는데, 실제로 앱이 쓰는 건 여전히 AI 기반 경로입니다. 결정론적 파서가 커버하지 못하는 형태가 남아 있어 아직 전환하지 못했고, 이건 제가 인지하고 있는 기술 부채입니다.

3. 프리뷰에서 만든 코드가 프로덕션에서도 똑같이 동작한다는 걸 어떻게 보장하나요?

   "보장"이라고까지 말하긴 어렵고, 어긋날 여지를 구조적으로 줄이는 쪽입니다. 프리뷰 앱의 설정 파일 전부(package.json·엔트리·전역 CSS·빌드 설정)를 실행할 때마다 원본에서 다시 생성해, 작업 중 AI가 건드려도 복원되게 했습니다. PR을 만들 때도 코드를 재작성하지 않고 import 경로만 조정하는 원칙을 뒀습니다.

   다만 타입체크나 빌드를 프로그램으로 강제하는 게이트는 아직 없습니다. 커밋 전 자체 점검을 프롬프트 지시로 두고 있는데, 그건 권고지 보증이 아닙니다. 실제로 이 부분이 다음 보완 대상이라고 보고 있습니다.

   1. 선택 근거프리뷰 앱을 따로 두지 않고 프로덕션 코드가 있는 저장소 안에서 바로 화면을 만드는 선택지는 검토하지 않았나요?

      프리뷰 앱을 따로 두는 결정이 어긋남의 출발점이 될 수 있다는 점을 알고 대안을 견주었는지 확인한다.

      1. 트레이드오프설정 파일을 매번 다시 생성해도 프리뷰 앱과 프로덕션 사이에 남는 차이가 있다면 무엇인가요?

         구조로 줄이지 못한 어긋남이 어디에 남는지 스스로 짚을 수 있는지 본다.

         1. 실패와 장애프리뷰에서는 정상이던 화면이 프로덕션 코드에 옮기자 다르게 동작한 적은 없었나요?어긋남을 실제로 겪었는지, 겪었다면 어느 지점에서 드러났는지 본다.
   2. 판단 근거설정 파일을 매번 원본에서 다시 생성하는 범위는 무엇을 기준으로 정했나요?

      어긋남을 만드는 파일을 가려낸 근거가 있었는지, 관례로 정한 범위는 아닌지 본다.

      1. 트레이드오프AI가 건드린 설정을 다음 실행에서 복원하면, 그 변경이 화면에 꼭 필요한 것이었을 때는 어떻게 되나요?설정을 복원하는 안전장치가 필요한 변경까지 지울 수 있다는 점을 알고 있는지 본다.
   3. 결과 검증커밋 전 자체 점검을 프롬프트로 지시한다고 했는데, AI가 그 점검을 실제로 했는지는 어떻게 확인하나요?권고로 둔 점검이 지켜졌는지 알 방법이 있는지, 지켜졌다고 가정하고 있지는 않은지 본다.
   4. 조건 변경타입체크와 빌드를 프로그램으로 강제하는 게이트를 넣는다면, 실패한 결과를 AI에게 다시 넘길지 사람에게 넘길지는 무엇을 기준으로 정하시겠어요? KR

      다음 보완 대상이라고 한 게이트를 설계로 옮겨 보았는지, 실패를 처리하는 방법까지 생각했는지 본다.

      1. 회고처음 설계에서 게이트를 뒤로 미룬 이유가 있었다면, 그 이유는 지금도 유효한가요? KR게이트를 뒤로 미룬 이유가 있었다면 그것을 지금 다시 따져 볼 수 있는지 본다.
4. AI에게 저장소 쓰기 권한을 주는데, 사고가 나면 어떡하나요?

   AI 에이전트의 신뢰 경계 설계를 묻는 질문. AI Native 조직에서 특히 자주 나온다.

   권한을 좁히는 대신 사고 반경을 격리하는 쪽을 택했습니다. PR 생성 작업은 별도 git worktree를 만들어 그 안에서만 수행하고, 성공하든 실패하든 정리되도록 했습니다. 메인 작업 트리는 건드리지 않습니다.

   이 선택의 위험은 설계 문서의 리스크 표에 명시해뒀습니다. 사람이 매 단계 확인하는 방식으로는 자동화의 이점이 사라져서, 넓은 권한을 주되 되돌릴 수 있는 공간 안에서만 주는 쪽이 맞다고 판단했습니다. 지금 규모에서는 유효하지만 도구가 팀 전체로 퍼지면 다시 볼 문제라고 생각합니다.

5. 속도 개선은 어떻게 했고 얼마나 줄었나요?

   먼저 벤치마크 스크립트를 만들어 단계별 소요를 실측했습니다. 분석과 분해가 대부분을 차지했고, 그중 분해를 병렬화했습니다. 결과적으로 실사용 PRD 기준 전체 소요가 9~11분에서 5~6분으로 줄었습니다.

6. LLM 출력은 매번 다른데 성능 개선을 어떻게 측정했나요?

   비결정적 시스템의 평가 설계를 묻는 질문. 실제 경험이 있어야 답할 수 있다.

   기존 방식과 개선 방식의 출력을 유사도로 비교하는 채점기를 만들어 회귀를 감지했습니다. 그런데 병렬화한 쪽이 회귀로 판정됐는데 실제로 열어보니 결과물이 더 나았습니다. 항목을 더 잘게 쪼개서 개수가 달라졌고, 유사도 점수만 떨어진 것이었습니다.

   측정 방법 자체가 틀렸다고 보고 절대 점수 기준을 버렸습니다. 기존 방식 대비 상대 평가로 바꿔서, 개수가 달라도 품질이 떨어지지 않으면 통과하도록 기준을 다시 세웠습니다. 비결정적 출력에서는 채점기도 함께 의심해야 한다는 걸 배운 사례입니다.

7. 지금 병목은 뭐고 어떻게 풀 계획인가요?

   속도는 절반으로 줄였지만 분석 단계는 여전히 수 분 단위라 일상적으로 쓰기엔 마찰이 있습니다. 구조적으로는 PRD가 바뀔 때마다 전체를 다시 생성하는 대신 바뀐 부분만 갱신하는 증분 처리가 근본 해법이라고 봅니다.

   아키텍처 쪽으로는 노드 구조를 중첩 트리에서 평면 맵으로 바꾸는 재설계를 진행 중입니다. 중첩 구조에서는 부분 업데이트를 반영할 때 경로를 따라 내려가며 갱신해야 해서, 스트리밍으로 조금씩 들어오는 결과를 반영하기가 까다로웠습니다.

   1. 결과 검증경력기술서에 아직 숫자로 증명할 단계는 아니라고 적으셨는데, 처리 속도 말고 어떤 지표를 무엇과 비교해 증명해 보시겠어요? KR·US

      속도 외의 효과를 숫자로 보여 줄 기준, 곧 무엇을 무엇과 견주면 증명이 되는지 갖고 있는지 본다.

      1. 판단 근거백오피스 제품에서 화면이 디자인 시스템대로 기민하게 만들어졌다는 판단은 무엇을 보고 내렸나요?

         숫자 없이 확인했다고 말한 결과가 어떤 관찰에서 나왔는지, 인상에 그치지 않는지 가른다.

         1. 조건 변경PRD가 복잡하거나 화면 형태가 정형화되지 않은 제품이라면 결과가 어디서부터 달라질 것이라고 보시나요?확인한 범위인 단순한 PRD와 정형화된 화면을 벗어나면 어디서부터 어려워지는지 아는지 본다.
   2. 트레이드오프바뀐 부분만 갱신하는 증분 처리로 바꾸면 전체를 다시 생성할 때 얻던 것 중 무엇을 포기하게 되나요?

      근본 해법이라고 한 방식이 치르는 대가를 알고 있는지, 좋은 점만 말하지는 않는지 본다.

      1. 구현 깊이갱신한 부분과 갱신하지 않은 부분이 서로 어긋났는지는 어떻게 확인하려고 하나요?증분 처리가 만드는 일관성 문제를 구체적인 확인 방법으로 풀어 말할 수 있는지 본다.
   3. 조건 변경PRD가 바뀌어 재실행하면 현재 코드베이스를 참조해 PR을 다시 만든다고 했는데, 그 사이 사람이 고친 코드가 있다면 결과에는 어떻게 반영되나요?재실행이 사람이 손본 결과와 만나는 경계를 설계에서 다뤘는지 본다.
   4. 선택 근거중첩 트리를 평면 맵으로 바꾸는 대신, 중첩 구조는 두고 노드를 바로 찾는 색인을 두는 방법은 검토하지 않았나요?

      재설계가 필요한 문제를 더 작은 수정으로 풀 수 있는지 견주어 보았는지 확인한다.

      1. 트레이드오프평면 맵으로 바꾸면 트리 모양으로 보여 주거나 순서를 지켜야 하는 곳에서는 무엇이 더 어려워지나요?재설계가 새로 만드는 불편을 알고 얻는 것과 견주어 보았는지 본다.
8. 디자인 시스템을 카탈로그로 만든 것이 핵심 결정이라고 하셨는데, 어떤 문제를 풀려던 결정이었나요?

   카탈로그라는 구현이 아니라 그것이 풀려던 문제에서 출발해 설명하는지 본다.

   1. 판단 근거AI에게 컴포넌트 코드를 뒤지게 하면 느리고 매번 다른 답이 나온다는 진단은 무엇을 보고 내렸나요?

      문제를 겪은 신호에서 진단이 나왔는지, 짐작에서 나왔는지를 가른다.

      1. 결과 검증카탈로그로 바꾼 뒤 그 두 가지가 나아졌는지는 어떻게 확인했나요? KR·US진단한 문제가 해결됐는지 확인할 수단이 있었는지, 체감에 그쳤는지를 본다.
   2. 선택 근거타입 정의만 읽게 하지 않고 컴포넌트의 용도와 사용 예시까지 카탈로그에 담은 이유는 무엇인가요?

      AI가 고르는 데 필요한 정보가 무엇이라고 보았는지, 더 가벼운 대안을 견주어 보았는지 확인한다.

      1. 구현 깊이카탈로그에 담기는 용도 설명과 사용 예시는 저장소의 무엇을 근거로 만들어지나요?자동으로 생성한다고 한 카탈로그의 내용이 어떤 근거에서 나오는지 아는지 본다.
   3. 트레이드오프카탈로그를 정본으로 두었는데, 카탈로그가 낡거나 틀리면 AI가 그린 화면은 어떻게 되나요?

      정본 하나에 기대는 구조의 약점, 곧 정본이 틀리면 결과도 함께 틀린다는 점을 알고 있는지 본다.

      1. 조건 변경디자인 시스템이 개편돼 컴포넌트가 여럿 바뀐다면, 캐싱한 워크스페이스 프로파일은 언제 다시 만들어야 하나요?

         캐시가 유효하다는 전제가 깨지는 조건을 알고 다시 만들 시점을 정하는 기준이 있는지 본다.

         1. 실패와 장애카탈로그와 실제 컴포넌트가 어긋난 채로 화면이 만들어진 적은 없었나요?어긋남을 이론이 아니라 실제로 겪었는지, 겪었다면 어디서 발견했는지 본다.
   4. 구체화카탈로그에 맞는 컴포넌트가 없어서 AI가 다르게 처리해야 했던 화면 요구가 있었다면 하나만 들어 주시겠어요?카탈로그에서 고른다는 원칙이 깨지는 경계를 구체적인 사례로 짚을 수 있는지 본다.

오픈소스 · Bugzar

1. Bugzar는 어떤 문제를 풀려고 만들었나요?

   개인 프로젝트에서 문제 정의와 동기가 얼마나 구체적인지 본다.

   1. 판단 근거리포트를 주고받는 과정에서 정보가 샌다는 진단은 무엇을 보고 내렸나요?

      문제를 정의한 근거가 겪은 신호인지 짐작인지를 가른다.

      1. 결과 검증Bugzar를 쓰면 "제 환경에서는 재현이 안 됩니다"로 되돌아오는 일이 줄어드는지는 어떻게 확인할 수 있나요? KR·US

         문제가 풀렸는지 확인할 수단을 갖고 있는지, 설계의 논리에서 그치지는 않는지 본다.

         1. 실패와 장애리포트가 있어도 개발자가 같은 상황을 다시 만들지 못하는 경우가 있다면 어떤 경우인가요?도구가 풀지 못하는 경우를 스스로 알고 있는지 본다.
      2. 구체화경력기술서에서 사람이 요약한 텍스트에는 실제로 무엇이 실패했는지가 빠져 있다고 하셨는데, 어떤 정보가 빠지는지 하나만 예로 들어 주시겠어요?에이전트에게 맡길 때 손실이 더 커진다는 주장을 구체적인 사례로 뒷받침할 수 있는지 본다.
   2. 선택 근거버그 리포트의 부담을 줄이려고 이미 있는 세션 리플레이나 이슈 트래커 연동 도구를 쓰지 않고 직접 만든 이유는 무엇인가요?

      기존 도구를 견주어 보았는지, 직접 만드는 결정에 근거가 있었는지 본다.

      1. 트레이드오프브라우저 API를 감싸 수집하는 방식은 브라우저가 바뀔 때 유지 부담이 따를 텐데, 이를 단독으로 어떻게 감당하나요?직접 만든 데 따르는 지속적인 비용을 알고 있는지 본다.
   3. 조건 변경React 앱에 컴포넌트 하나를 붙이는 방식이 통하지 않는 앱이라면 같은 문제를 어떻게 풀어야 한다고 보시나요?도구가 풀 수 있는 문제의 경계를 알고 있는지 본다.
   4. 회고처음 정의한 문제 가운데 만들고 나서 다시 보면 다르게 정했을 부분이 있다면 무엇인가요? KR문제 정의를 만든 뒤에도 다시 평가하는지 본다.
2. 결과물을 서버가 아니라 파일 하나로 둔 이유는 무엇인가요?

   제품 형태의 선택 근거와 대안 비교를 본다.

   1. 트레이드오프서버 없이 파일만 쓰면 리포트를 공유하고 찾아보는 일이 불편해질 수 있는데, 이 한계는 어떻게 다루나요?

      선택의 대가인 공유와 검색의 불편을 스스로 알고 있는지, 좋은 점만 말하지는 않는지 본다.

      1. 조건 변경리포트가 팀 단위로 쌓여 찾아봐야 하는 상황이 되면 파일 형식은 두고 무엇을 더하시겠어요?파일 중심 설계가 규모가 커질 때 어디서 부족해지는지 알고, 그 위에 무엇을 얹을지 생각해 두었는지 본다.
   2. 구체화경력기술서에 사내 도구가 "우리 서버에 올려야만 쓸 수 있다"는 이유로 안 쓰이는 걸 여러 번 보셨다고 적으셨는데, 그중 하나를 들어 주시겠어요?

      서버 없이 쓰게 만든 설계의 근거가 실제로 본 사례에서 나왔는지 본다.

      1. 협업과 이견화면 기록이 담긴 리포트를 사내 서버에만 두라고 보안이나 인프라 담당자가 요구한다면 어떻게 조율하시겠어요?파일 중심 설계가 조직의 통제 요구와 부딪힐 때 원칙을 지키면서 협의할 수 있는지 본다.
   3. 선택 근거결과물의 형식을 자기완결형 HTML로 정하기 전에 견준 다른 형식이 있다면 무엇인가요? KR·US

      형식을 고를 때 대안을 저울질했는지 본다.

      1. 회고파일로 두기로 한 결정에서 처음에는 놓쳤다고 지금 생각하는 것이 있다면 무엇인가요? KR결정을 내린 뒤에도 그 판단을 다시 점검하는지 본다.
   4. 구현 깊이계정도 네트워크도 없이 더블클릭으로 재생되게 하려고 파일 안에 담아야 했던 것 가운데 가장 까다로웠던 것이 있다면 무엇인가요?

      자기완결형이라는 말이 구현에서 무엇을 요구했는지 아는지 본다.

      1. 트레이드오프타임라인과 네트워크 요청까지 모두 파일 하나에 담으면 크기가 커질 수 있는데, 크기와 재생 속도는 어떻게 다루나요?모든 것을 한 파일에 담는 설계가 치르는 비용을 알고 있는지 본다.
3. 같은 리포트를 사람의 뷰어와 에이전트의 MCP가 함께 읽게 만든 설계는 어떻게 나왔나요?

   AI 시대의 도구 설계 관점과 인터페이스 결정을 본다.

   1. 선택 근거에이전트가 리포트를 읽는 방법으로 MCP 서버를 고르기 전에 견준 다른 방법이 있다면 무엇인가요? KR·US

      에이전트 연동 방식을 정할 때 대안을 저울질했는지 본다.

      1. 조건 변경MCP를 지원하지 않는 에이전트 환경이라면 같은 리포트를 어떻게 전달하시겠어요?MCP에 기대는 설계의 전제가 깨지는 곳에서도 리포트를 쓸 수 있게 생각해 두었는지 본다.
   2. 판단 근거리포트를 질의하는 도구를 재현 절차, 콘솔 에러, 실패한 요청, 요청의 헤더와 본문 조회로 나눈 기준은 무엇인가요? US

      에이전트가 쓰는 도구의 경계를 어떤 기준으로 나눴는지, 인터페이스 결정에 원칙이 있는지 본다.

      1. 결과 검증에이전트가 이 도구들을 의도한 대로 골라 쓰는지는 어떻게 확인할 수 있나요?

         도구를 만든 뒤 에이전트가 실제로 쓰는 방식을 볼 수단이 있는지 본다.

         1. 실패와 장애에이전트가 도구를 잘못 골라 엉뚱한 원인을 짚는 경우가 생긴다면, 도구의 어느 부분을 고쳐야 한다고 보시나요?에이전트의 오판이 도구 설계에서 비롯될 수 있다는 점을 알고 고칠 지점을 짚을 수 있는지 본다.
   3. 트레이드오프사람이 읽기 좋은 형태와 에이전트가 질의하기 좋은 형태가 다를 수 있는데, 포맷을 하나로 맞추면서 포기한 것은 무엇인가요?

      하나로 맞춘 것을 핵심이라고 한 설계가 치르는 대가를 알고 있는지, 좋은 점만 말하지는 않는지 본다.

      1. 조건 변경특정 요청의 본문이 에이전트가 한 번에 다루기에 너무 크다면 어떻게 넘기는 것이 좋다고 보시나요?필요한 것을 골라 가져가는 방식이 큰 데이터 앞에서 어디까지 버티는지 아는지 본다.
   4. 회고다시 설계한다면 사람의 뷰어와 에이전트의 MCP 중 어느 쪽을 기준으로 리포트 구조를 먼저 잡으시겠어요?두 소비자의 요구가 부딪힐 때 무엇을 우선하는지, 지금의 설계를 다시 평가할 수 있는지 본다.
4. 다른 사람의 화면을 통째로 기록하는 도구에서 어떤 안전장치를 넣었나요?

   보안과 개인정보에 대한 판단과 위협 모델링을 본다.

   1. 판단 근거어떤 위협을 염두에 두고 이 안전장치들을 골랐나요? US안전장치를 나열하는 데서 그치지 않고 어떤 위협을 따져 골랐는지 본다.
   2. 구현 깊이LLM에 보내기 전 개인정보를 걸러내는 필터는 어떤 방식으로 개인정보를 가려내나요?

      필터링이 구현에서 어떻게 이루어지는지 아는지, 이름만 붙인 것은 아닌지 본다.

      1. 트레이드오프필터링을 강하게 걸수록 초안에 필요한 정보까지 가려질 수 있는데, 그 균형은 어떻게 잡나요?개인정보 보호와 초안의 쓸모가 부딪히는 지점을 알고 있는지 본다.
      2. 실패와 장애필터가 놓친 개인정보가 LLM으로 넘어갔다면 그 뒤에는 어떻게 대응하시겠어요?필터가 완벽하지 않다는 전제에서 놓쳤을 때의 영향과 대응을 생각해 두었는지 본다.
   3. 결과 검증페이지 안의 텍스트가 프롬프트를 덮어쓰지 못하게 막았는지는 어떤 방법으로 검증하나요?

      방어를 넣었다는 말과 그것이 실제로 통하는지 확인하는 방법을 구분한다.

      1. 실패와 장애AI가 만든 초안을 클릭 한 번으로 Jira에 발행하는데, 방어가 뚫려 초안이 오염됐다면 그 사실은 발행 전에 어떻게 드러나나요?

         방어가 뚫린 경우에도 피해가 발행까지 번지지 않게 하는 장치가 있는지 본다.

         1. 트레이드오프확인 단계가 있다면 클릭 한 번이라는 이점이 줄어들 텐데, 발행 전 사람의 확인과 클릭 한 번의 편의 중 어느 쪽을 우선하시겠어요?안전과 편의가 부딪힐 때 무엇을 앞세울지 기준이 있는지 본다.
   4. 선택 근거이슈 발행 인증 토큰을 브라우저에 두는 방식 대신 서버 세션에만 두기로 한 이유는 무엇인가요? US

      토큰을 보관하는 방식을 정할 때 대안과 위험을 견주었는지 본다.

      1. 조건 변경발행 대상이 Jira 말고 다른 이슈 트래커로 늘어난다면 토큰을 서버 세션에만 두는 방식은 어디서부터 부담이 되나요?서버 세션에 기대는 설계가 확장될 때의 한계를 알고 있는지 본다.

AI 제품의 프론트엔드

1. LLM 응답은 느리고 결과가 매번 다릅니다. 프론트엔드에서 어떤 UX 장치가 필요하다고 보나요? AI Native 회사가 프론트엔드에게 가장 궁금해하는 지점.
2. 스트리밍 응답을 렌더링할 때 고려할 점은 무엇인가요? 중간 상태의 마크다운 파싱, 중단, 재시도는?
3. 모델이 틀린 답을 줬을 때 사용자에게 어떻게 알리고 회복시키나요?
4. 에이전트가 사용자 대신 행동하는 UI에서는 무엇을 조심해야 하나요? 확인 단계, 되돌리기, 무엇을 했는지 보여주기 — 커머스라면 주문·결제와 직결된다.
5. AI 기능의 성공을 무엇으로 측정하시겠어요?
6. 커머스에 LLM을 붙인다면 어디에 넣는 게 가장 효과가 클 것 같나요? 상품 도메인 경험이 있어서 구체적으로 답할 수 있는 자리. 준비해두면 차별화된다.

관점

1. AI Native 조직에서 프론트엔드 개발자의 역할이 어떻게 바뀐다고 보시나요?
2. AI가 대체하기 어려운 개발자의 일은 무엇이라고 생각하나요?
3. AI 도입으로 팀 생산성이 올랐다는 걸 어떻게 증명하시겠어요? 막연한 체감이 아니라 측정 방법을 말할 수 있는지 보는 질문.

설명하고 설득하기

1. 비개발 직군에게 기술적 제약을 설명해야 했던 경험을 말해주세요. 이력서 소개글이 커뮤니케이션을 앞세우고 있어 반드시 검증하려 든다.
2. 본인 의견이 받아들여지지 않았을 때 어떻게 하셨나요?
3. 반대로, 설득당해서 생각을 바꾼 경험이 있나요? 설득한 이야기만 하면 유연성을 의심받는다. 짝으로 준비해둘 것.
4. 기획·디자인과 의견이 다를 때 근거를 어떻게 만드나요?

   말 대신 동작하는 것을 만듭니다. 표준 옵션 작업에서 시안이 순서를 숫자로 입력하게 돼 있었는데, 운영자가 반복 입력할 걸 생각하면 불편하다고 판단해 Drag & Drop을 제안했습니다. 의견만 내지 않고 최소 리소스로 PoC를 만들어 동작 영상을 Slack에 올렸고, 디자인이 수정돼 실제 프로덕션에 반영됐습니다. 근거를 만들 수 없는 사안이면 결정권자의 기준을 먼저 묻습니다.

   1. 구체화동작 영상을 Slack에 올렸다고 하셨는데, 영상에 무엇을 담아야 보는 사람이 판단하기 쉽다고 보시나요?근거를 만드는 방법이 감이 아니라 보는 사람의 판단을 돕는 기준으로 정리돼 있는지 본다.
   2. 판단 근거PoC까지 만들어 보여줄 사안과 말이나 문서로 충분한 사안은 무엇으로 가르나요? KR

      근거를 만드는 노력을 모든 의견에 쓰지 않고 가려서 쓰는지 본다.

      1. 협업과 이견동작하는 것을 보여줬는데도 디자이너나 기획자가 원래 시안을 유지하자고 한다면 어떻게 하시겠어요? KR근거를 내밀어도 상대가 받아들이지 않을 때 관계를 해치지 않고 결론에 이르는 방법이 있는지 본다.
5. 동료와 의견이 부딪혔던 경험과, 어떻게 풀었는지 말해주세요.

   Service Layer를 둘지 말지를 놓고 팀 의견이 갈렸습니다. 저는 찬성이었지만 제 의견을 밀어붙이는 대신 찬성·반대·중립 의견을 전부 회의록에 기록하고 하나씩 다뤘습니다. 반대 근거였던 "레이어를 나누면 fetch 상태 추적이 어렵다"는 react-query와 커스텀 훅으로 해소된다는 걸 보여줬고, "각 레이어가 책임을 1씩 가지면 나누는 게 맞지만 지금은 0.8씩이라 부족하게 느껴진다"는 중립 의견도 그대로 남겼습니다. 결론은 "둔다"로 합의했는데, 이 기록 덕분에 몇 달 뒤 회고에서 같은 논쟁을 반복하지 않고 V2로 바로 넘어갈 수 있었습니다.

   1. 조건 변경논쟁이 기술 근거를 넘어 서로에 대한 감정으로 번졌다면, 의견을 전부 기록하고 하나씩 다루는 방식 대신 무엇부터 하시겠어요?기록과 절차로 푸는 방식이 통하지 않는 갈등에 쓸 다른 수단이 있는지 본다.
   2. 실패와 장애같은 방식으로 기록하고 다뤘는데도 논쟁이 정리되지 않은 안건이 있다면 어떻게 마무리하셨나요? KR·US잘 풀린 사례만이 아니라 이 방식이 통하지 않은 안건이 있었는지, 있었다면 어떻게 닫았는지 본다.
   3. 결과 검증기록 덕분에 몇 달 뒤 회고에서 같은 논쟁을 반복하지 않았다고 하셨는데, 그것이 기록 덕분이라는 것은 어떻게 판단하셨나요?결과와 자신의 행동 사이의 인과를 어떤 근거로 연결했는지 본다.
6. 우선순위를 두고 협상해야 했던 경험이 있나요?

나쁜 소식과 피드백

1. 일정이 밀릴 것 같을 때 언제, 어떻게 알리시나요? "언제"가 핵심이다. 늦게 알리는 사람인지 일찍 알리는 사람인지를 본다.
2. 장애가 났을 때 커뮤니케이션은 어떻게 하시나요?
3. 코드 리뷰에서 지적할 때 어떻게 표현하나요?

   팀 그라운드 룰을 만들 때 정한 원칙이 있습니다. GitHub의 Request Change는 받는 사람에게 폭력적으로 느껴질 수 있어 지양하고, Comment로 상세히 남깁니다. Request Change를 하려면 "합의된 컨벤션"이 선행돼야 한다는 조건도 함께 정했습니다 — 기준 없이 막는 건 취향 강요가 되니까요. 그리고 반복되는 구조 지적은 사람이 하지 않도록 리뷰 봇에 옮겼습니다.

   1. 구체화지적을 Comment로 상세히 남긴다고 하셨는데, 지적 하나를 어떤 구성으로 쓰시는지 예를 들어 주시겠어요? KR표현 원칙이 실제 코멘트의 형태로 옮겨지는지 세부를 본다.
   2. 트레이드오프Request Change 없이 Comment만 남기면 지적이 반영되지 않은 채 머지될 수도 있는데, 그런 경우는 어떻게 막으시나요?

      상대를 배려하는 표현 원칙이 반영을 강제하지 못하는 한계를 어떻게 보완하는지 본다.

      1. 조건 변경합의된 컨벤션이 아직 없는 상태에서 장애로 이어질 수 있는 코드를 발견했다면 어떻게 지적하시겠어요?컨벤션이 선행돼야 한다는 조건이 급한 상황에서도 지켜지는지, 예외를 두는 기준이 있는지 본다.
4. 껄끄러운 피드백을 받았을 때 어떻게 반응하시나요?
5. 팀에 나쁜 관행이 있다고 느낄 때 어떻게 바꾸시나요? 깃 정책 도입, CI 자동화, PR 봇 — 재료는 이미 이력서에 있다.

기록과 학습

1. 문서를 쓰는 편인가요? 무엇을 문서로 남기고, 무엇은 남기지 않나요?

   많이 쓰는 편이고, 기준은 "결정의 이유가 나중에 필요해지는가"입니다. 기술 선택은 ADR로 — 채택안만이 아니라 탈락 근거와 반대 의견까지 남깁니다. 운영 설정값은 근거와 함께(timeout 3초는 왜 3초인지), 회고는 데이터와 함께(계획 공수 대비 실제 공수), 온보딩은 신규 합류자가 문서만으로 첫 PR까지 가도록. 반대로 코드만 보면 알 수 있는 것은 문서로 만들지 않습니다 — 그건 코드와 폴더 구조가 말하게 하는 쪽입니다.

   1. 결과 검증온보딩 문서만으로 신규 합류자가 첫 PR까지 갈 수 있다는 것은 어떻게 확인하나요?문서의 목표를 세운 데서 그치지 않고 실제 합류자로 검증하는 수단이 있는지 본다.
   2. 조건 변경일정이 빠듯해 문서를 다 쓸 수 없다면 어떤 것부터 남기시겠어요?결정의 이유가 나중에 필요해지는가라는 기준을 시간이 부족할 때 우선순위로 바꿔 쓸 수 있는지 본다.
   3. 회고코드만 보면 알 수 있다고 보고 문서로 만들지 않았는데 다른 사람에게는 그렇지 않았던 경우가 있다면 무엇이었나요?문서로 남기지 않는 기준이 본인의 시선에만 맞춰져 있지는 않은지 점검해 본 적이 있는지 본다.
2. 비동기 커뮤니케이션에서 본인만의 원칙이 있나요?
3. 새로운 도메인에 들어갈 때 지식을 어떻게 습득하시나요? 차량 → 커머스 → 파트너 플랫폼으로 도메인을 여러 번 갈아탄 경력이라 물어보기 좋은 위치다.
4. 멘토링을 하면서 가장 어려웠던 점은 무엇이었나요? 프로그래머스·패스트캠퍼스 멘토 경험이 이력서에 있다.
5. 회고를 해본 적 있나요? 회고 이후 실제로 바뀐 것이 있나요?

   3개월짜리 카탈로그 프로젝트가 끝나고 회고를 직접 설계해 진행했습니다. 실제로 바뀐 게 둘 있습니다. 기술적으로는 레이어 간 결합 문제를 진단해 아키텍처 V2로 개정했고, 그걸 AI 룰로 만들어 리뷰 봇이 검증하게 했습니다. 프로세스로는 주당 5MD로 계획한 공수가 QA·후속작업을 포함하면 실제 7~8MD라는 걸 티켓 데이터로 드러내서, 재작업이 예외가 아니라 표준 과정의 일부임을 보여주고 공수 버퍼 제도화와 전 직군 주 1회 싱크를 관철시켰습니다.

   1. 구체화회고를 직접 설계했다고 하셨는데, 어떤 순서와 형식으로 진행하셨나요?회고를 했다는 사실이 아니라 진행 방식의 세부가 나오는지 본다.
   2. 결과 검증공수 버퍼를 제도화한 뒤 계획 공수와 실제 공수의 차이가 달라졌는지는 무엇으로 확인하나요?제도를 만든 데서 그치지 않고 바뀌었는지를 다시 데이터로 확인하는지 본다.
   3. 실패와 장애회고에서 개선안으로 나왔지만 실행되지 못했거나 흐지부지된 것이 있다면 무엇이었나요? US바뀐 것만 말하지 않고 바뀌지 않은 것과 그 이유까지 짚는지 본다.

Layered Architecture · Architecture Keeper

1. 이력서의 Layered Architecture가 뭔가요? 어떻게 나눴나요?

   가장 기본적인 검증 질문. 그림 없이도, 그림으로도 설명할 수 있어야 한다.

   모노레포를 Api → Service → Feature → App 4계층 단방향으로 나눴습니다. Api는 통신과 경계 검증만, Service는 비즈니스 로직과 자체 DTO, Feature는 도메인 UI와 쿼리 팩토리, App은 조립과 전역 설정입니다. 재사용 유틸은 packages로 빼서 모든 레이어가 참조합니다.

   원칙은 "폴더 구조만 보고도 아키텍처를 유추할 수 있어야 한다"였고, 실제 저장소가 layers/apis·services·features·apps로 그림과 똑같이 생겼습니다. 금지 규칙 — Feature가 Api를 직접 호출하지 않는다, Service는 React에 의존하지 않는다, Api에 비즈니스 로직을 넣지 않는다 — 를 문서화하고, 이걸 리뷰 봇이 검사합니다.

2. 왜 그 구조였나요? 어떤 문제를 풀려던 건가요?

   문제 정의가 먼저였습니다. 무신사 파트너와 29CM Connect 두 조직이 합쳐진 신설 팀이라 개발 표준이 서로 달랐고, "다양한 조직의 다양한 애플리케이션에서 쓰일 모듈을 재사용성·응집도는 높고 결합도는 낮게 설계한다"가 팀의 과제였습니다. 여러 어드민을 함께 만들어야 하니 데이터 흐름을 추적하기 쉬운 구조가 필요했고요.

   도입 논의에서 "테스트 작성이 쉬워진다"는 장점이 나왔을 때, 그건 목적이 아니라 구조가 좋아서 생기는 현상이라고 논리 층위를 구분해 정리했습니다. 목적과 부수효과를 섞으면 나중에 아키텍처를 평가할 기준이 흐려지니까요.

   1. 문제 정의아키텍처를 평가할 기준이 흐려진다고 했는데, 그 기준을 도입 전에 정했나요, 도입 뒤에 정리했나요?

      평가 기준을 도입 전에 세웠는지, 도입한 뒤에 끼워 맞췄는지를 가른다.

      1. 결과 검증재사용성·응집도는 높고 결합도는 낮게 한다는 목표가 지켜지는지는 무엇으로 확인했나요? KR·US

         기준을 세운 데서 그치지 않고 실제 코드에서 대조할 수단이 있었는지 본다.

         1. 실패와 장애공통으로 쓰는 모듈을 고친 변경이 다른 어드민을 깨뜨린 적은 없었나요?재사용을 노린 구조가 다른 앱으로 퍼뜨리는 파급 위험을 실제로 겪었는지, 겪었다면 무엇으로 막았는지 본다.
      2. 조건 변경어드민이 하나 더 늘어나면 4계층 중 무엇을 새로 만들고 무엇을 그대로 가져다 쓰게 되나요?재사용성이라는 주장을 새 어드민 하나를 만드는 구체적인 작업으로 풀어 말할 수 있는지 본다.
   2. 판단 근거데이터 흐름을 추적하기 쉬운 구조가 필요하다고 판단하게 만든 실제 상황은 무엇이었나요?필요성이 겪은 상황에서 나왔는지, 일반 원칙에서 출발했는지를 가른다.
   3. 선택 근거양쪽 조직이 이미 쓰던 개발 표준 중 하나를 넓혀 쓰는 선택지는 검토하지 않았나요?

      새 구조를 만드는 비용을 감수할 이유가 있었는지, 대안 비교의 깊이를 확인한다.

      1. 구체화각 조직이 쓰던 방식에서 4계층이 이어받은 것이 있다면 무엇인가요? US표준이 갈린 지점에서 무엇을 이어받았는지 구체적으로 짚을 수 있는지 본다.
   4. 트레이드오프packages는 모든 레이어가 참조할 수 있는데, 이 예외 통로가 단방향 원칙을 약하게 만들지는 않았나요?모든 레이어가 참조하는 통로가 원칙을 흔들 수 있다는 점을 알고 있는지 본다.
3. 그 아키텍처를 팀에 어떻게 설득했나요? 반대 의견은 없었나요?

   반대가 있었고, 그걸 지우지 않고 남긴 게 핵심이었습니다. Service Layer 존치를 놓고 찬성·반대·중립을 전부 기록하는 ADR 형식으로 회의를 진행했습니다. 반대 근거(비즈니스 로직과 서비스 로직은 분리 불가, fetch 상태 추적이 어렵다)에는 기술적 반박을 정리했고, 중립 의견("책임이 1씩이면 나누는 게 맞지만 0.8씩이라 부족하게 느껴진다")도 그대로 남겼습니다. 회의는 안건별 시간 배분까지 미리 설계했고, 결정된 것은 제가 문서화·테스트 코드 반영까지 맡아 실행했습니다.

   1. 선택 근거이견을 정리해 결정만 알리는 방식 대신 찬성·반대·중립을 전부 남기는 ADR 형식을 택한 이유는 무엇인가요? KR

      합의 방식을 고른 근거가 있었는지, 관성으로 쓴 형식은 아닌지 확인한다.

      1. 트레이드오프모든 의견을 남기면 논의가 길어질 수 있는데, 안건별 시간 배분을 미리 짠 것으로 그 비용을 어디까지 감당할 수 있었나요?

         의견을 전부 남기는 투명성이 치르는 시간 비용을 알고 회의 설계로 다뤘는지 본다.

         1. 회고지금 이 회의 방식을 다시 짠다면 가장 먼저 바꿀 부분은 무엇인가요?회의 설계의 약점을 스스로 짚고 다음 합의에 반영할 수 있는지 본다.
   2. 구체화반대 근거에 정리한 기술적 반박은 코드나 수치로 보여준 것이었나요, 논리로 설명한 것이었나요? US

      반박이 의견 다툼에 그치지 않고 근거를 갖춘 설득이었는지 본다.

      1. 결과 검증반대했던 사람이 결정을 납득했는지는 무엇으로 알 수 있었나요? US

         결정에 따르는 것과 납득하는 것을 구분해서 보았는지 확인한다.

         1. 협업과 이견끝까지 동의하지 않은 사람이 있었다면 그 결정은 어떻게 이행되었나요? US동의하지 않는 사람이 남아도 결정을 실행으로 잇는 방법을 아는지 본다.
   3. 판단 근거"0.8씩이라 부족하게 느껴진다"는 중립 의견을 결정에 반영할지는 무엇을 기준으로 판단했나요?기록해 둔 의견이 결정에 영향을 주었는지, 명목상의 기록이었는지를 가른다.
   4. 본인 기여결정이 난 뒤 문서화와 테스트 코드 반영까지 직접 맡은 이유는 무엇인가요? KR·US합의를 실행으로 잇는 책임을 스스로 졌는지, 역할로 주어진 일이었는지 본다.
4. 이 구조가 잘 안 맞았던 케이스도 있었나요?

   한계를 스스로 말할 수 있으면 설계 경험이 진짜라는 신호가 된다. "틀린 결정" 질문의 답이기도 하다.

   있습니다. 3개월 프로젝트를 끝내고 회고했더니 두 가지가 나왔습니다. 첫째, 레이어 간 인터페이스 전파 — 백엔드 응답 스키마가 조금만 바뀌어도 Api → Service → Feature로 전파돼 단일 변경에 최소 3개 레이어를 고쳐야 했습니다. 둘째, Service Layer의 정체성 위기 — API 단순 전달, 데이터 정규화, UI용 데이터 생성 세 역할이 뒤섞여 양쪽에 강결합된 중간 계층이 돼 있었습니다.

   V2에서 Service Layer 응답 스키마가 바뀌는 기준을 "UI가 바뀌어야 할 때"로 잡아 Anti-Corruption Layer로 재정의했고, 타입 안정성 때문에 뒀던 Entity는 오히려 오버헤드라 폐지하고 Swagger 기반 타입 자동 생성으로 대체했습니다. V2도 문서와 AI 룰로 다시 반영해 봇이 새 기준으로 검사합니다. 스스로 만든 구조의 실패를 데이터로 진단하고 고친 경험이라, 저는 이걸 실패라기보다 아키텍처를 운영한 경험이라고 생각합니다.

   1. 판단 근거단일 변경에 3개 레이어를 고쳐야 했다는 진단은 무엇을 근거로 내렸나요?

      진단이 체감에서 나온 것인지 기록에서 나온 것인지 가르는 질문.

      1. 본인 기여그 회고와 개선안은 누가 정리했고, 팀 합의는 어떤 과정을 거쳤나요?본인이 한 일과 팀이 결정한 일을 구분해서 말하는지 본다.
      2. 조건 변경같은 구조로 프로젝트가 3개월이 아니라 1년 규모였다면 그 비용은 어떻게 달라졌을까요?문제가 규모에 따라 어떻게 커지는지 예측하는지 본다.
   2. 선택 근거Service Layer를 아예 없애는 선택지는 검토하지 않았나요?

      존치 논쟁을 어떤 근거로 정리했는지, 대안 비교의 깊이를 확인한다.

      1. 트레이드오프Anti-Corruption Layer로 재정의해도 Service DTO와 Feature 사이에 같은 전파 문제가 남지 않나요?

         해결책의 남은 한계를 스스로 아는지 확인한다.

         1. 회고V1을 처음부터 다시 설계한다면 가장 먼저 무엇을 바꾸시겠어요?회고를 다음 판단 기준으로 바꿨는지 본다.
   3. 트레이드오프Entity를 없애고 Swagger 타입 생성으로 바꾸면 백엔드 스키마 변경이 화면까지 그대로 번지지 않나요?

      V2 결정이 V1의 문제를 다시 들여오는지 압박하는 질문.

      1. 결과 검증그 위험을 "UI가 바뀌어야 할 때"라는 기준으로 어떻게 막았고, 실제로 막힌 사례가 있나요?원칙이 운영에서 지켜졌는지 사례를 요구한다.
   4. 실패와 장애V1이 맞지 않는다는 신호를 회고 이전에 알아챌 수 있었던 순간은 없었나요?늦게 감지한 이유를 스스로 분석하는지 본다.
5. 계층 간 의존 방향을 어떤 규칙으로 정의했나요? 실제로 위반이 나온 사례는?

Figma 플러그인 · 디자인 시스템

1. 토큰 변환 플러그인을 직접 만든 이유는 무엇인가요?

   디자이너가 Figma Variables로 디자인 토큰을 바꾸면, FE는 Tailwind 테마와 Ant Design 테마 두 곳을 손으로 고쳐야 했습니다. 변경을 일일이 추적할 수 없어 누락과 휴먼 에러가 생겼고요. 그래서 Figma Variables를 읽어 Tailwind용 CSS 변수와 antd v5 ConfigProvider가 그대로 받는 theme JSON을 동시에 만들어 주는 플러그인을 직접 만들었습니다. 토큰의 단일 소스를 Figma로 두고, 이질적인 두 스타일 시스템이 거기서 파생되게 한 겁니다.

   사내 Figma에 MUSINSA style convertor라는 이름으로 등록해 디자이너도 실행할 수 있게 했고, 사용 가이드를 위키로 남겨 디자이너·개발자 공용 워크플로우로 정착시켰습니다. 외부 통신이 전혀 없는 단독 실행형이라 디자인 파일이 밖으로 나가지 않습니다 — 사내 디자인 자산을 다루는 도구라 이 부분은 의도적으로 못 박았습니다.

2. 변환기를 만들 때 가장 까다로웠던 부분은 무엇인가요?

   세 가지였습니다.

   첫째, 모드(mode)를 어떻게 표현하느냐입니다. Figma Variables는 같은 토큰이 light/dark/compact 같은 모드별로 다른 값을 가집니다. 이걸 CSS에서는 모드를 선택자로 바꿔 풀었습니다 — dark 모드는 .dark, compact은 .compact, 나머지는 :root 블록으로 내보내서, 클래스 하나만 토글하면 테마가 바뀌게 했습니다.

   둘째, 별칭(alias) 참조입니다. 토큰이 다른 토큰을 가리키는 경우가 많은데, 그것도 모드별로 다른 값을 가리킵니다. 그래서 현재 모드를 들고 재귀적으로 최종 값까지 따라가게 했고, 순환 참조를 대비해 깊이 제한을 뒀습니다. 디자인 파일은 사람이 만드는 거라 순환이 실제로 생길 수 있고, 그러면 플러그인이 그냥 멎어버리니까요.

   셋째, 단위입니다. Figma는 숫자만 주기 때문에 16이 16px인지 그냥 16인지 알 수 없습니다. 색상값·이미 단위가 붙은 값·font-weight를 예외로 두고 나머지 숫자에만 px를 붙이는 규칙을 넣었습니다. font-weight에 px가 붙으면 스타일이 조용히 깨지는데, 이런 건 한 번 겪어봐야 아는 종류의 예외라 코드에 규칙으로 박아뒀습니다.

3. 디자이너와 토큰 네이밍 규칙은 어떻게 합의했나요?

   플러그인이 규칙을 강제하는 쪽으로 만들었습니다. Figma 변수명을 카테고리/이름 구조로 쓰기로 하고, 플러그인이 카테고리를 읽어 Tailwind의 테마 변수 네임스페이스(color·spacing·radius·shadow·font·breakpoint 등)로 매핑합니다. 규칙에 맞게 지으면 변환이 되고, 아니면 결과에 안 나오니 네이밍이 지켜지는지가 눈에 보이게 됩니다.

   반대로 사람에게 맞춘 부분도 있습니다. 디자이너는 "Font Size / 16"처럼 사람이 읽기 좋은 이름을 쓰고 싶어 하는데, 그대로 변환하면 --text-font-size-16처럼 의미가 중복됩니다. 그래서 네임스페이스로 이미 표현된 단어는 이름에서 걷어내도록 했습니다. 규칙을 지키느라 디자이너가 불편해지면 그 규칙은 안 지켜진다고 봤습니다.

4. 플러그인 도입으로 없앤 수작업은 어느 정도였나요?
5. 디자인이 바뀌었는데 코드가 따라가지 못하는 상황은 어떻게 막았나요?

OCMP · 마케팅 구좌 · 그 외

1. 무신사와 29CM의 상품 카탈로그 스키마가 달랐을 텐데, 그 차이를 프론트엔드에서 어떻게 흡수했나요?
2. 두 회사 운영자가 함께 쓰는 어드민이면 권한·용어·업무 흐름이 달랐을 텐데 어떻게 풀었나요?
3. 세일즈포스를 내재화한 이유는 무엇이고, 무엇이 좋아졌나요?
4. 파트너 규모가 큰 환경에서 프론트엔드 성능 문제는 없었나요? 목록·검색은 어떻게 처리했나요?

크로스플랫폼 상품 어드민 · BFF (2026)

1. BFF가 뭐고, 왜 직접 만들게 됐나요?

   원래는 Backend가 Public API를 만들어 주고 FE는 클라이언트만 담당했는데, 이번 프로젝트에서 Backend가 도메인별 Internal API만 제공하기로 하면서 상품·재고·정산 API를 조합·변환하는 중간 서버를 FE 팀이 직접 만들고 운영하게 됐습니다.

   기술을 고르기 전에 책임 범위부터 정의했습니다 — 조합·변환·에러 처리·검증은 하고, DB 접근·트랜잭션·영속화는 하지 않는다. 그러면 전부 I/O 바운드라 "프레임워크 성능은 선택 기준이 아니다"라는 가설이 나왔고, 실측으로 확인한 뒤 Next.js API Routes + tRPC를 채택했습니다. 배포 단위 1개가 유지되고, 서버에서 컴포넌트까지 하나의 타입 시스템으로 이어진다는 게 결정적이었습니다.

2. 왜 Next.js + tRPC였나요? NestJS나 GraphQL은 검토 안 했나요?

   서버 프레임워크 3종(NestJS·Fastify·Next.js) × 프로토콜 3종(REST·GraphQL·tRPC)의 6개 조합을 5개 기준(BFF 적합도·러닝커브·타입 안전성·운용 안정성·생태계)으로 비교했습니다. NestJS는 DI·데코레이터·모듈 시스템이 DB와 트랜잭션을 가진 서버를 전제한 설계라 Stateless BFF에는 과했고, GraphQL은 클라이언트가 어드민 하나뿐이라 스키마·리졸버·Codegen 관리 비용만 남았습니다. Fastify+tRPC는 안정적이었지만 I/O 바운드에서 성능 이점이 없는데 별도 서버 인프라 비용이 들었습니다. 결론과 탈락 근거를 전부 ADR로 남겼습니다.

   1. 판단 근거6개 조합을 5개 기준으로 비교했을 때, 결론을 가장 크게 갈랐던 기준은 무엇이었나요? KR·US

      기준을 나열하는 데서 그쳤는지, 실제로 결정을 가른 기준을 짚을 수 있는지 본다.

      1. 협업과 이견ADR로 남긴 이 결론에 다른 조합을 밀었던 사람은 없었나요? US기술 결정에 대한 다른 의견을 어떻게 받아 정리했는지 본다.
   2. 조건 변경GraphQL을 제외한 이유가 클라이언트가 어드민 하나뿐이라는 점이었는데, 클라이언트가 하나 더 생기면 이 판단은 어떻게 되나요?결정이 기대는 전제와, 그 전제가 깨질 때 흔들리는 지점을 아는지 본다.
   3. 구현 깊이tRPC가 서버에서 컴포넌트까지 타입을 이어 주는데, Backend Internal API의 응답 형식이 바뀌면 그 변화는 어느 지점에서 처음 드러나나요? US

      타입 공유가 미치는 범위와 끊기는 지점을 구현 수준에서 아는지 본다.

      1. 실패와 장애Backend 응답 형식이 바뀐 것을 화면이 깨진 뒤에야 알게 된 적이 실제로 있었나요?이론상의 빈틈이 아니라 실제로 겪은 일인지, 겪었다면 무엇으로 막았는지 본다.
   4. 선택 근거Fastify+tRPC도 안정적이었다면, 배포 단위를 1개로 유지하는 가치를 별도 서버 인프라 비용과 어떻게 견주었나요? KR·US

      배포 단위라는 이점을 비용과 견줘 값을 매겼는지, 감으로 정했는지 확인한다.

      1. 조건 변경이 BFF를 별도 서버로 분리해야 하는 시점이 온다면, 그 계기는 무엇일 것 같나요? US

         지금의 선택이 어떤 조건에서 뒤집히는지 스스로 정해 두었는지 본다.

         1. 트레이드오프인증 컨텍스트를 만드는 지점이 Next 어댑터에 붙어 있어 독립 서버로 분리할 때 갈아끼워야 하는데, 이 결합은 무엇과 맞바꾼 것인가요? US분리 가능성을 내세운 설계에서 남은 한계를 인정하고 그 대가를 설명하는지 본다.
3. "프레임워크 성능은 차별점이 아니다"를 어떻게 확신했나요?

   통념을 실측으로 검증했습니다. 세 프레임워크에 동일한 tRPC procedure를 올리고 k6로 3단계 부하(1천/1만/10만 건 처리) × VU 30·100을 돌렸습니다. 경부하에서 NestJS와 Fastify의 차이는 0.02ms 미만, Next.js는 약 1ms 오버헤드 수준이었고, 고부하에서는 프레임워크가 아니라 비즈니스 로직 복잡도가 성능을 좌우했습니다. VU를 3.3배 올렸을 때 무거운 시나리오만 처리량이 1.1배에 그쳐 CPU 병목인 것도 확인했고요. 테스트 코드는 공개 레포로 남겼습니다.

   1. 결과 검증동일한 tRPC procedure로 잰 NestJS와 Fastify 사이의 0.02ms 미만 차이가 실제 BFF의 호출 전반을 대표한다고 볼 수 있는 근거는 무엇인가요? US

      좁은 조건에서 나온 수치를 일반화하고 있지는 않은지 본다.

      1. 구현 깊이k6가 보고한 지연이 서버 처리 시간인지 부하 도구 쪽 대기까지 포함한 값인지는 어떻게 구분했나요? KR·US

         측정 도구가 실제로 무엇을 재는지 알고 결과를 해석했는지 확인한다.

         1. 회고이 실측을 지금 다시 설계한다면 가장 먼저 바꿀 부분은 무엇인가요? US측정 설계의 한계를 스스로 알고 다음에 무엇을 보완할지 본다.
   2. 판단 근거Next.js는 약 1ms의 오버헤드가 나왔는데, 그 차이를 감수해도 된다고 본 기준은 무엇이었나요? KR·US

      실측에서 불리하게 나온 항목을 어떤 기준으로 받아들였는지 확인한다.

      1. 협업과 이견성능이 프레임워크 선택 기준이어야 한다고 보는 사람이 있었다면, 이 결과로 그 의견을 어떻게 좁혔나요? KR통념과 다른 결론을 데이터로 설득하는 과정을 어떻게 이끌었는지 본다.
   3. 조건 변경고부하에서 VU를 올려도 처리량이 거의 늘지 않은 CPU 병목 시나리오가 있었는데, BFF의 변환 로직이 그만큼 무거워지면 프레임워크 성능은 선택 기준이 아니라는 결론이 어디까지 유지되나요?

      결론이 성립하는 조건의 경계를 아는지, 일반론으로 밀어붙이지 않는지 본다.

      1. 실패와 장애운영 중에 CPU 병목이 실제로 나타난다면 가장 먼저 무엇을 보고 알아채나요? KR·US실측에서 본 병목을 운영 신호와 연결해 대응할 수 있는지 확인한다.
4. 부하테스트 기준은 어떻게 잡았나요? 결과는요?

   기준 부하를 임의로 정하지 않고 서비스 사용 패턴(사용자 수·활동 시간·평균 체류)으로 평균 동시접속을 계산해 baseline을 만들고, ×3 / ×5 / ×10 시나리오를 구성했습니다. 통과 기준은 사내 유사 어드민 서버를 참조해 P50 100ms·P95 300ms로 정했고, 결과는 P50 49ms·P95 177ms, 기준의 10배 부하까지 전 구간 Error Rate 0%였습니다. 측정값을 근거로 Pod을 늘리면 P95가 어디까지 내려가는지 예측치도 산출해 리소스 산정 근거로 제시했습니다.

   1. 판단 근거평균 동시접속으로 기준 부하를 잡으면 특정 시간대에 몰리는 피크는 어떻게 반영되나요?

      평균값이 가리는 순간적인 집중 부하를 인지하고 있는지 본다.

      1. 조건 변경기준의 10배까지 에러율이 0%였다면, 어느 지점에서 무너지는지도 확인했나요?

         통과했다는 사실에서 멈추지 않고 한계점까지 확인했는지 본다.

         1. 실패와 장애한계에 다다랐을 때 가장 먼저 무너지는 곳이 BFF인지 하류 Internal API인지는 어떻게 가려내나요? KR·US병목의 위치를 추측이 아니라 측정으로 가려낼 수 있는지 확인한다.
      2. 회고기준 부하와 통과 기준을 지금 다시 정한다면 어느 쪽을 가장 먼저 바꾸시겠어요? KR기준 설정의 약점을 스스로 알고 있는지, 지금의 정보로 다시 평가하는지 본다.
   2. 결과 검증사내 유사 어드민 서버를 참조해 정한 P95 300ms가 이 어드민 사용자가 실제로 체감하는 기준으로도 적절한지는 어떻게 확인했나요? US통과 기준의 출처가 다른 서비스에 있을 때 이 서비스에 맞는지 따져 봤는지 본다.
   3. 구체화부하테스트 중 하류 Internal API는 실제 서버였나요, 대체 응답이었나요?

      통과한 수치가 어느 범위의 시스템을 측정한 것인지, 결과의 해석 범위를 확인한다.

      1. 실패와 장애하류 Internal API 하나가 느려지는 상황에서 P95가 어떻게 달라지는지도 따로 시험했나요? US정상 상태의 수치만이 아니라 하류가 느려지는 상황까지 시험했는지 본다.
   4. 결과 검증Pod을 늘리면 P95가 어디까지 내려가는지 산출한 예측치를 실제로 증설한 뒤의 측정과 비교해 봤나요?

      예측치로 리소스를 산정했다면 그 예측이 맞았는지 되짚는지 확인한다.

      1. 협업과 이견리소스 산정 근거로 제시한 이 예측치에 대해 받아들이는 쪽에서 반박이나 추가 요구는 없었나요? US수치를 근거로 제시한 뒤 상대의 반박이나 추가 요구를 어떻게 다뤘는지 본다.
5. Circuit Breaker는 왜 필요했고, 멀티 Pod 상태 동기화는 어떻게 했나요?

   BFF가 여러 Internal API를 조합하니 하나가 느려지면 무관한 화면까지 함께 느려지는 연쇄 장애 위험이 있습니다. 적용 기준 4가지(P95 100ms 이상 / 에러율 7일 평균 1% 이상 / 병렬 호출 3개 이상 / 실패 시 페이지 진입 불가)와 설정값의 근거(timeout 3초 = 이탈 시점, reset 10초 = 재시작 회복 시간, volume 5회 = 저트래픽 오발동 방지)를 먼저 표준화했습니다.

   멀티 Pod 동기화는 일부러 안 했습니다. Redis로 맞출 수 있지만 Redis가 새 SPOF가 되고 Stateless 원칙에 어긋나며, Pod 2~5개 수준에선 volumeThreshold 안에서 각 Pod이 같은 상태로 수렴합니다. 이 트레이드오프를 문서에 명시했고요. 폴백 원칙도 정했습니다 — 폴백은 클라이언트가 처리 가능한 타입을 반환해야 하고, throw하면 Error Boundary까지 전파돼 화면 전체가 깨집니다. 현재는 기준 수립 단계고 적용을 진행하고 있습니다.

   1. 구체화적용 기준 4가지는 모두 충족해야 대상이 되나요, 하나만 충족해도 되나요?

      기준을 나열한 데서 그치지 않고 실제로 어떻게 판정하는지 확인한다.

      1. 판단 근거timeout을 3초로 잡으면서 그 시간을 사용자 이탈 시점으로 본 근거는 무엇인가요? US설정값이 감이 아니라 관측된 신호에서 나왔는지 본다.
   2. 트레이드오프적용이 아직 진행 중이라면, 멀티 Pod 상태 동기화를 뺀 대가로 감수하는 위험이 실제로 얼마나 큰지는 어떻게 가늠하나요? US

      운영 데이터가 충분히 쌓이기 전에 뺀 기능의 위험을 어떻게 가늠하는지 본다.

      1. 조건 변경Pod이 5개를 훨씬 넘게 늘어나면 상태를 맞추지 않아도 된다는 판단은 어디서부터 어긋나나요? US

         판단이 성립하는 규모의 한계를 스스로 정해 두었는지 본다.

         1. 실패와 장애Pod이 늘어 Pod당 요청이 줄면 volume 5회를 채우는 데 걸리는 시간도 늘어날 텐데, 그동안 하류 장애는 어떻게 다루나요? US설정값끼리 맞물려 생기는 빈틈을 미리 떠올려 봤는지 본다.
   3. 트레이드오프폴백이 클라이언트가 처리할 수 있는 타입으로 값을 돌려주면 사용자가 그것을 실제 데이터로 오해할 수 있는데, 화면에서는 어떻게 구분하나요? US

      장애를 가리는 폴백이 오히려 만드는 오해의 위험을 인지하는지 본다.

      1. 구현 깊이폴백은 throw하지 않고 타입을 반환해야 한다는 규칙을 리뷰가 아니라 코드나 도구로 강제할 수 있나요?규칙을 사람의 주의에 맡기는지 구조로 막는지 본다.
   4. 협업과 이견적용 기준을 표준으로 문서화하는 과정에서 팀원과 의견이 갈린 부분은 없었나요? KR

      문서로 남긴 기준이 팀의 합의를 거쳤는지 확인한다.

      1. 회고적용보다 기준 수립을 먼저 한 순서를 지금 다시 고른다면 그대로 두시겠어요? KR기준부터 세운 결정을 지금의 정보로 다시 평가하는지 본다.
6. "독립 서버로 분리 가능하게 설계했다"고 했는데, 정말 그런가요?

   "~할 수 있게 설계했다"는 주장은 실제로 해봤는지, 한계가 뭔지를 반드시 되묻는다.

   정확히 말하면 대부분은 그렇고, 한 군데가 남아 있습니다. 라우터·스키마·비즈니스 로직에는 Next.js import가 없고 전송 계층도 표준 fetch 어댑터를 써서, 다른 서버에 그대로 얹을 수 있습니다.

   남은 건 인증 컨텍스트를 만드는 지점입니다. 요청에서 쿠키·헤더를 읽는 부분이 Next 어댑터에 붙어 있어서, 실제로 떼어내려면 그 함수를 프레임워크에 맞게 갈아끼워야 합니다. 아직 분리해본 적은 없고, 지금 트래픽에서는 분리할 이유도 없습니다. "언제든 분리된다"가 아니라 "분리 비용을 한 군데로 몰아뒀다"가 정확한 표현입니다.

7. 팀 표준으로 정착한 코드가 있나요?

   API·Service 레이어에서 쓰는 함수형 파이프라인 유틸을 직접 만들었습니다. 요청 검증 → 호출 → 응답 검증 → 에러 캡처를 매번 같은 순서로 조립하게 해주는 얇은 도구인데, 지금은 저장소 전체에서 800곳 넘게 쓰이고 규칙 문서에도 표준 패턴으로 명시돼 있습니다.

   정착한 이유는 도구가 대단해서가 아니라 규칙 문서와 같이 갔기 때문이라고 봅니다. "이렇게 쓰세요"만 있으면 안 따르는데, 레이어 규칙에 예시로 박아두고 리뷰 봇이 그 형태를 검사하니 자연스럽게 기본값이 됐습니다.

8. 상품 폼이 200여 개 필드라던데, 어떻게 관리 가능하게 만들었나요?

   필드를 화면에 늘어놓지 않고 섹션 40여 개로 쪼갰습니다. 섹션마다 자기 스키마와 기본값을 갖고, 그걸 한 객체로 조립해 폼 전체 스키마를 만듭니다. 덕분에 섹션 하나를 고칠 때 그 파일만 보면 되고, 타입과 기본값이 자동으로 따라옵니다.

   섹션을 넘어가는 규칙 — 예를 들어 무신사 차이나를 선택하면 중국 전용 섹션들이 통째로 필수가 되는 — 은 개별 섹션이 알 수 없으니 크로스필드 검증 한 곳에 모았습니다.

   화면 쪽은 섹션 레지스트리라는 배열 하나가 단일 진실입니다. 각 항목이 id·라벨·앵커 그룹·기본 펼침 여부·작성 완료 판정 함수를 갖고, 배열 선언 순서가 곧 화면 순서입니다. 등록·수정·조회에 중국 검수 상세까지 네 화면이 이 배열을 그대로 map 해서 렌더하기 때문에, 화면마다 순서가 어긋나는 일이 구조적으로 생기지 않습니다.

   노출 여부만 별도 훅이 맡습니다. 폼 값(선택한 플랫폼·카테고리·품목)과 모드(등록/수정/조회, 내부 운영자/파트너)를 구독해 섹션별 true·false 맵을 만들고, 화면은 그 맵만 보고 그립니다.

   1. 구체화40여 개 섹션은 무엇을 기준으로 나눴고, 어느 섹션에 넣을지 애매한 필드는 어떻게 정했나요? US

      분리 기준이 원칙에서 나온 것인지 화면 단위로 나눈 관성인지 세부 사례로 가른다.

      1. 조건 변경필드가 지금의 200여 개보다 크게 늘어난다면 섹션 단위 분리에서 가장 먼저 한계를 보이는 지점은 어디일까요? US설계가 전제한 규모를 알고 한계를 예측하는지 본다.
   2. 선택 근거섹션마다 Zod 스키마와 기본값을 정의해 하나로 조립하는 방식을, 처음부터 하나의 큰 스키마로 두는 안과 견줘 고른 이유는 무엇인가요? KR·US

      구조를 대안과 견줘 정했는지, 익숙해서 골랐는지 가른다.

      1. 트레이드오프스키마와 기본값을 섹션마다 따로 두면 같은 개념이 섹션마다 다르게 정의될 위험이 생기지 않나요?

         분리의 대가를 스스로 아는지 압박해 본다.

         1. 협업과 이견섹션에 걸친 규칙(예: 특정 플랫폼 선택 시 전용 섹션 필수)이 바뀔 때 그 규칙을 정하는 쪽과는 어떻게 합의하고 크로스필드 검증에 반영했나요? KR규칙의 주인과 코드의 주인이 다를 때 조율하는 방식을 본다.
   3. 이력서 대조섹션 레지스트리가 화면의 순서·노출·검증 전략을 결정하는 단일 진실이라고 했는데, "검증 전략"은 구체적으로 무엇을 뜻하나요? KR이력서의 표현이 실제 구현과 맞는지, 모호한 용어를 풀어 말할 수 있는지 확인한다.
   4. 결과 검증폼을 40여 개 섹션으로 분리한 것이 분리하지 않았을 때보다 낫다는 것을 어떤 근거로 말할 수 있나요? KR·US

      개선했다는 주장을 측정이나 사례로 뒷받침하는지 본다.

      1. 실패와 장애분리한 뒤에 입력 지연처럼 새로 생긴 문제는 없었고, 있었다면 어떻게 확인하고 고쳤나요? KR·US성공한 구조에서도 실제 문제를 겪고 다뤘는지 확인한다.
9. 플랫폼이 하나 더 늘면 실제로 무엇을 고쳐야 하나요?

   "스키마 확장만으로 대응"이 사실인지 검증하는 질문. 구체적으로 답할 수 있어야 한다.

   무신사 차이나가 실제로 그 경로로 들어왔습니다. 순서대로 ① 전용 섹션의 스키마 파일을 추가하고, ② 폼 스키마 조립부에 그 섹션을 한 줄씩 등록하고, ③ 레지스트리에 항목을 넣어 순서와 라벨을 정하고, ④ 노출 조건을 가시성 훅에 추가합니다. 그렇게 중국 전용 섹션 10개가 붙었습니다.

   여기서 중요한 건 등록·수정·조회·검수 화면 코드는 건드리지 않는다는 점입니다. 네 화면 모두 레지스트리를 map 할 뿐이라, 항목이 늘면 알아서 렌더됩니다. 다만 정직하게 말하면 완전히 공짜는 아닙니다 — 섹션을 넘는 필수 규칙이 있으면 크로스필드 검증에도 손이 갑니다.

10. 섹션 하나를 빠뜨리면 어떻게 되나요? 타입으로 막히나요?

    노출 맵은 막힙니다. 섹션 식별자 enum을 키로 하는 완전한 레코드 타입이라, enum에 새 섹션을 추가하면 노출 맵에도 넣으라고 타입 검사가 강제합니다.

    반대로 레지스트리 배열에 넣는 것은 타입이 강제하지 못합니다. 배열이라 빠뜨려도 컴파일은 통과하고, 대신 화면에 안 나옵니다. 이건 한계로 알고 있고, 그래서 레지스트리 파일에 "화면 순서의 단일 진실은 이 배열"이라는 주석을 명시해뒀습니다.

11. 섹션 스키마가 자기 밖의 값을 알아야 할 때는 어떻게 하나요?

    스키마 자체는 자기 섹션만 봅니다. 다른 섹션 값에 의존하는 규칙은 조립된 폼 스키마 위에서 크로스필드 검증으로 처리하고, 어떤 섹션의 어떤 필드에 오류를 붙일지 경로를 지정해 화면이 그 자리에 에러를 띄우게 합니다.

    스키마만으로 안 되는 경우도 있습니다. 상품 속성의 필수 여부는 서버에서 받아온 메타데이터를 알아야 판정되는데, 이건 스키마가 접근할 수 없어서 폼 검증 단계에서 별도 검증 결과를 병합합니다. 검증 지점이 두 곳으로 갈리면 헷갈리니, 어디가 단일 진실인지 코드 주석으로 못박아뒀습니다.

12. 조회 화면은 입력이 없는데 왜 같은 구조를 씁니까?

    보이는 항목과 순서가 등록·수정과 같아야 하기 때문입니다. 조회를 따로 짜면 필드가 하나 추가될 때마다 두 곳을 고쳐야 하고, 실제로 한쪽만 반영되는 일이 생깁니다. 같은 레지스트리를 쓰면 추가·순서 변경이 한 번에 네 화면에 반영됩니다.

    대신 모드에 따라 달라지는 부분(편집 가능 여부, 내부 운영자 전용 섹션)은 가시성 훅과 모드 컨텍스트가 흡수합니다. 예를 들어 중국 검수 상태에서는 중국 관련 섹션만 읽기 전용으로 잠그고 공통 정보는 계속 편집 가능하게 두는 식입니다.

13. 이 구조에서 아쉬웠던 점은 없나요?

    한계를 스스로 말할 수 있으면 설계를 실제로 운영해본 사람으로 읽힌다.

    두 가지가 있습니다. 하나는 방금 말한 레지스트리 등록을 타입이 강제하지 못한다는 점이고, 다른 하나는 폼 그룹과 화면 섹션이 항상 1:1이 아니라는 것입니다. 중국 원산지·제조사는 값은 기존 섹션에 그대로 두고 화면만 분리해야 했는데, 그때 예외 처리를 위한 별도 매핑이 필요했습니다.

    둘 다 "한 곳에 모으면 단순해진다"는 원칙이 현실의 예외를 만났을 때 생긴 비용입니다. 지금은 예외가 소수라 매핑으로 감당하지만, 늘어나면 섹션 정의 자체를 폼 그룹과 분리하는 편이 낫다고 보고 있습니다.

14. 수천 건 엑셀 일괄 처리는 어떻게 설계했나요?

    원칙은 하나였습니다 — "사용자는 느려도 되지만, 일괄 작업 한 번이 UI를 서빙하는 서버 용량을 잠식하면 안 된다." BFF는 어드민 UI를 서빙하는 같은 프로세스니까요.

    파싱과 선검증을 클라이언트에서 끝내고, 청크로 나눠 동시 2개까지만 전송합니다. 처리 완료를 기다리는 동기 경로는 청크를 잘게(10행), 접수만 하고 폴링하는 비동기 경로는 100행 × 최대 50청크(상한 5,000행)로 크게 잡았습니다 — 워커를 잡아두는 시간이 다르기 때문입니다. 행 단위 실행은 여러 건을 병렬 처리하는 별도 서버에 청크당 한 번의 호출로 위임하고, 행 단위 멱등키(uploadId:rowIndex 해시)로 재시도 중복을 막았습니다. 결과는 행별 상태로 받아 그리드에 표시하고, 실패한 행만 엑셀로 다시 받아 그것만 고쳐 재업로드할 수 있게 했습니다.

    동시성 2는 처음부터 정한 값이 아니라 3 → 2 → 1 → 2로 조정한 값입니다. dev에서 서킷브레이커가 열려 1까지 내렸는데, 원인은 동시성이 아니라 청크당 하류 호출이 11회인 구조였습니다. 필수 필드 조회를 다건 1콜로 바꿔 청크당 호출을 11회에서 2회로 줄인 뒤에야 동시성을 되돌릴 수 있었습니다 — 숫자를 조이는 것보다 호출 구조를 고치는 게 답이었습니다.

    1. 판단 근거동시에 2건까지만 보내는 값은 무엇을 보고 정했나요? US

       숫자를 감으로 정했는지 신호를 보고 조정했는지, 값이 나온 과정을 확인한다.

       1. 조건 변경수천 건이 그보다 훨씬 많아진다면 동시 2건 제한과 청크 분할 중 무엇이 먼저 한계가 되나요? US구조가 전제하는 규모와 그 너머에서 무너지는 지점을 아는지 본다.
       2. 협업과 이견별도 서버가 묶음 단위로 병렬 처리하는 것을 전제로 동시 2건 제한을 정하면서, 반영 API나 서버를 맡은 쪽과 의견이 갈린 부분은 없었나요? US자기 영역 밖의 제약을 이웃 팀과 어떻게 맞췄는지 본다.
    2. 선택 근거파일을 통째로 서버에 올려 처리하지 않고 브라우저에서 파싱과 1차 검증까지 하도록 한 이유는 무엇인가요? KR·US

       처리 위치를 대안과 견줘 정했는지, 그 기준이 무엇이었는지 확인한다.

       1. 트레이드오프1차 검증이 브라우저에 있으면 서버가 최종으로 보는 규칙과 어긋나 통과한 행이 나중에 거절되지는 않나요? US

          검증이 두 곳으로 나뉜 대가를 스스로 아는지 압박해 본다.

          1. 회고검증 규칙이 브라우저와 서버 두 곳에 있는 구조를 지금 다시 정한다면 그대로 두시겠어요? KR과거 결정을 지금의 기준으로 다시 평가하는지 본다.
    3. 실패와 장애묶음 처리 중간에 일부 행이 실패하거나 요청이 끊기면, 실패한 행만 골라 다시 올리는 흐름에서 성공 여부를 모르는 행은 어떻게 다루나요? US

       정상 경로가 아니라 부분 실패와 재시도 경로를 끝까지 설계했는지 본다.

       1. 구현 깊이행마다 고유 키로 재시도 중복을 막는다고 했는데, 중복 여부는 어디서 판정하나요? US멱등성을 개념으로만 아는지 실제 구현 단위까지 아는지 가른다.
    4. 결과 검증일괄 작업이 도는 동안 "다른 사용자의 화면이 느려지면 안 된다"는 원칙이 지켜졌다는 것은 무엇으로 확인했나요? US원칙을 말로만 세웠는지 측정으로 확인했는지 본다.
15. 판매지역을 "단일 진실"로 재설계했다는 게 무슨 뜻인가요?

    기존에는 「해외 판매 여부」 스위치와 「글로벌 전용 상품」 라디오 같은 플래그를 사용자가 직접 설정했습니다. 플랫폼과 판매 국가가 늘어나니 플래그끼리 모순될 수 있는 구조였고요. 재설계에서 판매지역 선택 하나를 단일 진실로 두고, 기존 플래그들은 선택값에서 계산되는 파생값으로 바꿨습니다 — KR만이면 둘 다 N, KR+해외면 해외판매 Y, 해외만이면 글로벌 전용까지 Y.

    중요한 건 그 값을 이미 참조하던 기능들(결제·프로모션·물류·출고지 등 13곳)이었는데, 값을 없애지 않고 스키마 파생 필드로 남겨 그대로 공급해서 코드 변경 없이 유지했습니다. 레거시 상품은 기존 플래그 조합을 판매지역으로 역매핑하는 마이그레이션 프리필로 흡수했고요.

    1. 문제 정의판매 범위 설정값이 여러 개로 흩어져 서로 모순될 수 있는 구조를 재설계 대상으로 삼은 이유는 무엇이고, 재설계가 끝났다고 판단하는 기준은 무엇이었나요? KR·US

       과제를 받아 구현만 했는지, 문제와 성공 기준을 스스로 정의했는지 가른다.

       1. 조건 변경판매지역이 지금의 14개보다 늘거나 플랫폼마다 팔 수 있는 지역이 달라지면 파생 규칙에서 먼저 손봐야 하는 곳은 어디일까요? US파생 구조가 기대는 전제와 그 전제가 바뀔 때의 파급을 아는지 본다.
    2. 선택 근거판매지역에서 나머지 값을 파생시키는 대신, 값은 그대로 두고 서로 어긋나지 않게 검증만 추가하는 안은 검토하지 않았나요? KR·US

       단일 진실이라는 결론에 이르기까지 대안을 실제로 저울질했는지 본다.

       1. 트레이드오프값을 파생으로 바꾸면 항목마다 따로 조정하던 자유가 사라지는데, 그 때문에 막힌 요구는 없었나요?

          해결책이 포기한 것을 스스로 아는지 압박해 본다.

          1. 회고이 재설계를 지금 다시 한다면 무엇을 가장 먼저 바꾸시겠어요? US회고를 다음 설계의 기준으로 바꿨는지 본다.
    3. 결과 검증이미 그 값을 쓰던 13개 기능이 수정 없이 그대로 동작한다는 것은 무엇으로 확인했고, 13개라는 범위는 어떻게 파악했나요? US

       수치의 정의와 측정 방법, 범위를 빠뜨리지 않았다는 근거를 요구한다.

       1. 실패와 장애파생으로 바꾼 뒤 기존 값과 다르게 계산돼 문제가 된 상품이나 기능은 없었고, 있었다면 어떻게 발견하고 고쳤나요? US전환 뒤 실제로 생긴 어긋남을 감지하고 다룬 경험이 있는지 확인한다.
    4. 협업과 이견그 값을 쓰던 기능을 맡은 쪽에 변경을 어떻게 알렸고, 우려나 반대는 없었나요? US직접 관리하지 않는 영역을 건드리는 변경을 어떻게 설득해 진행했는지 본다.

29CM 카탈로그팀 (2024)

1. 상품 상세 아키텍처 전환 — 어떤 구조에서 어떤 구조로, 왜 전환했나요?
2. 트래픽이 가장 많은 화면을 바꾸면서 어떤 안전장치를 뒀나요? 점진 배포·롤백 계획은? 이 답이 있으면 "만들 줄 안다"에서 "운영할 줄 안다"로 올라간다.
3. AppleCare+ 같은 무형상품이 기존 상품 모델의 어떤 점과 맞지 않았나요?
4. 속성 조합이 많을 때 품절·비활성 조합은 어떻게 표현했나요? 속성 피커를 실제로 만들었다면 반드시 부딪히는 지점.
5. 사전판매 대기열에서 클라이언트가 책임진 범위는? 새로고침하거나 탭을 여러 개 열면?
6. 매입/위탁 상품 매칭은 어떤 문제였나요?

   같은 제품이라도 매입 상품과 위탁 상품이 별개로 등록돼 따로 팔리고 있어서, 고객이 원하는 옵션이 다른 쪽 상품에 있어도 알 수 없는 문제였습니다. 매칭된 상품끼리 서로 안내하고 넘어갈 수 있게 했는데, 이동할 때 지금까지 고른 옵션·수량 상태를 유실 없이 상대 상품 상세로 전달하는 게 프론트엔드의 핵심 설계였습니다. 고객향 화면과 운영자 매칭 어드민을 함께 담당했고요.

   배포는 "매칭 데이터가 없으면 기존 화면과 완전히 동일하게 동작한다"는 성질을 근거로 본 오픈 전 선배포가 무해하다고 판단해 리스크를 줄였습니다.

7. Testing Working Group은 어떻게 시작했고, 실제로 뭐가 바뀌었나요?

   당시 조직에 테스트 코드가 사실상 없었습니다 — CI에 typecheck 외에는 아무것도 없고, 커버리지 측정도 안 됐습니다. 누가 시킨 게 아니라 문제를 정의해서 크로스팀 워킹그룹을 직접 발족하고 오너십("FE 테스트 환경 전반의 오너십을 가진다")과 주 1회 운영을 정했습니다.

   전략은 아키텍처와 붙였습니다 — api는 검증, service는 단위, feature는 시각, app은 E2E로 레이어별 테스트 기법을 매핑했고, 8종의 테스트 유형 중 Unit/Integration/E2E 3계층으로 압축해 시작했습니다. 제가 쓴 개요 문서로 스터디를 직접 진행했고, 개인당 유닛 테스트 5개씩 PR로 올려 리뷰받는 식으로 실제 코드까지 끌고 갔습니다. 레거시(주문배송)는 범위에서 빼는 현실적 선긋기도 했고요.

SEO

1. 색인이 6천에서 7~8만으로 늘었다고 했는데, 그게 본인 작업 때문이라는 걸 어떻게 확인했나요?

   유일하게 수치가 있는 겟차 성과라 인과관계를 반드시 파고든다.

   1. 결과 검증검색 노출수와 클릭수가 2~3배 늘어난 것이 이번 SEO 조치 때문이라는 것은 어떻게 확신하시나요? KR

      노출과 클릭이 늘었다는 사실과 그 원인이 이 작업이라는 주장을 나누어 근거를 댈 수 있는지 본다.

      1. 본인 기여이 작업 말고도 노출과 클릭에 영향을 준 요인이 있었다면 본인 작업이 차지한 몫은 어떻게 가려낼 수 있나요?

         서비스 전체의 변화 속에서 본인 작업의 효과를 떼어 내는 방법을 아는지 본다.

         1. 조건 변경조치를 일부 콘텐츠에만 먼저 적용해 비교할 수 있는 상황이라면 노출과 클릭의 증가를 어떻게 검증하시겠어요? KR효과를 분리해서 확인하는 비교 설계를 스스로 그릴 수 있는지 본다.
   2. 이력서 대조이력서에 적은 색인 생성량 6천에서 7~8만이라는 수치는 무엇을 센 값인가요? US

      색인 생성량이라는 수치의 정의를 알고 있는지, 이력서의 숫자가 근거 없이 적힌 것은 아닌지 본다.

      1. 실패와 장애색인 생성량이 갑자기 줄어든 시점이 있었다면 그 원인은 어떻게 살폈나요?성과 수치가 꺾였을 때 원인을 추적한 경험이 있는지 본다.
   3. 판단 근거사이트맵 자동화, 캐노니컬 태그, 메타태그, 스키마 가운데 성과에 가장 크게 기여한 것이 무엇인지는 어떤 데이터로 판단할 수 있나요?네 가지 조치를 한 덩어리로 말하지 않고 조치별 효과를 가르는 방법이 있는지 본다.
   4. 회고작업을 시작하기 전에 미리 측정해 두었더라면 좋았을 지표가 있다면 무엇인가요?성과를 증명하는 데 무엇이 부족했는지 스스로 돌아보는지 본다.
2. 색인이 10배 늘어난 게 실제 유입이나 매출로 이어졌나요?

   1. 결과 검증색인 생성량은 10배 이상 늘었고 노출수와 클릭수는 2~3배 늘었다고 하셨는데, 두 증가 폭의 차이는 어디에서 온다고 보시나요?

      색인이 늘어난 폭과 검색 성과가 늘어난 폭이 다르다는 점을 스스로 짚고 해석할 수 있는지 본다.

      1. 판단 근거색인은 됐는데 검색 결과에 거의 나오지 않는 문서가 있다면 무엇부터 확인하시겠어요?노출이 적은 문서를 놓고 원인을 어떤 순서로 좁혀 가는지 본다.
   2. 구현 깊이콘텐츠별 메타태그에 콘텐츠의 어떤 정보를 담을지는 어떻게 정했나요? KR

      메타태그를 콘텐츠마다 다르게 만든다는 말이 구현에서 무엇을 뜻하는지 아는지 본다.

      1. 트레이드오프메타태그를 자동으로 채우면 문서마다 비슷한 문구가 반복될 수 있는데, 그 균형은 어떻게 잡나요?자동 생성이 규모를 감당하게 해 주는 대신 문구가 획일화되는 대가를 알고 있는지 본다.
   3. 선택 근거메타태그만으로 끝내지 않고 리치 텍스트 스키마까지 붙이기로 한 이유는 무엇인가요? KR·US

      스키마를 관행처럼 붙인 것이 아니라 메타태그로 부족한 부분을 따져 정했는지 본다.

      1. 실패와 장애스키마가 적용된 문서가 3만 건 이상이라고 하셨는데, 잘못 적용된 문서가 있다면 어떻게 찾아내나요?

         대량으로 붙인 스키마의 오류를 확인하는 수단이 있는지 본다.

         1. 조건 변경검색 엔진이 특정 리치 결과의 지원을 바꾸거나 없앤다면 붙여 둔 스키마는 어떻게 하시겠어요?검색 엔진의 정책에 기대는 조치가 바깥 조건이 바뀔 때 어떻게 되는지 생각해 두었는지 본다.
   4. 문제 정의이 작업의 성공 기준을 서비스의 어떤 변화로 정의하셨나요?색인 생성량 자체를 성공 기준으로 삼았는지, 서비스에 생기는 변화를 기준으로 삼았는지 본다.
3. 캐노니컬 태그를 잘못 걸면 어떤 일이 생기나요? 검증은 어떻게 했나요?
4. 사이트맵 자동화는 어떤 구조였나요?

   1. 판단 근거콘텐츠가 늘어날 때마다 사람이 대응하는 방식으로는 따라갈 수 없다는 판단은 무엇을 보고 내리셨나요?

      자동화가 필요하다는 결론이 실제로 확인한 신호에서 나왔는지, 짐작이었는지를 가른다.

      1. 선택 근거사이트맵을 자동으로 갱신하는 방식을 고르기 전에 견준 다른 방법이 있다면 무엇인가요? KR·US

         자동화 방식을 정할 때 대안을 저울질했는지 본다.

         1. 조건 변경콘텐츠가 쌓이는 속도가 훨씬 빨라진다면 선택한 자동 갱신 방식은 어느 부분에서 먼저 한계에 닿나요?자동화한 구조가 규모가 커질 때 어디서 무너지는지 아는지 본다.
   2. 구현 깊이사이트맵에 어떤 주소를 올릴지와 캐노니컬 태그로 어떤 주소를 대표로 삼을지는 각각 어떤 기준으로 정했나요?

      사이트맵과 캐노니컬이 색인 대상을 넓히는 데 맡은 역할을 구분해서 이해하고 있는지 본다.

      1. 실패와 장애색인하면 안 되는 주소가 사이트맵에 올라간 적이 있다면 어떻게 대응하셨나요?

         자동화가 잘못된 결과를 냈을 때 알아차리고 되돌리는 경로가 있는지 본다.

         1. 트레이드오프자동으로 올리는 주소를 사람이 미리 걸러 내는 단계가 있다면 자동화의 이점이 줄어들 텐데, 어디까지 자동에 맡기는 것이 맞다고 보시나요?자동화의 속도와 잘못된 주소가 나갈 위험을 저울질하는 기준이 있는지 본다.
   3. 결과 검증사이트맵에 올린 주소가 실제로 색인됐는지는 어떻게 확인하나요?

      사이트맵을 올렸다는 사실과 색인됐다는 결과를 나누어 확인하는지 본다.

      1. 구현 깊이올렸는데도 색인되지 않는 주소가 남는다면 그 원인은 어떻게 좁혀 가시나요?색인 상태를 확인하는 도구를 알고 원인을 좁혀 가는 방법이 있는지 본다.
   4. 회고처음 설계에서 지금 다시 보면 다르게 하고 싶은 부분이 있다면 무엇인가요? KR자동화 구조를 만든 뒤에도 자신의 설계를 다시 평가하는지 본다.
5. 렌더링 방식은 무엇이었고, SEO 관점에서 어떤 선택을 했나요?

TypeScript · React Query 마이그레이션

1. 전환을 결심하게 만든 구체적인 문제가 무엇이었나요?
2. 왜 Redux를 걷어내고 React Query였나요? RTK Query나 SWR은 검토했나요?
3. 서비스를 멈출 수 없는 상태에서 어떻게 점진적으로 전환했나요?
4. "주도했다"고 하셨는데, 팀원들이 실제로 따라왔나요? 주도의 진위를 가르는 질문. 채택률이 곧 증거다.

React Native · 오픈소스 · 그 외

1. react-native-webview 문제는 어떻게 찾아냈나요? 디버깅 과정을 설명해주세요.

   증상은 iOS에서만 영상이 네이티브 풀스크린 플레이어로 재생되는 것이었습니다. 처음엔 영상이 나오긴 하니 급하지 않다고 봤는데, 다시 보니 풀스크린 플레이어가 라이브쇼 솔루션의 채팅·구매 플로우 UI를 통째로 덮고 있었습니다. 라이브커머스에서 그 둘이 가려지면 방송이 성립하지 않으니 반드시 고쳐야 했습니다.

   구조상 의심 지점이 다섯 곳이었습니다 — 네이티브 앱, React Native·JS, 브릿지 라이브러리, 웹뷰용 웹페이지, 라이브쇼 솔루션사 제품. 어디서 끊기는지 알 수 없어 확인이 빠른 순서대로 전부 열었습니다. 솔루션사는 video 태그의 인라인 재생 속성이 제대로 설정돼 있어 무혐의, 웹은 iframe 임베딩 코드뿐이라 무혐의. React Native 문서에서 필요한 설정을 찾아 켰는데 동작하지 않았습니다.

   첫 방송이 다음 날이라 일단 급한 불부터 껐습니다. 네이티브 레벨로 내려가 iOS 쪽 구현 파일에서 해당 설정이 적용되도록 강제해 동작시켰습니다. 그리고 나서 라이브러리 코드를 처음부터 읽었습니다. JS에서 받은 props를 네이티브 모듈로 넘기는 지점에서 일부가 그냥 빠져 있었고, node_modules를 직접 고쳐 검증하니 바로 정상 동작했습니다.

   같은 이슈로 막힌 사람들이 있어 업스트림에 PR을 올렸습니다. 이때 제게 필요한 설정 하나만 고치지 않으려고 WKWebView 공식 문서를 훑어 함께 누락돼 있던 설정들까지 포함했습니다. 메인테이너 답변은 "리팩터링하다 누락했다"였고 머지됐습니다.

2. 그 PR은 머지됐나요? 링크가 있나요?

   네. react-native-webview#2548, 2022년 6월에 머지됐습니다. 인라인 재생·AirPlay·데이터 감지 세 설정을 iOS WKWebView 설정으로 전달하는 수정입니다.

   이 과정은 블로그에도 정리해뒀습니다. 라이브러리를 쓰는 것 자체가 일종의 기술 부채라는 것, 그리고 앱은 웹과 달리 hotfix가 안 돼서 라이브러리에 문제가 생기면 손쓸 방법이 거의 없다는 걸 그때 알았습니다. 코드푸시로도 네이티브 코드나 패키지 버전은 못 고치고, 런타임에 node_modules를 수정하는 방법도 찾아봤지만 빌드 시점에 그 개념 자체가 사라져 불가능했습니다.

3. Sentry를 붙이면 노이즈가 많았을 텐데 어떻게 걸러냈나요?
4. WebView와 웹 사이 통신 규칙을 정리했다고 했는데, 앱 구버전 하위호환은 어떻게 다뤘나요?
5. SDU(Server Driven UI)의 트레이드오프는 무엇이라고 보나요?

   겟차에서 SDU 기반 광고 화면을 만들었고, 무신사 팀 초기에도 어드민에 SDU를 적용할지 검토했습니다. 그때 제 판단은 "6:4로 찬성이되, 한계를 명시하자"였습니다 — 반복되는 화면이 많은 조직에는 공수를 줄여주지만, 전역 상태처럼 서버가 기술하기 어려운 영역을 넘어가면 유지가 어려워집니다. 어디까지 서버에 맡길지 경계를 먼저 정하는 게 도입보다 중요하다고 봅니다.

6. 스코어본에서 1인 개발로 1.0까지 갔다고 했는데, 혼자 할 때 품질은 어떻게 담보했나요?

1. React 렌더링 최적화를 실제로 적용한 사례를 말해주세요. 무엇으로 병목을 찾았나요?
2. 서버 상태와 클라이언트 상태를 어떤 기준으로 나누나요?

   팀 표준으로 정한 기준이 있습니다. 서버에서 온 데이터는 전부 TanStack Query가 관리하고, 쿼리 키와 쿼리 함수는 service를 따라가도록 쿼리 팩토리로 묶어 feature가 캐시 키를 임의로 만들지 못하게 했습니다. 공유가 필요한 클라이언트 상태는 Context를 제한적으로, URL에 있어야 할 상태(검색 조건·필터)는 nuqs로 쿼리스트링에 둡니다 — 어드민은 화면 공유가 잦아서 URL이 상태의 올바른 위치인 경우가 많습니다. 전역 스토어 남용은 이전 코드베이스에서 데이터 흐름 추적을 망가뜨리는 걸 직접 봤어서 의식적으로 피합니다.

   1. 구체화서버에서 받아 온 값을 사용자가 고쳐 가며 편집하는 폼 상태는 어떤 기준으로 어느 쪽에 두나요? US서버 상태와 클라이언트 상태의 경계에 걸친 사례에서도 기준이 흔들리지 않는지 본다.
   2. 이력서 대조경력기술서에는 자율형 프론트엔드 엔진의 기술에 Zustand가 들어 있는데, 전역 스토어 남용을 의식적으로 피한다는 기준은 그 프로젝트에서 Zustand를 쓰는 부분에 어떻게 적용됐나요? KR기술 목록의 Zustand와 답변의 기준이 어떻게 함께 성립하는지 설명할 수 있는지 본다.
   3. 조건 변경서버 응답을 기다리지 않고 화면에 먼저 반영해야 하는 상호작용이라면, 서버 데이터는 전부 TanStack Query가 관리한다는 기준을 어떻게 적용하시겠어요? US기준이 낙관적 업데이트처럼 클라이언트가 서버 값을 먼저 바꿔 보여 주는 경우에도 성립하는지 본다.
3. TanStack Query에서 캐시 무효화 전략을 어떻게 세우나요?
4. SSR과 CSR을 어떤 기준으로 선택하나요? 커머스에서 SSR이 필요한 이유는?
5. 프론트엔드 성능을 볼 때 어떤 지표를 보나요? 최근에 개선해본 지표는?
6. 타입을 어디까지 엄격하게 가져가나요? 과한 타이핑이라고 느낀 경험은?

   경계에서는 엄격하게, 내부에서는 추론에 맡깁니다. API 경계는 Zod 스키마로 런타임까지 검증하고 타입은 z.infer로 도출합니다. any 금지, 단언 대신 타입 가드가 팀 규칙이고요. 과했던 경험도 있습니다 — 타입 안정성을 위해 뒀던 Entity 계층이 오히려 오버헤드가 돼서(API 불안정성 때문에 Entity에 안 맞는 데이터가 내려와 런타임 에러 유발) 폐지하고 Swagger 기반 자동 생성으로 대체했습니다(생성 파이프라인 자체는 팀의 다른 분들이 만든 것을 썼습니다). 타입은 손으로 지키는 게 아니라 소스에서 생성하는 게 맞다는 교훈이었습니다.

   1. 구체화경계에서는 엄격하게 검증한다고 하셨는데, API 말고 폼 입력이나 URL처럼 밖에서 들어오는 값은 어느 수준까지 검증하시나요?

      경계의 정의가 API 응답에만 머무는지, 앱 안으로 들어오는 모든 외부 입력으로 넓어지는지 본다.

      1. 구현 깊이검증에 실패한 값이 들어오면 화면에서는 어떻게 처리하나요?런타임 검증을 걸어 두는 데서 그치지 않고 실패했을 때 사용자에게 보이는 동작까지 구현했는지 본다.
   2. 트레이드오프any 금지와 단언 대신 타입 가드를 팀 규칙으로 두면 급한 수정이나 라이브러리 타입이 맞지 않는 상황에서 걸림돌이 될 수 있는데, 그런 예외는 어떻게 다루나요? KR엄격한 규칙이 현장에서 만드는 마찰을 알고 예외를 다루는 방법이 있는지 본다.
7. 테스트는 어디까지 작성하나요? 프론트엔드에서 무엇을 테스트할 가치가 있다고 보나요?

   레이어에 따라 다르게 봅니다 — api는 스키마 검증, service는 단위 테스트, feature는 시각 테스트, app은 E2E가 제가 세운 매핑입니다. 순수 로직(service)의 단위 테스트가 비용 대비 가치가 가장 크고, UI는 렌더링이 깨지지 않는 수준의 스모크와 시각 회귀가 실용적이라고 봅니다. 29CM에서 테스트가 전무한 상태로 Testing WG를 만들어 이 기준으로 시작했고, 전부 하려다 아무것도 못 하는 걸 막으려 8종 중 3계층(Unit/Integration/E2E)으로 압축해 도입했습니다.

   1. 선택 근거8종 중 3계층으로 압축할 때 남길 것과 버릴 것은 어떤 기준으로 갈랐나요? US전부 하려다 아무것도 못 하는 상황을 피하려는 압축이 어떤 우선순위로 이뤄졌는지 본다.
   2. 결과 검증테스트가 전무하던 조직에서 Testing WG를 만든 뒤 테스트가 자리 잡았는지는 무엇으로 판단하나요? KR도입했다는 사실이 아니라 도입 뒤에 실제로 쓰이고 있는지를 확인하는 기준이 있는지 본다.
   3. 실패와 장애E2E나 시각 회귀 테스트가 간헐적으로 실패해 신뢰를 잃는 상황이 있다면 어떻게 다루시겠어요? US테스트를 만든 뒤 유지하는 문제와, 불안정한 테스트가 팀의 신뢰를 떨어뜨리는 문제를 아는지 본다.
8. 공용 컴포넌트의 API를 설계할 때 어떤 원칙을 두나요?

   팀 컨벤션으로 명문화한 원칙이 있습니다. 모든 컴포넌트는 선택적 className을 받아 사용처가 스타일을 주입할 수 있게 하고, 내부 기본 스타일과의 병합은 twMerge로(문자열 이어붙이기는 캐스케이딩 때문에 부모 스타일이 죽습니다), 조건부 변형은 tailwind-variants로 컴포넌트 밖에 선언합니다. 디자인 시스템 위에 만드는 컴포넌트는 원 라이브러리의 props를 상속(interface extends ButtonProps)해 사용자가 이미 아는 인터페이스를 유지합니다. 이벤트 핸들러는 on 접두사, 상호작용 없는 컴포넌트는 서버 컴포넌트로 두는 것까지가 규칙입니다.

   1. 트레이드오프모든 컴포넌트가 className을 받게 하면 사용처가 내부 스타일을 자유롭게 덮어써서 디자인 일관성이 흐트러질 수 있는데, 어디까지 허용하시나요? US재사용성을 열어 두는 규칙이 디자인 일관성과 부딪히는 지점에 기준이 있는지 본다.
   2. 조건 변경디자인 시스템 라이브러리를 다른 것으로 바꾼다면 원 라이브러리의 props를 상속해 만든 컴포넌트는 사용처에 어떤 영향을 주나요?사용자가 이미 아는 인터페이스를 유지하려는 선택이 라이브러리에 묶이는 비용을 알고 있는지 본다.
   3. 구현 깊이문자열 이어붙이기는 캐스케이딩 때문에 부모 스타일이 죽는다고 하셨는데, twMerge는 충돌하는 클래스를 어떻게 가려내나요?규칙으로 정한 도구를 사용법이 아니라 동작 원리로 설명할 수 있는지 본다.
9. 웹 접근성을 고려한 경험이 있나요?
10. 어드민과 대고객 서비스를 만들 때 접근이 어떻게 달라지나요? 둘 다 해본 경력이라 비교를 물어보기 좋은 위치에 있다.
11. 최근에 관심 있게 본 기술이나 읽은 자료가 있나요?

1. 기술 부채를 갚아야 할 시점을 어떻게 판단하나요? 그걸 어떻게 설득하나요?
2. 코드 리뷰에서 무엇을 주로 보나요? 의견이 갈리면 어떻게 결론을 내나요?
3. 일정과 품질이 충돌할 때 어떻게 결정하나요? 실제 사례가 있나요?
4. 본인이 내린 기술 결정 중 틀렸다고 판명된 것이 있나요? 어떻게 수습했나요?

   실패를 말할 수 있으면 신뢰도가 가장 크게 오르는 질문.

   제가 설계한 아키텍처 V1이 그렇습니다. 타입 안정성을 위해 Entity 계층을 뒀는데, 실제로는 백엔드 응답 스키마가 조금만 바뀌어도 3개 레이어를 함께 고쳐야 하는 결합을 만들었고, Entity에 안 맞는 데이터가 내려오면 런타임 에러가 나는 지점이 됐습니다. 수습은 회고로 했습니다 — 문제를 팀 데이터로 진단하고, Service Layer를 Anti-Corruption Layer로 재정의한 V2를 만들어 Entity를 폐지하고 Swagger 기반 타입 생성으로 대체하는 방향을 도출했습니다. 그리고 V2를 AI 룰로 만들어 봇이 새 기준으로 검사하게 했습니다. 틀린 결정 자체보다, 틀렸다는 걸 어떻게 발견하고 되돌리는 장치가 있느냐가 중요하다고 생각합니다.

   1. 회고V1을 겪은 뒤 다른 설계 결정에서 달라진 점이 있다면 무엇인가요? US틀린 결정에서 배운 것이 그 뒤의 결정에 실제로 적용됐는지 본다.
   2. 트레이드오프지금 유지하고 있는 결정 중 나중에 틀렸다고 판명될 가능성이 가장 크다고 보는 것이 있다면 무엇인가요? US과거의 실패를 말하는 데서 그치지 않고 현재 결정의 약점을 스스로 찾고 있는지 본다.
5. 말씀하신 성과 중에서 본인이 직접 한 부분과 팀이 함께 한 부분을 구분해주세요.

   주어가 불명확한 서술은 서류 감점 요인으로 자주 지적된다. 면접에서도 그대로 확인한다.

   구분해서 말씀드리면 — 아키텍처 설계와 문서화, 리뷰 봇·Figma 플러그인 같은 도구 제작, BFF 기술 선택은 제가 주도했습니다. ADR에 의사결정자가 저로 명시돼 있고 회의 설계·기록도 제가 했습니다. 반면 구현은 팀 작업입니다 — 카탈로그는 3인이 함께했고, Http 모듈·디자인 시스템 배포는 다른 분들 담당이었습니다. 회고 개선안도 제가 정리했지만 결정은 팀 합의였고, Service Layer 존치 같은 쟁점에선 반대 의견이 결론을 바꾸기도 했습니다.

   1. 구체화카탈로그를 3인이 함께했다고 하셨는데, 그중 본인이 직접 구현한 부분은 무엇인가요? US주도와 참여를 나눈 서술이 구현의 구체적인 몫으로 이어지는지 본다.
   2. 협업과 이견Service Layer 존치 같은 쟁점에서 반대 의견이 결론에 영향을 준 사례를 하나 들어 주시겠어요?본인이 주도한 결정에서 다른 사람의 반대가 결과에 영향을 준 구체적인 사례를 짚을 수 있는지 본다.
   3. 이력서 대조이력서에서 팀이 함께한 일이 혼자 한 일처럼 읽힐 수 있는 부분이 있다면 어느 항목인가요? KR이력서를 스스로 점검해 과장으로 읽힐 수 있는 문장을 알고 있는지 본다.
6. 주어진 시안이나 스펙대로 만들지 않고 더 나은 방향을 역제안한 적이 있나요?

   표준 옵션 관리에서 시안이 옵션 순서를 숫자 입력으로 지정하게 돼 있었습니다. 운영자가 수십 개 옵션의 순서를 숫자로 고쳐 넣는 그림이라 반복 비용이 크다고 봤고, Drag & Drop을 제안했습니다. 핵심은 제안 방식이었는데 — 말로 하지 않고 최소 리소스로 PoC를 만들어 동작 영상을 Slack에 올렸습니다. 디자이너·기획자가 영상을 보고 바로 판단할 수 있었고, 시안이 수정돼 실제 프로덕션에 반영됐습니다.

   1. 판단 근거숫자 입력이 운영자에게 반복 비용이 크다는 판단은 무엇을 보고 내리셨나요? KR사용자의 실제 작업을 관찰해서 나온 판단인지, 화면을 보고 상상한 판단인지를 가른다.
   2. 트레이드오프Drag & Drop은 숫자 입력보다 구현과 유지 비용이 커질 수 있는데, 그 비용을 이득과 어떻게 견주면 제안할 만하다고 보시나요?더 나은 방향이라는 주장이 만드는 쪽의 비용까지 따져 보는 기준이 있는지 본다.
   3. 조건 변경출시가 임박한 시점에 시안의 문제를 발견했다면 역제안과 시안대로 구현 중 무엇을 기준으로 정하시겠어요? KR·US역제안이 언제나 옳다고 보지 않고 일정 조건에 따라 시안대로 가는 판단도 하는지 본다.
7. 주니어가 합류했을 때 어떻게 온보딩시키나요?

   온보딩 가이드와 3단계 온보딩 미션을 만들어 운영했습니다. 1단계는 적응(팀·문서·채널), 2단계는 환경(개발환경 구동·컨벤션 숙지), 3단계는 실전(코드리뷰 참여 → PR → 배포 → 페어코딩 → 온보딩 회고)입니다. 제가 쓴 아키텍처·컨벤션 문서가 필독 코스로 연결돼 있어서, 문서 → 교육 → 코드리뷰가 하나의 체인으로 이어집니다. 신생 조직의 암묵지를 문서로 바꾸는 게 온보딩 비용을 줄이는 핵심이었습니다.

   1. 조건 변경합류자가 주니어가 아니라 경력이 충분한 개발자라면 3단계 중 무엇을 바꾸시겠어요?온보딩을 합류자의 수준에 맞춰 조정할 수 있는지, 미션이 한 가지 틀에 고정돼 있지는 않은지 본다.
   2. 트레이드오프코드리뷰와 페어코딩까지 미션에 넣으면 멘토 역할을 맡은 본인의 시간이 드는데, 개발 일정과는 어떻게 조율하시나요? US온보딩 비용을 문서로 줄였다고 설명하고 나서도 남는 사람의 시간을 어떻게 다뤘는지 본다.
   3. 실패와 장애미션을 따라가지 못하고 뒤처지는 합류자가 있다면 어떻게 대응하시나요? US잘 맞는 합류자만이 아니라 잘 맞지 않는 합류자를 마주쳤을 때의 대응이 있는지 본다.
8. 개발 프로세스나 팀 문화를 바꿔본 경험이 있나요? 저항은 없었나요?

   신설 팀이라 그라운드 룰 자체가 없어서, 논의할 주제 20여 개를 아젠다로 리스트업하고 데일리에서 하나씩 합의해 나갔습니다 — 코드리뷰 컨벤션, 브랜치 전략, 문서화 체계, 회고 주기, 공수 산정 기준, 모니터링 통합까지. 무신사와 29CM 양쪽의 다른 표준은 비교 문서를 만들어 통합 방향을 정했습니다.

   저항보다는 데이터로 관철한 사례가 기억에 남습니다. 계획 공수(주 5MD)와 실제(7~8MD)의 괴리를 티켓 라벨로 드러내서, 재작업이 예외가 아니라 표준 과정임을 보여주고 공수 버퍼 제도화와 전 직군 주 1회 싱크를 만들었습니다. 사람을 설득하는 것보다 현실을 측정해 보여주는 쪽이 빨랐습니다.

   1. 협업과 이견전 직군 주 1회 싱크는 개발자 외 직군의 시간도 쓰게 되는데, 그 직군에는 어떻게 필요성을 설득하셨나요? KR개발팀에서 정한 제도가 다른 직군의 시간을 요구할 때 그 직군을 어떻게 움직였는지 본다.
   2. 선택 근거20여 개 주제를 한 번에 정하지 않고 데일리에서 하나씩 합의하기로 한 이유는 무엇인가요? KR합의 방식을 정할 때 다른 진행 방식과 견줘 봤는지 본다.
   3. 조건 변경측정할 데이터가 아직 없는 문화 문제라면 변화가 필요하다는 근거를 어떻게 만드시겠어요?현실을 측정해 보여주는 방식이 통하지 않는 문제에도 설득할 다른 수단이 있는지 본다.
9. 채용에 참여해본 경험이 있나요?

   경력 FE 채용의 기술 면접관으로 참여했고, JD·서류 기준·과제 선정 같은 프로세스 설계도 챙겼습니다. 면접은 구조화 질문지를 사전 설계했습니다 — 지원자 이력서를 분해해 검증 항목별로 시간을 배분하고, 핵심 질문·꼬리질문·기대 답변까지 미리 적었습니다. 웹뷰 브릿지의 race condition, Web Vitals의 Lab vs Field 데이터 구분 같은 걸 물어 이력서 기재 내용의 실체를 확인하는 방식이었고, 힌트를 줬을 때만 답하는지까지 평가에 기록했습니다.

   1. 트레이드오프지원자마다 이력서에서 질문을 뽑으면 지원자 사이의 비교가 어려워질 수 있는데, 평가의 일관성은 어떻게 확보하나요?지원자에게 맞춘 검증과 지원자 사이의 비교 가능성이 부딪히는 지점을 아는지 본다.
   2. 구체화힌트를 줬을 때만 답하는지까지 평가에 기록했다고 하셨는데, 힌트를 주는 시점과 방식은 어떻게 정해 두셨나요?평가 기준으로 적은 서술이 실제 진행 규칙으로 이어지는지 본다.
   3. 결과 검증질문지로 한 평가가 합류한 뒤의 모습과 맞았는지는 어떻게 확인하나요? US면접에서 본 평가를 입사 후에 돌아보고 검증하는 습관이 있는지 본다.

렌더링과 성능

1. 소개 페이지의 정적·동적 렌더링을 나눠 첫 진입 속도를 확보하셨다고 했는데, 두 방식은 화면이 사용자에게 도착하는 과정에서 각각 어떻게 다른가요?KR·US

   렌더링 방식을 용어 정의가 아니라 요청에서 화면 표시까지의 흐름으로 설명할 수 있는지 본다.

   1. 구현 깊이서버에서 만든 화면과 브라우저가 처음 그린 화면이 서로 다르면 어떤 일이 생기나요? KR서버 렌더링 결과를 브라우저가 이어받는 과정을 알고, 그 불일치가 만드는 문제를 짚을 수 있는지 본다.
   2. 조건 변경내용이 가끔만 바뀌는 페이지가 크게 늘어난다면 전부 미리 만들어 두는 방식은 어디서부터 부담이 되나요? US미리 만드는 방식의 비용이 페이지 수에 따라 어떻게 커지는지와 그 대안을 아는지 본다.
2. DOM 변화, 콘솔 에러, 네트워크 요청과 함께 Web Vitals를 하나의 타임라인으로 모으셨는데, Web Vitals 값이 나쁘다고 판단하는 기준은 무엇으로 삼으시겠어요?US

   수집한 성능 값을 좋고 나쁨으로 가르는 기준을 외운 임계값이 아니라 근거를 갖고 세울 수 있는지 본다.

   1. 판단 근거기준에 못 미치는 페이지가 나왔을 때 초기 로드를 줄이려고 코드 스플리팅이나 비핵심 리소스 지연 같은 방법 중 무엇부터 보시겠어요? US나쁜 값의 원인을 좁혀 가는 순서를 초기 로드 최적화 방법과 연결해 말할 수 있는지 본다.
   2. 트레이드오프그 기준을 성능 예산으로 삼아 넘는 변경을 배포 전에 막는다면, 기능 일정과 부딪힐 때 예외는 어떤 기준으로 허용하시겠어요? US성능 기준을 세우는 데서 그치지 않고 기능 일정과 부딪힐 때 어떻게 운영할지 생각해 두었는지 본다.
3. 분해 단계를 병렬화해 소요를 줄이셨는데, 병렬화 말고 검토해 본 다른 개선 방법이 있다면 무엇인가요?KR·US 채용 공고가 요구하는 역량을 질문으로 바꾼 것. 개선 방법을 하나로 정하기 전에 견줘 보는지 본다.
4. 브라우저 주소창에 주소를 입력하고 Enter를 누르면 화면이 표시되기까지 어떤 일이 벌어지나요?KR 네트워크 요청부터 화면 렌더링까지 웹의 기본 흐름을 끊김 없이 이해하고 있는지 본다.
5. debounce와 throttle은 어떤 기준으로 나눠 쓰시나요?US 두 기법의 차이를 정의로 외우지 않고 이벤트가 몰리는 실제 상황에 맞춰 고를 수 있는지 본다.

상태와 데이터

1. 수천 행을 일정 크기로 쪼개 동시 2건까지만 보내도록 제한하셨는데, 먼저 나간 요청의 응답이 나중에 도착해 순서가 뒤바뀌더라도 화면의 결과가 어긋나지 않게 하려면 어떻게 하시겠어요?KR 동시에 나간 비동기 요청의 응답 순서가 보장되지 않는다는 점을 화면 결과가 어긋나지 않게 다루는 방법으로 설명할 수 있는지 본다.
2. 서버에서 받은 데이터를 페이지 단위로 미리 가져오는 방식과 컴포넌트가 필요할 때 가져오는 방식은 어떤 기준으로 나눠 쓰시나요?US 데이터를 가져오는 위치가 화면 로딩 순서와 중복 요청에 주는 영향을 기준으로 삼는지 본다.
3. 낙관적으로 화면에 먼저 반영한 변경이 서버에서 거절되거나 다른 사용자의 변경과 충돌하면 화면 상태는 어떻게 바로잡으시겠어요?US 화면을 먼저 바꿔 얻는 반응성과, 서버 결과가 달랐을 때 되돌리는 책임을 함께 설계할 수 있는지 본다.
4. BFF의 책임 범위를 API 조합·데이터 변환·에러 처리·입력 검증으로 정하셨는데, 특정 화면에만 필요한 응답 가공은 어디까지 BFF가 맡는 것이 맞다고 보시나요?US

   화면 사정을 따라 BFF의 책임이 넓어지려는 압력에서도 지킬 선을 근거를 갖고 말할 수 있는지 본다.

   1. 조건 변경화면이 늘어날 때마다 화면 전용 응답 가공을 BFF에 하나씩 더해 간다면 시간이 지난 뒤 BFF를 유지하는 데 어떤 비용이 생기나요? US화면 전용 가공이 쌓일 때 BFF가 떠안는 유지 비용을 내다보고, 그 비용으로 책임의 경계를 지킬 이유를 세우는지 본다.
   2. 실패와 장애화면에서 보낸 입력이 BFF의 검증은 통과했는데 Backend가 거절한다면 그 에러는 화면까지 어떤 형태로 전달하시겠어요?검증과 에러 처리가 나뉜 경계에서 사용자가 받는 오류의 모양까지 설계하는지 본다.
5. Circuit Breaker 적용 조건 4개를 근거와 함께 정의하셨는데, 여러 Internal API를 조합하는 화면에서 일부만 실패하면 화면 전체를 실패로 볼지 일부만 보여 줄지는 무엇을 기준으로 정해야 한다고 보시나요?US

   하류 API 하나의 실패를 화면 단위의 결정으로 옮겨 사용자에게 무엇을 보여 줄지 정하는 기준이 있는지 본다.

   1. 실패와 장애실패한 요청을 다시 시도하면서 대기 시간을 점점 늘리는 방식은 어떤 상황에서 오히려 문제가 되나요? US재시도가 이미 어려운 서버에 부담을 더하는 경우를 알고 재시도 정책을 설계할 수 있는지 본다.
   2. 구현 깊이에러 바운더리는 어떤 종류의 에러까지 잡을 수 있나요? US부분 실패를 화면에서 다룰 때 쓰는 도구의 적용 범위를 정확히 아는지 본다.
   3. 조건 변경네트워크가 끊긴 상태에서도 화면을 어느 정도 보여 줘야 한다면 무엇을 더 준비하시겠어요? US서버 실패에서 연결 자체가 끊기는 상황까지 실패 시나리오를 넓혀 생각하는지 본다.
6. 이슈 발행용 인증 토큰을 서버 세션에만 두어 브라우저로 내려가지 않게 하셨는데, 세션을 이어 가려면 브라우저에는 어떤 저장소에 무엇을 두어야 한다고 보시나요?KR 토큰을 서버에 둔다는 결정을 로컬 스토리지, 세션 스토리지, 쿠키의 차이와 연결해 설명할 수 있는지 본다.
7. REST API에서 HTTP 메서드를 나눠 쓰는 기준은 무엇인가요?KR GET, POST, PUT, PATCH의 의미와 멱등성 같은 기본 성질을 실제 API 설계 판단에 쓸 수 있는지 본다.

언어와 브라우저 기본기

1. 호이스팅은 실행 컨텍스트와 스코프로 어떻게 설명할 수 있나요?KR

   호이스팅을 현상으로 외우지 않고 실행 컨텍스트가 만들어지는 과정으로 설명할 수 있는지 본다.

   1. 구현 깊이var, let, const는 호이스팅과 스코프에서 각각 어떻게 다르게 동작하나요? KR선언 방식별 차이를 호이스팅과 스코프 규칙에 연결해 정확히 설명할 수 있는지 본다.
   2. 실패와 장애호이스팅 때문에 의도와 다르게 동작하는 코드를 하나 들어 주시겠어요?호이스팅을 개념으로만 아는지, 코드에서 문제가 되는 형태로 알아보는지 본다.
2. 자바스크립트가 비동기 코드를 실행하는 순서를 이벤트 루프로 설명해 주시겠어요?KR

   이벤트 루프를 용어 나열이 아니라 비동기 코드가 실제로 실행되는 순서로 설명할 수 있는지 본다.

   1. 구체화싱글 스레드인데 비동기 처리가 가능한 이유는 무엇인가요? KR실행 스레드가 하나라는 사실과 비동기 처리가 함께 성립하는 이유를 연결해 설명하는지 본다.
   2. 구현 깊이마이크로태스크 큐와 태스크 큐는 처리 순서가 어떻게 다른가요? KR같은 비동기 코드라도 큐의 종류에 따라 실행 시점이 달라지는 규칙을 아는지 본다.
   3. 실패와 장애오래 걸리는 동기 계산이 콜 스택을 차지하고 있으면 화면에는 어떤 일이 생기나요?이벤트 루프의 동작을 화면이 멈추는 실제 현상과 연결해 설명하는지 본다.
3. 클로저는 무엇이고 어떤 상황에서 유용하게 쓰이나요?KR

   클로저를 정의로 외우지 않고 함수가 만들어진 범위의 값을 계속 쓰는 실제 용도로 설명할 수 있는지 본다.

   1. 구체화클로저는 React 컴포넌트와 이벤트 핸들러의 동작에 어떤 영향을 주나요? US클로저를 언어 개념에 그치지 않고 컴포넌트 코드에서 값이 고정되는 현상과 연결해 아는지 본다.
   2. 실패와 장애클로저가 오래된 값을 참조하고 있어 예상과 다르게 동작한 사례를 하나 들어 주시겠어요?클로저에서 생기는 실제 버그를 알아보고 원인을 짚을 수 있는지 본다.
4. CORS는 무엇이며, 에러가 났을 때 어떻게 대처하시나요?KR

   CORS를 브라우저의 보안 정책으로 이해하고, 서버 설정으로 풀 문제와 우회 방법을 구분해 대처하는지 본다.

   1. 구현 깊이CORS가 전제로 삼는 동일 출처 정책은 무엇이고 왜 필요한가요? KRCORS 에러를 설정 문제로만 보지 않고 브라우저가 막으려는 위험에서부터 이해하는지 본다.
   2. 트레이드오프JSONP 같은 예전 우회 방법에는 어떤 한계가 있나요? KR우회 방법이 어떤 안전성이나 기능을 포기하는지 알고 있는지 본다.
   3. 실패와 장애서버 설정은 맞는 것 같은데 브라우저에서만 CORS 에러가 난다면 원인을 어떻게 좁혀 가시겠어요? KR에러 메시지와 응답 헤더를 근거로 원인 후보를 좁혀 가는 순서가 있는지 본다.
5. 이벤트 버블링과 캡처링은 무엇이고, 이벤트를 다룰 때 어떻게 활용하시나요?KR 이벤트가 전달되는 경로를 이해하고 이벤트 위임처럼 실제 코드 구조에 활용하는지 본다.
6. 레이아웃을 잡을 때 flex와 박스 모델, position은 각각 어떤 역할을 하나요?KR CSS 속성을 이름으로 외우지 않고 각 속성이 요소 배치에 미치는 영향으로 설명할 수 있는지 본다.

React와 타입스크립트

1. Virtual DOM은 무엇이고 화면을 갱신할 때 어떻게 동작하나요?KR Virtual DOM을 성능이 좋아진다는 문구로 외우지 않고 변경을 비교하고 반영하는 과정으로 설명할 수 있는지 본다.
2. React를 Vue나 Angular와 견주어 선택할 때 어떤 기준으로 판단하시나요?KR 프레임워크 선택을 유행이나 익숙함이 아니라 제품과 팀의 조건에 맞춘 기준으로 설명할 수 있는지 본다.
3. useEffect, useMemo, useCallback 같은 훅은 각각 어떤 문제를 풀려고 쓰나요?KR 훅을 이름과 문법으로 아는 데서 그치지 않고 각각이 해결하는 문제로 구분해 설명할 수 있는지 본다.
4. any를 금지하고 단언 대신 타입 가드를 팀 규칙으로 두셨는데, 타입 가드 함수가 실제 값과 어긋나게 작성되어 있다면 그 문제는 어떻게 막으시겠어요?KR 타입 가드가 컴파일러에게 하는 약속을 런타임 값으로 확인해 주지는 않는다는 한계를 알고 대비책을 갖고 있는지 본다.

설계와 품질

1. NestJS 계열은 DI·데코레이터·모듈 시스템이 DB와 트랜잭션을 가진 서버를 전제한 설계라 BFF에는 과하다고 보셨는데, 나중에 BFF가 DB나 트랜잭션을 다루게 된다면 그 판단은 어떻게 달라지나요?KR·US

   BFF에 DB와 트랜잭션이 없다는 전제 위에서 내린 기술 선택이 그 전제가 바뀔 때도 유지되는지 본다.

   1. 판단 근거기술을 고를 때 외부 지표와 프로젝트 조건 중 무엇을 더 무겁게 보시나요? KR기술 선택의 근거를 외부 지표와 프로젝트 조건 가운데 어디에 두는지 본다.
   2. 조건 변경팀이 이미 NestJS에 익숙한 상태였다면 이 선택은 어떻게 달라지나요?기술 자체의 적합성과 팀의 학습 비용을 나누어 판단하는지 본다.
2. JSDoc·Redux에서 TypeScript·React Query로 마이그레이션을 주도하며 혼자 바꾸면 되돌아간다고 보셨는데, 지금 돌아보면 그 마이그레이션에서 개선하고 싶은 점은 무엇인가요?KR

   지나간 마이그레이션을 성공담으로 끝내지 않고 남은 아쉬움과 개선점을 스스로 짚을 수 있는지 본다.

   1. 판단 근거레거시 코드를 전부 새 방식으로 바꾸지 않고 남겨 두기로 할 때는 무엇을 기준으로 삼으시나요? KR옛 코드를 바꿀 범위를 근거를 갖고 정하는지 본다.
   2. 결과 검증새 방식이 자리 잡아 팀이 옛 방식으로 되돌아가지 않는다는 것은 무엇으로 확인하시겠어요?마이그레이션의 성공을 코드가 바뀐 것이 아니라 팀이 새 방식을 계속 쓰는지로 확인하는지 본다.
3. Service Layer를 Anti-Corruption Layer로 재정의하셨는데, 그 패턴을 프론트엔드 계층에 옮길 때 원래 개념과 달라지는 점은 무엇이라고 보시나요?KR 이름을 빌려 온 설계 패턴을 원래 개념과 견주어 어디까지 같고 어디서 달라지는지 정확히 알고 쓰는지 본다.
4. Figma Variables를 Tailwind 테마와 Ant Design 테마로 동시 변환하는 플러그인을 만드셨는데, Figma Variables의 모드가 늘어날 때 두 테마 사이의 어긋남은 어떻게 막을 수 있나요?US 디자인 토큰 하나에서 여러 테마를 파생시킬 때 값이 늘어나도 테마 사이의 정합을 유지할 방법이 있는지 본다.
5. 다른 사람의 화면을 통째로 기록하는 도구라서 허용한 헤더만 통과시키셨는데, 새로 필요해진 헤더를 허용 목록에 넣을지는 어떤 기준으로 정하시겠어요?US 민감한 값이 실릴 수 있는 도구에서 허용 범위를 넓힐 때 보안과 쓸모 사이에서 정하는 기준이 있는지 본다.
6. Bugzar에서 PR마다 프로덕션과 분리된 프리뷰 환경으로 배포되도록 CI를 구성하셨는데, 테스트가 실패한 PR도 프리뷰 배포를 허용할지는 무엇을 기준으로 정하시겠어요?KR 테스트 자동화를 테스트 코드 작성에서 끝내지 않고 CI 단계에서 배포를 막을지 정하는 정책까지 설계하는지 본다.

제품 감각과 접근성

1. 표준 옵션 관리에서 옵션 순서를 숫자로 입력하는 시안 대신 Drag & Drop을 제안하셨는데, 그 방식이 운영자에게 실제로 더 낫다는 것은 무엇으로 확인할 수 있다고 보시나요?KR 사용성을 개선했다는 주장을 운영자가 실제로 편해졌는지 확인하는 방법으로 뒷받침할 수 있는지 본다.
2. iOS 웹뷰에서 바텀시트를 열면 배경이 스크롤되던 문제를 스크롤 위치 고정·복원 방식으로 해결하셨는데, 바텀시트가 열려 있는 동안 키보드 포커스가 시트 밖으로 나가지 않게 하려면 어떻게 하시겠어요?US 화면을 가리는 UI에서 스크롤뿐 아니라 키보드 포커스까지 함께 다루는 접근성 감각이 있는지 본다.
3. 클라이언트 라우팅으로 화면이 바뀔 때 키보드 사용자를 위해 포커스를 어떻게 관리하시나요?US 페이지 이동이 없는 SPA에서 사라지는 브라우저의 기본 포커스 동작을 직접 보완하는지 본다.
4. 버튼 같은 상호작용 요소에 시맨틱 HTML을 쓰는 이유는 무엇인가요?US 시맨틱 태그가 키보드 조작과 스크린 리더 지원을 기본으로 제공한다는 점을 이해하고 있는지 본다.
5. PRD에서 PR 초안까지 만드는 도구를 만들기로 하고 설계와 구현을 맡으셨는데, 도구를 만드는 대신 기존 절차를 개선하는 방법과 견준다면 어떤 기준으로 비교하시겠어요?KR·US 채용 공고가 요구하는 역량을 질문으로 바꾼 것. 만들기 전에 만들지 않는 선택지와 견주는지 본다.
6. 필드가 200여 개이고 어떤 섹션이 보이고 무엇이 필수인지가 판매할 플랫폼과 카테고리, 상품 유형에 따라 달라지는 상품 폼을 처음 받았다면, 섹션으로 나누기 전에 무엇부터 확인하시겠어요?KR·US 채용 공고가 요구하는 역량을 질문으로 바꾼 것. 크고 모호한 문제를 나누기 전에 확인할 것을 정하는지 본다.
7. 최근에 사용자나 고객과 직접 이야기한 경험과, 그 대화에서 나온 결정을 말씀해 주시겠어요?KR·US 제품을 만들 때 사용자의 말을 직접 듣고 결정에 반영하는 습관이 있는지 본다.

대규모 상품 폼

1. 필드가 200여 개인 상품 폼을 40여 개 섹션으로 나누고 섹션 레지스트리로 화면을 정하셨는데, 운영자가 섹션 구성과 조건부 규칙을 화면에서 직접 설정하는 폼 빌더로 넓힌다면 무엇을 새로 설계해야 하나요?US 섹션 스키마와 레지스트리로 짠 구조를 설정으로 다루는 폼 빌더로 넓힐 때 새로 생기는 설계 문제를 짚을 수 있는지 본다.

대량 일괄 처리

1. 수천 건 엑셀을 브라우저에서 파싱하고 1차 검증한 뒤 동시 2건까지만 나눠 보내도록 하셨는데, 그 수천 행의 검증 결과와 처리 진행 상태를 어드민 테이블로 보여 준다면 화면은 어떻게 설계하시겠어요?US 수천 행 규모의 결과를 한 화면에서 다루는 테이블의 렌더링과 상태 표시를 설계할 수 있는지 본다.

모노레포 레이어 구조

1. 모노레포를 Api → Service → Feature → App 4계층 단방향으로 나누셨는데, 마이크로 프론트엔드는 어떤 경우에 도입할 만하다고 보시나요?US 계층으로 나눈 모노레포 구조와 견주어 마이크로 프론트엔드를 도입할 만한 경우를 기준을 갖고 말할 수 있는지 본다.

리포트 · 기록 집계

1. 하나의 타임라인으로 기록한 리포트가 자기완결형 HTML 하나로 재생되게 하셨는데, 리포트 한 건을 보는 데서 나아가 배포 전후로 실제 사용자 전체의 오류와 성능 변화를 비교하는 체계를 설계한다면 리포트에서 무엇을 뽑아 어떻게 모으시겠어요?US 개별 세션을 재생해 보는 도구를 여러 사용자의 회귀 탐지로 넓힐 때 무엇을 집계할지 정하는 방식을 갖고 있는지 본다.

기타 설계

1. 뉴스피드처럼 게시물이 끝없이 이어지는 화면의 프론트엔드를 설계한다면 가장 먼저 무엇을 정하시겠어요?US

   설계에 들어가기 전에 요구 사항과 제약을 먼저 정리하는 습관이 있는지 본다.

   1. 선택 근거게시물을 이어서 불러오는 방식으로 페이지 번호와 커서 중 무엇을 고르시겠어요? US피드처럼 목록이 계속 바뀌는 화면에서 이어 불러오기 방식을 고르는 근거를 말할 수 있는지 본다.
   2. 조건 변경이미 지나간 게시물이 화면에 계속 쌓여 목록이 매우 길어지면 스크롤 성능은 어떻게 지키시겠어요? US긴 목록에서 화면에 실제로 그리는 항목을 줄이는 방법을 아는지 본다.
   3. 실패와 장애이어 불러오는 도중에 새 게시물이 끼어들면 같은 게시물이 목록에 두 번 나타나지 않게 하려면 어떻게 하시겠어요? US이어 불러오기와 새 게시물 갱신이 겹칠 때 항목이 중복되는 문제를 짚는지 본다.
2. 입력하는 대로 추천어를 보여 주는 자동완성 컴포넌트를 설계한다면 구성 요소와 데이터가 흐르는 길을 어떻게 나누시겠어요?US

   컴포넌트를 역할별로 나누고 데이터가 흐르는 길을 구조로 설명할 수 있는지 본다.

   1. 구현 깊이추천어 목록을 키보드만으로 오르내리며 고를 수 있게 하려면 어떤 동작과 접근성 속성이 필요한가요? US마우스 없이 추천어를 고르는 키 조작과 스크린 리더 지원을 구체적으로 아는지 본다.
   2. 트레이드오프입력을 멈춘 뒤에야 요청을 보내면 추천어가 그만큼 늦게 나타나는데, 기다리는 시간은 어떤 기준으로 정하시겠어요? US요청 수를 줄이는 이득과 추천어가 늦게 뜨는 불편을 견주어 기준을 세울 수 있는지 본다.
   3. 조건 변경응답이 느린 네트워크에서도 입력하는 순간 결과가 나오는 것처럼 느끼게 하려면 응답을 기다리는 동안 무엇을 보여 주시겠어요? US응답이 늦을 때 사용자가 느끼는 반응성을 화면 쪽에서 보완하는 방법을 아는지 본다.
3. 메신저 같은 채팅 애플리케이션의 프론트엔드를 설계한다면 새 메시지가 화면에 나타나기까지의 흐름을 어떻게 그리시겠어요?US

   실시간 연결로 받은 이벤트가 화면 상태로 이어지는 흐름을 처음부터 끝까지 이어서 설명할 수 있는지 본다.

   1. 구현 깊이대화방 목록과 메시지, 사용자 정보가 서로를 참조할 때 상태는 어떤 모양으로 저장하시겠어요? US같은 사용자나 메시지가 여러 곳에 나올 때 값을 한곳에서 고치도록 상태를 구조화하는 방법을 아는지 본다.
   2. 조건 변경같은 계정으로 브라우저 탭을 여러 개 열어 두었다면 한 탭에서 읽은 메시지는 다른 탭에 어떻게 반영하시겠어요? US탭마다 따로 도는 화면 상태를 같은 계정의 하나의 상태로 맞추는 방법을 아는지 본다.
   3. 실패와 장애연결이 잠시 끊겼다가 돌아오면 그사이에 도착한 메시지는 어떻게 화면에 채우시겠어요?실시간 이벤트를 놓쳤을 때 화면 상태를 다시 맞추는 방법을 미리 생각해 두었는지 본다.
4. AppleCare+ 같은 무형상품의 등록·판매 흐름을 별도로 다룰 수 있게 만드셨는데, 이커머스의 상품 카탈로그와 장바구니를 설계한다면 실물 상품과 다른 유형의 상품은 상품 모델과 화면에서 어디까지 분리하시겠어요?US

   상품 유형이 늘어날 때 하나의 상품 모델로 밀고 갈지 흐름을 나눌지를 기준을 갖고 판단하는지 본다.

   1. 구현 깊이카테고리와 속성으로 상품을 좁혀 가는 패싯 검색에서 사용자가 고른 필터 조건은 어디에 어떻게 보관하시겠어요? US필터 조건을 화면 상태로만 둘지 주소에도 남길지 따져 보관 위치를 정하는지 본다.
   2. 트레이드오프검색 엔진에 노출할 상품 페이지에 재고나 가격처럼 자주 바뀌는 값이 있다면 그 값은 언제 어디서 채우시겠어요? US검색 노출을 위해 미리 만든 화면과 자주 바뀌는 값 사이의 어긋남을 다루는 방법을 아는지 본다.
   3. 조건 변경장바구니에 담은 상품이 로그인 전후나 기기가 바뀌어도 유지되어야 한다면 어떤 저장소를 쓰시겠어요? US장바구니를 로그인 여부와 기기에 관계없이 유지하는 보관 방식을 아는지 본다.
5. Google Docs처럼 여러 사람이 한 문서를 동시에 편집하는 협업 편집기를 설계한다면 여러 사람의 편집이 하나의 문서로 이어지는 구조를 어떻게 잡으시겠어요?US

   동시에 들어오는 여러 사람의 입력을 하나의 문서 상태로 이어 가는 구조를 설명할 수 있는지 본다.

   1. 구현 깊이두 사람이 같은 문장을 동시에 고칠 때 두 변경을 어긋남 없이 합치는 방법에는 어떤 것들이 있나요? US동시 편집에서 생기는 충돌을 합치는 대표적인 방식과 그 차이를 아는지 본다.
   2. 조건 변경다른 참여자의 커서와 선택 영역까지 실시간으로 보여 준다면 참여자가 많아질수록 무엇이 먼저 문제가 되나요? US참여자 수가 늘 때 실시간 상태 공유의 부담이 어디서 먼저 드러나는지 예상할 수 있는지 본다.
6. 숙소를 찾아 예약을 마치기까지 이어지는 여행 예약 서비스의 프론트엔드를 설계한다면 화면과 데이터를 어떤 기준으로 나누시겠어요?US 검색에서 예약 완료까지 이어지는 긴 흐름을 화면과 데이터의 단위로 나누는 기준을 갖고 있는지 본다.
7. Netflix 같은 영상 스트리밍 서비스의 프론트엔드를 설계한다면 재생 제어와 화질 전환, 자막 동기화를 어떤 구조로 나누시겠어요?US 플레이어 안에서 서로 얽힌 재생 상태, 화질, 자막을 구조로 나누어 다룰 수 있는지 본다.
8. 여러 데이터 소스의 지표를 실시간으로 보여 주는 대시보드를 설계한다면 위젯 구성과 임계값 알림은 어떻게 다루시겠어요?US 서로 다른 소스에서 오는 실시간 데이터를 위젯 단위로 나누고 알림 기준까지 설계하는 방식을 갖고 있는지 본다.

이견과 갈등

1. 매니저나 테크 리드와 의견이 크게 갈렸던 경험을 말씀해 주시겠어요?US

   직급이 위인 사람에게도 근거를 갖고 반대 의견을 내고, 결론이 난 뒤의 관계와 결과까지 다루는지 본다.

   1. 판단 근거이견이 있는 자리에서 본인 입장을 뒷받침하려면 어떤 근거를 준비하시나요? US의견을 주장으로 끝내지 않고 데이터나 사례 같은 근거로 세우는 습관이 있는지 본다.
   2. 협업과 이견상대가 내세운 반론이 타당하다고 느껴졌다면 본인의 입장을 어떻게 조정하시겠어요? US반대 의견을 이겨야 할 대상으로만 보지 않고 입장을 고칠 근거로 받아들이는지 본다.
   3. 회고지금 돌아보면 그 이견에서 다르게 말하거나 행동했을 부분이 있다면 무엇인가요?이견이 정리된 뒤에도 자신의 대응을 점검하고 배우는지 본다.
2. 다른 사람들이 꺼리는 불편한 문제나 인기 없는 의견을 먼저 꺼낸 경험을 말씀해 주시겠어요?US 분위기를 거스르더라도 필요한 말을 하는 사람인지, 그 말을 상대가 받아들일 수 있는 방식으로 하는지 본다.
3. Service Layer 존치처럼 찬성·반대·중립 의견을 모두 기록해 합의하는 안건에서 결론이 본인 의견과 다르게 난다면, 그 결정을 어떻게 받아들이고 실행하시겠어요?US 합의에서 자기 의견이 채택되지 않았을 때 결정을 받아들이고 실행에 끝까지 참여하는지 본다.

피드백

1. 동료나 리더에게 받은 비판적인 피드백 중 가장 도움이 되었던 것은 무엇이었나요?US

   비판을 방어하지 않고 받아들여 일하는 방식을 고쳐 온 사람인지 본다.

   1. 구체화그 피드백을 받은 뒤 일하는 방식에서 달라진 점이 있다면 구체적으로 무엇인가요? US피드백을 들은 데서 그치지 않고 행동의 변화로 옮겼는지 세부로 확인한다.
   2. 협업과 이견비판적인 의견을 스스로 구하려면 주변 사람에게 어떤 방식으로 요청하시겠어요? US피드백을 기다리지 않고 먼저 구하는 습관이 있는지 본다.
   3. 판단 근거받은 피드백 중 일부만 받아들이고 나머지는 두기로 한다면 무엇을 기준으로 삼으시겠어요?모든 피드백을 그대로 따르지도 무시하지도 않고 걸러 낼 기준이 있는지 본다.
2. 동료가 듣고 싶어 하지 않을 피드백을 정직하게 전해야 했던 경험을 말씀해 주시겠어요?US 불편한 말을 피하지 않으면서 상대와의 관계가 상하지 않게 전하는 방식이 있는지 본다.

실패와 회고

1. 실수를 숨기지 않고 팀에 먼저 알렸던 경험을 말씀해 주시겠어요?US 실수를 드러내는 속도와 방식으로 팀의 신뢰를 지키는 사람인지 본다.
2. 본인의 실수가 사용자에게 영향을 줬던 경험과 그 직후의 대응을 말씀해 주시겠어요?US 문제를 발견한 직후 사용자 영향을 줄이는 일을 먼저 하고, 원인 파악과 재발 방지까지 이어 가는지 본다.

주도성과 성과

1. 지금까지 한 일 중 가장 자랑스러운 성과를 하나 꼽는다면 무엇이고, 왜 그 일을 꼽으시나요?KR·US

   무엇을 성과로 여기는지에서 지원자가 중시하는 가치와 성취의 기준을 본다.

   1. 결과 검증그 성과의 크기는 어떤 지표나 기준으로 설명하시겠어요? KR·US성과를 감상으로 말하지 않고 측정한 결과로 설명하는지 본다.
   2. 트레이드오프그 성과를 위해 미루거나 포기한 것이 있다면 무엇인가요?성과의 대가로 무엇을 감수했는지 스스로 알고 있는지 본다.
   3. 명료도그 성과를 다른 직군의 동료에게 두 문장으로 설명한다면 어떻게 말씀하시겠어요?성과를 듣는 사람의 눈높이에 맞춰 짧게 정리해 전달할 수 있는지 본다.
2. 담당 업무가 아니었지만 비효율을 발견하고 스스로 고친 경험을 말씀해 주시겠어요?KR·US 맡은 범위 밖의 문제도 자기 일로 여기고 누가 시키기 전에 움직이는지 본다.

모호함과 판단

1. 정보가 충분하지 않은 상태에서 기술적인 결정을 내려야 했던 경험을 말씀해 주시겠어요?US

   확실해질 때까지 기다릴 수 없을 때 판단하는 방식과 위험을 다루는 방식을 본다.

   1. 판단 근거정보가 부족한 상황에서 무엇을 확인하면 결정을 내려도 된다고 판단하시나요?부족한 정보 속에서도 결정에 꼭 필요한 최소한의 근거를 가려내는지 본다.
   2. 선택 근거당장 빨리 끝낼 수 있는 방법과 더 나은 방향이 갈릴 때 무엇을 기준으로 고르시나요? US단기 해법과 장기 방향 가운데 하나를 고르는 기준이 있는지 본다.
   3. 조건 변경결정을 내린 뒤 나온 정보가 결정의 전제를 뒤집는다면 어떻게 대응하시겠어요?불완전한 정보로 내린 결정을 고집하지 않고 방향을 바꿀 수 있는지 본다.
2. 요구사항이 분명하지 않거나 진행 중에 방향이 바뀌었던 프로젝트 경험을 말씀해 주시겠어요?US

   불분명하고 계속 바뀌는 상황에서 스스로 기준을 세워 일을 앞으로 이끄는지 본다.

   1. 구체화요구사항이 불분명한 일을 시작할 때 진행을 위해 어떤 구조나 기준을 먼저 세우시나요? US모호한 일에 스스로 틀을 세워 시작하는 방식이 있는지 본다.
   2. 결과 검증불분명한 상황에서 잡은 접근이 맞았다는 것은 어떤 근거로 확인하시겠어요? US모호한 상황에서 세운 접근이 옳았는지 데이터로 검증하는 습관이 있는지 본다.
   3. 조건 변경방향이 여러 번 바뀌어 일정이 흔들린다면 무엇을 지키고 무엇을 조정하시겠어요? US방향이 바뀔 때 지켜야 할 결과와 조정해도 되는 것을 가르는지 본다.
3. 실패할 수도 있다는 것을 알면서 위험을 감수하기로 했던 경험과 그 결과를 말씀해 주시겠어요?US 위험을 따져 본 뒤 감수하고 결과까지 책임지는지, 무모함과 구분되는지 본다.

우선순위와 거절

1. 우선순위가 높은 일이 한꺼번에 여러 개 들어오면 무엇을 먼저 할지 어떻게 정하시나요?KR·US

   급한 일과 중요한 일을 가르는 자기만의 기준이 있는지 본다.

   1. 협업과 이견일을 뒤로 미루기로 했다면 그 일을 요청한 사람에게 결정을 어떻게 전하시겠어요? KR·US정한 우선순위를 영향받는 사람이 납득하도록 전하는지 본다.
   2. 트레이드오프여러 일이 모두 중요해 보일 때 하나를 뒤로 미루는 대가는 어떻게 따지시나요? KR·US미루는 일의 비용을 알고도 선택하는지 본다.
   3. 조건 변경정한 우선순위가 갑자기 뒤집히면 진행하던 일은 어떻게 다루시겠어요?이미 들인 비용에 끌려가지 않고 우선순위를 다시 정하는지 본다.
2. 팀이나 상위 리더가 정한 마감 일정에 반대 의견을 냈던 경험을 말씀해 주시겠어요?US 무리한 일정을 그냥 받아들이지도 무작정 거부하지도 않고 근거를 갖고 조정하는지 본다.
3. 팀에는 손해지만 회사 전체에는 이로운 결정을 내렸던 경험을 말씀해 주시겠어요?US 팀의 이익보다 조직 전체의 이익을 먼저 보고 결정하는지 본다.

사용자와 고객

1. 사용자나 고객의 문제를 풀려고 요청받은 범위를 넘어 나선 경험을 말씀해 주시겠어요?US 주어진 요구를 처리하는 데서 멈추지 않고 사용자의 실제 문제까지 챙기는지 본다.
2. 고객의 요구와 회사가 이루려는 목표가 어긋날 때 무엇을 기준으로 균형을 맞추시나요?KR 고객 요구와 회사 목표 사이에서 어느 한쪽에 치우치지 않고 우선순위를 정하는 기준이 있는지 본다.

협업과 설득

1. 크로스팀 Testing Working Group을 발족하셨는데, 직접 관리하지 않는 다른 팀 동료가 함께하도록 만들려면 무엇이 가장 중요하다고 보시나요?US

   지시할 권한이 없는 상대에게 영향력을 만드는 원칙이 있는지 본다.

   1. 협업과 이견필요성에 공감하지 못하는 팀이 있다면 어떻게 설득하시겠어요? US이해관계가 다른 상대의 입장에서 출발해 공감을 얻는 방식이 있는지 본다.
   2. 조건 변경자율 참여로 모인 모임에서 시간이 지나 참여가 줄어든다면 무엇부터 바꾸시겠어요?모임을 시작하는 데서 그치지 않고 참여를 이어 가게 만드는 방법을 생각해 두었는지 본다.
2. 무신사 파트너와 29CM Connect 두 조직이 합쳐진 신설 팀에서 양쪽의 개발 표준이 서로 달랐는데, 배경이 다른 동료들이 모두 의견을 낼 수 있는 자리는 어떻게 만드시나요?US 다른 관점을 가진 사람을 배제하지 않고 모두가 의견을 낼 수 있는 자리를 만드는지 본다.
3. 팀 안에서 협업할 때 가장 잘 맞는 방식은 무엇이라고 보시나요?KR 본인에게 잘 맞는 협업 방식을 알고, 팀의 방식과 다를 때 어떻게 맞추는지 본다.
4. 동료나 팀장은 본인을 어떤 사람이라고 평가할 것 같으신가요?KR 스스로 보는 모습과 주변이 보는 모습이 얼마나 가까운지, 자기 인식이 정확한지 본다.
5. 혼자 끙끙대지 않고 일찍 도움을 요청했던 경험을 말씀해 주시겠어요?US 막혔을 때 혼자 붙들고 있지 않고 적절한 시점에 도움을 구하는 사람인지 본다.

멘토링과 팀 성장

1. 프로그래머스와 패스트캠퍼스에서 멘토로 활동하셨는데, 멘티의 성장에 도움이 되었다고 느낀 지도 경험을 하나 말씀해 주시겠어요?US 상대가 스스로 성장하도록 돕는 방식이 있는지, 지도한 결과를 어떻게 확인하는지 본다.

압박과 적응

1. 업무 스트레스나 압박감이 큰 시기에는 어떤 방식으로 컨디션과 성과를 관리하시나요?KR 압박이 큰 상황에서도 지속 가능하게 성과를 내는 자기만의 방식이 있는지 본다.
2. 일하는 환경이나 방식이 크게 바뀌었을 때는 어떻게 적응하시나요?KR 새로운 환경에 빠르게 자리 잡는 방식이 있는지, 어떤 환경에서 성과를 가장 잘 내는지 본다.

지원 동기와 회사 이해

1. 저희 회사가 일하는 방식과 가치관에 비추어 본인의 경험을 설명해 주시겠어요?KR

   지원하는 회사에 맞춰 다시 쓸 자리. 회사가 밝힌 일하는 방식과 이어지는 경험을 골라 답하는지 본다.

   1. 회고회사가 밝힌 일하는 방식 중 가장 공감되는 부분과 어색하게 느껴지는 부분은 각각 무엇인가요? US회사의 가치를 외운 문구로 답하지 않고 자기 기준과 견주어 솔직하게 말하는지 본다.
   2. 조건 변경회사가 중시하는 방식과 본인이 편한 방식이 부딪히는 상황이 생긴다면 어떻게 하시겠어요?회사의 방식과 본인의 방식 사이의 차이를 조정할 방법을 스스로 생각해 두었는지 본다.
2. 일하면서 가장 중요하게 생각하는 가치는 무엇이고, 그 가치는 저희 회사의 가치와 어떻게 이어지나요?KR 지원하는 회사에 맞춰 다시 쓸 자리. 본인의 핵심 가치를 알고 회사의 가치와 맞닿는 지점을 짚는지 본다.
3. 이전 팀에서 겪은 문화 중 가장 좋았던 점과 아쉬웠던 점은 각각 무엇인가요?KR 지원하는 회사에 맞춰 다시 쓸 자리. 어떤 조직문화를 선호하는지와 맞지 않을 수 있는 지점을 본다.
4. 어떤 상황에서 일에 가장 큰 동기를 얻으시나요?KR 지원하는 회사에 맞춰 다시 쓸 자리. 일에서 의욕을 만드는 것이 회사가 주는 환경과 맞는지 본다.
5. 저희 팀이 지원자님과 면접을 진행하기로 한 이유는 무엇이라고 생각하시나요?KR 지원하는 회사에 맞춰 다시 쓸 자리. 자신의 강점과 팀이 필요로 하는 것을 연결해 이해하고 있는지 본다.

1. 팀 구성과 제가 맡게 될 범위가 어떻게 되나요?
2. 프론트엔드 기술 결정은 누가, 어떤 방식으로 내리나요?
3. AI를 실제 개발 흐름 어디까지 쓰고 계신가요? 팀에서 자리 잡은 방식이 있나요? AI Native를 표방하는 회사라면 실제 운영 수준을 물어보는 게 자연스럽고, 관심도 드러난다.
4. AI가 만든 코드에 대한 리뷰나 품질 기준이 따로 있나요?
5. 코드 리뷰 문화는 어떤가요? 리뷰가 배포를 막나요?
6. 기술 부채를 다루는 시간이 일정에 포함되나요?
7. 지금 팀에서 가장 큰 기술적 과제는 무엇인가요?
8. 입사 후 3개월 동안 제가 무엇을 해내면 잘 적응했다고 보시겠어요?