드디어.. 혁펜하이님 강의 LEVEL3까지 완강을 했다. 벡엔드만 하다가 AI AGENT를 만들고 AI 오케스트레이션 플렛폼을 개발하면서,

예를들어 프롬프트를 구성할때에 내가 진짜 AI모델들을 잘 활용하고 있는가? 뭔가 잘 알아듣게 내가 더 나은 구성을 던질 수 있지 않을까에대한 순수한 호기심으로 딥러닝 공부를 시작을 했었다.

처음엔 다른 강의들을 들었었고, 그 강의 역시 선대부터 시작을 했었는데.. 대학생때는 시험공부를 패스하기 위한 수학으로써밖에 공부를 했어서 뒤로갈수록 뭔가 선형이동이라던지 차원개념이 너무 어려웠었다. 그렇게.. 그 선형대수학 강의를 이해하기 위해 유튜브에서 찾은 강의가 "혁펜하임" 님의 선형대수학 강의였다.

그렇게 선형대수학을 개념단계에서 이해하고 다음 머신러닝 가고.. 커리를 타는데 너무어려워서 역시 EASY 딥러닝으로 먼저 듣고, 공부하다가 아에 커리를 혁펜하임님의 커리로 갈아타고 이렇게 LEVEL3까지 완강을.. 드디어 했다..

부디 처음 AI를 공부하겠다고 생각하시는분들은 "** 백엔드 강의 = 김영한 강의** " 이것처럼 절대공식으로, " AI 강의 = 혁펜하임 강의" 로 공부를 시작한다면 정말 가장 고효율적으로 시간낭비 없이 학습 할 수 있을 것이라고 확신한다.

처음 EASY 딥러닝을 공부할때 물론.. 강의 내용은 쉬웠으나.. 역전파 이후로는 조금 힘들었던것같은데 살짝의 고비를 넘어서, 뒤에 CNN나오고 트렌스포머 강의로 넘어갈때는 와.. 이런거구나 신기하다 이해가 잘된다 하면서 쑥쑥 재미있어서 유튜브 보는것마냥 봤던것 같다.

이후로 LEVEL2부터 해도 나름 괜찮았는데.. 역시 LEVEL3넘어가면서 역시 한계가 와서 공식들을 이해하기보다는 뭔가.. 딥러닝에 대해 누가 말해도 아 그게 그거였지? 하면서 알아들을수 있는 정도로만 학습하자를 목표로 머리속에 냅다 들이부어가며 들었다.

이제 완강을 (물론 못알아듣겠는부분은 GPT한테 물어보면서..) 했는데 이제야 조금 CLIP이 뭐고.. 디퓨전이 어떤내용이고 흐름을 따라갈 수 있게 된것 같다. 저 강의들 안들었으면 진짜.. 중도포기했을거라고 느껴졌을정도로.. (다른분들은 쉽게 따라가시는것같은데 나만 그런건가 ㅠㅠ) 라이브 강의 참여하고싶긴했는데 라이브로는 바로바로 이해를 못할것같아서 참여하진 않았어요.. 혁펜하임님께는 감사의 인사를 드립니다 ㅠ

강의를 다 듣고 아 AI는 대강 이런 원리로 굴러가는거라는걸 깨닫고.. 지금와서 보니 뭔가 내가 처음에 "AI모델들을 더 잘 써먹고 싶다"라는 마음으로 딥러닝을 공부하기 시작했는데, 이건... 딥러닝을 공부하더라도 활용분야는 또 별도인것같다라는 생각이 들었다. 논문들 몇개 들여다봐도.. AI를 사용하는 회사들도, 연구하시는분들도 전부 이부분들 연구하시는것같았다.

처음엔 기계적으로 "아 이런 원리로 공부하거나 만들어졌으니 이런 프롬프트, RAG들 을 구성하면 잘 쓸 수 있겠다" 를 깨달을 수 있지 않을까 했었는데, 나도 역시 LLM 오케스트레이션 플렛폼을 개발하면서도 지속해서 고민했던 부분들이고, 써보면서 느꼈던거지만.. 저런 기계적인 접근보다는.. 한 "인공지능"이라고 부르는 만큼, 그리고 아직 사람의 뇌처럼 블랙박스인 부분이 많은 만큼 약간 아직은 똑똑하지만 말귀는 5살 아이인 인공지능에게 잘 알아듣게하는 AI심리학 부분은 딥러닝을 공부함으로써는 해소될 수 없을것같다 라는 생각이 들었다.

그럼에도 이제 AI라던지, 다른 컨퍼런스들을 갔을 때 대체 저게 무슨소리인지 아에 못알아듣기보다는 조금 그래도 주어들을 수 있는 정도까지는 학습한것같아서 뿌듯하다

--> mlp는 뭔가 암호를 잘 풀것같다.

skip-connection을 보면 과적합을 방지하는 용도.

-> 기울기소실문제 해결, 앙상블 효과 등등 -> 그렇다면 *프롬프트에다가 너무 필요한 내용만 주는 것 또한 오버피팅이 나지 않을까? *사실 대화내용이라고 한다면 노이즈가 껴도 될것같은데... -> 할루시네이션이 날것같긴한데.. -> 제미나이의 응답 -> 하지만 이 응답이 너무 파인튜닝이나 학습관점인것같아서 다시 물어봤다. 이 응담 결과를 보면.. 일단 추론을 잘하는 모델인경우에는 이런게 도움이 될 수도 있지 않을까라는 생각이 들었다.

알고리즘이 도배가된건지.. 아 머신러닝관련해서 구글링을 하다가 패캠 강의 광고를 보고 홀린듯이 들어가서 발견한 강의인데, 인프론엔 없고 아직 이런강의는 패캠에만 있는듯 하다.

한국형 딥시크 개발자가 알려주는 LLM의 모든 것 : 데이터생성부터 RAG 파인튜닝, 성능 최적화까지 손규진님의 강의인데, 꽤나 강의가 쭉쭉 들려서 좋다(아직 초기이지만)

아직 초반까지들었을때, 앞써 말했듯 개념들이 아직 익숙하지 않은 상태에서 부딪혀봤기때문에 중간중간.. 헷갈린 부분들은 gemini한테 물어보며..(pro이기때문 ㅎ) 하다가 내가 가졌던 질문들을 기록부터해본다.

1. 파인튜닝이란?

파인튜닝을 하는데.. 허깅스페이스에서 가져와서 하는데 이미 똑똑한 모델인것같은데, 학습을 시키고 하니까 갑자기.. 얘네는 빈 깡통이여서 학습시키는건가? 라는 이상한 생각이 들어 파인튜닝에 대해 물어봤고, 그 결과 아.. 이거그냥 파인튜닝이란 똑똑한 모델에게 약간 세뇌시키는 과정이구나 라는 생각이 들었다. 그래서 " 아 그럼 세뇌하는과정인거야 ?" 라고 제미나이에게 물어봤더니 "와 정말 핵심적인 비유야" 라는 칭찬(?)을 받았다 ㅎ

2. 그럼 데이터들을 어디다가 저장하는거야?

이번에도 칭찬받은(?) 질문들.. 정말 왕초보라서 할 수 있는 질문들이지만.. 백엔드 개발자 입장에서.. 아니 이미 똑똑한 친구라는데.. 사전지식들도 갖고있는 모델들인데 데이터를 어디다가 저장하는지... 궁금해져서.. 했던 질문

예전에는 하나하나 검색하고 찾아보면서 판단했었는데.. 지금은 일단 claude에게 물어보는중..

이미 예전에 했었던 고민이였지만 그당시에는 이렇게 점점 고도화가 되지 않았었기 때문에 deep-agent deploy가 나온 시점.. 함게 deep-agent도 다시 고민해보는 시간을 갖었다..

새로운게 계속 나오니까 나올때마다 이고민중이다 ㅠ 설계너무어려워..

create_react_agent vs Deep Agent — 실제 실행 메커니즘 차이

User: "강남역 지하철 도착 시간 알려줘"

