← 최신 논문
💻 computer science

Loosely-Structured Software: Engineering Context, Structure, and Evolution Entropy in Runtime-Rewired Multi-Agent Systems

이 논문은 LLM 기반 다중 에이전트 시스템의 복잡성과 엔트로피를 관리하기 위해 기존 소프트웨어 공학 원리를 확장하여 '경 loosely-구조화 소프트웨어 (LSS)'라는 새로운 패러다임과 3 층 엔지니어링 프레임워크를 제안하고, 이를 통해 에이전트 인프라의 설계성, 확장성, 진화성을 향상시키는 방법을 제시합니다.

원저자: Weihao Zhang, Yitong Zhou, Huanyu Qu, Hongyi Li

게시일 2026-03-18
📖 4 분 읽기☕ 가벼운 읽기

원저자: Weihao Zhang, Yitong Zhou, Huanyu Qu, Hongyi Li

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

이 논문은 **"LLM(거대 언어 모델) 기반의 여러 AI 에이전트들이 함께 일할 때, 어떻게 하면 혼란을 줄이고 잘 작동하게 할 수 있을까?"**라는 질문에 대한 해답을 제시합니다.

기존의 소프트웨어는 마치 정해진 레시피대로 요리하는 요리사처럼, 처음에 모든 과정을 정해두면 그대로 실행됩니다. 하지만 이 논문이 다루는 '에이전트 시스템'은 즉흥적인 재즈 밴드와 같습니다. 음악가들이 서로의 리듬에 맞춰 즉흥적으로 연주하듯, AI 들도 실시간으로 상황을 보고 서로 대화하며 일을 처리합니다. 문제는 밴드가 커질수록 (에이전트 수가 늘어날수록) 소음이 심해지고, 누가 무엇을 해야 할지 모호해져서 전체적인 음악이 엉망이 된다는 점입니다.

이 논문은 이런 **' Loose-Structured Software (약하게 구조화된 소프트웨어, LSS)'**를 어떻게 다스릴지 3 가지 핵심 원리로 설명합니다.


1. 핵심 개념: "정해진 레시피"가 아닌 "현장 상황"에 따른 요리

전통적인 소프트웨어는 **레시피 (코드)**가 먼저 있고, 그걸 따라 **요리 (실행)**가 일어납니다.
하지만 LSS 는 **상황 (Context)**이 먼저입니다.

  • 비유: 전통적인 소프트웨어는 "오늘 메뉴는 김치찌개다. 재료는 미리 다 준비해라"라고 정해두는 겁니다.
  • LSS 의 방식: "오늘 손님이 뭐가 먹고 싶어?"라고 물어보고, 그 답변에 따라 그 순간 필요한 재료 (정보) 만 가져와서 요리를 합니다. 만약 손님이 "매운 거 싫어"라고 하면, 그 순간 매운 재료는 제외하고 새로운 레시피를 즉석에서 만듭니다.

이런 방식은 유연하지만, 정보가 너무 많거나 (소음), 정보가 부족하면 (실패) 시스템이 망가질 수 있습니다. 이를 해결하기 위해 3 층짜리 관리 시스템을 제안합니다.


2. 3 층 관리 시스템 (Entropy, 즉 '혼란'을 다스리는 법)

저자는 AI 들이 만들어내는 혼란 (엔트로피) 을 3 가지 층위로 나누어 관리해야 한다고 말합니다.

1 층: 시야 관리 (View/Context Engineering) - "눈가리개와 돋보기"

  • 문제: AI 에이전트에게 모든 정보 (수천 개의 문서, 대화 기록) 를 다 보여주면, AI 는 무엇을 봐야 할지 몰라 멍해집니다 (주목력 분산).
  • 해결책: 시야 (View) 를 조절합니다.
    • 비유: 마치 현장 지휘관이 있습니다. 지휘관은 "지금 필요한 건 A 라는 자료야"라고 돋보기로만 필요한 부분만 보여줍니다. 나머지 불필요한 정보는 눈가리개로 가립니다.
    • 원리: 에이전트가 일을 할 때, 그 순간에 딱 필요한 정보만 골라내어 (Progressive Disclosure) 보여줍니다. 정보가 너무 많으면 요약하고, 너무 적으면 추가해줍니다.

