개발·보안 분야에서 적용된 LLM Agent 설계 방법론은 범용 문제 해결에도 효율적일까?# 1. TL;DR --- > 개발·보안 분야에서 적용된 LLM Agent 설계 방법론은 범용 문제 해결에도 효율적일까? 본 글에서는 저자가 **직접 설계하고 사용했던 도구를 오픈소스로 공개**하며 LLM Agent 설계 시 고려했던 부분과 Challenge, 더 나아가 어떻게 해결했는 지를 가감없이 공유합니다. 원본 글의 양이 많은 관계로 이 글에서 모두 담아내지 못했습니다. 본 글은 요약본 형태로 간략하게 설명하며 더 자세한 내용은 [시리즈1](https://cr0nu3.github.io/posts/kor_how_a_cybersecurity_researcher_prepared_for_the_kakao_ai_top_100/), [시리즈2](https://cr0nu3.github.io/posts/kor_how_a_cybersecurity_researcher_prepared_for_the_kakao_ai_top_100_2/)를 참고해주세요. # 2. Introduction --- 안녕하세요. cr0nu3(Cronus)입니다. 저는 평소 LLM 기반 취약점 분석 자동화 도구를 만드는 데 관심이 많았습니다. 그 과정에서 자연스럽게 한 가지 질문을 갖게 되었습니다. > 개발·보안 분야에서 적용된 LLM Agent 설계 방법론은 범용 문제 해결에도 효율적일까? 이 질문을 검증해볼 수 있는 환경이 [Kakao AI Top 100 대회](https://aitop100.org/)였습니다. Kakao Impact에서 주관한 이 대회는 특정 도메인의 지식만을 평가하는 대회가 아니라, 다양한 도메인의 문제를 제한된 시간 안에 해결하는 능력을 요구합니다. 제가 주로 다뤄온 영역은 코드 분석, 취약점 탐지, 보안 자동화처럼 입력과 목표가 비교적 명확한 문제들이었습니다. 반면 Kakao AI Top 100의 문제들은 훨씬 넓은 도메인을 포함하고 있었습니다. (실제 문제는 [여기](https://challenge.aitop100.org/)에서 확인할 수 있습니다.) 따라서 이 대회는 제가 연구하던 LLM Agent 설계 방법론을 범용 문제 해결 환경에서 검증해볼 수 있는 좋은 테스트베드였습니다. 저는 이 가설을 확인하기 위해 새로운 LLM Agent 시스템을 설계하고 대회에 참가했습니다. # **3. Why Single LLM Was Not Enough** --- 처음부터 시스템을 만들려고 했던 것은 아닙니다. 초기에는 Claude, GPT, Gemini와 같은 단일 LLM이나 기존 LLM 기반 도구들을 활용해 문제를 해결할 수 있을 것이라 생각했습니다. 모델 성능 자체가 이미 충분히 좋아졌고, 대회 문제 역시 결국 “문제를 이해하고 답을 찾는 과정”으로 볼 수 있었기 때문입니다. 하지만 실제 문제를 풀어보면 단일 LLM 접근에는 몇 가지 한계가 반복적으로 드러났습니다. 가장 먼저 보였던 문제는 **그럴듯한 오답(할루시네이션**)이었습니다. LLM은 문제를 완전히 이해하지 못했거나 근거가 부족한 상황에서도 자연스러운 형태의 답변을 만들어냅니다. 겉으로 보기에는 논리적인 풀이처럼 보이지만, 실제로는 문제 조건을 일부 누락하거나, 첨부파일의 특정 내용을 잘못 해석하거나, 계산 결과를 검증하지 않은 채 결론을 내리는 경우가 있었습니다. 두 번째는 **긴 Context에서 발생하는 정보 손실**입니다. Kakao AI Top 100의 문제들은 단순 텍스트 질의만으로 구성되어 있지 않았습니다. 문제들은 LLM이 한번에 다룰 수 없는 방대한 데이터 양을 제공해줍니다.. 이런 정보를 한 번에 LLM에게 넣으면 모델이 초반이나 중간에 등장한 중요한 조건을 놓치는 경우가 발생했습니다. 흔히 말하는 [Context Rot](https://cr0nu3.github.io/posts/kor_how_a_cybersecurity_researcher_prepared_for_the_kakao_ai_top_100_2/#51-%EB%8B%A8%EC%9D%BC-llm%EC%9D%98-%ED%95%9C%EA%B3%84)이나 [Lost in the Middle 문제](https://cr0nu3.github.io/posts/kor_how_a_cybersecurity_researcher_prepared_for_the_kakao_ai_top_100_2/#51-%EB%8B%A8%EC%9D%BC-llm%EC%9D%98-%ED%95%9C%EA%B3%84)가 실제 문제 풀이 과정에서도 관찰되었습니다. 세 번째는 **자기가 낸 답변을 비판적으로 검증하지 못하는 문제**였습니다. LLM에게 “네 답을 다시 검토해봐”라고 지시하더라도, 이미 자신이 생성한 답을 정당화하는 방향으로 흐르는 경우가 많았습니다. 즉, 답을 생성한 모델과 답을 평가하는 모델이 동일할 때 Self-Evaluation Bias가 발생할 수 있었습니다. 이는 단순히 “검토해줘”라는 프롬프트만으로는 해결하기 어려운 문제였습니다. 네 번째는 **비용과 시간의 증가**였습니다. 복잡한 문제를 풀기 위해 단일 LLM에게 반복적으로 질문하면, 어느 순간부터 비용과 시간이 빠르게 증가합니다. 특히 긴 Context를 계속 유지한 채 여러 번 재질의하면 토큰 사용량이 커지고, 문제 하나를 해결하는 데 필요한 시간이 길어집니다. 대회처럼 제한된 시간 안에 여러 문제를 처리해야 하는 환경에서는 치명적인 제약이었습니다. 정리하면, 단일 LLM은 준수한 문제 해결 능력을 가지고 있지만 다음과 같은 상황에서는 안정성이 떨어졌습니다. - \- 문제 조건이 많고 복잡한 경우 - \- 첨부파일이나 외부 자료를 함께 해석해야 하는 경우 - \- 코드 실행, 계산, 데이터 검증이 필요한 경우 - \- 답안의 근거를 명확히 추적해야 하는 경우 - \- 제한된 시간과 비용 안에서 효율적이고 정확하게 문제를 처리해야 하는 경우 이 시점에서 제가 깨달은 문제는 “어떤 모델을 사용할 것인가”가 아니라, **LLM을 어떤 구조 안에서 사용할 것인가**로 바뀌었습니다. ## 4. Architecture over Prompting --- 단일 LLM의 한계를 관찰하면서 얻은 결론은 명확했습니다. 좋은 프롬프트만으로는 충분하지 않았습니다. 물론 프롬프트는 중요합니다. 사용자가 원하는 것을 잘 설명하고, 역할을 명확히 부여하며, 답변 형식을 제한하는 것만으로도 성능은 개선될 수 있습니다. 하지만 복잡한 문제에서는 프롬프트만으로 해결하기 어려운 영역이 존재했습니다. 예를 들어 LLM이 중요한 조건을 놓쳤다면, 단순히 “꼼꼼히 읽어라”라고 지시하는 것만으로는 충분하지 않습니다. 코드 실행이 필요한 문제에서 실제 실행 없이 답을 추론했다면, “검증해라”라는 문장만으로 실행 결과를 보장할 수 없습니다. 자기 답변을 과신하는 문제가 있다면, 같은 모델에게 다시 평가를 맡기는 방식도 한계가 있습니다. 따라서 저는 문제 풀이 과정을 하나의 시스템으로 설계해야 한다고 판단했습니다. 그 핵심 아이디어는 다음과 같습니다. > LLM이 틀리지 않기를 기대하는 것이 아니라, LLM이 틀릴 수 있다는 전제 위에서 실패를 감지하고 수정하는 구조를 만든다. 이 관점은 제가 기존에 관심을 가지고 있던 보안 자동화와도 연결됩니다. 취약점 분석이나 코드 분석 자동화에서도 단순히 모델에게 “취약점을 찾아줘”라고 묻는 것만으로는 충분하지 않습니다. 입력을 수집하고, 분석 가능한 형태로 정리하고, 필요한 도구를 실행하고, 결과를 검증하고, 실패한 경우 다시 시도하는 구조가 필요합니다. 범용 문제 해결도 크게 다르지 않다고 보았습니다. ``` 문제 이해 → 입력 수집 → 정보 정리 → 풀이 생성 → 실행 또는 계산 → 근거 검증 → 피드백 → 재시도 ``` 즉, LLM Agent 설계에서 중요한 것은 모델 하나의 추론 능력만이 아닙니다. 어떤 정보를 어떤 단계에서 제공할지, 어떤 근거를 남길지, 누가 답을 생성하고 누가 검증할지, 언제 멈추고 언제 다시 시도할지를 결정하는 구조가 중요합니다. 다르게 말하면, 도메인이 달라져도 문제를 해결하기 위한 근본적인 방법론은 크게 달라지지 않습니다. 입력을 수집하고, 분석 가능한 형태로 정리하고, 실행 가능한 방식으로 검증하고, 실패를 피드백으로 반영하는 흐름은 보안·개발 문제뿐만 아니라 범용 문제 해결에서도 동일하게 적용될 수 있습니다. 이 관점에서 제가 세운 가설은 다음과 같습니다. > **Architecture over Prompting** ## **5. KAKAO Roastery Orchestra** --- 이러한 문제의식에서 만든 시스템이 [**KAKAO Roastery Orchestra**](https://github.com/Cr0nu3/kakao_roastery_orchestra)입니다. 이름에서 알 수 있듯이, 이 시스템은 하나의 LLM이 모든 일을 처리하는 구조가 아니라 여러 역할이 분리되어 함께 동작하는 구조를 지향했습니다. 복잡한 문제를 수집하고, 정리하고, 풀이를 생성하고, 검증하고, 필요하면 다시 시도하는 과정을 하나의 파이프라인으로 구성했습니다. ### [참고: Workflow 사진](https://cr0nu3.github.io/posts/kor_how_a_cybersecurity_researcher_prepared_for_the_kakao_ai_top_100_2/#33-high-level-workflow) (사진 첨부가 안되는 관계로 하이퍼링크로 남기겠습니다. 아래 컴포넌트 설명 때 참고하면 쉽게 이해되실 겁니다.) 전체 시스템은 크게 아래 컴포넌트로 나눌 수 있습니다. ### \[ Orchestrator \] Orchestrator는 전체 실행 흐름을 관리합니다. 어떤 문제를 어떤 방식으로 처리할지 결정하고, Generator와 Evaluator를 어떤 순서로 실행할지 제어합니다. 사용자의 요청에 따라 단순 추론이 필요한 경우도 있고, 코드 실행이나 계산이 필요한 경우도 있으며, 문서나 표에서 근거를 찾아야 하는 경우도 있습니다. 단일 LLM 방식에서는 모델에게 입력을 넣고 답을 받는 것으로 끝납니다. 반면 KAKAO Roastery Orchestra에서는 한 번의 답변으로 끝내지 않고, 답안 생성과 검증을 여러 단계로 나눕니다. ### \[ Generator \] Generator는 실제 문제를 풀고 후보 답안을 생성하는 역할을 합니다. 문제 유형에 따라 필요한 작업은 달라질 수 있습니다. 사용자 요청에 따라 어느 때는 문서를 요약해야 하고, 어떤 문제는 코드를 실행해야 하며, 어떤 문제는 수식 계산이나 조건 검증이 필요할 수 있습니다. 또 어떤 문제는 여러 파일을 비교하거나, 서로 다른 자료에서 근거를 종합해야 할 수도 있습니다. Generator는 문제를 분석하고, 필요한 근거를 수집한 뒤, 제출 가능한 형태의 후보 답안을 만듭니다. 중요한 점은 Generator의 답안을 그대로 신뢰하지 않는다는 것입니다. Generator는 어디까지나 “최종 답변”이 아니라 “검증 대상이 되는 후보 답변”을 만드는 역할입니다. ### **\[ Evaluator \]** Evaluator는 Generator가 만든 후보 답안을 검증하는 역할을 합니다. Evaluator는 단순히 답변이 그럴듯한지 확인하지 않습니다. 문제에서 요구한 조건을 충족했는지, 근거가 충분한지, 계산이나 코드 실행 결과가 실제 답안을 지지하는지 확인합니다. Generator와 다른 관점에서 문제를 다시 읽고, 누락된 조건이나 논리적 비약을 찾습니다. 이 구조를 통해 Generator의 Self-Evaluation Bias를 줄이고자 했습니다. 답을 만든 주체와 답을 검증하는 주체를 분리함으로써, 같은 모델이 자신의 답을 정당화하는 문제를 완화하려 했습니다. ### **\[ Feedback Filter \]** Feedback Filter는 Evaluator의 검증 결과를 바탕으로 다음 행동을 결정합니다. 검증 결과가 충분히 신뢰할 만하면 답안을 확정합니다. 반대로 조건이 누락되었거나, 근거가 부족하거나, 계산 결과가 맞지 않는다면 다음 라운드로 넘겨 Generator가 피드백을 반영하도록 합니다. 즉, Feedback Filter는 시스템이 무한히 반복하지 않도록 제어하는 장치입니다. 정확도를 높이는 것도 중요하지만, 실제 문제 해결 환경에서는 시간과 비용도 함께 관리해야 하기 때문입니다. KAKAO Roastery Orchestra의 목적은 LLM이 항상 한 번에 정답을 만들도록 하는 것이 아닙니다. 오히려 LLM이 틀릴 수 있다는 전제 위에서, 그 오류를 감지하고 수정하며 최종적으로 더 신뢰할 수 있는 답안을 선택하는 구조를 만드는 것입니다. 위 Workflow와 컴포넌트 별로 의미있는 역할 부여를 통해 Single LLM의 고질적인 문제를 해결하는 시스템을 구축하였습니다. (더 자세한 내용은 [포스팅 글](https://cr0nu3.github.io/posts/kor_how_a_cybersecurity_researcher_prepared_for_the_kakao_ai_top_100_2/#33-high-level-workflow)을 참고해주세요) ## 6. 그래서 무엇을 해결했나? --- | **문제이름** | 배점 | **순수 LLM 획득 점수(A)** | **제작된 시스템 획득 점수(B)** | **향상도 (B-A)** | **시스템 문제 풀이 소요 시간** | | --- | --- | --- | --- | --- | --- | | 2026 수능, 그날의 대화 | 55 | 20 | 55 | +35 | 54분 | | 프리라이더를 찾아라 | 75 | 35 | 45 | +10 | 45분 | | 웹사이트 버그 찾기 | 60 | 50 | 60 | +10 | 51분 | | 인수인계 자료 작성 | 75 | 45 | 53 | +8 | 47분 | | 뉴스 속 혁신가를 발굴하라 | 80 | 20 | 60 | +40 | 64분 | | **총점** | 345 | 170 | 273 | \- | \- | | **점수 획득률** | \- | 약 49% | 약 80% | \- | \- | 보안 연구에서 취약점 자동 분석 도구를 설계하듯, 문제 분류부터 근거 기반의 역방향 검증, 그리고 모델 간의 상호 피드백 루프를 구축함으로써 단일 LLM 대비 약 31%의 성능 향상(80%의 정답률)이라는 유의미한 결과를 얻을 수 있었습니다. 이를 통해 KAKAO Roastery Orchestra가 정확도와 자동화 효율 측면에서 기존 단일 LLM 접근보다 안정적인 성능을 보인다는 것을 확인했습니다. ## 7. 결론 --- 처음 가졌던 질문인 **"개발·보안 분야의 방법론이 범용 문제에도 통할까?**"에 대한 답은 "그렇다"였습니다. 도메인이 달라져도 신뢰할 수 있는 시스템을 만드는 본질은 변하지 않습니다. 정보를 정규화하고, 실행 가능한 근거를 확보하며, 비판적인 시각에서 결과를 검증하는 과정은 AI 에이전트가 더 복잡하고 범용적인 작업을 수행하기 위해 반드시 거쳐야 할 관문임을 확인했습니다. 사이버보안 연구에서 취약점을 “찾는 것”만큼 중요한 것은 “재현 및 검증 가능한 방식으로 문제를 분석하는 것”이라 생각합니다. 저는 LLM Agent를 설계할 때도 이러한 관점이 유용하다고 생각합니다. 더 많은 토큰을 사용해 오래 추론하는 방식만으로는 부족할 수 있으며, 효율적인 시스템 설계와 신뢰할 수 있는 근거를 함께 갖춘 구조가 더 안정적인 결과로 이어질 수 있습니다. 결국 이번 실험에서 확인한 것은 단순한 점수 향상이 아닙니다. 보안·개발 영역에서 사용하던 문제 해결 방법론이, 도메인이 다른 범용 문제에서도 재사용 가능한 구조가 될 수 있다는 가능성이었습니다.