팀프로젝트 면접 예상 질문 답변 정리입니다.

대상 코드 폴더: AI_LifeLong_WM_Wealth_Management
문서 작성일: 2026-06-19
주제: LangGraph state 흐름, MySQL/Neo4j 병행 사용, RAG와 Evidence Graph 차이, fallback, 테스트, AI 생성 코드 검증

1. "그럼 LangGraph에서 state는 어떻게 흘렀나요????"

간단한 답변

LangGraph의 SharedState를 모든 에이전트가 공유하는 계약으로 두고,

event → routing → parent run 생성 → financial_health → retirement 입력 조립 → chat/report 분기 → evidence graph 적재 → parent finalize

순서로 흘렀습니다. analysis_results는 키 단위로 병합하고, evidence_refs, rule_checks, candidate_relations 같은 리스트성 결과는 append reducer로 누적해서 여러 에이전트 결과가 덮어써지지 않게 했습니다.

자세한 답변

저희 프로젝트에서 LangGraph state는 단순 dict가 아니라 SharedState라는 명시적 TypedDict 계약으로 관리했습니다. 이 state에는 요청 이벤트, 라우팅 결과, 고객 스냅샷, 분석 결과, 근거 참조, 룰 체크, 후보 관계, child run, 에러, 준법 결과 등이 들어갑니다.

API 요청이 들어오면 event에 workflow_type, customer_id, chat/report 모드 같은 입력이 들어갑니다.
route 노드가 routing.selected_agents, routing.workflow_type, routing.mode를 결정합니다.
retirement 계열처럼 여러 agent가 필요한 경우 prepare_parent가 parent analysis_run을 만들고 meta.run_id에 넣습니다.
먼저 financial_health 노드가 실행되고, 결과는 analysis_results.financial_health, evidence_refs, rule_checks, candidate_relations로 누적됩니다.
retirement가 필요한 경우 build_orchestrator_input이 FH 결과를 재사용해서 retirement 입력을 조립합니다.
routing.mode에 따라 chat이면 build_retirement_context → retirement_chat, report면 retirement_report로 분기합니다.
마지막에 persist_graph가 누적된 근거 데이터를 Evidence Graph로 저장합니다.
다중 agent 실행이면 finalize_parent가 DB의 child run 상태를 기준으로 parent run을 마감합니다.

코드 출처: SharedState 병합 계약

AI_LifeLong_WM_Wealth_Management/src/app/state/shared_state.py:19

def merge_analysis_results(
    left: dict[str, Any] | None,
    right: dict[str, Any] | None,
) -> dict[str, Any]:
    if not left:
        return dict(right) if right else {}
    if not right:
        return dict(left)
    return {**left, **right}

class SharedState(TypedDict, total=False):
    meta: dict[str, Any]
    event: dict[str, Any]
    routing: dict[str, Any]
    data_snapshot: dict[str, Any]
    analysis_results: Annotated[dict[str, Any], merge_analysis_results]
    evidence_refs: Annotated[list[dict[str, Any]], operator.add]
    rule_checks: Annotated[list[dict[str, Any]], operator.add]
    candidate_relations: Annotated[list[dict[str, Any]], operator.add]
    child_runs: Annotated[list[dict[str, Any]], operator.add]
    agent_errors: Annotated[list[dict[str, Any]], operator.add]

코드 출처: Supervisor 그래프 흐름

AI_LifeLong_WM_Wealth_Management/src/app/graphs/supervisor.py:500

def build_supervisor_graph(container: "Container") -> Any:
    builder = StateGraph(SharedState)
    builder.add_node("route", route)
    builder.add_node("prepare_parent", build_prepare_parent_node(container))
    builder.add_node(_FH, build_financial_health_node(container))
    builder.add_node(_ORCH, build_orchestrator_input_node(container))
    builder.add_node(_CTX, build_retirement_context(container))
    builder.add_node(_CHAT, build_retirement_chat_node(container))
    builder.add_node(_REPORT, build_retirement_report_node(container))
    builder.add_node("persist_graph", build_persist_graph_node(container))
    builder.add_node("finalize_parent", build_finalize_parent_node(container))

    builder.set_entry_point("route")
    builder.add_edge("route", "prepare_parent")
    builder.add_conditional_edges("prepare_parent", _route_path, _route_map)
    builder.add_conditional_edges(_FH, _after_fh, _after_fh_map)
    builder.add_conditional_edges(_ORCH, _retire_mode, _mode_map)

