안녕하세요! 강의 열심히 들어주시고, 꼼꼼하게 링크까지 첨부해서 알려주셔서 정말 감사합니다. 말씀해주신 대로 네이버가 7월 31일부로 책 검색 API를 종료한 것이 맞습니다 (공식 대체 API도 없는 완전 종료로보이네요). 이에 대응해서 소스코드 저장소에 네이버 API와 동일한 스펙의 Mock 서버( mock-naver-api 모듈)를 추가 했습니다. 최신 코드를 받으신 후: 네이버 API 키 발급 부분은 건너뛰시고 (이제 키가 필요 없습니다) ./gradlew :mock-naver-api:bootRun 으로 Mock 서버를 먼저 띄운 다음 기존처럼 search-api를 실행하시면 이후 강의는 영상 그대로 따라 하실 수 있습니다. 요청/응답/에러 스펙을 네이버와 동일하게 만들어두어서 FeignClient, 응답객체, 에러 디코더, 서킷브레이커 챕터 모두 코드 변경 없이 동작합니다. 카카오 API는 정상 운영 중이므로 fallback 실습도 그대로입니다. 5번 챕터에 소스코드와 강의노트를 첨부해두었습니다 자세한 내용은 저장소의 MOCK-NAVER-API.md 에 정리해두었고, 전체 수강생 대상 공지도 함께 올렸습니다. 제보 다시 한번 감사드립니다. 진행하시다가 막히는 부분 있으면 언제든 질문 남겨주세요!
아이고 종혁님! 요 질문이 메일로 알람이 안와서 놓쳤네요 😭 늦어서 죄송합니다! 굉장히 좋은 포인트를 또 찾아주셨네요. 이질감을 느끼신게 정확한 감각입니다. 완벽한 격리는 없고, 어디서 타협할지를 결정하는것이 실무에서 항상 하는 고민포인트인것 같습니다. 다만 개인적으로는 항상 같은 원칙을 적용하지는 않고있습니다. 크기가 점점 커져서 조금 더 나눠야될 필요성이 있다면 인터페이스와 도메인 모델을 별도 모듈(:search-domain)으로 추출해서, search-api와 external 양쪽이 모두 그 모듈만 바라보게 하는 방법도 있습니다. 이런 결정은 프로젝트의 크기에 따라 달리 선택하고있는데요, 프로젝트 사이즈가 상대적으로 작다면 너무 잘게 쪼개게되면 그것또한 오버엔지니어링이 될 수 있기때문입니다. 질문주신 " 실무에서 search-api 와 external 간의 모듈 격리를 어떻게 하시며, 의존 방향을 어떻게 하시는지 궁금합니다." 이 내용에 대해서는 중간?정도 사이즈되는 프로젝트라면 강의에서 말씀드렸던 구조 그대로 사용합니다 ㅎㅎ 약간 주제에 벗어날수있는 얘기지만, 커리어 초반에는 꼭 무조건 이 원칙을 지켜야돼! 하면서 코드를 작성했었는데 시간이 지나면서 이런 사고들이 조금씩 바뀌었습니다. 나혼자 개발하는것이 아닌 팀원 전체가 동의하고 실수하지않고 최적의 효율을 내려면 구조를 어떻게 가져야할까? 정석적인 원칙보다는 우리 팀에 맞는, 우리 조직에 맞는 게 어떤걸까? 이런 효율측면에 조금씩 무게를 두게되네요. 제가 강의에서 말씀드린 이러한 구조도 특정 상황에서는 맞지 않을 수 있습니다. 정답은 없습니다. 종혁님께서 지금 이런저런 시도를 직접 해보시고 장/단점을 느껴보시는 연습이 추후에 종혁님께서 의사결정의 위치에 올라가시게될때 빛을 발하실거라고 확신합니다. 답변이 늦어 다시한번 죄송하고 해결되지 않은 궁금증이 있다면 언제나 편하게 남겨주세요!
안녕하세요 종혁님 ~ 먼저 구현하고 강의를 듣는 방법도 좋은데 잘 하고 계시네요 👍 넵 좋은 질문 해주셨네요! 말씀주신 이유도 맞습니다. 서로의 배포에 영향을 최대한 주지않기 위해서 분리한다로 봐주시면 될 것 같습니다. " 강사님은 어떤 기준으로 모듈과 패키지를 선택하시는지 질문 드립니다." -> 서로간의 의존성 오염방지 (쉬운예로 api서버에서는 필요없는 종류의 db드라이버 같은 경우) 모듈 단위의 빌드 및 배포 이렇게가 제일 큰 구분인거같네요~ 패키지로 나누면 좀 더 느슨한 격리가되고 (같은 모듈에서는 참조가되니) 모듈로 빼면 의존성을 명시를 안하면 강제격리가 되는점이 있기때문에 적절히 선택하면 되구요! 그리고 개인적으로 주의하는점은 처음부터 모듈로 너무 쪼개버리면 설정 오버헤드만 커지더라고요, 그래서 처음엔 패키지로 시작을 했다가 이 코드는 다른 서버에서도 써야겠다 혹은 이부분 빌드설정을 다르게 가져가야겠다 이런 판단이 들때 추출하는 방법도 좋습니다. (그리고 엄청많이 하다보면 이정도 사이즈면 모듈이다, 패키지다 그런 감?이 오시게될텐데 그때는 별 고민없이 선택하시게될거에요) 답변이 되었을까요? 해결되지 않은 부분이 있다면 다시 말씀주시구요 🙏
안녕하세요! spock사용하셔도 상관은 없지만 아무래도 kotlin사용하시면 kotest가 나을듯 싶습니다. kotlin문법을 그대로 활용하여 kotlin답게 사용하실수있으니까요. java -> kotlin 으로 전환단계에 있는 프로젝트가 아니라 처음부터 kotlin사용하신다면 spock보다는 kotest쪽으로 사용하시는걸 추천드려요 ☺ 그리고 같이 업무하시는 팀원이나 새롭게 들어오시는 분들도 kotlin + kotest조합을 더 선호하실 가능성이 높구요. 또한 팀원 전체가 익숙한 방향으로 논의를 추가로 해보셔도 좋구요 ㅎㅎ
안녕하세요 정주님~ 질문 남겨주셔서 감사합니다. 넵 말씀주신대로 강의에서 제가 AI도구도 언급을 했었죠! 저는 실무에서 주로 gpt(간단한질문용), grok(복잡한 로직) 을 자주사용하고 요즘은 cursor를 종종 사용하고있습니다. perplexity(출처찾기), gemini(글쓰기)도 종종 사용하고있습니다. 근데 다들 각자의 발전속도가 빨라서 어떨때는 차이없이 다 괜찮기도하더라구요~ 현재는 무료버전으로도 충분히 사용하고있습니다. 툴보다는 어떤 모델로 돌리느냐에 따라 퀄리티 차이가 많이 나구요 ㅎㅎ 사용방식은 코딩측면에서는 작성된 코드가 결점이 있는지 확인하거나 테스트작성에 주로 사용하고있습니다. IDE에 내장된 추천기능만 활용하더라도 굳이 물어보는 과정이 많이 필요없기도하구요. 시스템 스크립트작성이나 아주 반복적인 쿼리, 파일 작성에는 cursor를 활용해서 빠르게 작업합니다. 신규기능에 대한 설계나 프로젝트와의 연관성 (MSA 구조의 멀티프로젝트라면 서로간의 상호작용을 고려하면서 AI로 한번에 코딩하거나 하는게 힘들죠)이 필요한 부분들은 수작업으로 틀을 잡습니다. 그과정에서 연필과 종이를 많이 활용하고있네요 ㅎㅎ; 프롬프팅이 필요하다싶으면 종이, 머릿속에 그림을 미리 그려놓고 프롬프팅을 어떻게할지 리스트업을 한뒤에 진행하곤합니다. 참고로 처음배우는거라면 AI로 바로 쓰기보다는 직접 생각하고 타이핑을 하는과정을 한동안 거쳐보고 나서 AI를 활용하는게 더 좋다고 생각했기때문에, 처음배우는 분들을 위해서 직접 타이핑을 하면서 강의를 만들었었습니다 ☺
안녕하세요 거북이님~ 현재 모습만 두고보았을때는 생성자 기반 매핑을 사용하고 있어서 기본 생성자가 필요하지 않아서 문제가 발생하지 않는 모습이네요! jpa에서 사용하는 엔티티가 아니기 때문에 없어도 되겠네요 ☺ 현 상황에서는 제거해도 될 것 같네요 🙏 (참고로 다른 클라이언트에서는 record를 사용하는것을 보여드렸을거에요)
안녕하세요 kimoon님! id 'org.springframework.boot' version '3.2.5' ... mavenBom "org.springframework.cloud:spring-cloud-dependencies:2023.0.1" 버전을 위와같이 맞춰주시거나 혹은 말씀하신 버전을 사용하려면 아래 공식문서를 통해서 호환되는 버전을 찾아서 명시해주시면 될 것 같습니다! 문서에 따르면 2024버전을 사용하시면 될 것으로 보이네요~ https://spring.io/projects/spring-cloud https://github.com/spring-cloud/spring-cloud-release/wiki/Spring-Cloud-2024.0-Release-Notes
