{
  "schema_version": 1,
  "method": "실제 서비스의 답변 생성 API로 생성한 원문. 가상의 예시 자료를 사용했으며 음성 인식 시험은 포함하지 않습니다.",
  "fictional_materials": true,
  "edited": false,
  "examples": [
    {
      "id": "tech",
      "label": "프로젝트 · 기술",
      "document": {
        "name": "한정 수량 주문 프로젝트 · 설계와 검증 메모",
        "text": "[가상 지원자의 예시 자료 — 실제 고객의 경력이나 성과가 아닙니다.]\n프로젝트: 한정 수량 상품 주문 API. 역할: 백엔드 개발자. Spring Boot, MySQL, Redis 사용.\n담당: 재고 차감과 주문 생성 로직, 동시 요청 테스트를 직접 구현했다.\n문제: 재고를 먼저 읽고 나중에 차감하면, 두 요청이 재고 1개를 동시에 읽어 초과 판매할 수 있었다.\n선택: MySQL에서 UPDATE inventory SET stock = stock - 1 WHERE product_id = ? AND stock > 0을 실행하고 영향받은 행이 1개일 때만 주문을 생성했다. 재고 차감과 주문 생성은 같은 DB 트랜잭션에 묶었다. 주문 저장에 실패하면 재고 차감도 롤백된다.\n대안: Redis 분산 락도 검토했지만 락 만료·장애 처리와 DB 트랜잭션을 함께 관리해야 했다. 이 프로젝트는 재고와 주문이 한 DB에 있어 조건부 갱신을 선택했다. Redis는 상품 설명 조회 캐시에만 사용했다. 이 설계는 잠금을 없앤 것이 아니라 MySQL 내부의 행 잠금으로 동시 갱신을 직렬화한다. Redis와 성능을 비교 측정하거나 QPS 수치를 확인한 적은 없다.\n검증: 테스트 환경에서 재고 1개에 동시 요청 100개를 보내 주문 성공 1건, 나머지 품절 응답, 최종 재고 0을 확인했다. 주문 저장 실패를 강제로 발생시켜 재고가 복구되는 것도 검증했다. 운영 전체 트래픽이나 매출 성과를 측정한 것은 아니다.\n남은 과제: 같은 인기 상품으로 요청이 몰리면 DB 행 잠금 대기가 병목이 될 수 있다. 현재 규모에서 먼저 부하 테스트로 확인하고, 향후 필요하면 상품별 큐를 검토할 계획이다. 큐를 실제 도입한 경험은 없다."
      },
      "profile": {
        "company": "",
        "role": "백엔드 개발자",
        "seniority": "experienced",
        "interview": "technical",
        "language": "ko",
        "answer_seconds": 60
      },
      "settings": {
        "mode": "thoughtful",
        "model": "auto",
        "answer_seconds": 60,
        "answer_style": "balanced"
      },
      "turns": [
        {
          "question": "재고가 1개 남았는데 주문 요청 100개가 동시에 들어오면 어떻게 처리했나요?",
          "answer": "## 바로 말하기\n재고 1개에 100개 요청이 들어오면, **조건부 갱신**으로 초과 판매를 막고 실패한 요청에는 품절 응답을 주었습니다.\n\n## 이어서\n*   **WHERE stock > 0** 조건을 붙여 재고가 있을 때만 `UPDATE`를 실행하고, 영향받은 행이 1개일 때만 주문을 생성했습니다.\n*   재고 차감과 주문 생성을 **같은 트랜잭션**으로 묶어, 주문 저장 실패 시 재고가 자동으로 복구되도록 했습니다.\n*   Redis 락 대신 MySQL 내부 **행 잠금**을 활용해 동시 요청을 직렬화했으며, 이는 재고와 주문이 같은 DB에 있어 선택한 방식입니다.\n*   테스트에서 100개 동시 요청 시 **성공 1건**, 나머지 99건은 품절 처리되고 최종 재고가 0임을 확인했습니다.\n\n## 꼬리질문 대비\n인기 상품에 요청이 몰리면 DB 행 잠금 대기가 병목이 될 수 있으니, 부하 테스트로 확인 후 필요 시 상품별 큐 도입을 검토할 계획입니다.",
          "answer_sha256": "8b45b57adb64a1f2c88b224244ffa3123a71c1d273888c56b2bb2bdbcfc32faa",
          "transcript": "",
          "history": []
        },
        {
          "question": "그럼 직접 테스트로 확인한 범위는 어디까지인가요?",
          "answer": "## 바로 말하기\n테스트 환경에서 재고 1개에 동시 요청 100건을 보내 **성공 1건**과 **품절 99건**을 확인했고, 주문 저장 실패 시 **재고 복구**도 검증했습니다.\n\n## 이어서\n*   **동시성**: 100개 요청이 동시에 들어와도 최종 재고가 0이 되는지, 초과 판매가 없는지 확인했습니다.\n*   **롤백**: 주문 저장 단계에서 **예외를 강제로 발생**시켜 재고 차감이 자동 취소되는지 검증했습니다.\n*   **한계**: 운영 환경의 **실제 트래픽**이나 매출 성과는 측정하지 않았으며, 부하 테스트는 향후 과제로 남겼습니다.\n\n## 꼬리질문 대비\n운영 환경 부하 테스트 계획이 어떻게 되나요? → 인기 상품에 요청이 몰릴 때 DB 행 잠금 대기를 확인하기 위해 상품별 큐 도입 전 **부하 테스트**를 먼저 수행할 계획입니다.",
          "answer_sha256": "fa470e4a0c7ecbdf6b4328f50dc65ae91f783f1468ebbe003e4956681540c9f4",
          "transcript": "면접관: 재고가 1개 남았는데 주문 요청 100개가 동시에 들어오면 어떻게 처리했나요?\n지원자: ## 바로 말하기\n재고 1개에 100개 요청이 들어오면, **조건부 갱신**으로 초과 판매를 막고 실패한 요청에는 품절 응답을 주었습니다.\n\n## 이어서\n*   **WHERE stock > 0** 조건을 붙여 재고가 있을 때만 `UPDATE`를 실행하고, 영향받은 행이 1개일 때만 주문을 생성했습니다.\n*   재고 차감과 주문 생성을 **같은 트랜잭션**으로 묶어, 주문 저장 실패 시 재고가 자동으로 복구되도록 했습니다.\n*   Redis 락 대신 MySQL 내부 **행 잠금**을 활용해 동시 요청을 직렬화했으며, 이는 재고와 주문이 같은 DB에 있어 선택한 방식입니다.\n*   테스트에서 100개 동시 요청 시 **성공 1건**, 나머지 99건은 품절 처리되고 최종 재고가 0임을 확인했습니다.\n\n## 꼬리질문 대비\n인기 상품에 요청이 몰리면 DB 행 잠금 대기가 병목이 될 수 있으니, 부하 테스트로 확인 후 필요 시 상품별 큐 도입을 검토할 계획입니다.\n면접관: 그럼 직접 테스트로 확인한 범위는 어디까지인가요?",
          "history": [
            {
              "q": "재고가 1개 남았는데 주문 요청 100개가 동시에 들어오면 어떻게 처리했나요?",
              "a": "## 바로 말하기\n재고 1개에 100개 요청이 들어오면, **조건부 갱신**으로 초과 판매를 막고 실패한 요청에는 품절 응답을 주었습니다.\n\n## 이어서\n*   **WHERE stock > 0** 조건을 붙여 재고가 있을 때만 `UPDATE`를 실행하고, 영향받은 행이 1개일 때만 주문을 생성했습니다.\n*   재고 차감과 주문 생성을 **같은 트랜잭션**으로 묶어, 주문 저장 실패 시 재고가 자동으로 복구되도록 했습니다.\n*   Redis 락 대신 MySQL 내부 **행 잠금**을 활용해 동시 요청을 직렬화했으며, 이는 재고와 주문이 같은 DB에 있어 선택한 방식입니다.\n*   테스트에서 100개 동시 요청 시 **성공 1건**, 나머지 99건은 품절 처리되고 최종 재고가 0임을 확인했습니다.\n\n## 꼬리질문 대비\n인기 상품에 요청이 몰리면 DB 행 잠금 대기가 병목이 될 수 있으니, 부하 테스트로 확인 후 필요 시 상품별 큐 도입을 검토할 계획입니다."
            }
          ]
        }
      ],
      "generated_at": "2026-10-27T03:04:06.581862+00:00"
    },
    {
      "id": "behavior",
      "label": "경험 · 협업",
      "document": {
        "name": "첫 구매 화면 개선 · 협업 회고",
        "text": "[가상 지원자의 예시 자료 — 실제 고객의 경력이나 성과가 아닙니다.]\n프로젝트: 작은 커머스 앱의 첫 구매 화면 개편. 역할: 프로덕트 디자이너.\n상황: 출시 2주 전 개발자는 일정을 위해 기존 입력 화면을 유지하자고 했고, 나는 사용자가 배송지 입력에서 자주 멈추는 문제를 고치고 싶었다. 개발자는 전면 개편의 개발·검증 범위가 불확실한 점을 우려했다.\n내 행동: 사용성 테스트 녹화 5건에서 사용자가 막힌 지점을 정리해 개발자와 함께 봤다. 기존 화면 유지와 전면 개편 외에, 이번에는 필수 입력과 선택 입력만 분리하고 오류 문구를 해당 입력칸 아래로 옮기자는 작은 수정안을 제안했다. 나머지 화면 개편은 다음 배포로 분리했다. 나는 수정 시안과 입력 오류 상태별 화면을 만들고, 개발자와 이번 배포 범위를 문서로 합의했다.\n결과: 팀은 합의한 작은 수정 범위로 예정일에 배포했다. 후속 사용성 테스트 5명 중 4명이 도움 없이 배송지 입력을 끝냈다. 표본이 작고 이전 테스트와 참가자가 달라 전환율 상승이나 인과관계로 해석하지 않았다.\n후속 계획: 나머지 화면 개편은 아직 진행하지 않았다. 다음 배포 일정이나 추가 성과는 정해지지 않았고, 이번 테스트에서 남은 입력 문제를 먼저 검토할 예정이다.\n배운 점: 상대를 설득할 때 내 안의 장점만 주장하기보다 상대가 걱정하는 일정과 검증 부담을 함께 줄이는 선택지를 만드는 것이 중요했다."
      },
      "profile": {
        "company": "",
        "role": "프로덕트 디자이너",
        "seniority": "experienced",
        "interview": "behavioral",
        "language": "ko",
        "answer_seconds": 60
      },
      "settings": {
        "mode": "thoughtful",
        "model": "auto",
        "answer_seconds": 60,
        "answer_style": "balanced"
      },
      "turns": [
        {
          "question": "일정 때문에 개선에 반대하는 개발자와 어떻게 합의했나요?",
          "answer": "## 바로 말하기\n개발자의 일정 우려를 존중하면서도, 사용성 테스트 데이터를 바탕으로 \"이번 배포는 최소한으로, 나머지는 다음으로\"라는 타협안을 제안해 합의했습니다.\n\n## 이어서\n* **데이터 공유**: 사용성 테스트 녹화 5건에서 사용자가 막히는 지점을 개발자와 함께 확인하며 문제의 심각성을 공감했습니다.\n* **범위 축소**: 전면 개편 대신 '필수 입력 분리'와 '오류 문구 위치 변경'만 이번 배포에 포함하는 작은 수정안을 만들었습니다.\n* **문서화 합의**: 남은 화면 개편은 다음 배포로 분리하고, 이번 배포의 정확한 개발 범위를 문서로 정리해 불확실성을 제거했습니다.\n* **결과**: 합의된 작은 범위로 예정일에 배포했고, 후속 테스트에서 5명 중 4명이 도움 없이 입력을 완료했습니다.\n\n## 꼬리질문 대비\nQ: 만약 개발자가 그 작은 수정조차 일정에 맞지 않는다고 했다면?\nA: 필수 완료 범위와 추가 인력 또는 검수 비용을 비교하며, 책임자와 함께 어떤 부분을 다음으로 미루는 것이 영향이 가장 작은지 우선순위를 재조정했을 것입니다.",
          "answer_sha256": "c715caf234687a97e25db2954e3333ac66bc2ce1eb3f2d6347f16877e6c12e69",
          "transcript": "",
          "history": []
        }
      ],
      "generated_at": "2026-10-27T03:04:06.581862+00:00"
    },
    {
      "id": "english",
      "label": "영어 면접",
      "document": {
        "name": "한정 수량 주문 프로젝트 · 설계와 검증 메모",
        "text": "[가상 지원자의 예시 자료 — 실제 고객의 경력이나 성과가 아닙니다.]\n프로젝트: 한정 수량 상품 주문 API. 역할: 백엔드 개발자. Spring Boot, MySQL, Redis 사용.\n담당: 재고 차감과 주문 생성 로직, 동시 요청 테스트를 직접 구현했다.\n문제: 재고를 먼저 읽고 나중에 차감하면, 두 요청이 재고 1개를 동시에 읽어 초과 판매할 수 있었다.\n선택: MySQL에서 UPDATE inventory SET stock = stock - 1 WHERE product_id = ? AND stock > 0을 실행하고 영향받은 행이 1개일 때만 주문을 생성했다. 재고 차감과 주문 생성은 같은 DB 트랜잭션에 묶었다. 주문 저장에 실패하면 재고 차감도 롤백된다.\n대안: Redis 분산 락도 검토했지만 락 만료·장애 처리와 DB 트랜잭션을 함께 관리해야 했다. 이 프로젝트는 재고와 주문이 한 DB에 있어 조건부 갱신을 선택했다. Redis는 상품 설명 조회 캐시에만 사용했다. 이 설계는 잠금을 없앤 것이 아니라 MySQL 내부의 행 잠금으로 동시 갱신을 직렬화한다. Redis와 성능을 비교 측정하거나 QPS 수치를 확인한 적은 없다.\n검증: 테스트 환경에서 재고 1개에 동시 요청 100개를 보내 주문 성공 1건, 나머지 품절 응답, 최종 재고 0을 확인했다. 주문 저장 실패를 강제로 발생시켜 재고가 복구되는 것도 검증했다. 운영 전체 트래픽이나 매출 성과를 측정한 것은 아니다.\n남은 과제: 같은 인기 상품으로 요청이 몰리면 DB 행 잠금 대기가 병목이 될 수 있다. 현재 규모에서 먼저 부하 테스트로 확인하고, 향후 필요하면 상품별 큐를 검토할 계획이다. 큐를 실제 도입한 경험은 없다."
      },
      "profile": {
        "company": "",
        "role": "Backend engineer",
        "seniority": "experienced",
        "interview": "english",
        "language": "en",
        "answer_seconds": 60
      },
      "settings": {
        "mode": "thoughtful",
        "model": "auto",
        "answer_seconds": 60,
        "answer_style": "balanced"
      },
      "turns": [
        {
          "question": "How did you make sure the last item could not be sold twice?",
          "answer": "## 질문 뜻\n마지막 남은 재고가 두 번 팔리는 것을 어떻게 막았는지 묻고 있습니다.\n\n## Say this\nI prevented overselling by using an atomic database update instead of a read-then-write approach.\nSpecifically, I executed a SQL query that decremented the stock only if the current stock was greater than zero.\nThis ensured that if two users tried to buy the last item simultaneously, the database would handle the race condition.\nThe first request would succeed, while the second would fail because the stock was already zero.\nI verified this logic by running concurrent load tests to confirm no negative stock values occurred.\n\n## 표현\n*   **Atomic update**: 원자적 업데이트 (동시에 여러 작업이 일어나도 중간에 끊기지 않고 한 번에 처리되는 작업)\n*   **Race condition**: 레이스 컨디션 (동시 요청으로 인해 데이터가 엉키는 상황)",
          "answer_sha256": "a3731c6153f92d71a20dcb346b1facf8a1e904f8242e1ca08aa58c3ef51e97c8",
          "transcript": "",
          "history": []
        }
      ],
      "generated_at": "2026-10-27T03:02:44.336308+00:00"
    }
  ]
}