처음 만드는 AI Agent 구현하기: “말만 하는 챗봇”에서 “일을 하는 에이전트”로

개발하다 보면 이런 순간이 옵니다. “질문에 답은 잘하는데… 왜 자동으로 일을 못 하지?”

AI Agent란 무엇인가

AI Agent를 한 문장으로 줄이면 LLM(모델) + 상태(state) + 도구(tools) + 루프(loop)입니다.

✅ 핵심 특징 🔹 대화가 아니라 목표 중심으로 동작 🔹 “생각 → 실행 → 관찰 → 다음 행동” 같은 반복 루프를 가짐 🔹 계산기, 파일, DB, API 같은 도구 호출을 전제로 설계

챗봇과 에이전트의 차이

🔹 챗봇: 질문 → 답변(텍스트) 🔹 에이전트: 목표 → 계획 → 도구 실행 → 결과 검증 → 다음 액션

예를 들어 “이번 주 개발 할 일 정리해줘”를 받았을 때, 챗봇은 목록을 제안하는 데 그치지만 에이전트는 ✅ 캘린더/이슈 트래커를 조회하고 ✅ 우선순위를 계산하고 ✅ 초안 문서를 저장하는 식으로 실제 작업 흐름을 만듭니다.

구현 설계: 최소 기능부터 잡자

처음부터 거대한 프레임워크를 붙이면 디버깅이 어려워집니다. 최소 에이전트는 아래 4개면 충분해요.

1️⃣ State(상태): 목표, 진행 로그, 중간 결과 저장 2️⃣ Policy(정책): 지금 무엇을 할지 결정(모델 호출) 3️⃣ Tools(도구): 실제 행동(함수) 4️⃣ Loop(루프): 종료 조건까지 반복

도구 설계 팁

🔹 도구는 “텍스트 생성”이 아니라 결과가 명확한 작업이 좋아요(계산, 조회, 저장) 🔹 입력/출력을 단순하게 유지하면 안정성이 확 올라갑니다 🔹 실패할 수 있다는 전제(예외 처리, 재시도)를 꼭 둡니다

실전 코드: 파이썬으로 도구 호출형 Agent 만들기

아래 예시는 계산기 도구와 메모 저장 도구를 가진 초간단 에이전트입니다. 모델은 OpenAI 호환 API를 가정했지만, 핵심은 “모델이 도구를 선택하고 → 실행하고 → 관찰 결과로 다음 행동”을 이어가는 흐름입니다.

import json

# --- Tools ---
def tool_calc(expression: str) -> str:
    try:
        # 데모용: 실제 서비스에서는 안전한 파서 사용 권장
        result = eval(expression, {"__builtins__": {}})
        return str(result)
    except Exception as e:
        return f"calc_error: {e}"

MEMO = []

def tool_save_memo(text: str) -> str:
    MEMO.append(text)
    return f"saved({len(MEMO)}): {text[:30]}"

TOOLS = {
    "calc": tool_calc,
    "save_memo": tool_save_memo,
}

# --- Agent loop (모델은 '다음 액션'을 JSON으로 반환한다고 가정) ---
def fake_llm_decide(goal: str, observation: str) -> str:
    """
    실제로는 LLM 호출로 대체됩니다.
    반환 형식 예:
    {"action":"tool","tool":"calc","input":"(12000*3)*0.9"}
    {"action":"tool","tool":"save_memo","input":"정산 결과: ..."}
    {"action":"finish","output":"최종 답변 ..."}
    """
    if not observation:
        return json.dumps({"action":"tool","tool":"calc","input":"(12000*3)*0.9"}, ensure_ascii=)
        observation:
         json.dumps({:,:,:}, ensure_ascii=)
     json.dumps({:,:}, ensure_ascii=)

 ():
    state = {: goal, : []}
    observation = 

     step  (max_steps):
        decision = json.loads(fake_llm_decide(goal, observation))
        state[].append({: decision, : observation})

         decision[] == :
             decision[], state

         decision[] == :
            tool_name = decision[]
            tool_input = decision[]
            observation = TOOLS[tool_name](tool_input)
            

        observation = 

     , state

(run_agent()[])

✅ 이 예제에서 중요한 포인트 🔹 결정(Decision)과 관찰(Observation)을 분리해서 기록 → 디버깅이 쉬움 🔹 종료 조건이 명확함(steps 제한, finish 액션) 🔹 도구 실패가 있어도 루프가 깨지지 않음(에러 문자열을 관찰로 넘김)

예시 시나리오: 개발 업무에 바로 쓰는 Agent 아이디어

실무에서 바로 가치가 나는 패턴은 “반복 + 규칙 + 외부 데이터” 조합입니다.

🔹 릴리즈 노트 에이전트: 이슈 목록 요약 → 변경점 분류 → 릴리즈 텍스트 생성 → 파일 저장 🔹 코드 리뷰 보조: diff 요약 → 위험 구간 탐지 → 체크리스트 생성 🔹 에러 트리아지: 로그 파싱 → 유사 이슈 검색(내부 DB) → 재현 절차 정리

구현 시 흔히 부딪히는 함정과 해결책

✅ 안정성을 올리는 체크리스트 🔹 도구 입력 검증: 숫자/날짜/경로 같은 값은 특히 엄격하게 🔹 권한 분리: “읽기 도구”와 “쓰기 도구”를 분리하면 사고가 줄어듭니다 🔹 관찰 로그 저장: 나중에 문제를 재현할 수 있어야 개선이 됩니다 🔹 최대 스텝 제한: 무한 루프 방지용 안전장치

마무리: 좋은 Agent는 “말”보다 “흐름”이 강하다

AI Agent 구현의 본질은 모델을 똑똑하게 만드는 게 아니라, 도구와 루프를 설계해서 일을 끝내게 만드는 것입니다. 오늘 소개한 최소 구조로 시작해서, 다음 단계로는 🔹도구 확장(API/DB) 🔹계획 단계 추가(플래너) 🔹검증 단계(체커)까지 붙이면 꽤 탄탄한 에이전트가 됩니다.

#aiagent #개발 #파이썬 #llm #에이전트 #도구호출 #자동화 #소프트웨어개발 #프로덕트개발