LLM (1회 호출)
├─ System Prompt: "너는 도우미야"
├─ Tool descriptions: [a,b,c ..... ]  ← 20개 전부 프롬프트에
├─ User: "강남역 지하철 도착 시간"
└─ LLM 판단: tool_call → search(search="강남")
   └─ 결과 받아서 → LLM 최종 응답

이게 전부입니다. ReAct 루프는:

Think → Act(tool call) → Observe(결과) → Think → ... → 최종 답변

LLM 한 놈이 모든 걸 결정합니다. 도구 20개의 description을 전부 읽고, 어떤 도구를 쓸지 스스로 고릅니다.

Deep Agent 패턴 (Supervisor + Skill Agents)

User: "강남역 지하철 도착 시간 알려줘"

Supervisor (LLM 1회 호출) — 가벼운 라우터
├─ System Prompt: "아래 skill 중 적절한 것을 골라라"
├─ Skill 목록 (도구가 아니라 에이전트 이름):
│   ├─ "a" - search
│   ├─ "b" 
│   ├─ "c"
│   ├─ "d"— 
│   └─ "e" — 그냥 대화
├─ LLM 판단: → "search"
│
└─ Agent (별도 LLM 호출)
   ├─ System Prompt: "너는 한국 서비스 전문가야"
   ├─ Tool descriptions: [a] ← 1개만!
   ├─ Context: 원래 질문 + Supervisor가 전달한 맥락
   └─ LLM 판단: tool_call → search(search="강남")
      └─ 결과 받아서 → 최종 응답

대체 뭐가 다른 건데?

본질적 차이는 "2단계 분류"입니다. 그 이상도 이하도 아닙니다.

"하네스(Harness)"란?

Deep Agents 블로그에서 말하는 harness는 거창한 게 아닙니다:

# 이게 하네스의 전부입니다
harness = {
    "supervisor": supervisor_agent,      # 라우팅 에이전트
    "skills": {
        "search": search_agent,          # Skill Agent 1
        "math": math_agent,              # Skill Agent 2
    },
    "memory": memory_store,              # 대화 기록/학습된 패턴
    "config": agents_md                  # AGENTS.md 설정 파일
}

# 실행
async def run(user_input):
    skill_name = await harness["supervisor"].invoke(user_input)  # 분류
    result = await harness["skills"][skill_name].invoke(user_input)  # 실행
    return result

하네스 = Supervisor + Skill Agents + Memory + Config를 묶어놓은 실행 컨테이너

LangChain 코드로 치면:

from langgraph.prebuilt import create_react_agent

# Skill Agent들 정의
search_agent = create_react_agent(
    model=llm,
    tools=[a, b, c]
)
math_agent = create_react_agent(
    model=llm,
    tools=[d, f]
)

# Supervisor = 그냥 또 다른 에이전트인데, "tools" 대신 "agents"를 호출
supervisor = create_react_agent(
    model=llm,
    tools=[
        Tool(name="search", func=search_agent.ainvoke, description="웹 검색"),
        Tool(name="math", func=math_agent.ainvoke, description="수학 계산"),
    ]
)

Supervisor의 "도구"가 다른 에이전트를 호출하는 함수인 겁니다.

솔직한 평가

현재 시스템에서 도구 20개 중 오선택이 자주 발생하나요?

• 오선택 자주 발생 → Skill Router 도입 가치 있음
• 잘 작동하고 있음 → LLM 호출 1회 추가 비용만 생기는 오버엔지니어링

도구가 50개, 100개로 늘어날 예정이라면 지금 구조화해두는 게 맞고, 현재 20개 선에서 잘 돌아가고 있다면 굳이 바꿀 필요 없습니다.

이렇게 보면.. 또 클로드 코드분석했을때의 tool사용하는 방법이랑 비슷한것같기도 한데.. 아마 좀 더 기능을 붙이면 나중에는 deep-agent를 써야하지 않을 까 싶다..

제대로 알아보고 이해한게 맞는지 여러번 되묻고 찾아보기도했는데 혹시나 알게되는 다른내용이라던지.. 잘못이해한 내용있다면 언제든 피드백 환영입니다!

우선 위의 사진에처럼, 질문별로 문서를 작성하고, 관련해서 꼬리에 꼬리를 무는 질문을하여 문서를 구체화 한 뒤에, 블로그에 작성할 내용을 정리하도록 하였다.

LLM 에이전트 맥락관리와 Tool Orchestration: FastAPI + Python 실전 가이드

최근 에이전트 시스템을 운영해보면, 성능 이슈의 대부분은 모델 자체보다 두 가지에서 터집니다.

• 맥락관리(Context Management)
• 도구 실행 제어(Tool Orchestration)

이 글은 실제 CLI 에이전트 구조를 바탕으로, 왜 이 두 축이 중요한지와 FastAPI + Python으로 어떻게 최소 구현할 수 있는지 정리합니다.

빠른 네비게이션

• 문제 정의: 왜 이 주제가 중요한가
• 설계 핵심: 설계 원칙 5가지, 아키텍처 한 장 요약
• 동작 예시: 구체 시나리오 1~4
• 구현 예시: FastAPI 미니 예제 1~3
• 운영 가이드: Prompt Caching, 운영 체크리스트, 전체 흐름 순서도

3줄 요약

• 맥락관리의 핵심은 "기록을 늘리는 것"이 아니라 "핵심 상태를 남기며 압축하는 것"입니다.
• Tool Orchestration의 핵심은 "많이 병렬화"가 아니라 "안전한 툴만 병렬화"입니다.
• Prompt Caching의 핵심은 "모든 블록 캐시"가 아니라 "안정된 경계 1개"입니다.

왜 이 주제가 중요한가

모델은 잘 대답하는데 서비스는 불안정한 이유는 보통 아래 패턴입니다.

• 메시지 히스토리가 계속 누적되어 컨텍스트 윈도우를 압박한다.
• 툴 호출이 병렬/직렬 기준 없이 섞여 레이스 컨디션이 난다.
• 권한 확인 없이 위험한 툴이 즉시 실행된다.
• 캐시 경계가 불안정해서 요청 비용이 매 턴 급증한다.

핵심은 간단합니다.

• 토큰은 예산이고,
• 툴은 상태를 바꾸는 트랜잭션이며,
• 캐시는 경계가 안정적일 때만 이득이 납니다.

설계 원칙 5가지

1. 최근 대화만 남기는 것이 아니라, 중요한 상태를 요약본으로 보존한다.
2. 툴은 무조건 병렬이 아니라, 안전한 툴만 병렬로 돌린다.
3. 위험한 툴은 권한 게이트를 통과해야 실행한다.
4. 캐시 마커는 많이 붙이는 것이 아니라, 안정된 경계 한 곳에 둔다.
5. 실패(PTL, timeout, permission deny)를 정상 경로로 취급하고 재시도 정책을 둔다.

아키텍처 한 장 요약

• API 레이어: 모델 호출, 스트리밍 처리, usage 수집
• Context 레이어: 히스토리 누적, 압축(snip/microcompact/autocompact), 첨부 재주입
• Orchestration 레이어: tool_use 파싱, 병렬/직렬 실행, 결과 병합
• Safety 레이어: 권한 정책, 사용자 승인, 위험도 분류
• Observability 레이어: cache hit/miss, 토큰 사용량, 실패 카운트

구체 시나리오 1: "src/auth.py 고쳐줘" 요청이 들어오면

아래는 실제 운영에서 가장 자주 보는 1턴 내부 흐름입니다.

[1] UserMessage("src/auth.py 고쳐줘") append
        -> 모델 호출

[2] AssistantMessage(text + tool_use: read_file)
        stop_reason = tool_use

[3] 런타임이 read_file 실행
        -> UserMessage(tool_result: 파일 내용)
        -> 같은 턴에서 모델 재호출

[4] AssistantMessage(text + tool_use: write_file)
        stop_reason = tool_use

[5] 권한 게이트 ask 발생 (write_file은 위험도 중간 이상)
        -> 사용자 승인 후 실행
        -> UserMessage(tool_result: 수정 완료)

[6] AssistantMessage("수정 완료")
        stop_reason = end_turn

핵심:

• tool_use가 나오면 턴이 끝나는 게 아니라 follow-up 루프가 이어집니다.
• tool_result는 user role로 다시 들어가 다음 모델 호출 컨텍스트가 됩니다.

