2026-06-15 시니어 에이전트 아키텍트(Senior Agent Architect) 면접 질문

Q1: [스트리밍 UI 렌더링 중단 및 상태 복구]

난이도: Senior
분야: 프로덕션 AI / Agent 아키텍처
관련 업무: 오늘 Flutter 채팅 인터페이스의 AI 콘텐츠 스트리밍 타이핑 효과(Typewriter effect) 중단 문제를 수정하며, 텍스트 추가 로직과 줄바꿈 처리 결함을 조사함.

문제:
AI 대화 Agent의 프론트엔드 전시에서 SSE (Server-Sent Events)를 통해 AI의 응답 내용을 스트리밍합니다. 간헐적으로 타이핑 효과가 중단되어 이후 내용이 표시되지 않는 현상이 발생합니다. 이를 수정하려 할 때, 실수로 절단(Truncation) 로직을 수정하면 첫 줄의 텍스트만 표시되는 문제가 발생합니다. 다음 상황들을 처리할 수 있는 범용적인 스트리밍 상태 업데이트 메커니즘을 설계하세요:

1. 네트워크 지터(Jitter)로 인한 데이터 패킷의 순서 뒤바뀜 또는 지연.
2. Markdown 렌더링 라이브러리가 닫히지 않은 태그를 절단할 때 발생하는 백스크린(White screen) 현상.
3. 상태 업데이트의 동시성 경합(Race condition)으로 인해 텍스트가 추가되지 않고 덮어씌워지는 현상.

핵심 상태 관리 코드 로직을 제시하고, "백엔드 데이터 전송 중단"과 "프론트엔드 렌더링 로직 오류"를 빠르게 구분하기 위한 로그 시스템 설계 방법을 설명하세요.

답변 요점:

1. 핵심 아이디어:
   **누적기 패턴 (Accumulator pattern)**과 **불변 상태 업데이트 (Immutable state update)**를 결합하여 사용합니다. 스트리밍 조각(Chunk)을 처리하기 위해 버퍼(Buffer)를 도입하고, Markdown 렌더링이 "결함 허용(Fault tolerance)" 또는 "지연 렌더링(Lazy rendering)" 메커니즘을 갖추도록 합니다. 핵심은 "네트워크 데이터 수신"과 "UI 렌더링"을 분리(Decoupling)하는 것입니다.

2. 기술 솔루션 (의사 코드 예시, React/Flutter 공용 로직 시뮬레이션):

# 의사 코드: 스트리밍 상태 관리자
class StreamMessageHandler:
    def __init__(self, message_id):
...

1. 트레이드오프 분석:

   • 선택 A (전체 재그리기 vs 증분 렌더링): Markdown 엔진에 전체를 다시 전달하는 것은 성능 비용이 크지만, 형식의 정확성을 보장할 수 있습니다 (닫히지 않은 **가 전체 문단을 굵게 만드는 현상 방지). 증분 렌더링(Incremental rendering)은 성능은 좋지만 스타일 깜빡임이나 렌더링 오류가 발생하기 매우 쉽습니다.
   • 결정: 긴 텍스트(>500자)의 경우 디바운싱(Debouncing)을 결합한 전체 재그리기를 채택하고, 짧은 텍스트의 경우 증분 렌더링을 시도할 수 있습니다. 하지만 버그 수정 단계에서는 데이터 무결성을 보장하기 위해 전체 재그리기를 우선시합니다.

2. 반면교사 (Lessons Learned):

   • 추가 로직은 그대로 두고 절단 로직만 수정함: 오늘 수정 중에 텍스트가 너무 길어 절단된 것이라고 잘못 판단하여 Split 로직을 수정했고, 그 결과 첫 줄만 표시되었습니다. 실제 문제는 setState 시 현재의 fullText가 아닌 이전 상태인 oldText를 가져온 데 있었습니다.
   • 로그 부재: chunk의 원시 바이트(Raw bytes)를 출력하지 않았다면, 백엔드가 데이터를 보내지 않은 것인지 프론트엔드가 데이터를 놓친 것인지 영원히 알 수 없었을 것입니다.