2. "MySQL과 Neo4j를 왜 같이 썼나요?"

간단한 답변

MySQL은 운영 데이터의 정합성과 트랜잭션을 책임지는 SSOT로 썼고, Neo4j는 분석 결과의 근거 관계를 탐색하기 위한 Evidence Graph 백엔드로 썼습니다. 고객, 계좌, 거래, 분석 run, 시뮬레이션 결과처럼 정형 데이터는 MySQL에 저장하고, 고객 → 위험 룰 → 근거 데이터처럼 관계를 따라 설명해야 하는 부분은 Neo4j에 저장했습니다.

자세한 답변

두 DB를 같이 쓴 이유는 저장하려는 데이터의 성격이 달랐기 때문입니다. MySQL은 고객 프로필, 계좌, 잔액, 거래, 분석 run, simulation, generated response 같은 정형 운영 데이터를 저장합니다. Neo4j는 고객이 어떤 룰을 trigger했고, 그 룰이 어떤 evidence row에 의해 뒷받침되는지 탐색하기 위한 관계 저장소입니다.

즉 MySQL은 "사실과 결과 저장", Neo4j는 "근거 관계 탐색"입니다. 개발 환경에서는 Neo4j 장애 시 MySQL graph table로 graceful fallback하고, demo/prod에서는 조용한 저장소 변경을 막기 위해 fail-fast하도록 했습니다.

코드 출처: Neo4j 우선, 연결 불가 시 환경별 fallback

AI_LifeLong_WM_Wealth_Management/src/app/graph/graph_builder.py:91

def resolve_graph_backend(db: Session) -> ResolvedBackend:
    settings = get_settings()
    if settings.graph_backend.strip().lower() != "neo4j":
        return ResolvedBackend(MySQLGraphRepository(db), "mysql", False)

    from app.core.neo4j import can_connect, get_database, get_driver

    if can_connect():
        from app.graph.neo4j_repository import Neo4jGraphRepository
        return ResolvedBackend(Neo4jGraphRepository(get_driver(), get_database()), "neo4j", False)

    if settings.graph_fallback_to_mysql:
        return ResolvedBackend(MySQLGraphRepository(db), "mysql", True)

    raise RuntimeError("Neo4j 연결 불가 + fallback 비활성")

3. "RAG와 Evidence Graph는 뭐가 다르죠?"

간단한 답변

RAG는 답변 생성이나 준법 검증 전에 외부 문서 조각을 검색해서 LLM 입력에 넣는 검색 계층입니다. Evidence Graph는 분석이 끝난 뒤 "이 결과가 어떤 고객 데이터와 어떤 룰, 어떤 근거 때문에 나왔는지"를 저장하고 조회하는 설명/감사 계층입니다. RAG는 생성 전 context retrieval이고, Evidence Graph는 생성/분석 후 provenance tracking입니다.

자세한 답변

구분	RAG	Evidence Graph
시점	답변 생성/검증 전	분석 결과 생성 후
목적	LLM에 외부 문서 context 제공	결과의 원인과 근거 추적
저장소	Milvus/Zilliz vector store	Neo4j 또는 MySQL graph table
데이터 형태	문서 chunk, score, source	node, edge, path, explanation
예시	법령 조문 검색	고객 → 위험룰 → 근거 row

코드 출처: RAG tool fallback

AI_LifeLong_WM_Wealth_Management/src/app/agents/retirement/tools/rag_tools.py:15

def build_rag_search(vector_store: Any = None):
    @tool
    def rag_search(query: str, top_k: int = 3) -> dict:
        if vector_store is None:
            return {
                "results": [{"text": "RAG 미연결 (Milvus stub).", "score": 0.0, "source": "placeholder"}],
                "source": "placeholder",
                "query": query,
            }
        try:
            results = vector_store.search(query, top_k=top_k)
            return {"results": list(results), "source": "milvus", "query": query}
        except Exception as exc:
            return {"results": [], "source": "milvus_error", "error": str(exc), "query": query}