구체 시나리오 2: 스트리밍 이벤트가 메시지로 조립되는 방식

아래처럼 네트워크 이벤트(델타)를 받아 상위 메시지로 조립합니다.

message_start
-> content_block_start(text)
-> content_block_delta(text_delta: "파일을")
-> content_block_delta(text_delta: " 확인할게요")
-> content_block_stop
    => AssistantMessage(text) 방출

-> content_block_start(tool_use)
-> content_block_delta(input_json_delta: '{"file_path":"src/auth.py"')
-> content_block_delta(input_json_delta: '}')
-> content_block_stop
    => AssistantMessage(tool_use) 방출

-> message_delta(stop_reason: tool_use, usage: ...)
    => 직전 메시지 메타 확정(usage/stop_reason)

핵심:

• 사용자 체감 출력은 빠르게 먼저 내보내고,
• usage/stop_reason은 message_delta에서 최종 보강됩니다.

구체 시나리오 3: 병렬/직렬 오케스트레이션 결과 비교

요청된 tool plan이 아래와 같다고 가정합니다.

{
    "calls": [
        {"name": "read_file", "args": {"path": "src/auth.py"}},
        {"name": "search_code", "args": {"query": "login"}},
        {"name": "write_file", "args": {"path": "src/auth.py", "patch": "..."}}
    ]
}

실행 정책:

• read_file + search_code: 병렬 배치
• write_file: 직렬 단독 배치

결과적으로 읽기/검색은 빠르게 합쳐지고, 상태 변경은 안전하게 뒤에서 실행됩니다.

구체 시나리오 4: 캐시 마커는 "많이"가 아니라 "안정적으로 1개"

잘못된 예시(경계를 여러 군데 흔듦):

messages.map(m => ({
    ...m,
    content: m.content.map(c => ({
        ...c,
        cache_control: { type: 'ephemeral', ttl: '1h' },
    })),
}))

권장 예시(요청당 message-level marker 1개):

const markerIndex = skipCacheWrite ? messages.length - 2 : messages.length - 1
const payload = messages.map((m, i) => toMessageParam(m, i === markerIndex))

핵심:

• cache_control은 캐시 데이터 본문이 아니라 경계 힌트입니다.
• 경계가 자주 흔들리면 cache hit rate가 급락하고 비용/지연이 증가합니다.

FastAPI 예제 실행 방법 (로컬)

아래 예제들은 각각 독립 파일로 저장해서 실행할 수 있습니다.

1. 가상환경 및 패키지 설치

python -m venv .venv
source .venv/bin/activate
pip install fastapi uvicorn pydantic

2. 예제 파일 저장

• example_context.py
• example_orchestrator.py
• example_guard.py

3. 서버 실행

uvicorn example_context:app --reload --port 8000
uvicorn example_orchestrator:app --reload --port 8001
uvicorn example_guard:app --reload --port 8002

4. 빠른 테스트

curl -X POST http://127.0.0.1:8000/chat \
    -H 'Content-Type: application/json' \
    -d '{"session_id":"s1","user_input":"문서 20개 요약해줘"}'

FastAPI 미니 예제 1: 맥락관리 파이프라인

아래 예제는 턴마다 히스토리를 누적하고, 임계값을 넘으면 자동 요약(compact)을 수행합니다.

from fastapi import FastAPI
from pydantic import BaseModel
from typing import List, Dict

app = FastAPI()


class Turn(BaseModel):
    role: str
    content: str


class ChatRequest(BaseModel):
    session_id: str
    user_input: str


SESSIONS: Dict[str, List[Turn]] = {}

TOKEN_LIMIT = 12000
AUTO_COMPACT_THRESHOLD = 9000


