도서, 그리고 로드맵 강의 순서

안녕하세요! 책에 관심 가져주셔서 감사합니다. 강의와 책의 순서는 관계 없다고 생각되지만, 추후 신규 강의 전에 책을 먼저 읽으시면 왜 제가 해당 강의를 준비했는지 조금 더 와닿으실 것 같습니다!

스토리북에 대해서

결론부터 말씀 드리자면 개인 프로젝트나 소규모 프로젝트에는 적합하지 않다고 생각합니다.엔지니어마다 생각이 다르겠지만, 저는 기술을 도입할 때는 해당 기술이 필요할 때 도입하는 것이 맞다고 생각합니다. Storybook도 기술이라고 본다면, Storybook이 필요할 때 도입하는 게 맞다고 생각합니다. 예를 들면 Storybook 도입이 권장되는 경우 (효과가 비용을 상회함)복잡한 UI 상태가 많은 프로젝트: 특정 조건(에러, 로딩, 데이터 만료, 다양한 권한 등)에서만 보이는 UI가 많을 때, 이를 확인하기 위해 매번 앱의 복잡한 비즈니스 로직을 타는 것은 비효율적입니다. Storybook은 UI를 격리된 환경에서 즉시 확인할 수 있게 해줍니다.컴포넌트 단위의 협업이 필요한 팀: 기획자나 디자이너가 개발 중인 UI를 수시로 확인해야 하거나, 개발자가 만든 컴포넌트의 사양을 문서화하여 공유해야 할 때 매우 유용합니다.시각적 회귀 테스트(Visual Regression Test)가 중요할 때: Chromatic과 연동하여 CSS 수정이 엉뚱한 페이지의 버튼 디자인을 깨뜨리지 않았는지 자동으로 검증하고 싶을 때 필수적입니다.자체 디자인 시스템을 구축할 때: 여러 프로젝트에서 공통으로 사용할 컴포넌트 라이브러리를 만든다면, Storybook은 선택이 아닌 필수입니다.2. Storybook 도입을 재고하거나 나중에 해도 되는 경우 (관리 비용이 더 큰 경우)UI 요구사항이 단순하고 정적인 경우: 표준 UI 라이브러리(MUI, Tailwind UI 등)를 거의 그대로 사용하고 커스텀 컴포넌트가 적다면 Storybook 관리 비용이 더 큽니다. 비즈니스 로직 중심의 프로젝트: UI보다는 서버 사이드 로직이나 복잡한 계산이 핵심인 대시보드 형태의 앱이라면, UI 격리 개발의 이점이 줄어듭니다.프로토타이핑 단계: 내일 당장 디자인이 뒤엎어질 수 있는 초기 가설 검증 단계에서는 스토리북을 작성하는 행위 자체가 낭비가 될 수 있습니다.꼭 필요하지 않은 상황에 도입하면 오히려 관리 포인트가 늘어난다고 생각합니다. 질문해주신 내용과는 다르지만 예전에 프로토타입단계에서 백엔드에 쿠버네티스를 도입했던 적이 있는데, 관리할 것도 없는데 관리 툴을 너무 과대한 걸 쓰다보니 오히려 고생햇던 경험이 있습니다. 다만 제 의견이 정답은 아니니 다양한 분들의 의견을 들어보시고 최종적으로 판단하시면 좋겠습니다!

new_question에 대한 답 출력

new_question은 dictionary_chain을 활용해서 사용자의 질문을 검색이 조금 더 잘되게 수정하는 용도입니다. 코드를 조금 더 따라가보시면 답변을 얻으실 수 있을거에요!

md vs txt 차이..

안녕하세요! 좋은 질문 감사합니다. 제가 설명을 깔끔하게 드리지 못한 것 같습니다. 표가 "짤린다"는 표현이 청크 사이즈로 인해서 짤린다는게 아니라 표의 형식이 "짤린다"라는 뜻이었습니다. 표 형식을 마크다운이 유지하려면 |, ---, : 등과 같은 기호들이 남아있어야 하는데, 마크다운 로더로 파일을 읽으면 해당 기호들이 사라지면서 표의 형식을 상실하게 되는데, 제가 "짤린다"라고 표현해서 오해가 있었던 것 같습니다.추가로 설명이 필요하신 부분이 있다면 말씀 부탁드립니다!

