지능형 컨텍스트 주입 관련 실습 질문

안녕하세요 수남님!공식 레퍼런스를 확인해보니process.exit(0) → Hook 메시지를 Claude에게 전달하되, 작업은 허용process.exit(2) → Hook 메시지를 Claude에게 전달하고, 작업을 차단라고 합니다. 해당 변경사항은 Claude Opus 4.6 (v2.1.32) 이후에 반영이 되었다고 합니다. 덕분에 말씀해주신 내용을 교재에 업데이트해두겠습니다!! 제보해주셔서 넘넘 감사합니다 ㅎㅎ

Supabse 연동이 되지 않습니다.

안녕하세요 kafka 님! 현재 연동은 성공하신 것 같습니다!다만 public 스키마에는 아직 테이블이 생성이 안되어있을 수 있습니다 따라서 ex) 사람들의 방명록을 남기는 테이블을 supabase 에 생성시키고 연동해줘 라는 식으로 테이블 생성 명령을 내려보신 후 공유해주실 수 있을까요? (사진),

화면이 안 나옵니다. 소리만 나와요

안녕하세요 Ryan 님!이 부분은 인프런 측에 문의해주셔야 할 것 같습니다. 저의 경우에는 화면 녹화를 키는 경우에는 인프런 강의 영상이 나오지 않던데, 한번 점검해보셔도 좋을 것 같습니다 감사합니다

수강평 작성 후 자료

안녕하세요 pawder 님!강의 맨 마지막에 참여하는 방법에 대해 적혀있어서, 그 방법을 통해서 수강평 인증 진행해주시면 발급 도와드리겠습니다 감사합니다

딩코님 유튜브 보다가 처음 결제했어요 포항공대 출신이라 믿고 결제했어요

감사합니다 형님!! 편하게 언제든 질문주십셔 ㅎㅎ 열심히 하겠습니다!!

10:1초에 드리블에서 이미지 복사해서 쓰시는데 그러면 저작권에 걸리지 않나요????

먼저 말씀해주신 부분, 전적으로 공감하고 불편하셨을 부분에 대해 진심으로 죄송합니다. 충분히 문제 제기하실 수 있는 부분입니다. 지적해주셔서 오히려 감사합니다.해당 영상 부분은 확인 후 라이선스가 명확한 무료 리소스로 교체하는 방향으로 빠르게 수정하겠습니다. 그리고 디자인 레퍼런스를 활용할 때 저작권에 대한 주의사항도 강의 내에 추가로 안내하겠습니다.디자이너 관점에서 날카롭게 짚어주신 덕분에 강의 품질을 높일 수 있을 것 같습니다. 다시 한번 불편 드린 점 죄송하고, 빠르게 반영하겠습니다 감사합니다.

네임드 락 사용 시 커넥션 풀을 분리하는 방법에 대한 질문