def rough_token_count(turns: List[Turn]) -> int:
    return sum(len(t.content) // 3 for t in turns)


def compact_history(turns: List[Turn]) -> List[Turn]:
    if len(turns) < 6:
        return turns

    head = turns[:-4]
    tail = turns[-4:]

    summary_text = " ".join(t.content for t in head)[:1200]
    summary = Turn(role="system", content=f"Summary of earlier context: {summary_text}")
    return [summary] + tail


@app.post("/chat")
def chat(req: ChatRequest):
    turns = SESSIONS.setdefault(req.session_id, [])

    turns.append(Turn(role="user", content=req.user_input))

    token_est = rough_token_count(turns)
    if token_est > AUTO_COMPACT_THRESHOLD:
        turns[:] = compact_history(turns)

    # 여기서 실제 LLM 호출을 수행한다고 가정
    answer = f"Echo: {req.user_input}"
    turns.append(Turn(role="assistant", content=answer))

    if rough_token_count(turns) > TOKEN_LIMIT:
        return {
            "ok": False,
            "reason": "context_window_exceeded",
            "hint": "compact 강도를 높이거나 입력 배치를 분할하세요",
        }

    return {
        "ok": True,
        "answer": answer,
        "token_estimate": rough_token_count(turns),
        "turns": len(turns),
    }

포인트:

• 자동 압축을 늦게 걸면 이미 PTL 근처까지 가서 실패 확률이 커집니다.
• 압축 후에도 첨부/파일 컨텍스트를 선택적으로 재주입하는 단계가 필요합니다.

FastAPI 미니 예제 2: Tool Orchestration (병렬/직렬 분리)

도구는 모두 병렬 실행하면 빨라 보이지만, 상태 변경 툴이 섞이면 깨집니다.

import asyncio
from fastapi import FastAPI
from pydantic import BaseModel
from typing import Any, Dict, List

app = FastAPI()


class ToolCall(BaseModel):
    name: str
    args: Dict[str, Any]


class ToolPlan(BaseModel):
    calls: List[ToolCall]


TOOL_META = {
    "read_file": {"concurrency_safe": True},
    "search_code": {"concurrency_safe": True},
    "run_terminal": {"concurrency_safe": False},
    "write_file": {"concurrency_safe": False},
}


async def execute_tool(call: ToolCall) -> Dict[str, Any]:
    # 실제 구현에서는 도구별 dispatcher 연결
    await asyncio.sleep(0.05)
    return {"tool": call.name, "ok": True, "result": call.args}


@app.post("/orchestrate")
async def orchestrate(plan: ToolPlan):
    safe_calls = [
        c for c in plan.calls if TOOL_META.get(c.name, {}).get("concurrency_safe", False)
    ]
    unsafe_calls = [c for c in plan.calls if c not in safe_calls]

    safe_results = await asyncio.gather(*(execute_tool(c) for c in safe_calls))

    unsafe_results = []
    for c in unsafe_calls:
        unsafe_results.append(await execute_tool(c))

    return {
        "parallel_count": len(safe_calls),
        "serial_count": len(unsafe_calls),
        "results": safe_results + unsafe_results,
    }

포인트:

• 읽기 전용/조회성 툴은 병렬, 상태 변경 툴은 직렬이 기본값입니다.
• 이 분리만 해도 툴 충돌과 재현 어려운 버그가 크게 줄어듭니다.

FastAPI 미니 예제 3: 권한 게이트(Approval Loop)

실무에서는 자동화보다 안전이 우선인 경우가 많습니다.

from enum import Enum
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI()


class Decision(str, Enum):
    allow = "allow"
    deny = "deny"
    ask = "ask"


class GuardRequest(BaseModel):
    tool_name: str
    risk: str
    user_approved: bool = False


def policy(tool_name: str, risk: str) -> Decision:
    if risk == "low":
        return Decision.allow
    if tool_name in {"write_file", "run_terminal"}:
        return Decision.ask
    return Decision.deny


@app.post("/guard")
def guard(req: GuardRequest):
    d = policy(req.tool_name, req.risk)

    if d == Decision.allow:
        return {"decision": "allow"}

    if d == Decision.deny:
        return {"decision": "deny", "reason": "policy_blocked"}

    if req.user_approved:
        return {"decision": "allow", "reason": "user_approved"}

    raise HTTPException(
        status_code=409,
        detail={
            "decision": "ask",
            "reason": "need_user_approval",
        },
    )

포인트:

• allow/deny/ask의 3상태 모델이 운영 난이도를 크게 낮춥니다.
• ask 상태를 UI 승인 루프로 연결하면 안전성과 자동화를 함께 가져갈 수 있습니다.

Prompt Caching은 어떻게 봐야 하나

캐싱 관련 오해를 한 줄로 정리하면:

• cache_control은 캐시 경계 마커이지, 캐시 데이터 본문이 아닙니다.

즉 클라이언트는 평소처럼 메시지를 보내고, 서버가 캐시를 저장/재사용합니다. 그래서 중요한 건 다음입니다.

• 경계를 안정적으로 유지할 것
• 시스템 프롬프트/툴 스키마/베타 헤더를 자주 흔들지 말 것
• hit rate는 cache read 토큰과 응답 지연으로 관측할 것

운영 체크리스트

1. 압축 트리거 임계값이 PTL 전에 작동하는가
2. 병렬 툴과 직렬 툴의 기준이 명시되어 있는가
3. 위험 툴에 대해 사용자 승인 루프가 있는가
4. 캐시 경계를 턴마다 바꾸고 있지 않은가
5. 실패 시 재시도와 circuit breaker가 있는가
6. 비용/지연/실패 지표를 대시보드에서 보는가

마무리

에이전트 품질은 모델 선택보다 운영 구조에서 갈립니다.

• 맥락관리: 오래된 정보를 버리는 기술이 아니라, 중요한 상태를 보존하는 기술
• 툴 오케스트레이션: 많이 실행하는 기술이 아니라, 안전하게 실행 순서를 제어하는 기술

이 두 축만 제대로 잡아도, 같은 모델로도 체감 품질과 비용 효율이 크게 달라집니다.

실제 운영에서 가장 효과가 큰 개선 순서는 보통 아래와 같습니다.

1. PTL 전 자동 압축 임계값 조정
2. concurrency-safe 기준 정리(병렬/직렬 분리)
3. 위험 툴 approval loop 의무화
4. 캐시 경계 안정화(마커 정책 고정)

즉, 모델 교체보다 먼저 오케스트레이션과 맥락정책을 고정하면, 실패율과 비용이 함께 내려갑니다.

전체 흐름 순서도

[User Input]
    -> messages에 UserMessage append
    -> 토큰 추정 / 임계값 체크
            -> (초과) compact 실행: snip/microcompact/autocompact
            -> 모델 호출

모델 응답 처리:
    -> Assistant 응답에 tool_use 존재?
            -> No: stop_reason=end_turn -> 턴 종료 / 다음 턴 대기
            -> Yes:
                    -> Tool plan 생성
                    -> concurrency_safe 기준으로 병렬/직렬 분리
                    -> 권한 정책 분기
                            -> allow: tool 실행
                            -> deny: 에러 tool_result 생성
                -> ask: 사용자 승인 대기
                    -> (백그라운드) classifier/hook 판정 작업 진행
                    -> 승인 시 실행 / 거절 시 에러 tool_result
            -> tool 실행 결과를 UserMessage(tool_result)로 append
            -> 같은 턴에서 모델 재호출
            -> tool_use가 사라질 때까지 반복

캐시 처리:
    -> cache_control 경계 마커 적용
    -> 요청당 message-level marker 1개 유지
    -> TTL 정책 결정(사용자 eligibility + querySource allowlist)
    -> skipCacheWrite면 marker를 second-to-last로 이동
    -> 서버측 prompt cache read/write

백그라운드 실행 처리:
    -> 장시간 작업인가?
        -> Yes: run_in_background 경로로 전환, task id 반환, 턴은 계속 진행
        -> No: foreground 실행 후 즉시 tool_result 반환

캐시정책/백그라운드/동의 루프 운영 포인트

1. 캐시 정책

• cache_control은 캐시 데이터 본문이 아니라 경계 힌트입니다.
• 마커를 여러 개 두기보다, 요청당 1개를 안정적으로 유지해야 hit rate가 높습니다.
• TTL 1h는 항상 적용이 아니라 eligibility + allowlist 조건을 통과해야 적용됩니다.

2. 동의(ask) 루프

• ask 상태는 실행 전 대기 상태입니다.
• 대기 중에는 정책 판정 보조 작업(classifier/hook)을 백그라운드로 돌려 응답 시간을 줄일 수 있습니다.
• 승인되면 동일 tool call을 이어서 실행하고, 거절되면 에러 tool_result를 user role로 반환합니다.

3. 백그라운드 실행

• 백그라운드 전환은 권한 대기와 다릅니다.
• 권한 대기는 "아직 실행 전", 백그라운드는 "실행은 시작했고 분리 실행"입니다.
• 장시간 명령은 task id 기반으로 추적하고, 후속 턴에서 상태/로그를 조회하도록 설계하는 것이 안전합니다.

대체 좋은 쿼리는 뭘까?

1. 내가 기억하기로는 처음에 생겼던 질문중 하나는 ..

select * from 으로 해서 전부 조회한다음에 코드로 필요한부분을 쓰는게 좋나? 아니면 필요한 부분만 select하는게 좋을까?

처음 입사하고나서 이 부분에대해 사수분께 여쭤본적이 있는데, 사실 지금 엄청 복잡한걸 건들지 않으니 크게 상관은 없을거고, 실행시켜서 해봐~

라는 답변을 받았었는데, 테스트를 해봐도 엄청 복잡한게 아니다보니 시간차이를 알아볼수 없어서 실패했었다. ㅋㅋㅋㅋ

GPT는

운영 환경이나 실서비스 코드에서는 SELECT *를 지양하고, 필요한 컬럼만 선택하는 것이 일반적인 베스트 프랙티스입니다. 
성능, 유지보수성, 코드 명확성 측면 모두에서 이점이 크기 때문입니다.

라고 답을 해주었고, 일부 동의한다. 이제는 그저 상황에 그때그때 상황에 맞게끔 판단하고있다.

2. 두번째 생긴 질문은,

그래서 좋은 쿼리는 뭔데?

굉장히 근본적인 질문이다. 이때는 한참 쿼리 최적화에 빠져서, 여기저기 컨퍼런스가서 관련주제있으면 듣고, explain는 꼭 확인해보고 했었던 시기였는데,

그래서인가, 이때는 index잘 타고, 원하는값 나오고, 빠르고, 부하가 적고 그게 좋은쿼리 아닌가? 라고 결론을 지었던 것 같다.

3. 현재 생긴 질문은..

원하는 값은 잘 나오고 index잘 탔는데.. 그래서 그렇게 복잡한 쿼리가 나을까? 두번 조회하더라도 알아보기 편한게 좋을까?

2번때의 내가 짰던 쿼리들을 보면 한참.. join이랑 각종 것들을 엄청해서 나름 최적화시키고, db조회는 최소화로 하는 방법으로 쿼리를 작성했었다.

그러다보니, 이후에 해당 쿼리에 수정을 해야한다 하면.. 정말 수정하기가 복잡해졌다.. 거기다가 동적쿼리도 하려고했다보니 한번 수정하기가 너무 힘들었다. GPT가 요즘엔 도와줘서 그래도 괜찮다 싶다가도, GPT의 코딩은 좀 더 빡셀때가 많다 ㅋㅋㅋ

그래서 하면서도.. 이거 만든 나도 힘든데, 다른사람이 알아보기 좀 빡셀 것 같은데 라는 생각을 하고있었는데,

최근데 다녀왔던 2025토스컨퍼런스에서, 레거시 코드를 뜯어고친 것을 주제로 한 연사를 들었다. 다른부분은 아 그냥 묶고 분리하고 뭐 그런거군 하면서 듣고있다가,

레거시 query가 정말 너무길고 join도 여러번에 너무 복잡해서 
다 끊어내고 알아보기쉽게했다. 그래야 에러도 덜나고 디버깅도 쉽다

이런말을 하셨었는데, 아.. 나만하던 고민이 아니였구나 라는걸 깨닫고, 이 질문에 대해 다시한번 생각해보게되었다.

그래서 지금 현재 나의 생각은..

*그치, 한번에 조회하는게 connection차지도 덜하고 좋지만, 하지만 그것이 협업을 할때 유지보수에 있어 지대한 영향을 준다면 성능보다 더 앞으로 크게 작용을 할 수 있겠구나 *

이다.

앞으로의 나의 생각이 어떻게 변하게 될지 나도 궁금하다.

들어가기 앞서서..

처음 공부는 java spring으로 입문을 해서, 회사에 들어가니 바로 javascript nodejs를 급하게 익혀서 사용해야했어서, 언어나 프레임워크의 이해도가 다소 떨어진다 느껴저서 강의를 보고....했지만.. 따로 공부를 해도 사실 크게 체감이 되는 부분이 없어서

부끄럽지만 그동안 나는 단순하게

동기 = 순서대로진행 비동기 = 처리순서가 빠른대로 진행 async await = 비동기 환경에서 동기처럼 처리하기위한 것

이렇게만 생각을 해왔다..

2. 발단

이번에 python을 사용해서 프로젝트를 진행하게 되어, 맞는 프레임워크를 찾아보다가 fastAPI를 입문을 하게 되었다.

python이 느린건.. 사실 코테공부를 python으로 했어서 느린건 익히 알고있었는데, fastAPI의 장점이 Django나 다른 친구들보다 빠르고 간편하게 사용할 수 있다는 점이 와닿아 사용을 하게 되었는데( 급하게 시작을했어야해서 새로운 프레임워크 공부에 큰 시간을 쓸 수가 없었다)

사용을 하다보니 알겠더라..

FastAPI의 장점중 하나 "빠르다"가 async await을 지원한다 라는게 하나의 주요 원인중 하나였는데,

처음에 너무 단순하게 생각했던 나는..

어차피 함수 앞에 async안붙이면 javascript랑은 다르게 동기함수가 되는건데, 비동기로 갈거 아니면 async 붙일 필요가 있어..? 라는 오만한 생각을 하게 된다..

그렇게 코드를 완성하고.. 서버 api막 만들어서 프론트랑 작업을 하고 배포도 해서 테스트를 하는데.. 한 부분이 느리면.. 전체가 멈춰버리는 것이다..

3. 전개

아니.. 자바스크립트에서는 이런적이없는데.. 여긴 기본이 동기여서그런가..? 하고 원인을 분석하다가

문뜩, async await쪽을 건들여보기 시작했다.. 그러다보니 문뜩.. NodeJS공부할때 EventLoop쪽이 생각이났다.. 공부했을때는..

아.. 그냥 그렇구나~ 저래서 동기처럼 작동을 하는구나~ 저래서 빠르구나~~

하고 그냥 달달암기만 하고있었는데.. 이번에 뽝 느낌이 왔다.. 이거였구나..

4. 깨달음

결론부터 얘기하자면

동기는 결과를 “기다리면서 멈추는 것”이고, await는 “기다리지만 멈추지 않고 다른 일을 할 수 있게 하는 것”

async await가 동기"처럼" 에 "처럼"을 깨닫는 순간이였다..

그러니까, fastapi의 장점중에 "빠르다" 가 비동기를 지원하기때문에, await를 사용하면 동기처럼 행동해도 다른곳에서 멈추지 않는다 즉, 동기만 가능한 프레임워크보다 빠르다 였구나 라는걸 한번에 확 체감 가능한 순간이였다..

그동안.. 자바스크립트 await이거 고생을 엄청해서.. 조금 미워했는데.. 너에겐 큰 뜻이 있었구나..

5. 그래서..

그래서 시간이 오래걸리고, 굳이 async를 붙이지 않게해서 동기로 만든 함수들 전부 async붙이고 await사용해서 수정을했고,

그렇게 처리가 오래걸림으로 인해, 서비스가 멈추던 모든 이슈들이 해결되었답니다.. ㅎ

나는 진짜.. 바본가보다.. 아무리 공부해도 겪어봐야.. 아 이게 그거구나.. 하고있다 ㅠㅠ

1. langchain에서 지원하는 callback매니저를 사용해보기.

무슨이유에서인지 나는 예제대로 해도 리턴받은 토큰소모량이 전부 0으로 나왔다. 그래서 이리저리 막 검색하고 해봤는데 결국.. 실패했었다.. 더욱이 이때는 이제 막 langchain에 입문했던 시기였기에 다음단계로 넘어가게 되었다.

2. Ticktoken 라이브러리 사용하기.

해당 라이브러리는 openai에서 제공해주는 토큰세기 라이브러리여서 이걸사용하면 되겠다~ 하고 사용하게 되었다.

정말 편하고 좋았는데, 문제가있다면.. 아무리 최신을 해도 o1시리즈같은건 없는 모델이라고.. 떠서 내가 임의지정한 default모델의 토큰으로 세진다는 거였다.. 정확성이 떨어졌지만 이때는 우선 이방식을 사용했다.

3. Return값으로 받았다..

프로젝트가 어느정도 진행되고, langchain에 익숙해지고 langgraph도 사용해봤을 때, 1번을 다시 시도하였으나.. 실패를 했다.. 공식문서랑 검색이랑 진짜 다해봤는데 나한테 왜그래 ㅠㅠ

무튼 그래서 2번상태 유지중일때 의외에 곳에서 해결이 되었는데.. langchain을 주로 사용하다보니, gpt에 endpoint를 나는 잘 살펴볼 일이 없었다. 근데, 잘 만들어서 이것저것 테스트하다가 보니, o1-pro모델, o1-mini등등 o시리즈에서 에러가 나는 것이었다...

첫번째로는, 라이브러리랑 하나하나 뜯어 보니까 langchain자체 모듈에서 o시리즈일때, role을 developer라고 변경하는 부분이 있었는데.. o1에서는 또 자긴 그런 role없다고 에러가 났고..

두번째로는, langchain에서 기본적으로 invoke혹은 stream할때 사용하는 endpoint v1/chat/completions o1-pro 나 o1-mini에서는 제공이 안된다는 것이였다..

그래서 이리저리 테스트와 검색을하다가

  chat_model = ChatOpenAI(   
              model= 모델명,
            ...
            use_responses_api=True //이거
        )

모델정의부분에서 use_responses_api = True를 설정하면, endpoint가 v1/responses 로 변경되어 나갈 수 있게 된다는 사실을 알았고, 이 방법을 사용했더니 글쎄..

. . *return값으로.. 사용토큰값이 전달되었다.. * 이렇게.. 사용한 토큰값 리턴받기 성공...

진짜 하면 할수록 느끼는건데 정말 엄청빨리 새로운게 나오고 또 변하는구나 싶다..

4. 기타

langgraph에서 openai시에 중간 agent응답에 대한 토큰값이 안오기 시작했다.

그래서 이것저것 해보다가 혹시나 하고 확인을 했더니..

로.. langsmith의 토큰값이 안맞는다는 사실을 알았다..

혹시나 싶어서 다른 모델들도 각 홈페이지에서 실 토큰 사용량과 langsmith값 그리고 return값의 토큰 사용량을 비교해봤는데 미묘하게 살짝씩 다르다는걸 발견했다..

• 책 한권을 다 놓고 돌렸을때 gpt 3.5로는 3달러, 4o mini로는 0.4달러(...?)였다고 한다.. 너무신기.. (구현에만 치우쳐서 가격을 몰랐는데 생각보다 저렴한걸..?)

• api들 쓰면 다들 말 안듣는건 같구나..

• 가끔 코드를 llm에게 예시코드를 받기위해서 물어보면, 예전코드를 줄 때가 있다. 이때는, https://aistudio.google.com/prompts/new_chat 이와같은 사이트에 있는 코드 예제를 던져서 해당 버전으로 해달라고 하면 훨씬 최신의 정보를 얻을 수 있다.

• 크롤링코드 요청시, 응답, 헤더 등의 다양한 소스를 주고 요청을 하자.

• hugging face : 학습시킨 모델을 공유하는 플렛폼

• 데이더셋의 용량이 크다면 hugging에 올려서 사용해보자.

• hugging에서 한국어지원하는 모델 찾고싶다면..? 다른 한국어 모델 찾아보기 : https://huggingface.co/models?search=korean

• RDBMS(답변 그때그때 저장용) + 벡터DB 를 사용해서 프로젝트를 하셨다고..

• 너무 긴 문단은 langchain chunk spliter이용해보자.

• 한국어 embedding 모델

  embeddings = HuggingFaceEmbeddings(model_name="upskyy/e5-small-korean")

• vectorDB로 검색하면 정확도는 떨어진다(유사도 검색이기 때문)

• embedding projector에서 유사도 ui보기 쉽다. https://projector.tensorflow.org

• 벡터화(텍스트 숫자변환)랑 임베딩(의미포함 숫자변환)은 다르구나..

• 임베딩할때 참고하면 좋은 사이트(시각화) https://damien0x0023.github.io/rnnExplainer/

• 오.. 벡터 토큰화 하는코드 ..

  # prompt: texts 내용 tf-idf로 토큰화
  

from sklearn.feature_extraction.text import TfidfVectorizer

tfidf_vectorizer = TfidfVectorizer() tfidf_matrix = tfidf_vectorizer.fit_transform(texts)

TF-IDF 행렬 출력

print(tfidf_matrix.toarray())

TF-IDF 어휘 목록 출력

print(tfidf_vectorizer.get_feature_names_out())

[[0. 0. 0. ... 0.46383605 0. 0. ] [0. 0. 0. ... 0. 0. 0. ] [0. 0. 0. ... 0.36661165 0. 0. ] ... [0. 0. 0. ... 0. 0. 0. ] [0. 0. 0. ... 0. 0. 0. ] [0. 0. 0. ... 0. 0. 0. ]] ['20달러로' '2판' 'agi의' 'ai' 'ai를' 'api를' 'cs' 'git' 'github' 'gpt' 'llm' 'mysql이다' 'nlp와' 'sql' 'with' '가이드' '가이드북' '개발' '개발을' '개발자' '개발자를' '게임' '견고한' '고작' '공략집' '공부하는' '과학이다' '구조' '권으로' '그림으로' '글쓰기' '기술' '네트워크' '노트' '다섯' '대신' '데이터' '도메인' '도커' '디자인' '딥러닝' '라이브러리를' '러스트' '리팩터링' '만렙' '말을' '매니지먼트' '머신러닝' '면접' '명이' '모두를' '몽고db' '믿어요' '밑바닥부터' '배우는' '분석' '비밀' '비즈니스' '사토시의' '선형대수학' '소프트웨어' '수학' '시대' '시대의' '시작하기' '시작하는' '실무로' '실전' '알고리즘이다' '애저' '양자' '어떻게' '언어' '업무' '엑셀' '엔지니어' '엔지니어링' '완벽' '운영체제' '위한' '이것이' '이다' '이지' '인공지능' '인과추론' '일잘러의' '일타강사의' '자동화하기' '자료구조' '자바' '전문가를' '제대로' '주도' '직장인' '챗gpt' '챗gpt와' '처음' '첫걸음' '취업을' '컴퓨터' '코딩' '쿠버네티스' '테스트다' '통하는' '파이썬' '파이썬으로' '패턴' '퍼스트' '프로그래머' '프로그래밍' '프로덕트' '플랫폼' '필수' '핸즈온' '헤드' '혼자' '활용' '활용한']

* 보통 유사도를 검색할때는, cos방식으로 사용한다(거리)방식 
-> 사실이게 추천시스템이다.

* 차원축소 : 모델압축 및 모델 학습시에 주로 활용됨 (통계기법)
* 임베딩시 차원이 크면 클수록 좋지만, 모델이 계산할때 오래걸린다.
* 임베딩 모델에서 사용하는 모델을 그대로 쓰자~
* 여러문서를 llm에서 쓰고싶다면 notebookllm을 사용하자.

---

### 후기
* 그동안 내가 혼자서 했던것들이 영 틀린것은 아니였구나 하고 뿌듯..
* 흥미로운 부분도 새로운 부분도 많았다(특히 통계기법등)
* 정말 궁금한 부분이 사실 들어서 해결되지는 않았지만, 들으면 들을수록 답이 없구나.. 생각이 들었다.

beta같은 환경은 이미 nginx에서 ip제한을 걸어두었는데, live환경에서는 ip제한을 걸어두기가 애매해서 어떻게 할까 하다가 nginx에서 시간당 ip별 횟수제한을 걸 수 있는 방법을 찾아서 시도해보았다.

1. 설정하기

nginx.conf 또는 해당 서버의 설정 파일에서 아래와 같이 설정한다.

http {
    # IP 기반 요청 제한 설정 (초당 4번 허용)
    limit_req_zone $binary_remote_addr zone=perip:10m rate=4r/s;

    server {
        listen 80;
        server_name example.com;

        location / {
            # IP 기반 요청 제한 적용, 초당 4회 요청 이상 시 503 응답
            limit_req zone=perip burst=4 nodelay;

            proxy_pass http://backend;
        }
    }
}

limit_req_zone $binary_remote_addr zone=perip:10m rate=4r/s;

• $binary_remote_addr: 클라이언트의 IP 주소를 기준으로 제한.
• zone=perip:10m: 공유 메모리 영역(perip)을 10MB 크기로 설정(약 16만 개의 IP 저장 가능).
• rate=4r/s: 초당 4번의 요청만 허용.

limit_req zone=perip burst=4 nodelay;

• burst=4: 초과 요청을 최대 4개까지 허용하고 이후부터는 제한.
• nodelay: burst 허용 내에서도 즉시 처리(지연 없음) / nodelay가 없다면 초과 요청이 발생하면 순차적으로 대기 후 처리된다.
• 요청이 4r/s를 초과하면 503(서비스 사용 불가) 응답.

이렇게 설정해주면 된다.. (from GPT)

이후 이슈

이렇게 설정을 했더니.. 해당 도메인을 타고오는 모든 url에서 ip제한이 걸리기 시작했다.. 대표적으로.. 프론트화면도 이미지같은것 렌더링시 지연 혹은 에러 이슈가 발생했다.

그래서, 처음에 이것저것 설정을 해보았고 결과적으로 서버에 오는것만 ip제한을 걸도록 범위를 구체화하였다.

    location / {
        limit_req zone=perip burst=4 nodelay;
        proxy_pass http://backend;
    }

이렇게 설정하면, 해당 도메인 하위단의 주소 모두 ip제한이 걸려서

    location /api {
        limit_req zone=perip burst=4 nodelay;
        proxy_pass http://backend_api;
    }
}

