예전에는 하나하나 검색하고 찾아보면서 판단했었는데.. 지금은 일단 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를 시켜보자!

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

mkdir config .ssh/

config파일에 아래 코드들을 상황에 맞게 작성한다.

일반 ssh연결

Host ${원하는 이름}
Hostname ${hostname}
User ${접속할 유저 이름}
IdentityFile {만약에 key가 있다면 key위치}

포워딩 ssh 연결

Host ${원하는 이름} A
  HostName ${hostname}
  Port ${포트번호}
  User ${접속할 유저 이름}


Host ${원하는 이름} B
  HostName ${hostname}
  User ${접속할 유저 이름}
  IdentityFile {만약에 key가 있다면 key위치}
  ProxyJump ${중간 포워딩 서버이름} A

이렇게하면 로컬 -> A -> B 로, 즉 결국 로컬에서 B로 SSH 접속이 가능하다. hostname에는 ip주소든 도메인이든 작성하면 된다.

이렇게 설정 이후에

ssh ${내가 설정한 연결 이름}

을 cmd창에 작성하면 해당 서버로 접속 가능하다.

번외. mysql workbench에서 포워드해서 접속

REST Client

Id: humao.rest-client Description: REST Client for Visual Studio Code Version: 0.25.1 Publisher: Huachao Mao VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=humao.rest-client

Prettier - Code formatter

Id: esbenp.prettier-vscode Description: Code formatter using prettier Version: 10.4.0 Publisher: Prettier VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode

Path Intellisense

Id: christian-kohler.path-intellisense Description: Visual Studio Code plugin that autocompletes filenames Version: 2.9.0 Publisher: Christian Kohler VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=christian-kohler.path-intellisense

WSL

Id: ms-vscode-remote.remote-wsl Description: Open any folder in the Windows Subsystem for Linux (WSL) and take advantage of Visual Studio Code's full feature set. Version: 0.88.2 Publisher: Microsoft VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl

TODO Highlight

Id: wayou.vscode-todo-highlight Description: highlight TODOs, FIXMEs, and any keywords, annotations... Version: 1.0.5 Publisher: Wayou Liu VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=wayou.vscode-todo-highlight

Remote - SSH

Id: ms-vscode-remote.remote-ssh Description: Open any folder on a remote machine using SSH and take advantage of VS Code's full feature set. Version: 0.112.0 Publisher: Microsoft VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-ssh

Remote - Tunnels

Id: ms-vscode.remote-server Description: Connect to a remote machine through a Tunnel Version: 1.5.2 Publisher: Microsoft VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=ms-vscode.remote-server

이전에 취준생 및 대학생 시절.. 인터넷 강의로 socket을 활용한 채팅을 만들어본적이있다.

회사에서 작년에 채팅서버를 새로 만들어야할것같다 라는 말을 들었을 때

그때랑 별다를것없고 어렵지 않을것같은데..

라는 아주 무시무시한 착각을 하고서 덜컥 받아버린다. 그때 깨달았었어야 했다.. 왜.. 나의 사수가 나를 그런눈을 처다봤는지..

아무튼간에 작년에 채팅서버를 만들고 1년이지난지금에서 생각해보면 가장 헤맸던건

1. 왜.. 인강 따라했을때처럼 소켓연결이 부드럽지도 않고 연결이 안될까...? 2. 요구사항에 맞게 내가 배웠던걸 응용만 하면 될 뿐인데 이게 난이도가 이렇게 올라간다고..?

딱 이 2가지였다.

1. webocket의 프론트와의 연결

혼자서했을땐 로컬서버를 띄우고 pug파일이나 대강 만들어서 테스트를 했었기에 연결이 어렵지 않았는데.. 막상 베타서버에 올려놓으니 통신이 안되는거다..