2 층: 구조 관리 (Structure Engineering) - "팀 구성과 연결 고리"

  • 문제: 에이전트들이 서로 누구와 말을 해야 할지, 어떤 도구를 써야 할지 매번 헷갈려서 엉뚱한 사람과 대화하거나, 너무 많은 사람과 대화하며 비효율적입니다.
  • 해결책: **동적인 연결 (Binding)**을 관리합니다.
    • 비유: 프로젝트 매니저가 있습니다. 매니저는 "이 일은 A 팀이, 저 일은 B 팀이 하라"고 팀을 즉석에서 구성합니다.
    • 원리:
      • Semantic Router (의미 라우터): "이 질문은 누구에게 가야 해?"라고 물어보면, 가장 적합한 에이전트에게 연결해줍니다.
      • Team Generator (팀 생성기): 복잡한 일이 생기면, 역할 (기획자, 실행자, 검토자) 을 정해 팀을 꾸려줍니다.
      • Inheritance (상속): 한 에이전트가 일을 잘해냈다면, 그 경험을 바탕으로 새로운 에이전트를 만들어 "너는 이 경험을 바탕으로 일해"라고 넘겨줍니다.

3 층: 진화 관리 (Evolution Engineering) - "학습과 수정"

  • 문제: 시간이 지나면 시스템이 스스로 수정을 하다 보니, 과거의 좋은 습관이 사라지거나 (지식 부패), 엉뚱한 방향으로 변질될 수 있습니다.
  • 해결책: 시스템이 스스로를 고치는 과정을 통제합니다.
    • 비유: 연구실의 실험실입니다. 새로운 아이디어를 시도할 때, 바로 전체 시스템을 바꾸지 않고 **모의 실험실 (Sandbox)**에서 먼저 테스트해봅니다.
    • 원리:
      • Sandbox Mode (샌드박스 모드): 새로운 규칙을 적용하기 전에, 가상의 공간에서 "이게 잘 작동할까?" 테스트해봅니다. 실패하면 원래대로 돌립니다.
      • Evolver (진화자): 어떤 일이 잘되었는지, 안 되었는지 분석해서 시스템의 '지식 파일'을 업데이트합니다.
      • Semantic Palimpsest (의미 중첩 문서): 단순히 파일 내용을 덮어쓰는 게 아니라, "왜 이렇게 바꿨는지"에 대한 기록까지 남깁니다. 나중에 "아, 그때 왜 그랬는지 알겠다"라고 이해할 수 있게요.

3. 왜 이것이 중요한가? (결론)

이 논문은 **"AI 가 더 똑똑해지면, 우리가 코딩할 필요가 없어진다"**는 말은 틀렸다고 말합니다. 오히려 AI 가 스스로 움직일수록, 그 움직임을 통제하고 관리하는 '시스템 엔지니어링'이 더 중요해집니다.

  • 기존 방식: 정해진 규칙대로 움직이는 로봇을 조립합니다.
  • 이 논문 제안: 유연하게 움직이는 재즈 밴드를 지휘하는 방법을 설계합니다.

핵심 메시지:
AI 에이전트들이 자유롭게 떠들고 움직이는 것은 좋지만, 그 자유로움이 **혼란 (Entropy)**으로 변하지 않도록 시야를 조절하고 (1 층), 팀을 짜주고 (2 층), 스스로 배우되 망가지지 않게 통제하는 (3 층) 새로운 소프트웨어 공학이 필요합니다.

이 방식은 AI 가 스스로 코드를 쓰고, 스스로 팀을 꾸리고, 스스로 발전하는 미래의 소프트웨어를 설계하는 데 필요한 청사진을 제시합니다.

연구 분야의 논문에 파묻히고 계신가요?

연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.

Digest 사용해 보기 →