이렇게, 만약 서버가로 가는 주소가 /api 라 한다면.. 위에처럼 서버주소로 가는 주소들만 ip제한이 걸리도록 수정했다.

이렇게 설정하면, 부하도 방지할 수 있고, ip제한도 걸 수 있다. 설정하지 않았을 때, default값은 서버가 처리할수 있는 양만큼의 값들을 모두 수용한다고 한다.

그저 프로시저실행하는 코드고 해당 코드는 건든적이 없었는데.. 프로시저 안에 일이기 때문에 아무리 디버깅을 해봐도 소용이 없었다..

이리 저리 로그를 찍어보다가... 깨달았는데

"1234455673939"이런식으로 string으로 전달되었던 인자가 프로시저 내부에서 "1.xxxxxx"형태의 부동소수점형태로 변환되어 전달되고 있었다..

1. 문제 원인

해당 내용에 대해 gpt에게 물어보니

이러한 대답을 받을 수 있었다.. 내부적으로 mysql에서 숫자형태의 varchar을 부동소수점방식으로 변환한다는것이다..

2. 해결방법

mysql의 묵시적 형 변환에 대해 구글링을 해봐도, 요즘에 프로시저를 잘 사용하지 않는것인지 많은 검색결과를 얻을 수 없었다.

그래서 gpt에게 다시 물어본 결과

