jasonkang

미들 (4~8년)

안녕하세요! 강의를 수강해주셔서 감사합니다. 다른 수강생분들이 작업하신 예제들을 보여드릴 수는 없고, 외부 MCP들을 모아둔 사이트에서 한번 보시고 만들어 볼만한 것들을 찾아보시는 걸 추천 드립니다<a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/modelcontextprotocol/servers?tab=readme-ov-file">https://github.com/modelcontextprotocol/servers?tab=readme-ov-file</a>

MCP를 활용해서 간단한 에이전트를 만들어보세요

안녕하세요! 좋은 질문 감사합니다. 파일 안에 사진이 있는 경우에는, 경험상 비용이 발생하긴 하지만 Upstage의 Document API를 활용하는게 가장 좋은 선택입니다. 다른 대안이 있을 수도 있는데 저는 다른 방법은 시도해보지 않았습니다. 다만 Upstage의 Document API도 사진을 분석해주지는 않고, 아래 방식으로 진행하셔야 합니다. <ol><li> pdf 파일을 분석해서 사진의 위치를 알려주는데요(좌표 포함), </li><li>해당 영역을 코드로 잘라서 별도로 사진 파일로 저장한 다음에 </li><li>사진 인식이 가능한 AI를 활용해서 사진의 설명을 생성하고 </li><li>사진의 설명을 임베딩하는 방식입니다 </li></ol>제가 시도해봤던 방법들 중에서는 가장 효과가 좋았습니다.

PDF 형식

안녕하세요, 좋은 질문 감사합니다. RAG의 핵심은 데이터를 어떻게 잘 전달하느냐 인데요, 질문하신 내용에 답변을 드려보자면<ol><li>마크다운 형식으로 간다면 유지하는 편이 좋습니다. <code>1.2</code> , <code>1.2.1</code> 과 같은 구분이 문서의 형식을 나타내기 때문에 남겨두는 편이 좋습니다. 아래처럼 수정해주시면 더 좋습니다 </li></ol><pre><code class="language-markdown">## 1.2 화면 설명
### 1.2.1 개요
- 이 화면은 사용자가 업무를 처리하기 위한 화면입니다.

### 1.2.2 화면 위치
상단 메뉴 > 업무 관리 > 처리 화면

### 1.2.3 처리 절차
1) 항목 선택
2) 저장 버튼 클릭
</code></pre>그리고 이런식으로 가능하시다면 더 좋습니다 <pre><code class="language-markdown">## 1.2 화면 설명
### 1.2.1 개요
- 이 화면은 사용자가 업무를 처리하기 위한 화면입니다.

## 1.2 화면 설명
### 1.2.2 화면 위치
상단 메뉴 > 업무 관리 > 처리 화면

## 1.2 화면 설명
### 1.2.3 처리 절차
1) 항목 선택
2) 저장 버튼 클릭
</code></pre>1.2.2와 1.2.3에 1.2의 내용을 넣어주면서, 어떤 화면에 대한 내용인지를 부연설명해서 더 좋은 context를 전달할 수 있습니다.<ol start="2"><li><code>-</code> 와 같은 기호는 남겨두는 편이 좋습니다. 일반 줄글로는 텍스트들의 관계를 쉽게 파악할 수 없기 때문입니다.</li></ol><pre><code>상단 메뉴 > 업무 관리 > 처리 화면</code></pre>의 경우에는 처리 순서의 depth를 확인할 수 있지만<pre><code>상단 메뉴 업무 관리 처리 화면</code></pre>이렇게 보면 어떤 관계가 있는지 알 수 없기 때문입니다<ol start="3"><li>1, 2 번에서 답변이 되었을 것 같은데요, 추가하시는 방향을 추천 드립니다</li></ol>

문서 전처리 고민

안녕하세요! 책에 관심 보여주셔서 감사합니다 <code>PART II LangChain을 활용한 RAG 파이프라인 구성하기</code> 가 강의 내용과 맞는 부분이라고 보시면 됩니다

강의와 책 관련 질문

안녕하세요! 좋은 질문 감사합니다.TL;DR핵심부터 말씀드리면, case 3(<code>update_tool</code>)은 "도구 자체를 바꾸는 것"이 아니라 "도구 호출을 건너뛰고, 사람이 직접 도구 결과를 제공하는 것"입니다.코드를 다시 보시면:<pre><code>if review_action == 'update_tool':
 updated_tool_message = {
 'tool_call_id': tool_call['id'],
 'name': tool_call['name'],
 'role': 'tool',
 'content': review_data # 사람이 직접 제공하는 "결과값"
 }
 return Command(goto='agent', update={'messages': [updated_tool_message]})</code></pre>여기서 두 가지를 확인할 수 있는데요<ol><li><code>goto='agent'</code><ol><li><code>tools</code> 노드가 아니라 바로 <code>agent</code>로 갑니다. </li><li>즉, 실제로 도구를 실행하지 않습니다.</li></ol></li><li><code>role: 'tool'</code>인 메시지를 직접 만들어서 삽입을 하게 되는데, 마치 도구가 실행된 것처럼 LLM에게 결과를 전달하는 가짜 ToolMessage입니다.</li></ol>이 패턴의 의도는 이렇습니다: AI가 잘못된 도구를 선택했을 때, 사람이 "이 도구 말고 웹에서 검색해줘"라고 자연어로 피드백을 주면, 그 피드백 자체가 ToolMessage의 <code>content</code>로 들어가서 agent가 다시 판단할 수 있게 되는 것입니다.실제 예시에서도 확인할 수 있습니다:<pre><code class="language-python">Command(resume={"action": "update_tool", "data": "arxiv말고 web에서 검색해주세요"})</code></pre>여기서 <code>arxiv말고 web에서 검색해주세요</code> 라는 문자열이 ToolMessage의 content가 되어 agent에게 전달되고, agent는 이를 보고 다음에 <code>duckduckgo_search</code>를 호출하게 됩니다.&nbsp;그러면 질문하신 것처럼 ai_message의 tool_calls에서 tool name을 직접 바꾸면 안 되는 것인지 의문이 들 수 있는데요,기술적으로 가능은 하지만, 실용적으로 문제가 있습니다:<ul><li><code>tool_name</code>을 바꾸면 args도 함께 바꿔야 합니다. 각 도구마다 파라미터 스키마가 다르기 때문입니다. 강의에서 진행한 케이스의 경우 <code>arxiv</code> 도구와 <code>duckduckgo_search</code> 도구의 인자 형식이 동일한데요(모두 <code>query</code>를 사용함), 만약 스키마가 다른 경우에는 에러가 발생합니다.<ul><li>사람이 도구 이름과 정확한 인자까지 알아서 지정해야 하므로 human-in-the-loop의 편의성이 크게 떨어집니다.</li></ul></li><li>반면 case 3 방식은 사람이 자연어로 피드백만 주면, agent(LLM)가 알아서 적절한 도구와 인자를 다시 선택하므로 훨씬 유연합니다.</li></ul>