3. 정량적 지표:

   • "스트리밍 중단율" 모니터링: (예상 Token 수 - 실제 렌더링된 Token 수) / 예상 Token 수로 정의합니다. 수정 전 약 2%에서 수정 후 0.01%로 낮추어야 합니다.
   • 엔드 투 엔드(End-to-End) 지연 시간: Full Content 렌더링 완료 시간과 SSE 종료 시간 사이의 차이.

면접관 관점:

• 후보자가 "불완전한 스트림을 파싱할 때 Markdown의 AST Parser 동작"(예: *가 단독으로 나타나면 이후 문자를 삼켜버리는 현상 등)을 언급한다면, 실제로 스트리밍 렌더링을 경험해 본 것으로 간주합니다 (가산점, +20).
• 후보자가 단순히 "setInterval을 사용한 폴링"이나 "직접 innerHTML += chunk를 사용한다"라고 말한다면, 복잡한 스트리밍 시나리오를 경험하지 못했으며 XSS 위험과 렌더링 성능을 이해하지 못한 것으로 간주합니다 (감점, -20).
• 흔한 오답: "이것은 백엔드 문제입니다. 백엔드에서 빨리 보내라고 하세요."
• 추가 질문 가능: "만약 SSE 연결이 끊어졌다면, 프론트엔드는 전송이 완료된 것인지 네트워크가 끊긴 것인지 어떻게 알 수 있습니까? HTTP 상태 코드나 이벤트 리스너를 어떻게 설계했습니까?"

Q2: [Title Agent의 다단계 오케스트레이션 및 평가]

난이도: Senior
분야: Agent 아키텍처 / 프롬프트 엔지니어링 (Prompt Engineering)
관련 업무: 오늘 ai-developer-knowledge-hub 프로젝트의 Title Agent를 검수했습니다. 해당 Agent는 3개의 후보 제목을 생성하고, 점수를 매긴 뒤 최적의 제목을 선정해야 합니다.

문제:

당신은 Title Generation Agent를 설계해야 합니다. 입력값은 긴 텍스트이며, 출력값은 단 하나의 최적의 제목입니다. 품질을 보장하기 위해 단순히 LLM이 하나의 결과만 생성하게 해서는 안 됩니다. 당신은 다음과 같은 워크플로우(Workflow)를 설계해야 합니다: 먼저 N개의 후보를 생성하고, 그 N개의 후보를 평가한 뒤, 마지막으로 가장 높은 점수를 받은 것을 선정합니다. 여기에는 세 가지 아키텍처(Architecture) 방안이 있습니다. 당신은 어떤 것을 선택하겠으며, 그 이유는 무엇입니까?

방안 A: Single Prompt를 사용하여, LLM이 한 번에 JSON [{"title": "...", "score": 10}, ...]을 출력하도록 요청합니다.
방안 B: ReAct 루프를 사용하여, 첫 번째 단계에서는 Tool Call로 후보를 생성하고, 두 번째 단계에서는 Tool Call로 평가를 진행합니다.
방안 C: DAG (Directed Acyclic Graph, 유향 비순환 그래프) 오케스트레이션(Orchestration)을 사용하여, 3개의 독립적인 LLM 인스턴스를 병렬로 호출하여 각각 1개의 제목을 생성하게 한 뒤, 이를 하나의 Judge Agent로 모아 평가합니다.

코드 아키텍처(의사 코드, Pseudo-code)를 제시하고, 토큰(Token) 비용과 응답 지연 시간(Latency) 측면에서의 트레이드오프(Trade-off)를 분석하세요.

답변 핵심 포인트:

1. 핵심 아이디어:
   **방안 C (DAG 오케스트레이션)**를 선택합니다. 제목 생성은 "발산적 작업(Divergent Task)"이므로, 병렬 호출을 통해 첫 글자 지연 시간(TTFT)을 줄이고 다양성을 높일 수 있습니다. 반면 평가는 "수렴적 작업(Convergent Task)"이므로 전체적인 관점이 필요합니다. 방안 A는 점수가 부풀려지거나 후보들이 유사해지는 문제가 발생하기 쉽고, 방안 B는 직렬(Serial) 방식이라 지연 시간이 누적됩니다.