✅ 방법 1: 명확하게 문자열로 감싸기 쿼리 실행 시 강제로 문자열로 취급하도록 따옴표('')를 사용하세요.

INSERT INTO my_table (my_varchar_column) VALUES ('109958166097066644827');

✅ 방법 2: CAST() 또는 CONVERT() 사용하기 MySQL에서 명시적으로 VARCHAR로 변환하여 저장

INSERT INTO my_table (my_varchar_column) VALUES (CAST(109958166097066644827 AS CHAR));
INSERT INTO my_table (my_varchar_column) VALUES (CONVERT(109958166097066644827, CHAR));
SET my_varchar_column = CAST(my_varchar_column AS CHAR);

의 대답을 얻을 수 있었다.

처음엔 프로시저를 먼저 고쳐봤다. 인자를 받을 varchar을 64 -> 255 로 늘려도보고, 2번의 변환도 시도해보았다.

다만 문제는.. 프로시저에 인자를 넘어올때 이미 mysql에서 변환을 해서 넘어와서, 프로시저 내부에서 변환을 해도 이미 변환된 값을 string형태로 받을 뿐이였다.

그래서 다음으로 방법1을 선택을 했지만.. 해당 방법또한 나에게 는 해결방법이 되어주지 않았다.

3. 결론

그래서 마지막으로 나랑 사수님과 같이 해결방법을 모색하였는데..