cho766님 좋은 질문 해주셔서 감사합니다!!면접에서 나온 키워드까지 연결지어서 질문해주신 부분이 정말 좋은 사고 흐름인 것 같습니다!!서킷 브레이커 / Bulkhead와 커넥션 풀 분리의 관계결론부터 말씀드리면, 서킷 브레이커와 Bulkhead는 커넥션 풀 분리와 직접적으로 같은 기술은 아니지만, 해결하려는 문제의 본질이 같습니다. "하나의 장애가 전체 시스템으로 전파되는 것을 막자"라는 격리(Isolation) 원칙입니다강의에서 다룬 네임드 락 커넥션 풀 분리는 이렇게 생각하시면 됩니다. Named Lock용 커넥션이 일반 비즈니스 트랜잭션 커넥션을 잡아먹지 않도록 풀 자체를 나눠서, Named Lock 쪽에서 지연이 생기더라도 일반 트랜잭션은 정상 동작하게 만드는 거죠. 이게 사실 Bulkhead 패턴의 핵심 아이디어와 동일합니다!Bulkhead는 선박의 격벽에서 유래한 개념인데, 배의 한 구획에 물이 들어와도 다른 구획은 안전하도록 벽으로 나누는 겁니다. (격벽 패턴, 격벽이라고도 불러용)면접에서 나온 "외부 API 호출 지연으로 스레드 풀이 고갈되는 상황"도 똑같은 맥락이에요. 외부 API 호출용 스레드 풀과 내부 처리용 스레드 풀을 분리해서, 외부 API가 느려져도 내부 서비스는 영향받지 않게 하는 겁니다.서킷 브레이커는 조금 다른 각도에서 접근합니다. 외부 시스템이 일정 횟수 이상 실패하면 아예 호출 자체를 차단(Open)해버리고, 일정 시간 후에 다시 시도(Half-Open)하는 방식이에요. 풀을 분리하는 게 아니라 "더 이상 요청을 보내지 않는다"는 전략입니다. 커넥션 풀 분리 / Bulkhead 패턴은 리소스를 격리해서 장애 전파를 차단하는 방식이고, 서킷 브레이커는 실패가 반복되면 요청 자체를 끊어서 시스템을 보호하는 방식입니다. 실무에서는 이 두 가지를 함께 사용하는 경우가 많아요. Resilience4j 라이브러리가 서킷 브레이커와 Bulkhead를 모두 지원하니 참고하시면 좋겠습니다. (https://resilience4j.readme.io/docs/getting-started)실무에서 커넥션 풀을 분리하는 방법실무에서 가장 많이 쓰이는 방법들을 키워드와 함께 알려드리겠습니다.첫 번째는 Spring Boot에서 DataSource를 여러 개 등록하는 방법입니다. HikariCP 기반으로 Named Lock 전용 DataSource와 비즈니스 로직 전용 DataSource를 각각 Bean으로 등록하고, @Qualifier를 통해 구분해서 주입하는 방식이에요. 강의에서 언급한 "Named Lock 전용 HikariCP 풀"이 바로 이 방법입니다. Spring Boot의 Multi DataSource 설정으로 검색하시면 구현 가이드를 찾으실 수 있습니다. (https://docs.spring.io/spring-boot/reference/data/sql.html)두 번째는 AbstractRoutingDataSource를 활용하는 방법입니다. 요청의 컨텍스트에 따라 동적으로 DataSource를 선택하는 방식인데, 읽기/쓰기를 분리하는 용도로도 많이 사용됩니다. 예를 들어 @Transactional(readOnly = true)일 때는 읽기 전용 DB로, 아닐 때는 쓰기 DB로 라우팅하는 식이죠. (요건 대부분의 서비스에서 적용하곤 합니다)세 번째는 JDBC를 직접 사용하는 방법입니다. Named Lock의 GET_LOCK/RELEASE_LOCK은 JPA의 트랜잭션 관리와 별개로 동작하는 게 오히려 자연스러운 경우가 있어서, Named Lock 전용으로는 별도의 DataSource에서 직접 JDBC Connection을 가져와서 사용하는 방식도 실무에서 쓰입니다. 이러면 JPA의 트랜잭션 관리와 완전히 분리되니까 커넥션 충돌 가능성이 사라집니다.면접에서 이 내용을 연결하는 방법면접에서 "외부 API 호출 지연으로 스레드 풀 고갈 시 어떻게 설계할 것인가"라는 질문을 받으셨다면, 이렇게 연결해서 대답할 수 있습니다."리소스 격리 차원에서 Bulkhead 패턴으로 스레드 풀이나 커넥션 풀을 분리하고, 실패 임계치를 넘기면 서킷 브레이커로 요청 자체를 차단합니다. 실제로 프로젝트에서 Named Lock과 비즈니스 트랜잭션의 커넥션 풀을 분리하면서 이 격리 원칙을 적용해본 경험이 있습니다." 이런 식으로 프로젝트 경험과 면접 질문을 자연스럽게 연결시킬 수 있으면 상당히 인상적인 답변이 됩니다.이런 격리 패턴에 대한 고민을 프로젝트에 직접 적용해보시고, 커넥션 풀 분리 전후의 성능 차이를 수치로 만들어서 이력서에 녹여보시면 좋겠습니다. 파이팅입ㄴ다!!!

26강 10:10 부근 자료 잘못된 건가요?

앗 맞습니다!! 왼쪽 노드부터 채워져야 하는데 애니메이션상 에러가 있었던 것 같습니다 제보해주셔서 감사드립니다!! 수정해두겠습니다 🙇

외부 api 처리 방안에 대하여 궁금한 점이 있습니다.

안녕하세요 곰고미님 좋은 질문 해주셔서 감사합니다!!!질문하신 부분이 실무에서도 정말 중요하게 다뤄지는 포인트인 것 같습니다! 날카로운 질문 감사합니다강의 예시와 좌석 지정 시나리오의 차이강의에서 다루는 예시는 "이벤트 참가" 시나리오입니다. 참가자가 등록되고, 외부 API에서 예약번호(externalId)를 받아오는 구조인데요, 이 경우에는 "참가 자체"가 우리 시스템에서 확정된 상태이고, externalId는 부가 정보에 해당합니다. 그래서 externalId가 잠시 누락되더라도 참가 자체는 유효하고, 나중에 보정해도 비즈니스적으로 큰 문제가 없는 거죠.반면에 질문해주신 것처럼 "A-1번 좌석"이라는 한정된 자원을 점유하는 시나리오에서는 성격이 완전히 다릅니다. 우리 쪽에서 예약 성공 처리를 했는데, 말씀해주신 것처럼 외부 시스템에서는 해당 좌석이 확보되지 않았다면 그 사이에 다른 요청이 같은 좌석을 잡아버릴 수 있고, 이러면 후보정으로도 복구가 불가능한 상태가 됩니다. 근데 만약 참가도 한정 자원이라면? 한정 자원 예약에서는 동기 처리가 맞는 경우가 많습니다말씀하신 대로, 좌석처럼 대체 불가능한 자원을 다루는 경우에는 외부 API 응답을 확인한 후에 예약을 확정하는 동기적 흐름이 더 안전합니다. 외부 API가 "좌석 점유 성공"을 응답으로 줘야만 우리 DB에 예약 완료를 기록하는 방식이죠.이 경우에는 트랜잭션 범위가 길어지는 단점이 있지만, 데이터 정합성이 깨졌을 때의 비용이 훨씬 크기 때문에 트레이드오프 상 동기 처리가 합리적입니다.그렇다면 후보정은 언제 쓰는 게 맞는가후보정이 적합한 경우와 동기 처리가 적합한 경우를 구분하는 기준은 "실패했을 때 나중에 복구할 수 있는가"입니다.후보정이 적합한 경우: 외부 API의 응답이 "부가 정보"일 때입니다. 강의 예시처럼 예약번호, 알림 발송, 쿠폰 발급 같은 것들입니다. 핵심 비즈니스 로직은 이미 완료되었고, 부가 정보만 나중에 채워넣으면 되는 상황에서 효과적입니다.동기 처리가 적합한 경우: 외부 API의 응답이 "핵심 자원의 확보 여부"를 결정할 때입니다. 좌석 점유, 결제 승인, 재고 차감 등 외부 시스템의 확인 없이는 우리 쪽에서 성공이라고 말할 수 없는 경우일 것 같습니다.실무에서의 하이브리드 접근실제 티켓팅 서비스들은 이 두 가지를 섞어서 사용하는 경우가 많습니다. 예를 들면 좌석 점유는 동기적으로 외부 API 호출해서 확보하고, 확보가 확인된 후에 우리 DB에 예약을 확정합니다. 그 이후에 알림 발송이나 예약 확인 메일 같은 부가 기능은 Spring Event 등을 통해 비동기로 처리하는 거죠.이렇게 하면 핵심 자원에 대한 정합성은 동기적으로 보장하면서, 부가 기능에 대해서는 결과적 일관성을 활용해서 트랜잭션 범위를 최소화할 수 있습니다.정리하면, 한정 자원에 대해서는 동기 처리로 확실하게 잡고, 부가 정보에 대해서는 후보정으로 유연하게 가는 것이 실무적으로 가장 균형 잡힌 접근이에요. 이런 판단 기준 자체를 이력서나 면접에서 "왜 이 방식을 선택했는가"로 설명할 수 있으면 상당히 강력한 어필 포인트가 될 것 같습니다!이런 트레이드오프를 고민하고 판단한 경험을 프로젝트에 직접 적용해서, 면접에서 설명할 수 있는 수치와 함께 이력서에 녹여보시면 좋겠습니다. 빠이팅입니다!!!

open in brower 세팅

안녕하세요 정원님!저는 테스트해보니 아직 open in browser 선택기능이 잘 나오는 것 같습니다혹시 열려고 하시는 파일의 확장명이 무엇일까요?스크린샷 통해서 공유해주시면 더 확인이 수월할 것 같습니다좋은 질문 감사합니다! (사진)