2. 기술 방안 (LangChain/LangGraph 스타일의 의사 코드):

from typing import List

# 1. 병렬 생성 노드
...

1. 트레이드오프 분석:

   • 방안 A (Single Prompt): 비용이 가장 낮지만(1회 호출), LLM은 보통 자신의 작업에 대해 편향된 평가를 내리는 경향이 있으며, 구조화된 비교 분석을 출력하기 어렵습니다.
   • 방안 B (ReAct): 논리는 명확하지만, N이 커질 경우 Latency = T_gen + T_rate + T_gen + T_rate... 와 같이 선형적으로 증가하여 수용 불가능해집니다.
   • 방안 C (DAG): Latency = Max(T_gen1, T_gen2, T_gen3) + T_rate 입니다. 성능이 최적이며 품질이 가장 높습니다(서로 다른 프롬프트가 각기 다른 창의성을 자극하기 때문). 비용은 약간 더 높지만(4회 호출), 제목 생성과 같이 빈도가 높으면서도 비용이 낮은 시나리오에서는 충분히 수용 가능합니다.

2. 반면교사 (Lessons Learned):

   • 실제 Title Agent를 개발할 때, 단 하나의 프롬프트로 "3개를 생성하고 가장 좋은 것을 골라라"라고 요청하면, LLM은 종종 게으름을 피워 거의 동의어에 가까운 3개의 제목을 생성하게 되며, 이는 선택의 의미를 없앱니다.
   • 반드시 프롬프트에서 JSON Schema를 강제해야 합니다. 그렇지 않으면 Judge Agent가 자연어로 응답하여 파싱(Parsing) 실패 및 데드 루프(Dead Loop)에 빠질 수 있습니다.

3. 정량적 지표:

   • 다양성 점수 (Diversity Score): 3개 후보 제목 간의 편집 거리(Edit Distance) 평균이 30%보다 커야 합니다.
   • 사용자 채택률 (User Adoption Rate): 사용자가 수정 없이 바로 게시하는 비율입니다.

면접관 관점:

• 만약 지원자가 "Temperature 설정 차이"(생성 시에는 0.7-1.0, 평가 시에는 0.1 사용)를 언급한다면, LLM의 파라미터 제어를 이해하고 있다는 의미입니다 (가산점, +20).
• 만약 지원자가 방안 A만을 선택하며 "프롬프트를 잘 쓰면 된다"라고 말한다면, 이는 엔지니어링 사고가 부족하며 LLM의 확률적 특성을 간과하고 있음을 의미합니다 (감점, -10).
• 흔한 오답: "Map-Reduce를 사용하겠습니다." (답변이 너무 일반적이며, 생성과 평가의 구체적인 차이를 반영하지 못함).
• 추가 질문 가능: "만약 병렬로 생성된 3개의 제목이 모두 형편없다면, Judge Agent는 반드시 하나를 골라야 합니다. 어떻게 하겠습니까? 당신의 시스템은 '재작업(Re-run)'을 지원합니까?"

Q3: [스트리밍 중의 "첫 번째 줄 함정"과 경계 처리]

난이도: Senior
분야: 프로덕션 AI / 트러블슈팅
관련 업무: 오늘 타이핑 효과(Typewriter effect) 중단 문제를 수정하다가 새로운 버그를 발견했습니다. 수정을 했더니 첫 번째 줄만 출력되는 현상이 발생했습니다. 이는 전형적인 "버그 하나를 고치려다 두 개의 버그를 만드는" 상황입니다.