1. 문제가 되는 부분이 첫문단이니, 첫 문단을 프로시저에서 분리하자.
2. 숫자형태가 문제라면, base64로 값을 변환해서 값을 보내고, 프로시저내부에서 풀어서 해결

이 중에서사실 어떤걸 먼저해도 상관없었지만.. 기존의 프로시저 형태는 계속 가져가고싶어서 2번을 택하였고 (1번을 최후통첩으로 남겨놓았다)

2번방법은 동작하였다.

4. 마지막으로..

아직도 해결되지 않은 의문점이 있는데..

서버를 껐다 키면 또 프로시저 내부에서 묵시적 형 변환이 일어나지 않는다.. 처음엔 30분정도 있다가부터 에러가 났고,

그 다음에 2번 해결과정의 gpt가 말해준 1번 방법(명확하게 string형태로 바인딩하기) 으로 인자를 바인딩할때 String()으로 형태를 지정해서 넘겨눴다니 4시간 이후부터 에러가 나기 시작했다.

그래서 문제를 해결할때 진짜 해결이 된건지 테스트하기가 정말.. 어려웠다... 소스코드 하나만 바꿔서 테스트할라해도 몇시간을 기다려야하니..

정말 왜 그런거지..? gpt에 물어보면 세션을 날려보던지 해봐라 그러던데.. 음..

* 이번에 참여한 오픈소스

해당 오픈소스는 ActivityPub 및 기타 표준(소위 fediverse) 으로 구동되는 연합 서버 앱을 구축하기 위한 TypeScript 라이브러리이다. 패더버스라는 개념도 activity pub이란 개념도 매우 생소하였지만 꽤나 흥미로워서 해당 오픈소스로 도전하게 되었다. 홈페이지 Github

* 후기

처음 오픈소스에 도전해보는거고, 사용을 안해본건 아니지만 대부분 내가 사용했던것들은 이미 많은 레퍼런스들이 있던 것들이였어서 참고할것들이 많았었는데 문서 하나하나 뜯어보는건 굉장히 낮선 경험이였고 또 한편으로는 진짜 메인테이너분 5년차라고 들었는데 대단하다.. 라는 생각밖에 들지 않았다.

내가 정말 엄청난것을 기여한것도 아니고 그저 쉬운 이슈들을 메인테이너분의 도움을 받아서.. 하나하나해보고 PR을 올려 머지까지 해보았는데, 색다른 기분이 들었다.

메인테이너분의도움으로 PR도 해보았는데 이렇게 내 이름도 릴리즈 노트에 작성해주시다니.. 너무 감사했습니다...!!

우아콘에 컨퍼런스에 갔을 때, 항상 고민이였던 모니터링툴에대해 듣게 되었고 검색했고 한번 해볼만 하다는 생각이 들어 시도하게 되었다.

구축할 환경은 실제 코드들이 돌아가는 서버들, 그리고 모니터링 서버 하나이다.

처음에 가장 헷갈렸던것들이 어떤걸 어느 서버에 깔아야하는가였지만 여러번 삽질과.. 시도 끝해 어느정도 감을 잡은 것 같다.

query-exporter, node-exporter 와 같은 관측을 위한 것들은 모니터링 대상 서버에, Grafana, Prometheus 와 같은 모니터링을 위한 도구는 모니터링서버에서 실행시키면 된다.

로그는 서버가 동작할 때 서버의 상태와 동작 정보를 시간 경과에 따라 기록된 결과입니다. 로그는 시스템의 오류와 문제들을 쉽게 찾아낼 수 있도록 도와줍니다. 반면, 메트릭은 시스템의 성능과 상태에 대한 통계적인 정보를 의미합니다. 메트릭을 잘 수집하면 시스템의 현재 상태를 손쉽게 파악할 수 있고, 사업 현황에 관한 유용한 정보를 얻을 수 있습니다. 가령, 메트릭은 DAU, Retension, CPU 사용량, 메모리 사용량 등이 있습니다.

아직은 베타에서 테스트중이라 완벽하게 정리되면 마저 작성하겠다. .

1. 모니터링 서버에 그라파나, 프로메테우스, 로키 파일을 설정해주기.

소스를 받아서, 각자의 환경에 맞는 셋팅을 해주기 readme를 (한국어로도 있음) 통해서 알맞게 셋팅을 해준다. https://github.com/Heesunni/grafana_loki_prometheus

이후에 잘 켜졌는지각각 확인

http://localhost:3003        //그라파나 확인
http://localhost:9100        //프로메테우스 확인
http://localhost:3100/ready //로키 확인

별다른 포트를 설정하지 않았다면 위의 포트들이 기본 포트이다.

이후에, 그라파나에 들어가서

Home > Connections > Add new connection

에 들어가 Loki, Prometheus를 각각 연결해주고( url 각각을 킨 주소를 작성하면 됨), 하단에 Save&test까지 눌러서 통과하면 끝!

2. 관측할 서버에 promtail, exporter을 심어서 실행시켜주기

관측대상 서버에 promtail, exporter을 알맞게 실행시킨다.

원래는 각각의 프로그램들을 따로 다운받아서 켜야하는데, 나의 경우 다 다운받아서 한 파일에 정리해두고 다른 서버에서도 같은 설정으로 사용하려고 이렇게 만들어놨다.

다른 블로그들을 보면 systemctl이나 service등록해서 사용하던데 나는 pm2로 프로그램들을 켰다.

https://github.com/Heesunni/promtail-exporter

3. 결론

그라파나에서 제공해주는 예시 대시보드들로 mysql, linux서버, nodejs 모니터링을 구축을 했고, loki는 원하는 대시보드가 없어서 한참 만지작만지작 거리다가 gpt와 구글링으로 대시보드를 하나 내가 직접 구축했고, 지금은 회사에 큰 모니터에 띄어져있다 ㅎ 아직 계속 연구중이지만 하나하나 대시보드가 업데이트가 되어가는중

아직 모르는거 투성이라 계속 연구중이지만, 회사에 띄어져있는 대시보드를 보면 뿌듯하다 ㅎ

이건 로키이용해서 쌓인 log분석해주는거 만들었다

++추가내용

docker로 그라파나, 로키, 프로메테우스를 작동시켰었는데.. 어느순간부터 용량이슈가 발생했다.