OpenAI API 호출 때문에 발생하는 Error code: 429 문제

네 맞습니다 금액을 충전해주셔야 합니다 ㅠㅠ

19강에 있는 postgres account 계정 로그인이 안돼요

저는 사용하던 데이터베이스라 비밀번호가 다릅니다!

Storybook 10에서 argTypes에 action 설정 시

안녕하세요! 좋은 질문 감사합니다. 각각의 질문에 답변을 드려보자면action 키가 뜨지 않는 것은 Storybook 버전이 올라가면서 Meta와 StoryObj의 타입 정의가 훨씬 엄격해졌기 때문인 것 같습니다. 최신 버전에서는 argTypes 내에서 문자열로 액션을 지정하는 방식보다, 실제 함수를 할당하는 방식을 권장합니다. 따라서 TypeScript 환경에서는 유효하지 않은 속성으로 간주되어 자동 완성이 나타나지 않을 수 있습니다.fn() 만 사용하셔도 됩니다. 최신 버전에서는 오히려 권장하는 방식입니다.action: 'clicked'를 사용하는 이유는 가독성 때문입니다. 클릭이라는 액션이 가능하다는 것을 명시적으로 작성해 주는 것이라고 보시면 됩니다.

이메일 답장 드래프트 작성 개선 관련

안녕하세요! 좋은 질문 감사합니다. 저는 전자의 방식을 선호합니다. 다만 이건 엔지니어들마다 생각이 달라서 의사결정의 영역이라고 생각합니다. 강의에서 말씀 드리는 것처럼, 저는 가급적이면 작은 단위로 작업을 쪼개서 진행하는 것이 가장 AI를 효율적으로 사용하는 방법이라고 생각합니다. 기술의 발전으로 모델이 조금 더 다양한 task를 수행할 수 있게 되면서 말씀하신 정교한 프롬프트로 한번에 좋은 결과물을 낼 수도 있겠지만, 만약 그렇지 못한 경우에는 어떤 부분에서 문제가 되는지 파악이 어렵다는 문제가 있습니다. 원하는 포맷으로 메일을 작성하지 못하는데는 질문해주신 내용을 기반으로 볼 때 다양한 이유가 있다고 생각하는데요이전 답장 기록을 넣는 방식의 문제인지작성 룰을 이해하지 못해서 인지형식을 제대로 따르지 못하는 것인지 단순히 AI가 에러가 나는 것인지 처음 말씀하신 리뷰의 형식으로 진행을 하게 되면, 1번부터 4번까지 별도로 최적화를 하거나 다양한 시도를 통해서 디버깅이 가능한데, 한번에 큰 프롬프트를 사용하게 되면 디버깅이나 최적화가 어려워지는 이슈가 있습니다. 그리고 경험상 장황한 프롬프트에서 2번을 담당하는 영역을 수정하면 3번을 담당하는 영역이 안되고 그러다보면 반복만 계속하게되는 문제가 있었습니다. 물론 이 부분도 모델의 성능이 엄청 좋아지면 충분히 개선될 수 있는 영역이긴 합니다. 하지만 저는 모델이 아무리 좋아져도 거대한 프롬프트를 하나 사용하는 것은 지양하는 것이 좋다고 생각합니다. 특히 말씀드린 최적화의 영역을 고민해야 한다면 특히 업무를 작은 단위로 나누는 것이 좋을 것 같습니다. 다만 이건 제 개인적인 생각이고, 의견이 다른 분들도 있을거라 다양한 의견을 들어보시고 종합적으로 판단하시는 것을 추천 드립니다!

랭체인 라이브러리

좋은 질문 감사합니다! 말씀하신 것처럼 순수 라이브러리를 사용하면 더 가볍다는 이점이 있지만 랭체인과 연동 편의성을 위해서 가급적 랭체인에서 제공하는 패키지를 사용하고 있습니다.

[LangGraph를 활용한 AI Agent 개발] 쿠폰 유효기간

안녕하세요! 할인 쿠폰은 어떤 쿠폰을 말씀하시는 걸까요? 기간이 만료됐거나 인원을 초과해서 발생하는 에러인 것 같습니다.