문제:
스트리밍 텍스트를 추가(Append)할 때, "텍스트가 너무 길어 렌더링이 끊기는 문제"를 해결하기 위해 프론트엔드에서 다음과 같은 최적화를 결정했습니다: 렌더링 시 앞의 100자만 보여주고 나머지는 버리거나(또는 앞의 3줄만 유지), 그 이후는 무시합니다. 결과적으로 배포 후, 사용자들이 AI의 답변이 항상 중간에 끊긴다고 보고했습니다. 코드 관점에서 이러한 "절단 로직(Truncation logic)"의 무엇이 잘못되었는지 분석하세요. 만약 반드시 "성능 최적화"를 해야 한다면(긴 텍스트를 전체 렌더링할 수 없다면), 올바른 방법은 무엇입니까? 수정된 코드 로직을 작성하세요.

답변 핵심 포인트:

1. 핵심 아이디어:
   실수는 **"상태 저장(State Storage)"**와 **"뷰 렌더링(View Rendering)"**을 혼동한 데 있습니다. 상태는 항상 완전하게 유지되어야 하며, 뷰(View)만 일부를 보여줄 수 있습니다(예: 가상 스크롤링 또는 접기 기능). 하지만 문제에서 설명한 로직은 "추가 단계(Append stage)\

// --- 잘못된 방법 (오늘의 실수) ---
function onChunk(chunk) {
  // 치명적인 오류: 영속화(persistence)가 필요한 text 상태를 직접 수정함
...

1. 트레이드오프 분석 (Trade-off Analysis):

   • 메모리 vs 무결성 (Memory vs Integrity): fullTextBuffer를 유지하면 메모리를 점유하게 됩니다. 하지만 채팅 버블 (Chat bubble) 시나리오에서 단일 텍스트가 10k 토큰을 넘는 경우는 매우 드물기 때문에, 메모리 비용은 무시할 수 있는 수준입니다.
   • 만약 반드시 절단(Truncation)해야 한다면: 실시간 로그 콘솔과 같이 히스토리 기록이 명확히 필요하지 않은 시나리오에서만 수신 계층(receiving layer)에서 절단해야 합니다. AI 대화의 경우, 사용자의 복사, 재생성(Regeneration) 또는 요약(Summarization)을 위해 반드시 전체 텍스트를 보존해야 합니다.

2. 반면교사 (Lessons Learned):

   • 오늘의 회귀 (Regression): "표시 중단" 문제를 해결하기 위해 "너무 길어서" 발생하는 문제라고 의심하여 split('\n')[0]을 추가했습니다. 실제로는 백엔드에서 두 번째, 세 번째 줄을 끊임없이 보내고 있었지만, 프론트엔드 상태(State)에는 항상 첫 번째 줄만 남아 있었습니다. 새로운 청크(Chunk)가 첫 번째 줄 뒤에 추가되면서 Line1Line2Line3...와 같이 줄바꿈 없이 이어졌고, 결과적으로 깨진 문자열처럼 보이거나 첫 줄만 보이게 되었습니다.
   • 디버깅 시에는 UI만 볼 것이 아니라, 반드시 "입력 소스(Input source)"와 "상태 변수(State variable)"의 값을 확인해야 합니다.

3. 정량적 지표 (Quantitative Metrics):

   • 없음. 이 문제는 성능 지표가 아닌 로직의 정확성을 평가합니다.

면접관의 관점 (Interviewer's Perspective):

• 후보자가 즉시 "데이터 소스와 뷰의 분리 (Separation of data source and view)" 원칙을 지적한다면, 탄탄한 아키텍처 기초를 갖추고 있음을 의미합니다 (가산점, +20).
• 후보자가 "백엔드에서 줄바꿈 문자를 보냈는지 여부"에 집착하기 시작한다면, 프론트엔드 로직이 잘못 고정(Hard-coded)되어 있다는 점을 아직 깨닫지 못한 것입니다 (감점, -10).
• 흔한 오답: "버퍼(Buffer) 크기를 늘린다." (방향이 틀렸습니다. 버퍼가 아무리 커도 로직 자체에서 절단해버리면 소용이 없습니다).
• 추가 질문 가능: "만약 사용자가 스트리밍 출력 도중에 '생성 중지'를 클릭한다면, 당신의 상태 머신(State machine)은 어떻게 처리합니까? 이때 버퍼는 완전한 상태입니까?"