3.6 human_in_the_loop 3rd case

oopy에서 일시적으로 에러가 있었던 것 같습니다! 다시 한 번 확인해주실 수 있을까요? <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.kangsium.com/agent-use-cases-with-n8n-and-langgraph">https://www.kangsium.com/agent-use-cases-with-n8n-and-langgraph</a>

Notion 강의 자료가 보이지 않습니다.

안녕하세요, 좋은 질문 감사합니다. 답변을 드려보자면강의에서 Streamlit과 LangChain을 한 곳에서 사용하는 이유는 빠른 프로토타이핑 때문입니다 강의에서는 파이썬 코드 하나로 UI와 로직을 모두 처리할 수 있어 로직 검증에 최적화되어 있습니다. 현업에서는 질문하신 대로 프론트엔드와 백엔드를 엄격히 분리합니다. Streamlit은 내부 운영 툴이나 간단한 데모용으로만 쓰고, 실제 서비스는 React/Next.js와 FastAPI/Spring Boot 조합으로 구축하는 것이 일반적입니다. 경험상 프로토타입이라고 Streamlit을 활용해서 배포를 하면, 사용자 요구사항이 늘어나고, streamlit을 streamlit답지 않게 사용하는 경우가 발생합니다&nbsp;이상적인 상태의 서비스라면 RAG 로직은 별도의 'AI 마이크로서비스(FastAPI 등)'로 분리하는 것이 맞겠지만, 저는 monolithic서버로 운영해도 무관하다고 생각합니다. 인증을 Spring Boot로 꼭 해야한다면 아무래도 AI 관련 라이브러리들이 파이썬으로 많이 구성되어있으니 별도의 서비스를 띄우는게 개발할 때 편하다고 생각합니다. 말씀하신 것처럼 FastAPI로 인증을 통합하신다면 하나로 충분히 갈 수 있을 것 같습니다. &nbsp;Qdrant는 저는 사용해본적은 없는데 Rust기반이라 빠르다고 하네요, 크게 문제가 될 것 같진 않습니다. GraphRAG는 제가 현업에서 사용한 경험이 없어서 강의로 출시하긴 어려울 것 같습니다.&nbsp;추가로 궁금하신 부분이 있으시면 말씀 부탁 드립니다

RAG 배포 질문드립니다

안녕하세요! 좋은 질문 감사합니다. LLM을 활용한다면 전혀 문제 없을 거라고 생각합니다. 예전에 NLP를 학습할 때는 감정분석이나, 라벨링같은 태스크가 상당히 어려웠는데, LLM으로 하시면 제 생각엔 거의 모든 케이스를 커버할 수 있지 않을까 싶습니다. 만약 학습 측면에서 접근하신다면 GPT-5, Claude Opus 4.5, Gemini 3 과같은 상용 모델보다는 google-bert/bert-base-multilingual-cased같은 걸 파인튜닝해서 시도해보시는게 어떨까 싶네요. 다만 완전(?) 다국어로 간다면 기대하시는 만큼의 성능은 나오지 않을 것 같습니다

강의 내용과는 별개로 궁금한 점이 있습니다

안녕하세요! 좋은 질문 감사합니다. 질문해주신 내용은 프롬프트 작성에 관한 팁이라고 말씀드릴 수 있는데요<img src="https://cdn.inflearn.com/public/files/posts/009f4f60-c8b9-4c54-bdec-0c76686d33a6/01dee86d-703e-4e9c-a39e-4f49727bae6b.png" media-type="img" alt="Screenshot 2026-01-31 at 1.26.32 PM.png" title="Screenshot 2026-01-31 at 1.26.32 PM.png" width="658" height="159">주택에 대한 세금을 산정할 때, 공제액이라는 개념이 들어가게 되는데요, 세금을 내는 사람이 보유한 주택의 수가 공제액에 영향을 미치게 됩니다. 그래서 프롬프트에 조금 더 구체적으로 명시를 해서 LLM이 더 정확한 답변을 생성하게 하기 위함이라고 보시면 됩니다&nbsp;

병렬 처리 중 retrieve 관련 궁금한 사항

Context만 있고 답변이 나오지 않는 상황인가요? 코드 전체를 올려주시면 디버깅을 시도해 볼 수 있을 것 같습니다~

jasonkang

投稿