sudo du -sh /var/lib/docker/containers/* | sort -h

해당 명령어를 통해, docker에서 어떤파일이 가장 많은 용량을 차지하는지 확인을 해봤는데 로키의 로그파일이 21기가나 먹고있었다..

우선 불필요한 내용들을 삭제해주고

// docker 컨테이너별 Root FS 사용량 확인하기
docker system df

// docker 전체 정리( 사용하지 않는정보 정리)
docker system prune -af                

// 사용하지 않는 볼륨 확인
docker volume ls -f dangling=true   

//사용하지 않는 볼륨 삭제
docker volume prune -f                

// 로그파일 모두 삭제
for log in $(docker inspect --format='{{.LogPath}}' $(docker ps -aq)); do
  sudo truncate -s 0 "$log";
done

용량제한 설정 docker.yml파일에 추가하고,

--storage.tsdb.retention.time=90d
--storage.tsdb.retention.size=5GB

도커 데몬 설정도 변경

sudo nano /etc/docker/daemon.json

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

sudo systemctl restart docker

[참고링크]

사용자 수 모니터링 빠르게 시작하기 (Grafana + Prometheus) Prometheus/Grafana 모니터링 구축 Prometheus/Grafana 모니터링 구축 세상에서 제일 쉬운 Prometheus - Grafana 모니터링 설정 Node.js 모니터링 시스템 구축과 트러블 슈팅 사례(Part 1 — 모니터링 환경구축)

2024.11.05 2024 현대카드 Tech Talk 서울 용산구 이태원로 246 언더스테이지

.

간단정리

• 현대카드에서 ai기술을 접목시켜 내부에서의 데이터를 분류 및 커스텀할 수 있는 기능들을 개발함.
• 개발한 기술을 내부에서만이 아니라 해외회사에도 판매.
• 원 데이터들을 갖고 → 1차가공 → 2차가공 등등을 거쳐 태그로 데이터들을 분류
• 시뮬레이션 결과 세일러분들이 해당 ai를 이긴적은 없음
• kafka대신 에어플로우 사용
• 로그들을 모아 엘라스틱 서치 사용

.

후기

간단하게 정리하자면

2024.10.25 우아콘 삼성역 인터네셔널 호텔 https://2024.woowacon.com/

.

간단정리

• 백엔드세션기준으로 kafka를 많이 사용하는것같다.
• kafka를 사용하면서의 에로사항 및 대용량서버 핸들링 방법 → 비동기처리
• 대부분의 백엔드 세션이 대용량처리 및 워커에 치중된듯

.

후기

나름 듣고싶던 세션 전부 다 들을 수 있었고, 음향도 좋았고 정말 열심히 준비하셨다는게 보였다는 행사였다. 대용량 처리 및 메세지 큐 관련해서 고민이 많았는데 kafka라는걸 정말 많이 쓰는구나라는걸 깨달을 수 있었고 관련해서 한번 공부해야겠다라는 생각이 많이 들었다. 여러 열정적인 사람들과 같은공간에서의 좋은 에너지를 받을 수 있어서 좋았다.

그리고 개인적으로는 나름 3년차이고 곧 4년차가 다되어가는데 내가 하는건 빙산의 일각이라는 생각이 들었다. 관련해서 내가 앞으로는 더 어떻게 해야할까 라는 생각이 많이 들었던 하루였다.

.

세션을 들으며 간단 메모내용

https://www.notion.so/2024-12fa910a64f080b38321ca003ca8d4e3?pvs=4

2024.11.05 구글&메가존소프트 주최 삼성역 스페이스쉐어 세미나 정보 https://www.megazonesoft.com/appmodseminar-20241105/

간단정리

• 컨테이너 기반 서비스들, AI의 서버 배포 및 마이그레이션툴로는 GKE와 Cloud Run이 있다.
• GKE와 CloudRun의 각 특장점

.

내용 필기

https://www.notion.so/AI-Cloud-Native-AI-135a910a64f080138d41f736d86bef58?pvs=4

3. 읽음처리하기

. 상대방 읽음처리가 가장 어려운 난제중에 하나였다. 이 부분에서 정말 많이 헤맸는데 우선 헤맸던 포인트가 있다.

1. 앱이라면 괜찮지만 웹은 유저가 이 방에서 나가도 프론트에서 정확하게 트래킹이 어려웠다.
2. 그렇다보니 해당 채팅방에서 나가서 다른 채팅방에 갔는데, socket을 쏘니 방 a의 채팅에 방 b에서의 채팅이 가기시작하고, 혹은 a를 읽었는데 b방의 채팅을 읽음이 전송되었다.

이러한 이슈들로 인해 앞선 고생기(1)에서의 2번(전면 구조변경) 을 채택하고, socket의 room에 저장하는 방식들을 전면 수정을 했다.

1. 상대방이 A방에 채팅을 보낸다. 그러면 A방의 다른유저에게 new채팅에 대한 socket을 보내게 된다.
2. A방에 내가 있다면(채팅창에 활성화 상태라면) 이때 내가 해당 채팅방에서 읽었음에 대한 정보를 서버로 보내게끔 했다.
3. 이렇게 "나 읽음" 이라는 socket을 수신받는다면 서버에서는 내가 아닌 상대방이 보낸 메세지를 모두 읽음처리하고, A방에 읽음처리가 완료되었음을 내가아닌 다른사람에게보내, 상대방이 내 채팅을 읽었음을 알 수 있게 한다.
4. 내가 해당 파티채팅을 리로딩할때도 마찬가지로 읽음처리 루틴을 실행시킨다.

이 외에도,

최대한 서로 다른방의 간섭을 막아주기 위해, 채팅방에서 나와 목록으로 들어갈때 모든 방에서 leave를 했고, 새로운 채팅방에 접속할때 또한 그 방을 제외한 나머지 방에서 leave하도록 하는 등의 다양한 방법을 써서 구현을 했다.

물론 끝마쳤다고 끝은 아니고.. 뒤에 잔 버그들 관리는 계속해야하지만..

링링이들은 더 귀엽고 예쁘게 변했고, 처음에는 똑같다고 생각했던 UI도 더 예뻐진게 쓰면쓸수록 체감하게 된다. ( 버전업 마이그레이션 테스트한다고 이전버전으로 돌렸다가 버전업시키고 했을때마다 예전께 투박하다고 느껴졌다 )

버전업시 가장 어려웠던점.

1. 기존에 돌아갔던 로직들은 그대로 잘 돌아가야한다.
2. 기존의 DB구조 틀에서 많이 벗어나면 안된다. 쓰레기데이터도 품고가야함..
3. 운영을 위한 데이터셋이 전부 변경되어 그 데이터셋 구조를 맞춰야하지만.. 기존의 값들도 잘 돌아가게해야한다..

등등.. 즉,

달리는 마차의 바퀴는 바꾸지만, 바꾸는 과정에서도 잘 돌아가게 하는것이 가장 힘든 작업이었다.

로직들, 저장하는 방법, 불러오는방법 모~~ 두 변경되었는데 기존꺼는 기존대로 잘 돌아가야한다니.. 정말 새로운걸 만드는것보다 이게 몇배는 힘들었다.

거기다가, 2.5라이브는 계속 돌아가고있는데 2.5라이브 서버대로 업데이트 해야하지.. 그러면 그 파일은 3.0서버에도 적용시키고.. 로컬에도 적용시키고 3.0 베타에도 적용시키고..

한번 업데이트 할때마다 온 파일들을 전부 적용시켜야했다.. 하나만이 아니고 어드민, 채팅 전부 그랬다..

한번에 여러 파일들을 관리하다보니 정말 너무 헷갈리고 어려움이 많았는데 인력이 부족한 상황에, 기존의 라이브버전은 계속 돌아가고 있으며 추가적으로 업데이트가 지속적으로 필요했던 상황이라 3.0 업데이트가 많이 딜레이가 지속되어 정말 힘들었다..

그 과정에서 얻는것도 있었고, 정말 건들기 무서웠었던 레거시코드도 다 분해해서 수정하고 다양한 경험을 했다. ( 정말 무서운 경험이었다)

원래 코드는 개인의 자유이자 돌아가기만 하면 그만이라 하시던 사수님이 내 코드가 점점 잼있어지고있다고했다. 점점 활용성을 기반으로 코드를 만들고있다고 ( 모듈화를 하려고 노력했더니 그런듯! )

아직 계속 이슈 모니터링을 하고 최적화 및 수정을 해야하지만, 정말 나를 너무나도 길었던 작업 끝내서 너무 뿌듯하고 이 경험이 나를 더 성장시켰을것이라고 믿는다!

예쁜 링키드 구경오세요 https://linkid.pw/

분명 평소와 같이 서버들을 띄우는데 외부에서 접속이 안되었다.. 로그를 봐도 api가 날라오는 흔적도 안보이고 nginx의 로그를 봐도 어떠한 패킷도 넘어오지 않았다.

이럴땐, tomcat이나 아파치가 켜저있지 않은지 한번 보자. 그리고 nginx를 restart를 시켜보자!

그랬더니.. 접속이 되었다..