코드 출처: Evidence Graph path 생성

AI_LifeLong_WM_Wealth_Management/src/app/graph/graph_builder.py:232

for rel in state.get("candidate_relations") or []:
    from_id = ensure_entity(rel.get("from") or {})
    to_id = ensure_entity(rel.get("to") or {})
    trig_edge = repo.insert_edge(
        customer_id=customer_id, from_id=from_id, to_id=to_id,
        edge_type=rel["edge_type"], weight=rel.get("weight", 1.0),
    )
    ev_id = rel.get("evidence_id")
    if ev_id and ev_id in ev_node:
        evidence_node_id = ev_node[ev_id]
        evidenced_edge = repo.insert_edge(
            customer_id=customer_id, from_id=to_id, to_id=evidence_node_id,
            edge_type="EVIDENCED_BY", weight=rel.get("weight", 1.0),
        )

4. "장애 났을 때 fallback은 어떻게 했나요?"

간단한 답변

Neo4j 연결 장애는 dev에서는 MySQL graph table로 fallback하고, demo/prod에서는 fail-fast했습니다. RAG 미연결이나 검색 실패는 placeholder 또는 빈 결과로 반환했습니다. LLM이 없거나 실패하면 결정론 기반 baseline이나 템플릿 응답으로 대체했습니다. 다중 agent 중 하나가 실패하면 전체를 죽이지 않고 agent_errors와 child run FAILED로 격리했습니다. 준법 검증은 안전이 중요해서 LLM 응답 파싱 실패 시 PASS가 아니라 NOT_PASS로 fail-closed했습니다.

자세한 답변

fallback은 장애 성격에 따라 나눴습니다. 결과 산출을 계속해도 되는 graph/RAG/일부 LLM 장애는 graceful degrade했고, 준법 검증처럼 잘못 통과시키면 위험한 영역은 fail-closed했습니다.

Evidence Graph 저장 실패: 분석 결과는 보존하고 GraphStatus(ok=False)로 흡수합니다.
Neo4j 연결 실패: dev/test는 MySQL fallback, demo/prod는 fail-fast입니다.
RAG 미연결/검색 실패: placeholder 또는 source=milvus_error를 반환합니다.
LLM 미연결/실패: retirement 계산은 deterministic baseline으로 대체합니다.
다중 agent 일부 실패: 실패 agent만 child run FAILED로 기록하고 다른 결과는 유지합니다.
Compliance 파싱 실패: PASS가 아니라 NOT_PASS 처리합니다.

코드 출처: Evidence Graph best-effort

AI_LifeLong_WM_Wealth_Management/src/app/graph/graph_builder.py:305

try:
    result = build_evidence_graph(db, state, repo)
    return GraphStatus(ok=True, result=result, backend_used=backend_used, fell_back=fell_back)
except Exception as exc:
    logger.warning("evidence graph 적재 실패 (best-effort, 결과는 보존): %s", exc)
    return GraphStatus(ok=False, error=str(exc)[:1000], backend_used=backend_used, fell_back=fell_back)

5. "테스트는 어떻게 작성했나요?"

간단한 답변

단위 테스트, 통합 테스트, API 테스트로 나눠 작성했습니다. 단위 테스트는 DB/LLM 없이 reducer, graph routing, fallback, rule/scoring, compliance branch를 검증했고, 통합 테스트는 sqlite in-memory나 실제 연결 가능한 Neo4j를 이용해 Evidence Graph 저장/조회 parity를 검증했습니다. LLM이 필요한 부분은 fake LLM이나 scripted mock을 써서 외부 API 없이 결정론적으로 검증했습니다.

자세한 답변

State 계약 테스트: FH 결과가 정해진 SharedState key로 변환되는지 확인했습니다.
Supervisor graph 테스트: fake container와 monkeypatch로 FH-only, FULL_DIAGNOSIS, partial failure를 검증했습니다.
Evidence Graph 통합 테스트: sqlite in-memory로 node/edge/path 적재, rollback, best-effort를 검증했습니다.
Neo4j/MySQL parity 테스트: 같은 state를 두 backend에 적재하고 의미 구조가 같은지 비교했습니다.
LLM fallback 테스트: fake LLM으로 외부 API 없이 tool-calling, fallback, retry limit를 검증했습니다.
Compliance loop 테스트: rewrite 루프가 MAX_REWRITE로 제한되는지 검증했습니다.