몇일에 걸쳐 이것도 했다가 저겄도 했다가 뻘짓하고 구글링해서 검색한 결과 nginx셋팅을 통해 해결할 수 있었다.

    location /socket.io/ {
        ....
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

이후에

sudo systemctl restsart nginx

를 통해 변경한 설정을 적용시키면 된다.

이때 nginx를 처음 만져보았었는데 여기서 나와같은경우는 해결법을 찾고도 저 많은 nginx설정중에 어디다가 넣어야하는지 몰라서 정말 nginx설정을 계속 하나하나 바꿔가며 적용시키면서 했었다. 사실 지금도 저게 맞는건지는 모르겠으니 각자 상황에 따라서 변경해보길 바란다.

다른건 모르겠지만 가장 중요한 코드는 location이 아니라 그 내부에 4줄이니 저 4줄을 어디다가 놓아야할지를 각자 상황에 맞추도록 하자.

https://velog.io/@habins226/Nginx-WebSocket%EC%9D%84-%EC%9C%84%ED%95%9C-%EC%84%A4%EC%A0%95-%EB%B0%A9%EB%B2%95

블로그보니까 나말고도 진짜 다들 고생많이한것같다.. 저기에 더 자세한 설명이 있어 첨부한다.

2. webocket관련 설계 다시..

거기다가, 대강 설계를 조금만 틀어서 저장구조랑 만들면 되겠지 했지만.. 소켓은 연결될때마다 socket id가 변경되었고.. 사람들이 권장하지는 않는 방법이지만, socket과 api통신을 둘다 하려니 정말 막막했다..

api통신을 하자니 broadcast로써만 작동을 했다.. target을 지정하려해도 reqest값에서 socket id 받는것에 실패를 하는바람에 나빼고 보내는것도 실패 ....

그래서 그냥 api는 broadcast만으로 동작할 수 있게 해볼까..? 라는 헛생각을 잠시마나 했었다.

거기다가... 이전에는 node + socket으로 만들었었는데 이번엔 nest + websocket 이라 레퍼런스 또한 많이 없었어서 공식문서와 맨땅의 헤딩으로 겨우겨우 만들었다. 회사내에 다른분들도 socket쪽은 아에 모른다고하시니.. 우선은 내가 간 길이 정답이다 하는수밖에..

이 부분에 대해서는 말로만작성하기 너무 힘들어서 추후에 시간이 된다면 ... 작성하는걸로..!

. . . .

진짜 만들면서 느꼈던건.. 카카오톡.. 라인.. 등등 진짜 엄청난거구나....

1. Ubuntu에 도커 설치/docker hub계정생성

//우분투 시스템 패키지 업데이트
$ sudo apt-get update

//필요한 패키지 설치
$ sudo apt-get install apt-transport-https ca-certificates curl gnupg-agent software-properties-common

//Docker의 공식 GPG키를 추가
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

//Docker의 공식 apt 저장소를 추가
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

// 시스템 패키지 업데이트
$ sudo apt-get update

//도커 실행상태 확인
$ sudo systemctl status docker

//도커 실행
$ sudo docker run hello-world

https://velog.io/@osk3856/Docker-Ubuntu-22.04-Docker-Installation 참조 https://docs.docker.com/desktop/install/windows-install/ 윈도우 데스트탑 깔기 주소

.

2. 한 프로젝트를 image로 저장시키기

// {project1} root 폴더로 이동
$ cd project

// root에 Dockerfile 파일 만들기
$ mkdir Dockerfile

// Dockerfile파일에 붙여넣기 (아래 파일은 상황에 맞게 조정시켜주기, 노드기준임)
FROM node:18-alpine
WORKDIR /app
COPY . .
RUN yarn install --production
CMD ["node", "src/index.js"]
EXPOSE 3000

//도커로 해당 파일 빌드하기
$ docker build -t {Dockerhub 이름(user 이름)/이미지 이름}:tag이름

//도커로 이미지 실행시키기(실행시킬 포트:연결될 포트)
$ docker run -dp 3000:3000 {Dockerhub 이름(user 이름)/이미지 이름}:tag이름

//container생성 확인, 제대로 실행되었는지 {localhost:포트} 로 이동하여 확인하기
$ docker ps

3. docker hub에 업로드하기

//로그인
$ docker login

//hub에 만든 container push하기
$ docker push {Dockerhub 이름(user 이름)/이미지 이름}:tag이름

4. 협업하기

1) cmd로 하기 : 아래 명령어로 pull받아서 실행하기

$ docker pull {Dockerhub 이름(user 이름)/이미지 이름}:tag이름
$ docker run -p 3000:8080 {Dockerhub 이름(user 이름)/이미지 이름}:tag이름

2) docker desktop에서 pull받아서 실행하기

(https://velog.velcdn.com/images/ssunn_ni/post/76138857-68c6-4891-8f44-7f80cdd5e2fd/image.png 출처