본 콘텐츠의 이미지 및 내용은 AI로 생성되었습니다.
본 콘텐츠의 이미지 및 내용을 무단으로 복제, 배포, 수정하여 사용할 경우 저작권법에 의해 법적 제재를 받을 수 있습니다.
이미지 로딩 중...
AI Generated
2025. 12. 24. · 3 Views
ReAct 패턴으로 코드 디버깅 완벽 가이드
LLM을 활용한 ReAct 패턴으로 버그를 자동으로 찾고 수정하는 방법을 배웁니다. Reasoning, Acting, Observation 사이클을 통해 체계적인 디버깅 프로세스를 구축할 수 있습니다.
목차
- Reasoning_버그_원인_추론
- Acting_코드_수정_시도
- Observation_테스트_결과_확인
- Self_Reflection_수정_재시도
- 실습_자동_버그_수정_에이전트
- 실습_디버깅_과정_로깅_시스템
1. Reasoning 버그 원인 추론
어느 월요일 아침, 김개발 씨는 주말 동안 작성한 코드를 테스트하다가 이상한 에러를 발견했습니다. "분명히 잘 작동할 것 같은데 왜 안 되지?" 고민하던 중, 선배 박시니어 씨가 다가와 말했습니다.
"버그를 고치기 전에, 먼저 왜 이런 문제가 생겼는지 추론해봐야 해요."
Reasoning은 ReAct 패턴의 첫 번째 단계로, 문제의 원인을 논리적으로 추론하는 과정입니다. 마치 탐정이 범죄 현장의 단서를 모아 범인을 추리하듯이, 코드의 증상을 보고 원인을 추측합니다.
LLM은 코드 컨텍스트를 분석하여 가능성 있는 버그 원인을 제시합니다.
다음 코드를 살펴봅시다.
# LLM을 활용한 버그 원인 추론
def reasoning_bug_cause(error_message, code_snippet, context):
# 프롬프트 구성: 에러와 코드를 함께 제공
prompt = f"""
에러 메시지: {error_message}
문제가 발생한 코드:
{code_snippet}
컨텍스트: {context}
이 버그의 원인을 3가지 가능성으로 추론하세요.
각 가능성마다 확률과 근거를 제시하세요.
"""
# LLM 호출하여 추론 결과 받기
reasoning_result = llm.generate(prompt)
return reasoning_result
김개발 씨는 입사 6개월 차 백엔드 개발자입니다. 오늘도 API 서버를 개발하던 중, 특정 엔드포인트에서 간헐적으로 500 에러가 발생하는 것을 발견했습니다.
로그를 봐도 명확한 원인이 보이지 않습니다. 박시니어 씨가 모니터를 들여다보며 말했습니다.
"무작정 코드를 고치기 전에, 먼저 왜 이런 문제가 생겼는지 체계적으로 추론해야 해요. 그게 바로 ReAct 패턴의 첫 번째 단계인 Reasoning입니다." 그렇다면 Reasoning이란 정확히 무엇일까요?
쉽게 비유하자면, Reasoning은 마치 의사가 환자의 증상을 듣고 병명을 추측하는 과정과 같습니다. 의사는 "열이 나고 목이 아프다"는 증상만으로 즉시 감기약을 처방하지 않습니다.
먼저 여러 가능성을 생각합니다. 감기일 수도 있고, 편도염일 수도 있고, 독감일 수도 있습니다.
각 가능성의 확률을 따져보며 가장 유력한 원인을 찾아냅니다. 코드 디버깅도 마찬가지입니다.
에러 메시지라는 증상을 보고, 코드라는 환자의 상태를 살피며, 버그라는 병의 원인을 추론하는 것입니다. Reasoning이 없던 시절에는 어땠을까요?
개발자들은 버그를 발견하면 즉시 코드를 수정하려고 했습니다. "아, 여기가 문제인 것 같아"라며 직감에 의존했죠.
하지만 이런 방식은 실수하기 쉬웠습니다. 진짜 원인이 아닌 증상만 고치는 경우가 많았고, 더 큰 문제를 만들기도 했습니다.
더 심각한 문제는 복잡한 버그를 만났을 때였습니다. 여러 모듈이 얽혀있고, 원인이 명확하지 않을 때는 몇 시간씩 헤매기 일쑤였습니다.
코드베이스가 커질수록 이런 비효율은 눈덩이처럼 불어났습니다. 바로 이런 문제를 해결하기 위해 ReAct 패턴이 등장했습니다.
ReAct는 Reasoning(추론)과 Acting(행동)을 결합한 패턴으로, LLM의 강력한 추론 능력을 활용합니다. 먼저 문제의 원인을 논리적으로 추론한 뒤, 그 추론에 기반하여 행동합니다.
이렇게 하면 더 정확하고 효율적인 디버깅이 가능해집니다. 무엇보다 체계적인 접근이 가능하다는 큰 이점이 있습니다.
LLM은 방대한 코드 패턴과 버그 사례를 학습했기 때문에, 인간이 놓칠 수 있는 원인까지 고려할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.
먼저 reasoning_bug_cause 함수는 세 가지 정보를 받습니다. 에러 메시지, 문제가 발생한 코드 스니펫, 그리고 컨텍스트입니다.
컨텍스트에는 사용 중인 라이브러리, 실행 환경, 최근 변경 사항 등이 포함될 수 있습니다. 다음으로 프롬프트를 구성합니다.
여기서 핵심은 LLM에게 단순히 답을 요구하는 게 아니라, 추론 과정을 요구한다는 점입니다. "3가지 가능성으로 추론하세요"라고 명시하면, LLM은 여러 각도에서 문제를 분석합니다.
각 가능성마다 확률과 근거를 제시하도록 하면, 우리는 가장 유력한 원인부터 검증할 수 있습니다. 마지막으로 LLM을 호출하여 추론 결과를 받아옵니다.
이 결과는 다음 단계인 Acting에서 활용됩니다. 실제 현업에서는 어떻게 활용할까요?
예를 들어 전자상거래 플랫폼을 운영한다고 가정해봅시다. 결제 프로세스에서 간헐적으로 결제가 실패하는 버그가 발생했습니다.
로그를 보니 "Connection timeout" 에러가 뜹니다. 이때 Reasoning 단계를 거치면 LLM이 이렇게 추론할 수 있습니다.
"70% 확률로 외부 결제 API의 응답 지연 문제, 20% 확률로 네트워크 설정 문제, 10% 확률로 데이터베이스 커넥션 풀 고갈 문제." 이제 우리는 가장 가능성 높은 원인부터 체크할 수 있습니다. 많은 기업에서 이런 패턴을 적극적으로 사용하고 있습니다.
특히 마이크로서비스 아키텍처처럼 복잡한 시스템에서 효과가 큽니다. 하지만 주의할 점도 있습니다.
초보 개발자들이 흔히 하는 실수 중 하나는 LLM의 추론을 무조건 신뢰하는 것입니다. LLM도 완벽하지 않습니다.
잘못된 추론을 할 수 있습니다. 따라서 추론 결과를 받았다면, 반드시 검증 단계를 거쳐야 합니다.
이것이 바로 ReAct 패턴의 다음 단계들입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.
박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 먼저 원인을 추론해야 하는군요!" Reasoning을 제대로 활용하면 버그 수정 시간을 크게 줄일 수 있습니다.
무작정 코드를 고치는 대신, 체계적으로 원인을 찾아낼 수 있기 때문입니다. 여러분도 오늘 배운 내용을 실제 디버깅에 적용해 보세요.
실전 팁
💡 - LLM에게 추론 과정을 단계별로 요청하면 더 정확한 결과를 얻을 수 있습니다
- 여러 가능성을 확률과 함께 제시하도록 하면 우선순위를 정하기 쉽습니다
- 추론 결과를 로그로 남겨두면 나중에 비슷한 버그가 생겼을 때 참고할 수 있습니다
2. Acting 코드 수정 시도
김개발 씨는 LLM이 제시한 추론 결과를 받았습니다. "70% 확률로 null 체크 누락이 원인입니다"라는 분석이었습니다.
이제 뭘 해야 할까요? 박시니어 씨가 말했습니다.
"추론만으로는 버그가 고쳐지지 않아요. 이제 실제로 행동해야 합니다.
그게 바로 Acting 단계죠."
Acting은 ReAct 패턴의 두 번째 단계로, 추론 결과에 기반하여 실제 코드를 수정하는 과정입니다. 마치 의사가 진단을 내린 후 처방전을 쓰듯이, LLM은 추론한 원인에 맞는 해결책을 제시하고 코드 수정안을 생성합니다.
단순히 이론에 그치지 않고 구체적인 행동으로 옮기는 단계입니다.
다음 코드를 살펴봅시다.
# 추론 결과를 바탕으로 코드 수정안 생성
def acting_fix_code(reasoning_result, original_code):
# 가장 가능성 높은 원인 선택
most_likely_cause = reasoning_result['possibilities'][0]
# 수정 프롬프트 구성
prompt = f"""
원인: {most_likely_cause['cause']}
근거: {most_likely_cause['evidence']}
원본 코드:
{original_code}
이 원인을 해결하는 코드 수정안을 제시하세요.
변경 전/후를 명확히 표시하세요.
"""
# LLM이 코드 수정안 생성
fix_suggestion = llm.generate(prompt)
# 수정안 적용
fixed_code = apply_fix(original_code, fix_suggestion)
return fixed_code, fix_suggestion
김개발 씨는 이제 문제의 원인을 알게 되었습니다. LLM이 "사용자 입력값에 대한 null 체크가 누락되어 있고, 이로 인해 NullPointerException이 발생할 수 있다"고 추론했습니다.
확률도 70%로 가장 높습니다. "자, 이제 알았으니 코드를 고치면 되겠네요!" 김개발 씨가 말했습니다.
박시니어 씨가 미소를 지으며 말했습니다. "맞아요.
하지만 여기서도 LLM의 도움을 받을 수 있어요. Acting 단계에서는 추론한 원인을 실제로 해결하는 코드를 생성합니다." Acting이란 정확히 무엇일까요?
쉽게 비유하자면, Acting은 마치 건축가가 설계도를 보고 실제 건물을 짓는 과정과 같습니다. Reasoning이 "이 건물은 기초가 약해서 흔들린다"는 진단이라면, Acting은 "그럼 이렇게 기초를 보강하자"는 구체적인 시공 계획입니다.
진단만으로는 건물이 고쳐지지 않습니다. 실제로 삽을 들고 작업해야 합니다.
코드 수정도 마찬가지입니다. 원인을 알았다면 이제 그것을 해결하는 구체적인 코드를 작성해야 합니다.
전통적인 디버깅 방식에서는 어땠을까요? 개발자는 원인을 파악한 후 직접 코드를 수정해야 했습니다.
간단한 버그라면 괜찮지만, 복잡한 로직이나 낯선 코드베이스에서는 어려움을 겪었습니다. "이 부분을 고치면 다른 부분에 영향이 가지 않을까?" "더 나은 수정 방법은 없을까?" 고민하느라 시간을 많이 썼습니다.
특히 주니어 개발자들은 최선의 수정 방법을 찾기 어려워했습니다. 버그는 고쳤지만 코드 품질이 떨어지거나, 새로운 버그를 만들어내는 경우도 많았습니다.
바로 이런 문제를 해결하기 위해 Acting 단계가 중요합니다. LLM을 활용하면 추론한 원인에 정확히 맞는 해결책을 제시받을 수 있습니다.
LLM은 수많은 코드 패턴과 베스트 프랙티스를 학습했기 때문에, 단순히 버그만 고치는 게 아니라 더 나은 코드를 제안합니다. 또한 변경의 영향 범위도 고려합니다.
이 코드를 수정했을 때 다른 부분에 어떤 영향이 있을지 분석하여, 안전한 수정안을 제시합니다. 무엇보다 학습 효과가 큽니다.
LLM이 제시한 수정안을 보면서 "아, 이런 식으로 처리하는구나" 하고 배울 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.
먼저 reasoning_result에서 가장 가능성 높은 원인을 선택합니다. 여러 가능성 중 첫 번째는 가장 높은 확률을 가진 원인입니다.
다음으로 수정 프롬프트를 구성합니다. 여기서 중요한 점은 원인과 근거를 함께 제공한다는 것입니다.
LLM은 왜 이 코드를 고쳐야 하는지 이해하고, 그에 맞는 최적의 수정안을 제시합니다. "변경 전/후를 명확히 표시하세요"라는 지시를 넣으면, 어떤 부분이 어떻게 바뀌는지 쉽게 파악할 수 있습니다.
LLM이 생성한 수정안은 apply_fix 함수를 통해 실제 코드에 적용됩니다. 이 함수는 diff 형식의 수정안을 파싱하여 원본 코드를 변경합니다.
실제 현업에서는 어떻게 활용할까요? 예를 들어 레거시 코드베이스를 유지보수하는 상황을 생각해봅시다.
10년 전에 작성된 코드에서 보안 취약점이 발견되었습니다. 코드는 복잡하고, 원작성자는 이미 퇴사했습니다.
이때 Acting 단계를 활용하면 LLM이 "이 부분에서 SQL 인젝션 취약점이 발견되었으니, Prepared Statement를 사용하도록 수정하세요"라는 구체적인 수정안을 제시합니다. 심지어 수정 전/후 코드를 비교하여 보여주므로, 검토하기도 쉽습니다.
많은 기업에서 코드 리뷰 시스템과 결합하여 사용하고 있습니다. 자동으로 수정안을 생성한 뒤, 시니어 개발자가 최종 검토하는 방식입니다.
하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 LLM이 생성한 코드를 검증 없이 바로 적용하는 것입니다.
LLM도 실수할 수 있습니다. 잘못된 수정안을 제시할 수도 있고, 엣지 케이스를 놓칠 수도 있습니다.
따라서 생성된 코드를 반드시 리뷰하고 테스트해야 합니다. 이것이 바로 다음 단계인 Observation입니다.
다시 김개발 씨의 이야기로 돌아가 봅시다. LLM이 제시한 수정안을 본 김개발 씨는 감탄했습니다.
"와, null 체크뿐만 아니라 더 안전한 Optional 패턴까지 제안해주네요!" Acting을 제대로 활용하면 더 빠르고 안전하게 버그를 수정할 수 있습니다. 단순히 땜질하는 게 아니라, 코드 품질까지 개선할 수 있습니다.
여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.
실전 팁
💡 - 수정안을 적용하기 전에 항상 diff를 확인하여 의도하지 않은 변경이 없는지 체크하세요
- 복잡한 수정은 여러 단계로 나누어 진행하면 더 안전합니다
- 수정 전 원본 코드를 백업하거나 git commit을 먼저 해두세요
3. Observation 테스트 결과 확인
김개발 씨는 LLM이 제안한 코드 수정안을 적용했습니다. 이제 끝일까요?
박시니어 씨가 고개를 저었습니다. "아직 끝이 아니에요.
고친 코드가 정말 문제를 해결했는지 확인해야 합니다. 그게 바로 Observation 단계입니다."
Observation은 ReAct 패턴의 세 번째 단계로, 수정한 코드를 실제로 테스트하고 결과를 관찰하는 과정입니다. 마치 의사가 약을 처방한 후 환자의 상태를 재진찰하듯이, 코드 수정 후 버그가 정말 해결되었는지 검증합니다.
이 단계에서 수정이 성공했는지, 새로운 문제가 생겼는지 파악합니다.
다음 코드를 살펴봅시다.
# 수정된 코드의 테스트 및 결과 관찰
def observation_test_fix(fixed_code, test_cases, original_error):
results = {
'original_error_fixed': False,
'new_errors': [],
'test_results': []
}
# 원래 에러가 해결되었는지 확인
try:
execute_code(fixed_code, original_error['input'])
results['original_error_fixed'] = True
except Exception as e:
results['new_errors'].append(str(e))
# 전체 테스트 케이스 실행
for test in test_cases:
try:
output = execute_code(fixed_code, test['input'])
results['test_results'].append({
'passed': output == test['expected'],
'test': test['name']
})
except Exception as e:
results['new_errors'].append(f"{test['name']}: {str(e)}")
return results
김개발 씨는 코드를 수정하고 나서 뿌듯한 마음으로 커밋하려 했습니다. 그런데 박시니어 씨가 말렸습니다.
"잠깐만요! 정말 고쳐졌는지 확인은 해봤나요?" 김개발 씨는 당황했습니다.
"아, 그냥 코드를 보니까 맞는 것 같아서요..." 박시니어 씨가 웃으며 말했습니다. "코드는 실행해봐야 알 수 있어요.
Observation 단계에서는 수정한 코드를 실제로 돌려보고 결과를 관찰합니다." Observation이란 정확히 무엇일까요? 쉽게 비유하자면, Observation은 마치 과학자가 실험 결과를 기록하는 과정과 같습니다.
가설을 세우고(Reasoning), 실험을 진행하고(Acting), 이제 결과를 관찰합니다(Observation). 시험관의 색이 바뀌었나요?
온도가 올라갔나요? 예상한 대로 반응이 일어났나요?
꼼꼼히 기록하고 분석합니다. 코드 수정도 일종의 실험입니다.
"이렇게 고치면 버그가 해결될 것이다"라는 가설을 세우고, 코드를 수정하고, 이제 정말 해결되었는지 확인하는 것입니다. 전통적인 개발 방식에서는 어땠을까요?
많은 개발자들이 코드를 수정한 후 "이제 됐겠지" 하고 넘어갔습니다. 간단한 수정이라면 문제없지만, 복잡한 로직에서는 위험했습니다.
겉보기에는 고쳐진 것 같지만 특정 조건에서만 나타나는 버그가 남아있을 수 있습니다. 더 큰 문제는 새로운 버그를 만드는 경우였습니다.
A라는 버그를 고쳤는데, B라는 새로운 버그가 생기는 것이죠. 이를 "리그레션(regression)"이라고 합니다.
체계적인 테스트 없이는 이런 문제를 발견하기 어렵습니다. 바로 이런 문제를 방지하기 위해 Observation 단계가 필수적입니다.
Observation을 통해 두 가지 핵심 질문에 답할 수 있습니다. 첫째, 원래 버그가 정말 해결되었는가?
둘째, 수정으로 인해 새로운 문제가 생기지 않았는가? 또한 테스트 커버리지를 확보할 수 있습니다.
단순히 에러가 난 케이스만 테스트하는 게 아니라, 여러 엣지 케이스까지 확인합니다. 이렇게 하면 수정의 안정성을 보장할 수 있습니다.
무엇보다 데이터 기반 의사결정이 가능합니다. "고쳐진 것 같아요"가 아니라 "10개의 테스트를 모두 통과했습니다"라고 말할 수 있습니다.
위의 코드를 한 줄씩 살펴보겠습니다. 먼저 결과를 담을 딕셔너리를 초기화합니다.
original_error_fixed는 원래 에러가 해결되었는지, new_errors는 새로운 에러 목록, test_results는 각 테스트의 통과 여부를 기록합니다. 다음으로 원래 에러를 재현한 입력값으로 수정된 코드를 실행합니다.
예외가 발생하지 않으면 원래 버그가 해결된 것입니다. 만약 여전히 에러가 발생하거나 다른 에러가 발생하면 new_errors에 기록합니다.
그 다음 전체 테스트 케이스를 순회하며 실행합니다. 각 테스트마다 기대한 출력값이 나오는지 확인하고, 통과 여부를 기록합니다.
만약 예외가 발생하면 어떤 테스트에서 어떤 에러가 났는지 상세히 기록합니다. 마지막으로 모든 관찰 결과를 반환합니다.
이 결과는 다음 단계인 Self-Reflection에서 분석됩니다. 실제 현업에서는 어떻게 활용할까요?
예를 들어 금융 서비스의 거래 처리 로직을 수정했다고 가정해봅시다. 이는 매우 중요한 부분이므로 철저한 검증이 필요합니다.
Observation 단계에서는 수백 개의 테스트 케이스를 자동으로 실행합니다. 정상 거래, 잔액 부족, 동시성 이슈, 네트워크 장애 등 다양한 시나리오를 테스트하죠.
모든 테스트가 통과해야만 프로덕션에 배포할 수 있습니다. 많은 기업에서 CI/CD 파이프라인에 이런 Observation 단계를 통합하여 사용합니다.
코드가 수정되면 자동으로 테스트가 실행되고, 결과가 리포트됩니다. 하지만 주의할 점도 있습니다.
초보 개발자들이 흔히 하는 실수 중 하나는 해피 패스만 테스트하는 것입니다. 정상적인 입력에 대해서만 확인하고, 에러 케이스나 엣지 케이스를 놓칩니다.
실제 버그는 바로 이런 예외 상황에서 발생하는 경우가 많습니다. 따라서 다양한 시나리오를 테스트해야 합니다.
또한 성능 이슈도 관찰해야 합니다. 버그는 고쳤지만 실행 시간이 10배 느려졌다면 좋은 수정이 아닙니다.
기능적 정확성뿐만 아니라 성능, 메모리 사용량 등도 함께 관찰하세요. 다시 김개발 씨의 이야기로 돌아가 봅시다.
테스트를 돌려본 김개발 씨는 안도의 한숨을 쉬었습니다. "다행히 모든 테스트가 통과했네요!" Observation을 제대로 활용하면 자신 있게 코드를 배포할 수 있습니다.
추측이 아닌 검증된 결과를 바탕으로 판단할 수 있기 때문입니다. 여러분도 코드를 수정한 후에는 반드시 철저히 테스트하세요.
실전 팁
💡 - 유닛 테스트뿐만 아니라 통합 테스트까지 실행하여 전체 시스템이 정상 작동하는지 확인하세요
- 테스트 결과를 로그로 남겨두면 나중에 문제가 생겼을 때 추적하기 쉽습니다
- 성능 회귀를 방지하기 위해 벤치마크 테스트도 함께 실행하세요
4. Self Reflection 수정 재시도
김개발 씨는 테스트 결과를 확인하다가 당황했습니다. 원래 버그는 고쳐졌지만, 다른 테스트 케이스 2개가 실패했습니다.
"어떡하죠? 새로운 버그가 생긴 것 같아요." 박시니어 씨가 차분히 말했습니다.
"괜찮아요. 이럴 때를 위한 Self-Reflection 단계가 있습니다.
다시 분석하고 개선하면 됩니다."
Self-Reflection은 ReAct 패턴의 네 번째 단계로, 테스트 결과를 분석하고 수정 전략을 재평가하는 과정입니다. 마치 체스 선수가 한 수를 둔 후 상황을 재평가하고 다음 전략을 세우듯이, LLM은 관찰 결과를 바탕으로 수정이 충분했는지, 추가 조치가 필요한지 판단합니다.
다음 코드를 살펴봅시다.
# 테스트 결과를 분석하고 다음 행동 결정
def self_reflection_analyze(observation_results, reasoning_history):
# 분석 프롬프트 구성
prompt = f"""
이전 추론 과정:
{reasoning_history}
테스트 결과:
- 원래 에러 해결됨: {observation_results['original_error_fixed']}
- 새로운 에러: {observation_results['new_errors']}
- 테스트 통과율: {calculate_pass_rate(observation_results)}
현재 상황을 분석하고 다음 중 하나를 선택하세요:
1. SUCCESS: 모든 문제 해결됨
2. REFINE: 수정 방향은 맞으나 개선 필요
3. PIVOT: 완전히 다른 접근 필요
선택한 이유와 다음 단계 계획을 제시하세요.
"""
# LLM이 상황 분석
reflection = llm.generate(prompt)
# 다음 행동 결정
if reflection['decision'] == 'REFINE':
return reasoning_bug_cause(updated_context)
elif reflection['decision'] == 'PIVOT':
return reasoning_bug_cause(new_approach)
else:
return 'COMPLETE'
김개발 씨는 처음으로 만난 상황에 당황했습니다. 버그를 고쳤다고 생각했는데, 테스트 결과를 보니 새로운 문제가 생겼습니다.
"제가 뭘 잘못한 걸까요?" 박시니어 씨가 모니터를 가리키며 설명했습니다. "잘못한 게 아니에요.
복잡한 시스템에서는 이런 일이 흔합니다. 중요한 건 이 결과를 어떻게 해석하고 대응하느냐죠.
그게 바로 Self-Reflection입니다." Self-Reflection이란 정확히 무엇일까요? 쉽게 비유하자면, Self-Reflection은 마치 등산가가 중간 지점에서 지도를 다시 펼쳐보는 것과 같습니다.
"현재 여기까지 왔고, 계획했던 루트대로 잘 가고 있나? 아니면 다른 길을 찾아야 하나?" 자신의 진행 상황을 객관적으로 평가하고, 필요하다면 경로를 수정합니다.
디버깅도 마찬가지입니다. 한 번의 시도로 모든 문제가 해결되는 경우는 드뭅니다.
특히 복잡한 버그일수록 여러 번의 시행착오를 거칩니다. Self-Reflection은 각 시도의 결과를 분석하고, 다음 시도를 더 효과적으로 만들어줍니다.
전통적인 디버깅에서는 어떤 문제가 있었을까요? 많은 개발자들이 같은 실수를 반복했습니다.
테스트가 실패하면 "뭐가 문제지?" 하고 다시 코드를 보지만, 왜 실패했는지 체계적으로 분석하지 않았습니다. 그냥 "이번엔 이렇게 해볼까?" 하며 또 다른 시도를 했죠.
이런 방식은 비효율적입니다. 마치 어두운 방에서 손으로 더듬거리며 출구를 찾는 것과 같습니다.
운이 좋으면 찾을 수 있지만, 시간이 오래 걸리고 같은 곳을 여러 번 헤맬 수 있습니다. 더 큰 문제는 학습 기회를 놓친다는 것입니다.
왜 첫 번째 시도가 실패했는지 이해하지 못하면, 비슷한 상황에서 또 같은 실수를 합니다. 바로 이런 문제를 해결하기 위해 Self-Reflection이 중요합니다.
Self-Reflection을 통해 현재 상황을 정확히 파악할 수 있습니다. 원래 버그는 고쳐졌는가?
새로운 문제가 생겼는가? 테스트 통과율은 얼마인가?
객관적인 데이터를 바탕으로 판단합니다. 또한 다음 전략을 결정합니다.
수정 방향은 맞는데 세부 구현만 다듬으면 되는지(REFINE), 아니면 완전히 다른 접근이 필요한지(PIVOT) 판단합니다. 이렇게 하면 시행착오를 줄이고 효율적으로 문제를 해결할 수 있습니다.
무엇보다 학습 루프를 만들 수 있습니다. 각 시도의 결과를 기록하고 분석하면, 점점 더 나은 추론과 행동을 할 수 있게 됩니다.
위의 코드를 한 줄씩 살펴보겠습니다. 먼저 분석 프롬프트를 구성합니다.
여기서 핵심은 이전 추론 과정을 포함한다는 점입니다. "우리가 왜 이렇게 수정했었지?"를 기억하고 있어야, 결과를 제대로 해석할 수 있습니다.
테스트 결과도 구체적으로 제공합니다. 단순히 "실패했다"가 아니라, 무엇이 해결되고 무엇이 안 되었는지, 통과율은 얼마인지 정량적으로 전달합니다.
LLM에게 세 가지 선택지를 제시합니다. SUCCESS는 모든 문제가 해결되어 종료할 수 있는 상태입니다.
REFINE은 방향은 맞지만 미세 조정이 필요한 상태입니다. PIVOT은 완전히 다른 접근을 시도해야 하는 상태입니다.
LLM의 결정에 따라 다음 행동을 취합니다. REFINE이라면 같은 방향에서 개선된 추론을 시도하고, PIVOT이라면 완전히 새로운 가설을 세웁니다.
SUCCESS라면 디버깅을 완료합니다. 실제 현업에서는 어떻게 활용할까요?
예를 들어 대규모 웹 애플리케이션의 성능 문제를 디버깅한다고 가정해봅시다. 첫 번째 시도에서 "데이터베이스 쿼리 최적화"를 했습니다.
테스트 결과 응답 시간이 100ms에서 80ms로 개선되었지만, 목표인 50ms에는 도달하지 못했습니다. Self-Reflection 단계에서 LLM이 분석합니다.
"REFINE: 쿼리 최적화 방향은 맞지만 충분하지 않음. 인덱스 추가와 함께 캐싱 전략도 검토 필요." 이제 다음 시도에서는 캐싱까지 추가하여 목표 성능을 달성할 수 있습니다.
만약 Self-Reflection 없이 무작정 시도했다면, "왜 안 되지?" 하며 시간을 낭비했을 것입니다. 체계적인 분석 덕분에 효율적으로 문제를 해결할 수 있었습니다.
하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 무한 루프에 빠지는 것입니다.
REFINE과 PIVOT을 반복하다가 끝나지 않는 경우가 있습니다. 따라서 최대 시도 횟수를 정해두거나, 개선이 미미할 때는 멈추는 중단 조건을 설정해야 합니다.
또한 과도한 최적화를 경계해야 합니다. 99% 통과율에서 99.9%를 위해 며칠을 쏟는 것은 비효율적일 수 있습니다.
비즈니스 가치를 고려하여 적절한 타협점을 찾아야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.
Self-Reflection 결과를 본 김개발 씨는 이해했습니다. "아, null 체크는 잘했지만 빈 문자열 케이스를 놓쳤군요.
이것만 추가하면 되겠네요!" Self-Reflection을 제대로 활용하면 시행착오를 학습 기회로 바꿀 수 있습니다. 실패에서 배우고, 점점 더 나은 해결책을 찾아갈 수 있습니다.
여러분도 디버깅할 때 각 시도의 결과를 꼼꼼히 분석하는 습관을 들이세요.
실전 팁
💡 - 각 시도의 결과를 문서화하면 나중에 비슷한 문제를 만났을 때 참고할 수 있습니다
- 최대 시도 횟수를 정해두어 무한 루프를 방지하세요
- 개선율이 일정 수준 이하로 떨어지면 다른 접근을 고려하세요
5. 실습 자동 버그 수정 에이전트
김개발 씨는 ReAct 패턴의 각 단계를 이해했습니다. "이제 이걸 다 합쳐서 자동으로 버그를 고치는 시스템을 만들 수 있을 것 같아요!" 박시니어 씨가 미소를 지었습니다.
"바로 그겁니다. Reasoning, Acting, Observation, Self-Reflection을 순환시키면 자동 디버깅 에이전트가 되죠."
자동 버그 수정 에이전트는 ReAct 패턴의 모든 단계를 통합하여 버그를 스스로 찾고 고치는 시스템입니다. 에러가 발생하면 자동으로 원인을 추론하고, 수정안을 생성하고, 테스트하고, 결과를 반영하여 재시도하는 전체 사이클을 반복합니다.
마치 자율주행차가 스스로 길을 찾듯이, 코드가 스스로 버그를 고칩니다.
다음 코드를 살펴봅시다.
# 자동 버그 수정 에이전트
class AutoDebugAgent:
def __init__(self, llm_model, max_iterations=5):
self.llm = llm_model
self.max_iterations = max_iterations
self.history = []
def fix_bug(self, code, error_message, test_cases):
iteration = 0
current_code = code
while iteration < self.max_iterations:
# 1. Reasoning: 원인 추론
reasoning = self.reasoning(error_message, current_code)
# 2. Acting: 코드 수정
fixed_code, fix_desc = self.acting(reasoning, current_code)
# 3. Observation: 테스트 실행
results = self.observation(fixed_code, test_cases, error_message)
# 4. Self-Reflection: 결과 분석
decision = self.reflection(results, reasoning)
# 히스토리 기록
self.history.append({
'iteration': iteration,
'reasoning': reasoning,
'fix': fix_desc,
'results': results,
'decision': decision
})
if decision == 'SUCCESS':
return fixed_code, self.history
current_code = fixed_code
iteration += 1
return None, self.history # 실패
김개발 씨는 이제 각 단계를 모두 이해했습니다. Reasoning으로 원인을 추론하고, Acting으로 코드를 고치고, Observation으로 테스트하고, Self-Reflection으로 재평가하는 것이죠.
"근데 이걸 어떻게 합치나요?" 박시니어 씨가 화이트보드에 원을 그렸습니다. "이 네 단계를 순환시키는 겁니다.
마치 바퀴가 돌듯이, 계속 반복하면서 점점 더 나은 해결책을 찾아가죠." 자동 버그 수정 에이전트란 정확히 무엇일까요? 쉽게 비유하자면, 자동 버그 수정 에이전트는 마치 자가 치유 능력이 있는 생명체와 같습니다.
사람의 몸은 상처가 생기면 자동으로 치유됩니다. 백혈구가 감염을 막고, 새로운 세포가 자라나고, 자연스럽게 회복됩니다.
자동 버그 수정 에이전트도 코드에 문제가 생기면 스스로 진단하고 치료합니다. 전통적인 방식에서는 어땠을까요?
개발자가 직접 모든 과정을 수행해야 했습니다. 에러 로그를 보고, 원인을 찾고, 코드를 수정하고, 테스트하고, 실패하면 다시 처음부터 반복했습니다.
간단한 버그라면 괜찮지만, 복잡한 버그는 몇 시간, 심지어 며칠이 걸렸습니다. 특히 야간이나 주말에 버그가 발생하면 큰 문제였습니다.
온콜 개발자를 깨워야 하고, 졸린 눈으로 디버깅하다 보면 실수하기 쉬웠습니다. 서비스 다운타임이 길어질수록 손실도 커졌습니다.
바로 이런 문제를 해결하기 위해 자동 버그 수정 에이전트가 등장했습니다. 자동 에이전트를 사용하면 24시간 자동 모니터링이 가능합니다.
에러가 발생하면 즉시 감지하고, 사람의 개입 없이 자동으로 수정을 시도합니다. 간단한 버그는 몇 분 안에 자동으로 해결됩니다.
또한 일관성이 보장됩니다. 사람은 피곤하거나 스트레스 받으면 실수하지만, 에이전트는 항상 같은 품질로 작업합니다.
체계적인 프로세스를 빠짐없이 따릅니다. 무엇보다 개발자 시간을 절약할 수 있습니다.
반복적이고 단순한 버그 수정에 시간을 쓰는 대신, 더 창의적이고 중요한 작업에 집중할 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.
먼저 AutoDebugAgent 클래스를 정의합니다. max_iterations는 최대 시도 횟수로, 무한 루프를 방지합니다.
history는 각 시도의 기록을 저장하여 나중에 분석할 수 있게 합니다. fix_bug 메서드가 핵심입니다.
while 루프를 통해 ReAct 사이클을 반복합니다. 각 반복에서 네 단계를 순차적으로 실행합니다.
첫 번째로 reasoning 메서드를 호출하여 원인을 추론합니다. 두 번째로 acting 메서드로 코드를 수정합니다.
세 번째로 observation 메서드로 테스트합니다. 네 번째로 reflection 메서드로 결과를 분석합니다.
각 단계의 결과를 history에 기록합니다. 이렇게 하면 "왜 이런 결정을 내렸는지" 추적할 수 있습니다.
디버깅의 디버깅이 가능해지는 것이죠. 만약 reflection이 SUCCESS를 반환하면 수정된 코드와 히스토리를 반환하며 종료합니다.
그렇지 않으면 수정된 코드를 다음 반복의 입력으로 사용하고 계속 진행합니다. 최대 반복 횟수에 도달하면 실패로 간주하고 None을 반환합니다.
이때도 히스토리는 함께 반환하여 왜 실패했는지 분석할 수 있게 합니다. 실제 현업에서는 어떻게 활용할까요?
예를 들어 대규모 이커머스 플랫폼을 운영한다고 가정해봅시다. 블랙프라이데이 세일 중에 결제 시스템에서 간헐적으로 타임아웃 에러가 발생합니다.
자동 버그 수정 에이전트가 즉시 작동합니다. 첫 번째 반복에서 "데이터베이스 연결 풀 부족"으로 추론하고 풀 사이즈를 늘립니다.
테스트 결과 개선되었지만 완전히 해결되지 않았습니다. 두 번째 반복에서 "외부 API 응답 지연"을 추가로 발견하고 타임아웃을 조정합니다.
이번에는 모든 테스트를 통과합니다. 전체 과정이 10분 안에 자동으로 완료되어, 사용자는 불편을 거의 느끼지 못합니다.
만약 사람이 직접 했다면 최소 1시간 이상 걸렸을 것입니다. 에이전트 덕분에 매출 손실을 크게 줄일 수 있었습니다.
하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 에이전트를 맹신하는 것입니다.
자동 에이전트도 모든 버그를 고칠 수는 없습니다. 복잡한 아키텍처 문제나 비즈니스 로직 문제는 사람의 판단이 필요합니다.
따라서 에이전트가 실패했을 때는 사람이 개입할 수 있는 에스컬레이션 프로세스를 만들어야 합니다. 또한 보안을 고려해야 합니다.
에이전트가 자동으로 코드를 수정하므로, 악의적인 입력이나 잘못된 수정을 방지하는 안전장치가 필요합니다. 수정 전 코드 리뷰나 승인 단계를 추가할 수 있습니다.
다시 김개발 씨의 이야기로 돌아가 봅시다. 자동 에이전트를 구현한 김개발 씨는 감탄했습니다.
"와, 정말 스스로 버그를 고치네요!" 자동 버그 수정 에이전트를 제대로 구현하면 개발 생산성을 크게 높일 수 있습니다. 반복적인 작업은 자동화하고, 개발자는 더 가치 있는 일에 집중할 수 있습니다.
여러분도 작은 것부터 시작해서 점진적으로 자동화 범위를 넓혀보세요.
실전 팁
💡 - 처음에는 간단한 버그 타입부터 자동화하고, 점차 범위를 넓히세요
- 에이전트의 모든 행동을 로깅하여 감사 추적이 가능하게 하세요
- 중요한 코드는 자동 수정하지 않고 사람의 승인을 받도록 설정하세요
6. 실습 디버깅 과정 로깅 시스템
자동 에이전트가 버그를 고치는 것을 본 김개발 씨는 궁금해졌습니다. "근데 에이전트가 어떤 생각을 하며 이렇게 고쳤는지 알 수 있나요?" 박시니어 씨가 답했습니다.
"물론이죠! 디버깅 과정을 상세히 로깅하면 에이전트의 사고 과정을 추적할 수 있습니다.
이게 매우 중요합니다."
디버깅 과정 로깅 시스템은 ReAct 에이전트의 모든 추론과 행동을 기록하여 투명성을 확보하는 시스템입니다. 마치 비행기의 블랙박스처럼, 에이전트가 어떤 판단을 내렸고 왜 그런 결정을 했는지 모든 과정을 기록합니다.
이를 통해 에이전트의 행동을 감사하고, 실패 원인을 분석하고, 지속적으로 개선할 수 있습니다.
다음 코드를 살펴봅시다.
# 디버깅 과정 로깅 시스템
import json
from datetime import datetime
class DebugLogger:
def __init__(self, log_file='debug_sessions.jsonl'):
self.log_file = log_file
self.session_id = None
def start_session(self, code, error, context):
self.session_id = f"debug_{datetime.now().strftime('%Y%m%d_%H%M%S')}"
session_start = {
'session_id': self.session_id,
'timestamp': datetime.now().isoformat(),
'event': 'session_start',
'initial_code': code,
'error': error,
'context': context
}
self._write_log(session_start)
return self.session_id
def log_reasoning(self, iteration, reasoning_result):
log_entry = {
'session_id': self.session_id,
'timestamp': datetime.now().isoformat(),
'event': 'reasoning',
'iteration': iteration,
'hypotheses': reasoning_result['possibilities'],
'selected_cause': reasoning_result['possibilities'][0]
}
self._write_log(log_entry)
def log_action(self, iteration, action_desc, code_diff):
log_entry = {
'session_id': self.session_id,
'timestamp': datetime.now().isoformat(),
'event': 'action',
'iteration': iteration,
'description': action_desc,
'code_diff': code_diff
}
self._write_log(log_entry)
def log_observation(self, iteration, test_results):
log_entry = {
'session_id': self.session_id,
'timestamp': datetime.now().isoformat(),
'event': 'observation',
'iteration': iteration,
'test_results': test_results,
'pass_rate': self._calculate_pass_rate(test_results)
}
self._write_log(log_entry)
def log_reflection(self, iteration, decision, reasoning):
log_entry = {
'session_id': self.session_id,
'timestamp': datetime.now().isoformat(),
'event': 'reflection',
'iteration': iteration,
'decision': decision,
'reasoning': reasoning
}
self._write_log(log_entry)
def end_session(self, success, final_code=None):
session_end = {
'session_id': self.session_id,
'timestamp': datetime.now().isoformat(),
'event': 'session_end',
'success': success,
'final_code': final_code
}
self._write_log(session_end)
def _write_log(self, entry):
with open(self.log_file, 'a') as f:
f.write(json.dumps(entry, ensure_ascii=False) + '\n')
def _calculate_pass_rate(self, results):
total = len(results['test_results'])
passed = sum(1 for t in results['test_results'] if t['passed'])
return passed / total if total > 0 else 0
김개발 씨는 자동 에이전트가 버그를 성공적으로 고치는 것을 보고 기뻤습니다. 하지만 동시에 불안하기도 했습니다.
"이 에이전트가 정말 안전하게 작동하는 걸까? 혹시 이상한 수정을 하면 어떡하지?" 박시니어 씨가 고개를 끄덕였습니다.
"좋은 질문이에요. 자동화는 편리하지만, 투명성이 없으면 위험합니다.
그래서 모든 과정을 상세히 로깅해야 해요." 디버깅 과정 로깅 시스템이란 정확히 무엇일까요? 쉽게 비유하자면, 로깅 시스템은 마치 항해 일지와 같습니다.
배가 항해할 때 선장은 매일 일지를 씁니다. 어디로 갔는지, 날씨는 어땠는지, 무슨 일이 있었는지 기록합니다.
나중에 문제가 생기면 일지를 보고 원인을 찾을 수 있습니다. 자동 디버깅 에이전트도 마찬가지입니다.
어떤 추론을 했는지, 왜 그런 결정을 내렸는지, 어떤 코드를 수정했는지 모두 기록합니다. 이 기록이 있어야 에이전트의 행동을 신뢰할 수 있습니다.
로깅이 없다면 어떤 문제가 생길까요? 에이전트가 코드를 수정했는데 나중에 버그가 발생했다고 가정해봅시다.
로깅이 없다면 "도대체 뭘 바꾼 거지?" 알 수가 없습니다. 마치 블랙박스처럼 입력과 출력만 보이고, 중간 과정은 모릅니다.
더 큰 문제는 신뢰 문제입니다. 팀원들이나 관리자가 "자동으로 코드가 수정된다고?
정말 안전한가?"라고 의심합니다. 아무리 좋은 기술이라도 신뢰받지 못하면 사용되지 않습니다.
또한 개선 기회를 놓칩니다. 에이전트가 왜 실패했는지 알 수 없으면, 같은 실수를 계속 반복합니다.
학습할 수 없습니다. 바로 이런 문제를 해결하기 위해 상세한 로깅이 필수적입니다.
로깅 시스템을 통해 완전한 투명성을 확보할 수 있습니다. 에이전트의 모든 생각과 행동이 기록되므로, 언제든 검토할 수 있습니다.
"왜 이렇게 했지?"라는 질문에 명확히 답할 수 있습니다. 또한 감사 추적이 가능합니다.
규제가 엄격한 금융이나 의료 분야에서는 모든 코드 변경을 추적해야 합니다. 로깅을 통해 컴플라이언스를 만족할 수 있습니다.
무엇보다 지속적 개선이 가능합니다. 로그를 분석하여 에이전트의 성공 패턴과 실패 패턴을 파악할 수 있습니다.
이를 바탕으로 프롬프트를 개선하고, 더 나은 에이전트를 만들 수 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.
DebugLogger 클래스는 JSONL 형식으로 로그를 저장합니다. JSONL은 각 줄이 독립적인 JSON 객체인 형식으로, 대용량 로그 처리에 적합합니다.
start_session 메서드는 디버깅 세션을 시작할 때 호출됩니다. 고유한 세션 ID를 생성하여 나중에 이 세션의 모든 이벤트를 추적할 수 있게 합니다.
초기 코드, 에러, 컨텍스트를 모두 기록합니다. 각 단계마다 전용 로깅 메서드가 있습니다.
log_reasoning은 추론 과정을, log_action은 수정 행동을, log_observation은 테스트 결과를, log_reflection은 반성 과정을 기록합니다. 모든 로그 엔트리에는 타임스탬프가 포함됩니다.
이를 통해 시간 순서대로 이벤트를 재구성할 수 있습니다. "3번째 반복에서 왜 갑자기 다른 접근을 시도했지?" 같은 질문에 답할 수 있습니다.
end_session 메서드는 세션을 종료하며 성공 여부와 최종 코드를 기록합니다. 이제 전체 디버깅 스토리가 완성됩니다.
실제 현업에서는 어떻게 활용할까요? 예를 들어 SaaS 제품을 운영하는 스타트업이라고 가정해봅시다.
자동 디버깅 에이전트가 한 달 동안 100개의 버그를 수정했습니다. 이 중 95개는 성공했고 5개는 실패했습니다.
로그를 분석하면 흥미로운 패턴을 발견할 수 있습니다. 성공한 케이스는 평균 2.3번의 반복으로 해결되었고, null 체크 관련 버그의 성공률이 98%였습니다.
반면 동시성 문제는 성공률이 60%에 불과했습니다. 이 인사이트를 바탕으로 전략을 조정할 수 있습니다.
간단한 버그는 완전 자동화하고, 복잡한 동시성 문제는 사람에게 에스컬레이션하도록 설정합니다. 또한 동시성 문제를 더 잘 처리할 수 있도록 에이전트의 프롬프트를 개선합니다.
많은 기업에서 이런 로그를 대시보드로 시각화하여 실시간으로 모니터링합니다. 에이전트의 성능 지표를 추적하고, 이상 징후를 빠르게 감지합니다.
하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 많이 로깅하는 것입니다.
모든 변수값, 모든 중간 계산을 로깅하면 로그 파일이 너무 커져서 오히려 분석이 어려워집니다. 핵심 결정 포인트만 로깅하는 게 중요합니다.
또한 민감 정보 보호에 신경 써야 합니다. 로그에 사용자 비밀번호나 개인정보가 포함되지 않도록 필터링해야 합니다.
GDPR 같은 개인정보 보호 규정을 준수해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.
로깅 시스템을 구현한 김개발 씨는 안심했습니다. "이제 에이전트가 뭘 하는지 다 볼 수 있네요.
훨씬 안심이 돼요!" 디버깅 과정 로깅 시스템을 제대로 구축하면 자동화와 통제를 동시에 달성할 수 있습니다. 에이전트에게 자율성을 주되, 모든 행동을 추적하여 책임성을 확보하는 것입니다.
여러분도 자동화 시스템을 만들 때 반드시 로깅을 함께 고려하세요.
실전 팁
💡 - 로그는 구조화된 형식(JSON, JSONL)으로 저장하여 나중에 프로그램으로 분석하기 쉽게 만드세요
- 타임스탬프와 세션 ID를 반드시 포함하여 이벤트를 추적할 수 있게 하세요
- 로그 레벨(DEBUG, INFO, WARNING, ERROR)을 활용하여 중요도에 따라 필터링할 수 있게 하세요
이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!
댓글 (0)
함께 보면 좋은 카드 뉴스
ReAct 패턴 마스터 완벽 가이드
LLM이 생각하고 행동하는 ReAct 패턴을 처음부터 끝까지 배웁니다. Thought-Action-Observation 루프로 똑똑한 에이전트를 만들고, 실전 예제로 웹 검색과 계산을 결합한 강력한 AI 시스템을 구축합니다.
AI 에이전트의 모든 것 - 개념부터 실습까지
AI 에이전트란 무엇일까요? 단순한 LLM 호출과 어떻게 다를까요? 초급 개발자를 위해 에이전트의 핵심 개념부터 실제 구현까지 이북처럼 술술 읽히는 스타일로 설명합니다.
프로덕션 RAG 시스템 완벽 가이드
검색 증강 생성(RAG) 시스템을 실제 서비스로 배포하기 위한 확장성, 비용 최적화, 모니터링 전략을 다룹니다. AWS/GCP 배포 실습과 대시보드 구축까지 프로덕션 환경의 모든 것을 담았습니다.
RAG 캐싱 전략 완벽 가이드
RAG 시스템의 성능을 획기적으로 개선하는 캐싱 전략을 배웁니다. 쿼리 캐싱부터 임베딩 캐싱, Redis 통합까지 실무에서 바로 적용할 수 있는 최적화 기법을 다룹니다.
실시간으로 답변하는 RAG 시스템 만들기
사용자가 질문하면 즉시 답변이 스트리밍되는 RAG 시스템을 구축하는 방법을 배웁니다. 실시간 응답 생성부터 청크별 스트리밍, 사용자 경험 최적화까지 실무에서 바로 적용할 수 있는 완전한 가이드입니다.