코드 출처: Supervisor parent/child run 분리 테스트

AI_LifeLong_WM_Wealth_Management/tests/unit/test_supervisor_graph.py

def test_full_diagnosis_report_sequential_and_dual_run_id(monkeypatch):
    graph = sup.build_supervisor_graph(_fake_container(skipped=False))
    final = graph.invoke({"event": {"workflow_type": "FULL_DIAGNOSIS", "customer_id": 900002}})

    assert final["routing"]["selected_agents"] == ["financial_health", "retirement"]
    assert "financial_health" in final["analysis_results"]
    assert "retirement_simulation" in final["analysis_results"]

    parent_run_id = final["meta"]["run_id"]
    child_run_id = final["retirement_run_id"]
    assert child_run_id != parent_run_id

6. "AI가 만든 코드 검증은 어떻게 했나요?"

간단한 답변

AI가 만든 코드는 바로 믿지 않고, 먼저 계약을 코드와 테스트로 고정했습니다. SharedState key, evidence_id 존재, parent/child run id 분리, graph rollback, compliance fail-closed 같은 핵심 불변식을 테스트로 만들었습니다. LLM이 들어가는 부분은 fake LLM/scripted LLM으로 외부 API 없이 재현 가능하게 검증했고, graph backend는 MySQL/Neo4j parity 테스트로 같은 구조를 반환하는지 확인했습니다.

자세한 답변

AI 생성 코드 검증 기준은 "동작해 보인다"가 아니라 "계약을 깨지 않는다"였습니다. 금융/자산관리 프로젝트라서 설명 가능성, 준법, 장애 처리, 데이터 정합성을 중심으로 불변식을 테스트했습니다.

SharedState key와 reducer 계약을 고정했습니다.
발동 룰에는 반드시 evidence_id가 있어야 하도록 validator와 테스트를 두었습니다.
graph 적재는 rollback 테스트로 원자성을 검증했습니다.
LLM 기반 코드는 fake LLM으로 tool-calling loop와 fallback을 검증했습니다.
준법 검증은 fail-closed로, 파싱 실패가 PASS가 되지 않도록 했습니다.
MySQL/Neo4j backend는 parity 테스트로 같은 의미 구조를 반환하는지 확인했습니다.

코드 출처: Evidence validator

AI_LifeLong_WM_Wealth_Management/src/app/graph/validator.py

def validate(state: SharedState) -> list[str]:
    problems: list[str] = []
    if _run_id(state) is None:
        problems.append("run_id 누락")

    evidence_refs = state.get("evidence_refs") or []
    evidence_ids = {ref.get("evidence_id") for ref in evidence_refs}

    for rc in state.get("rule_checks") or []:
        if not rc.get("triggered"):
            continue
        ev_id = rc.get("evidence_id")
        if not ev_id:
            problems.append(f"발동 룰 {rc.get('rule_code')} 에 evidence_id 없음")
        elif ev_id not in evidence_ids:
            problems.append(f"룰 {rc.get('rule_code')} 의 evidence_id={ev_id} 가 evidence_refs 에 없음")

면접 답변용 핵심 문장 모음

LangGraph state는 SharedState로 고정했고, agent 결과가 서로 덮어쓰이지 않게 reducer를 붙였습니다.
FH와 retirement는 병렬이 아니라 FH 결과를 retirement가 소비하는 순차 흐름입니다.
다중 agent 실행에서는 meta.run_id는 parent run, retirement_run_id는 child run으로 분리했습니다.
MySQL은 운영 데이터의 SSOT, Neo4j는 설명 가능한 근거 관계 탐색용입니다.
RAG는 생성 전 검색이고, Evidence Graph는 생성 후 근거 추적입니다.
fallback은 장애 성격에 따라 달랐습니다. graph/RAG/LLM은 graceful degrade, compliance 파싱 실패는 fail-closed입니다.
테스트는 외부 API 없이 fake LLM, sqlite in-memory, monkeypatch로 핵심 계약을 재현 가능하게 검증했습니다.