팔란티어 FDE(Forward Deployed Engineer) 완전 분석: 역할, 필수 역량, 고객 응대 전략

예시: 제조 회사의 Ontology

Object Types:
  - Factory (공장): 위치, 생산능력, 가동률
  - Production Line (생산라인): 제품유형, 속도, 불량률
  - Product (제품): SKU, 원가, 품질등급
  - Supplier (공급자): 리드타임, 신뢰도

Links:
  - Factory --has--> Production Line
  - Production Line --produces--> Product
  - Product --supplied-by--> Supplier

07:30 - 출근 전 이메일/슬랙 체크
        - 고객의 야간 이슈 확인, 긴급 사항 트리아지

08:30 - 고객 사이트 도착
        - 고객 IT팀과 스탠드업 (15분)
        - 어제 배포한 파이프라인 모니터링 결과 공유

09:00 - 데이터 파이프라인 개발
        - PySpark Transform 코드 작성
        - 새로운 데이터 소스(SAP) 연동 작업

11:00 - 비즈니스 사용자 워크숍
        - 공급망 담당자와 대시보드 요구사항 논의
        - Ontology 객체 타입 추가 필요성 확인

12:00 - 점심 (고객 팀과 함께)
        - 비공식적 관계 구축, 숨겨진 니즈 파악

13:30 - Workshop 앱 개발
        - React/TypeScript 기반 사용자 인터페이스 구축
        - Ontology Action 연결

15:00 - 팔란티어 내부 싱크
        - 본사 제품팀과 기능 요청 논의
        - 다른 FDE와 유사 사례 공유

16:00 - 데모 준비
        - 금주 성과를 경영진에게 보여줄 데모 시나리오 구성

17:00 - 경영진 데모
        - VP급에게 파이프라인 자동화로 절감된 시간 시연
        - 다음 분기 확장 제안

18:30 - 일일 리뷰 및 문서화
        - 오늘의 진행 상황, 블로커, 내일 계획 기록

-- 시간 기반 누적 매출 계산
SELECT
  order_date,
  customer_id,
  amount,
  SUM(amount) OVER (
    PARTITION BY customer_id
    ORDER BY order_date
    ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
  ) AS cumulative_revenue,
  LAG(amount, 1) OVER (
    PARTITION BY customer_id
    ORDER BY order_date
  ) AS prev_order_amount,
  RANK() OVER (
    PARTITION BY EXTRACT(MONTH FROM order_date)
    ORDER BY amount DESC
  ) AS monthly_rank
FROM orders;

-- 조직도 계층 구조 탐색 (Recursive CTE)
WITH RECURSIVE org_hierarchy AS (
  -- Base case: 최상위 관리자
  SELECT
    employee_id,
    name,
    manager_id,
    1 AS depth,
    CAST(name AS VARCHAR(1000)) AS path
  FROM employees
  WHERE manager_id IS NULL

  UNION ALL

  -- Recursive case: 하위 직원
  SELECT
    e.employee_id,
    e.name,
    e.manager_id,
    oh.depth + 1,
    CAST(oh.path || ' > ' || e.name AS VARCHAR(1000))
  FROM employees e
  INNER JOIN org_hierarchy oh ON e.manager_id = oh.employee_id
)
SELECT * FROM org_hierarchy ORDER BY depth, name;

# Foundry Transforms에서 사용되는 PySpark 패턴
from transforms.api import transform, Input, Output
from pyspark.sql import functions as F
from pyspark.sql.window import Window

@transform(
    output=Output("/datasets/clean/daily_metrics"),
    raw_orders=Input("/datasets/raw/orders"),
    raw_products=Input("/datasets/raw/products"),
)
def compute(output, raw_orders, raw_products):
    orders_df = raw_orders.dataframe()
    products_df = raw_products.dataframe()

    # 데이터 정제 + 조인 + 집계
    result = (
        orders_df
        .filter(F.col("status") == "completed")
        .join(products_df, on="product_id", how="inner")
        .groupBy(F.date_trunc("day", F.col("order_timestamp")).alias("order_date"))
        .agg(
            F.count("order_id").alias("total_orders"),
            F.sum("revenue").alias("total_revenue"),
            F.countDistinct("customer_id").alias("unique_customers"),
            F.avg("revenue").alias("avg_order_value"),
        )
        .withColumn(
            "revenue_7d_avg",
            F.avg("total_revenue").over(
                Window.orderBy("order_date").rowsBetween(-6, 0)
            )
        )
        .orderBy("order_date")
    )

    output.write_dataframe(result)

ETL vs ELT 비교:

ETL (Extract-Transform-Load):
  소스 --Extract--> 스테이징 --Transform--> 정제 --Load--> 데이터 웨어하우스
  장점: 변환 후 로드하여 저장소 효율적
  단점: 변환 로직 변경 시 재처리 필요

ELT (Extract-Load-Transform):
  소스 --Extract--> 데이터 레이크 --Load--> 원본 저장 --Transform--> 뷰/테이블
  장점: 원본 보존, 유연한 재가공
  단점: 저장 비용 증가

Foundry 방식 (ELT 선호):
  소스 --> Data Connection --> Raw Dataset --> Transforms --> Clean Dataset --> Ontology

Star Schema vs Ontology 비교:

Star Schema (전통):
          dim_customer
              |
  dim_product -- fact_orders -- dim_date
              |
          dim_store

Ontology (Foundry):
  Customer --places--> Order --contains--> Product
      |                   |
      +--located-in-->  Store <--shipped-from-- Warehouse

차이점:
- Star Schema: 분석 중심, 정적 구조
- Ontology: 운영 중심, 동적 관계, Action 실행 가능
- Ontology의 Object에는 Property뿐 아니라 Action도 정의 가능

// Foundry Workshop 위젯 패턴 예시
interface SupplyChainDashboardProps {
  factoryId: string;
  dateRange: DateRange;
  onAlertDismiss: (alertId: string) => void;
}

interface FactoryMetrics {
  utilization: number;
  defectRate: number;
  throughput: number;
  alerts: Alert[];
}

const SupplyChainDashboard: React.FC<SupplyChainDashboardProps> = ({
  factoryId,
  dateRange,
  onAlertDismiss,
}) => {
  const [metrics, setMetrics] = useState<FactoryMetrics | null>(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    // Ontology API를 통해 실시간 메트릭 조회
    async function fetchMetrics() {
      setLoading(true);
      try {
        const factory = await OntologyClient.getObject("Factory", factoryId);
        const lines = await factory.getLinkedObjects("hasProductionLine");
        const calculated = computeMetrics(lines, dateRange);
        setMetrics(calculated);
      } catch (error) {
        console.error("Failed to fetch metrics:", error);
      } finally {
        setLoading(false);
      }
    }
    fetchMetrics();
  }, [factoryId, dateRange]);

  if (loading) return <Spinner />;
  if (!metrics) return <ErrorState message="데이터를 불러올 수 없습니다" />;

  return (
    <DashboardLayout>
      <MetricCard title="가동률" value={metrics.utilization} unit="%" />
      <MetricCard title="불량률" value={metrics.defectRate} unit="%" />
      <MetricCard title="처리량" value={metrics.throughput} unit="units/hr" />
      <AlertList alerts={metrics.alerts} onDismiss={onAlertDismiss} />
    </DashboardLayout>
  );
};

# Foundry에서 Ontology Action 정의 예시
from ontology_sdk import action, OntologyObject

@action(
    name="create_maintenance_order",
    description="설비 점검 작업 주문 생성",
    parameters={
        "equipment_id": "string",
        "priority": "enum(HIGH, MEDIUM, LOW)",
        "description": "string",
        "scheduled_date": "datetime",
    },
)
def create_maintenance_order(params, context):
    equipment = context.ontology.get("Equipment", params["equipment_id"])

    if equipment.status == "DECOMMISSIONED":
        raise ValueError("폐기된 설비에는 점검 주문을 생성할 수 없습니다")

    # 새 MaintenanceOrder 객체 생성
    order = context.ontology.create("MaintenanceOrder", {
        "equipment": equipment,
        "priority": params["priority"],
        "description": params["description"],
        "scheduled_date": params["scheduled_date"],
        "status": "PENDING",
        "created_by": context.current_user,
    })

    # 담당자 자동 할당
    assignee = find_available_technician(
        equipment.location,
        params["priority"],
        params["scheduled_date"],
    )
    order.assign_to(assignee)

    # 알림 발송
    notify_stakeholders(order, assignee)

    return order

# AIP에서 LLM + Ontology 연동 패턴
def aip_supply_chain_assistant(user_query, context):
    """
    사용자 자연어 질의를 Ontology 조회로 변환
    """
    # 1. 의도 분석
    intent = classify_intent(user_query)
    # 예: "지난 주에 불량률이 가장 높았던 공장은?"

    # 2. Ontology 쿼리 생성
    if intent == "factory_defect_analysis":
        factories = context.ontology.search(
            "Factory",
            filters=[
                ("metrics.defect_rate", ">", 0),
                ("metrics.date", ">=", last_week_start),
            ],
            order_by="metrics.defect_rate DESC",
            limit=5,
        )

        # 3. LLM으로 자연어 응답 생성
        response = generate_response(
            template="factory_analysis",
            data=factories,
            user_query=user_query,
        )

        return response

    # 4. Action 실행이 필요한 경우
    if intent == "create_action":
        # LLM이 적절한 Ontology Action 식별
        action_plan = plan_action(user_query, context)
        # 사용자 확인 후 실행
        return request_confirmation(action_plan)

고객 시나리오: 글로벌 제조사의 실시간 품질 관리 시스템

데이터 소스 (전 세계 20개 공장):
  IoT 센서 --> Kafka --> Foundry Streaming
  MES 시스템 --> API Connector --> Foundry Batch
  SAP --> Magritte Sync --> Foundry Batch

처리 레이어:
  Raw Layer:   원본 데이터 (보존)
  Clean Layer: 정제/표준화 (Transforms)
  Semantic Layer: Ontology 매핑
  Application Layer: Workshop 앱, 대시보드

스케일:
  - 일일 데이터: 약 50TB
  - 실시간 이벤트: 약 100K events/sec
  - Ontology 객체: 약 500M objects
  - 동시 사용자: 약 5,000명

배치 처리 (Transforms):
  실행 주기: 매시간 또는 매일
  적합한 경우: 일일 보고서, 주간 분석, 과거 데이터 재처리
  기술: PySpark, SQL Transforms

스트리밍 처리 (Foundry Streaming):
  실행 주기: 실시간 (초 단위)
  적합한 경우: 이상 탐지, 실시간 알림, 라이브 대시보드
  기술: Kafka, Spark Streaming

Lambda Architecture (팔란티어 패턴):
  배치 레이어: 정확한 과거 분석 (시간 지연 허용)
  속도 레이어: 실시간 근사값 (정확도 약간 희생)
  서빙 레이어: 배치 + 실시간 결과 통합

Foundry의 데이터 거버넌스 핵심:

1. 접근 제어 (RBAC + ABAC):
   - Organization --> Project --> Dataset --> Column 수준
   - Marking 기반 접근 제어 (PII, Confidential 등)

2. 데이터 리니지 (Lineage):
   - 모든 Transform의 입출력 자동 추적
   - 데이터 원본부터 최종 소비까지 추적 가능

3. 감사 로그 (Audit):
   - 누가, 언제, 어떤 데이터에 접근했는지 기록
   - 규제 준수 (GDPR, HIPAA) 증빙

4. 데이터 품질:
   - Health Check: 자동 품질 모니터링
   - Expectation: 데이터 규칙 정의 및 검증

5-Day Domain Immersion Framework:

Day 1: 빅 픽처
  - 산업 개요 보고서 읽기 (McKinsey, Gartner)
  - 고객 회사의 10-K 보고서 분석
  - 핵심 용어 50개 정리

Day 2: 프로세스 매핑
  - 고객의 핵심 비즈니스 프로세스 3-5개 이해
  - As-Is 프로세스 다이어그램 그리기
  - 페인포인트 가설 수립

Day 3: 데이터 랜드스케이프
  - 사용 중인 시스템 목록 (ERP, CRM, MES 등)
  - 데이터 흐름 다이어그램
  - 데이터 품질 이슈 파악

Day 4: 이해관계자 인터뷰
  - C-레벨: 전략적 목표
  - 중간 관리자: 운영 과제
  - 현장 실무자: 일상의 고충

Day 5: 가치 가설 수립
  - Quick Win 3가지 식별
  - 중기 프로젝트 2-3개 로드맵
  - ROI 추정 (시간 절감, 비용 절감, 매출 증가)

나쁜 예:
  고객: "데이터가 실시간으로 안 들어와요"
  FDE: "Kafka 커넥터 설정을 확인해 보겠습니다" (바로 기술 솔루션)

좋은 예:
  고객: "데이터가 실시간으로 안 들어와요"
  FDE: "그 데이터가 실시간으로 필요한 이유가 무엇인가요?
        어떤 의사결정에 영향을 미치나요?"
  고객: "공장 라인에서 불량이 발생하면 30분 내에 중단해야 하는데,
        지금은 다음 날에야 알게 됩니다"
  FDE: "그러면 품질 이상 감지가 핵심이군요. 30분 내 알림이
        되려면 어떤 센서 데이터가 가장 중요할까요?"

적극적 경청 기법:

1. 반영 (Reflecting):
   고객: "이 보고서 만드는 데 매주 8시간이 걸려요"
   FDE: "매주 8시간을 보고서 작성에 쓰고 계시군요"

2. 명확화 (Clarifying):
   "8시간 중 가장 시간이 많이 걸리는 부분이 어디인가요?"

3. 요약 (Summarizing):
   "정리하면, 데이터 수집에 3시간, 정제에 2시간,
    시각화에 3시간이 걸리는 것이군요"

4. 감정 인식 (Emotional Recognition):
   "그 과정이 상당히 지치셨겠습니다"

열린 질문 (Open Questions) - 탐색 단계:
  "현재 가장 큰 데이터 관련 과제는 무엇인가요?"
  "이상적인 상태는 어떤 모습인가요?"
  "이 프로세스에서 가장 답답한 부분은 무엇인가요?"

닫힌 질문 (Closed Questions) - 확인 단계:
  "이 대시보드에 일별 추이 차트가 필요하신 건가요?"
  "데이터 업데이트 주기는 1시간이면 충분한가요?"
  "승인 권한은 팀장급까지만 있으면 되나요?"

5 Why 기법 - 근본 원인 탐색:
  1. "왜 보고서가 늦게 완성되나요?"
     --> "데이터 수집이 오래 걸려서요"
  2. "왜 데이터 수집이 오래 걸리나요?"
     --> "5개 시스템에서 수동으로 뽑아야 해서요"
  3. "왜 수동으로 뽑아야 하나요?"
     --> "시스템들이 서로 연결되어 있지 않아서요"
  4. "왜 연결되어 있지 않나요?"
     --> "각 부서가 독립적으로 시스템을 도입해서요"
  5. "왜 독립적으로 도입했나요?"
     --> "중앙 데이터 전략이 없었어요"
  근본 원인: 데이터 거버넌스 부재 --> Foundry 도입의 핵심 가치 제안

실천 방법:
  - 고객이 말하는 동안 절대 끊지 않는다
  - 메모를 하며 핵심 포인트를 기록한다
  - 비언어적 신호로 경청하고 있음을 보여준다 (고개 끄덕임, 눈 맞춤)
  - 말이 끝나면 핵심을 반복하여 정확히 이해했는지 확인한다

예시:
  고객: "지난주 배포한 대시보드가 아침마다 깨져 있어요.
        우리 VP가 매일 아침 이 대시보드를 보는데, 매번 제가
        IT에 전화해서 다시 만들어 달라고 해야 해요.
        정말 신뢰가 안 갑니다."

  FDE: "아침마다 대시보드가 정상적으로 표시되지 않아서
       VP분께 보여드리기 전에 매번 IT팀에 요청하셔야 했군요.
       그 상황이 반복되면서 신뢰에 영향을 받으셨다는 것이죠?"

공감 표현 템플릿:
  - "그 상황이 얼마나 답답하셨을지 충분히 이해합니다"
  - "매일 아침마다 그런 일이 반복되면 스트레스가 크셨겠습니다"
  - "VP분 앞에서 매번 그런 상황이 생기면 곤란하셨을 거예요"

주의: 공감은 동의가 아닙니다
  - 좋음: "그 상황이 불편하셨다는 것을 이해합니다"
  - 나쁨: "네, 저희 시스템이 정말 안 좋네요" (과도한 자기 비하)

진심 어린 사과의 원칙:
  - 변명을 하지 않는다
  - 구체적으로 무엇에 대해 사과하는지 명시한다
  - 책임을 인정한다

좋은 사과:
  "대시보드 안정성 문제로 매일 아침 불편을 드려서 진심으로 죄송합니다.
   배포 전에 더 충분한 테스트를 했어야 했습니다."

나쁜 사과:
  "죄송합니다만, 원래 데이터 소스 쪽에서 문제가 있어서..."
  (변명이 포함된 사과는 사과가 아닙니다)

해결 방안 제시 템플릿:

즉시 조치 (24시간 이내):
  "오늘 안으로 대시보드 새로고침 스케줄의 오류를 수정하겠습니다.
   내일 아침 7시 전에 정상 동작을 확인하고 결과를 알려드리겠습니다."

단기 개선 (1주 이내):
  "이번 주 안으로 대시보드에 자동 헬스체크를 추가하여
   문제 발생 시 자동으로 복구되도록 하겠습니다."

장기 방지 (1개월 이내):
  "모든 대시보드에 대해 배포 전 자동화된 테스트 파이프라인을
   구축하여 이런 문제가 재발하지 않도록 하겠습니다."

핵심: 구체적인 타임라인과 담당자를 명시할 것

근본 원인 분석 후 보고:

RCA (Root Cause Analysis) 보고서 구조:
  1. 사건 개요: 무엇이 발생했는가
  2. 타임라인: 언제 시작되어 언제 해결되었는가
  3. 영향 범위: 누가, 얼마나 영향을 받았는가
  4. 근본 원인: 왜 발생했는가
  5. 즉시 조치: 어떻게 해결했는가
  6. 재발 방지: 앞으로 어떻게 예방할 것인가

예시:
  근본 원인: 야간 데이터 파이프라인이 UTC 기준으로 스케줄링되어
            한국 시간(KST) 아침 8시에 아직 처리가 완료되지 않았음.
  재발 방지: 스케줄을 KST 기준 새벽 4시 완료로 변경,
            완료 알림 설정, 모니터링 대시보드 추가.

L - Listen (경청):
  고객의 말을 끝까지 듣습니다. 메모하며 핵심 키워드를 포착합니다.

A - Acknowledge (인정):
  "말씀하신 문제를 정확히 이해했습니다.
   데이터 로딩 속도가 기대보다 느린 것이 핵심 이슈이군요."

S - Solve (해결):
  "두 가지 방법으로 해결할 수 있습니다.
   첫째, 쿼리 최적화로 즉시 2배 빠르게 할 수 있고,
   둘째, 캐싱 레이어 추가로 추가 3배 개선이 가능합니다."

T - Thank (감사):
  "이 문제를 알려주셔서 감사합니다.
   덕분에 다른 사용자에게도 더 나은 경험을 제공할 수 있게 됐습니다."

Step 1: 안전한 공간 확보
  - 가능하면 1:1 환경으로 이동
  - 공개적 망신을 피한다
  - 화상 회의라면 참가자를 최소화

Step 2: 경청과 감정 인정
  - "정말 화가 나신 것이 당연합니다"
  - 절대 방어적으로 반응하지 않는다
  - "그런데요," "하지만" 사용을 피한다

Step 3: 사실 확인
  - 감정이 가라앉으면 구체적 사실을 확인
  - "정확히 이해하고 싶은데, 어떤 일이 있었는지 순서대로 말씀해 주시겠어요?"

Step 4: 즉시 가능한 조치 제시
  - 작더라도 바로 할 수 있는 것을 제시
  - "지금 바로 할 수 있는 것은 A입니다. B는 내일까지 가능합니다."

Step 5: 후속 관리
  - 약속한 시간 전에 업데이트
  - 해결 후에도 1주일 뒤 확인 연락

예방 전략:
  1. 프로젝트 시작 시 명확한 SOW(Statement of Work) 합의
  2. MoSCoW 우선순위: Must/Should/Could/Won't
  3. 변경 요청 프로세스 정의

대응 화법:
  나쁜 예: "그건 범위 밖입니다" (거부감)

  좋은 예: "좋은 아이디어입니다! 현재 Phase 1의 핵심 목표가
           [X]인데, 말씀하신 기능은 Phase 2에서 구현하면
           더 효과적으로 반영할 수 있을 것 같습니다.
           Phase 1을 먼저 성공적으로 완료한 후에
           우선순위에 반영하는 것은 어떨까요?"

핵심: "No"가 아니라 "Yes, but later/differently"

건설적으로 "No" 말하기:

상황: 고객이 실시간(1초 미만) 분석을 요청했지만
      데이터 볼륨이 너무 커서 기술적으로 불가능

나쁜 예:
  "불가능합니다. 데이터가 너무 많아서 실시간 처리가 안 됩니다."

좋은 예:
  "실시간 분석의 필요성을 이해합니다. 현재 데이터 볼륨(일 50TB)으로
   1초 미만 응답은 기술적 한계가 있지만, 두 가지 대안을 제안드립니다.

   대안 1: 가장 중요한 KPI 5개에 대해서만 실시간 처리
           --> 1초 미만 응답 가능
   대안 2: 전체 데이터를 5분 주기로 사전 집계
           --> 모든 KPI를 3초 이내에 제공

   어떤 방향이 비즈니스에 더 도움이 될까요?"

원칙: 불가능 대신 대안을, 기술 용어 대신 비즈니스 영향을

상황: 고객이 3주째 아키텍처 결정을 미루고 있음

Nudging 전략:

1. 기한 설정:
   "다음 주 목요일까지 결정해 주시면 Q2 안에 Phase 1 완료가 가능합니다"

2. 비용 프레이밍:
   "결정이 1주 지연될 때마다 약 X만큼의 운영 비용이 추가됩니다"

3. 선택지 단순화:
   "10가지 옵션을 검토하셨는데, 귀사 상황에 가장 적합한
    2가지로 좁혀드렸습니다. A와 B의 차이점은..."

4. 파일럿 제안:
   "전체를 한 번에 결정하지 않고, 먼저 A방식으로 2주 파일럿을
    진행한 후 결과를 보고 판단하시는 것은 어떨까요?"

5. 사회적 증거:
   "유사한 규모의 X사에서 A방식을 선택하여 3개월 만에
    ROI 300%를 달성했습니다"

상황: IT 부서장은 보안을 우선시하고, 비즈니스 부서장은 속도를 원함

Facilitation 기법:

1. 공통 목표 확인:
   "두 분 모두 고객 만족도 향상이라는 같은 목표를 가지고 계시죠?"

2. 각 입장 시각화:
   화이트보드에 양쪽 요구사항과 우려사항을 나란히 정리

3. 트레이드오프 명시:
   "보안을 최우선으로 하면 출시가 2주 늦어지고,
    속도를 최우선으로 하면 보안 검토가 불완전합니다.
    중간안으로 핵심 보안만 1주 안에 적용하는 것은 어떨까요?"

4. 의사결정자 명확화:
   "최종 결정권자는 누구인가요?
    그분의 기준은 무엇인가요?"

5. 서면 합의:
   결정 사항을 문서화하여 모든 관계자의 서명을 받음

RACI 매트릭스 예시: Foundry 도입 프로젝트

                    | 요구사항 정의 | 데이터 연동 | 테스트 | Go-Live |
--------------------|---------------|-------------|--------|---------|
프로젝트 스폰서(VP) |      A        |      I      |   I    |    A    |
IT 디렉터           |      C        |      A      |   A    |    R    |
비즈니스 매니저     |      R        |      C      |   R    |    C    |
FDE (팔란티어)      |      C        |      R      |   R    |    R    |
데이터 엔지니어     |      I        |      R      |   C    |    C    |

R = Responsible (실행), A = Accountable (최종 책임)
C = Consulted (자문), I = Informed (통보)

높은 영향력 + 높은 관심:  적극적 관리 (Key Players)
  --> CIO, VP of Operations
  전략: 주 1회 정기 보고, 의사결정에 참여

높은 영향력 + 낮은 관심:  만족 유지 (Keep Satisfied)
  --> CEO, CFO
  전략: 월 1회 요약 보고, 중요 의사결정 시만 참여

낮은 영향력 + 높은 관심:  정보 제공 (Keep Informed)
  --> 현장 분석가, 데이터 엔지니어
  전략: 주간 뉴스레터, 슬랙 채널 업데이트

낮은 영향력 + 낮은 관심:  모니터링 (Monitor)
  --> 일반 사용자
  전략: 분기별 업데이트, 필요 시 소통

Champion이란:
  고객 조직 내에서 팔란티어/Foundry의 가치를 적극적으로 전파하는 내부 옹호자

Champion 식별 특징:
  - 미팅에서 적극적으로 질문하고 아이디어를 제시
  - 동료들에게 Foundry 사용을 권유
  - 자발적으로 피드백을 제공
  - 성공 사례를 경영진에게 공유

Champion 육성 전략:
  1. 조기 접근: 프로젝트 초기부터 관계 구축
  2. 독점 정보: 신기능, 로드맵을 먼저 공유
  3. 역량 강화: 심화 트레이닝 제공
  4. 인정: 그들의 기여를 공식적으로 인정
  5. 네트워크: 다른 고객사 Champion과 연결

Executive Sponsor 관리 원칙:

1. 그들의 시간은 금이다:
   - 미팅은 30분 이내
   - 핵심 3가지만 전달
   - 시각적 자료 (차트, 대시보드) 활용

2. 비즈니스 언어로 소통:
   - 나쁜 예: "Spark 클러스터 최적화로 쿼리 성능이 40% 향상"
   - 좋은 예: "보고서 생성 시간이 2시간에서 20분으로 단축되어
              팀이 주당 15시간을 분석에 더 쓸 수 있게 됐습니다"

3. 위험 사항은 조기 보고:
   - 나쁜 소식일수록 빨리 전달
   - 문제만이 아닌 해결 방안과 함께 보고

4. 성과 가시화:
   - 월간 ROI 대시보드
   - Before/After 비교 데이터
   - 사용자 만족도 조사 결과

주간 업데이트 이메일 구조:

Subject: [Project Name] 주간 업데이트 - W12 (3/17-3/21)

1. 요약 (3줄 이내):
   이번 주 공급망 대시보드 v2 배포 완료.
   사용자 피드백 반영하여 필터링 기능 추가.
   다음 주 재고 예측 모델 파일럿 시작 예정.

2. 이번 주 완료:
   - 공급망 대시보드 v2 프로덕션 배포 (완료)
   - 사용자 5명 대상 트레이닝 실시 (완료)
   - SAP 데이터 연동 테스트 (완료)

3. 다음 주 계획:
   - 재고 예측 모델 파일럿 (3/24-3/28)
   - 경영진 데모 준비 (3/28)

4. 리스크/블로커:
   - SAP 서버 접근 권한 대기 중 (IT팀 승인 필요)
   - 예상 해결일: 3/25

5. 지표:
   - 대시보드 일일 사용자: 45명 (지난주 대비 +12)
   - 보고서 생성 시간: 20분 (기존 2시간 대비 -83%)

Slack 에티켓 가이드:

DO:
  - 스레드를 적극 활용 (채널 정리)
  - 긴급도를 명시 (긴급/일반/참고)
  - 질문에는 기대 응답 시간 명시
  - 해결된 이슈는 결과를 공유

DON'T:
  - 업무 시간 외 멘션 (긴급 아닌 한)
  - 같은 메시지를 여러 채널에 중복 발송
  - 긴 논의를 DM 대신 채널에서 진행 (다른 팀원도 참고)
  - "안녕하세요"만 보내고 기다리기 (질문을 바로 전달)

채널 구조 추천:
  palantir-general:    일반 소통
  palantir-technical:  기술 논의
  palantir-urgent:     긴급 이슈 (알림 ON)
  palantir-demos:      데모/발표 일정

효과적인 미팅 템플릿:

미팅 전:
  - 아젠다를 24시간 전에 공유
  - 참석자별 준비 사항 명시
  - 미팅 목적 1줄 요약

미팅 중:
  - 타임키퍼 지정
  - 노트테이커 지정
  - 각 안건별 시간 배정
  - 결론 없는 토론은 별도 미팅으로 분리

미팅 후 (24시간 이내):
  - 회의록 공유
  - 액션 아이템: 담당자 + 기한 명시
  - 다음 미팅 일정 확인

FDE 데모 구조 (15분 기준):

1분: Hook (관심 끌기)
  "지난 분기 재고 부족으로 인한 매출 손실이 2억이었습니다.
   오늘 보여드릴 솔루션으로 이를 80% 줄일 수 있습니다."

3분: Context (맥락)
  "현재 재고 관리 프로세스의 문제점 3가지를 먼저 짚겠습니다"
  (고객의 고통을 시각화)

8분: Live Demo (라이브 시연)
  - 반드시 실제 데이터로 시연 (더미 데이터 X)
  - 고객의 일상 시나리오로 흐름 구성
  - "만약 A 상황이 발생하면..." 시나리오 기반

2분: Impact (영향)
  "이 대시보드를 통해 재고 부족 예측이 3일 전으로 당겨지고,
   예상 절감 효과는 연간 1.6억입니다"

1분: Next Steps (다음 단계)
  구체적 액션 아이템과 일정 제시

팔란티어 FDE 면접 프로세스:

Stage 1: Online Assessment (1-2시간)
  - HackerRank 스타일 코딩 테스트
  - SQL + Python/Java 문제 2-3개
  - 알고리즘보다 데이터 처리 중심

Stage 2: Phone Screen (45-60분)
  - 기술 면접: SQL 실시간 문제 풀이
  - 또는 시스템 설계 간단 토론
  - "Why Palantir?" 질문 거의 확실

Stage 3: Onsite (3-5 라운드, 하루)

  Round 1: Coding (60분)
    - Python 또는 Java로 데이터 처리 문제
    - 실제 비즈니스 시나리오 기반
    - 예: "물류 최적화 알고리즘 구현"

  Round 2: SQL Deep Dive (60분)
    - 복잡한 쿼리 작성 (Window Functions, CTEs)
    - 성능 최적화 논의
    - 데이터 모델링 설계

  Round 3: System Design (60분)
    - 데이터 파이프라인 설계
    - 확장성, 내결함성 논의
    - Foundry 아키텍처 이해도 평가

  Round 4: Case Study (60분)
    - 고객 시나리오 기반 문제 해결
    - "제조 회사가 불량률을 줄이고 싶어합니다"
    - 기술 + 비즈니스 + 커뮤니케이션 종합 평가

  Round 5: Behavioral (45분)
    - STAR 방식 답변
    - 고객 경험, 갈등 해결, 리더십
    - 팔란티어 가치관 fit 확인

# 자주 출제되는 유형: 데이터 처리 + 비즈니스 로직

# 문제: 공급망 지연 분석
# 주문 데이터에서 지연이 가장 심한 공급자 Top 5와
# 지연 원인별 패턴을 분석하시오

import pandas as pd
from collections import defaultdict

def analyze_supply_chain_delays(orders_df):
    """
    공급망 지연 분석 함수

    Parameters:
    - orders_df: DataFrame with columns
      [order_id, supplier_id, expected_date, actual_date,
       product_category, quantity, region]
    """
    # 1. 지연 일수 계산
    orders_df["delay_days"] = (
        pd.to_datetime(orders_df["actual_date"])
        - pd.to_datetime(orders_df["expected_date"])
    ).dt.days

    # 2. 지연 주문만 필터링
    delayed = orders_df[orders_df["delay_days"] > 0].copy()

    # 3. 공급자별 지연 통계
    supplier_stats = (
        delayed.groupby("supplier_id")
        .agg(
            total_delayed_orders=("order_id", "count"),
            avg_delay_days=("delay_days", "mean"),
            max_delay_days=("delay_days", "max"),
            total_affected_quantity=("quantity", "sum"),
        )
        .sort_values("avg_delay_days", ascending=False)
        .head(5)
    )

    # 4. 카테고리-지역별 지연 패턴
    pattern_analysis = (
        delayed.groupby(["product_category", "region"])
        .agg(
            delay_count=("order_id", "count"),
            avg_delay=("delay_days", "mean"),
        )
        .sort_values("delay_count", ascending=False)
    )

    # 5. 시계열 지연 추세
    delayed["month"] = pd.to_datetime(delayed["actual_date"]).dt.to_period("M")
    trend = (
        delayed.groupby("month")
        .agg(
            monthly_delays=("order_id", "count"),
            avg_monthly_delay=("delay_days", "mean"),
        )
    )

    return {
        "top_5_delayed_suppliers": supplier_stats,
        "delay_patterns": pattern_analysis,
        "monthly_trend": trend,
    }

-- 문제: 고객 세그먼테이션
-- 최근 90일간 구매 패턴을 기반으로 고객을 RFM 세그먼트로 분류하시오

WITH customer_rfm AS (
  SELECT
    customer_id,
    DATEDIFF(day, MAX(order_date), CURRENT_DATE) AS recency,
    COUNT(DISTINCT order_id) AS frequency,
    SUM(total_amount) AS monetary
  FROM orders
  WHERE order_date >= DATEADD(day, -90, CURRENT_DATE)
  GROUP BY customer_id
),
rfm_scores AS (
  SELECT
    customer_id,
    recency,
    frequency,
    monetary,
    NTILE(5) OVER (ORDER BY recency ASC) AS r_score,
    NTILE(5) OVER (ORDER BY frequency DESC) AS f_score,
    NTILE(5) OVER (ORDER BY monetary DESC) AS m_score
  FROM customer_rfm
)
SELECT
  customer_id,
  r_score,
  f_score,
  m_score,
  CASE
    WHEN r_score >= 4 AND f_score >= 4 AND m_score >= 4 THEN 'Champions'
    WHEN r_score >= 3 AND f_score >= 3 THEN 'Loyal Customers'
    WHEN r_score >= 4 AND f_score <= 2 THEN 'New Customers'
    WHEN r_score <= 2 AND f_score >= 3 THEN 'At Risk'
    WHEN r_score <= 2 AND f_score <= 2 THEN 'Lost'
    ELSE 'Others'
  END AS segment
FROM rfm_scores
ORDER BY monetary DESC;

케이스 스터디 응답 프레임워크 (BRIDGE):

B - Business Understanding
  "먼저 고객의 비즈니스를 이해하겠습니다.
   이 제조사의 핵심 KPI와 현재 가장 큰 과제는 무엇인가요?"

R - Requirements Gathering
  "구체적으로 필요한 것을 정리하면:
   1. 불량률을 현재 3%에서 1% 미만으로
   2. 감지 시간을 24시간에서 30분으로
   3. 의사결정 자동화"

I - Investigation (데이터/기술 환경)
  "현재 사용 중인 시스템은 무엇이고,
   어떤 데이터를 수집하고 있나요?"

D - Design (솔루션 설계)
  "Foundry 기반으로 다음과 같이 설계하겠습니다:
   Phase 1: 데이터 통합 (2주)
   Phase 2: 실시간 모니터링 (3주)
   Phase 3: 예측 모델 (4주)"

G - Go-Live Plan
  "파일럿 공장 1곳에서 4주 운영 후
   성과 검증 뒤 전체 공장으로 확대"

E - Expansion
  "초기 성공 후 추가 확장 가능 영역:
   공급자 품질 관리, 예지 보전, 수요 예측"

STAR 응답 템플릿:

질문: "고객이 불만을 표시한 경험을 이야기해 주세요"

S (Situation):
  "전 직장에서 글로벌 은행의 데이터 마이그레이션 프로젝트를
   담당했습니다. 고객의 IT 디렉터가 프로젝트 지연에 대해
   강하게 불만을 표시했습니다."

T (Task):
  "저의 역할은 지연 원인을 파악하고 고객의 신뢰를 회복하며
   프로젝트를 정상 궤도로 복귀시키는 것이었습니다."

A (Action):
  "1. 먼저 고객의 이야기를 30분간 경청하고 핵심 우려사항 정리
   2. 24시간 이내에 RCA 보고서와 수정 계획 전달
   3. 일일 진행 보고를 도입하여 투명성 확보
   4. 추가 리소스를 투입하여 병렬 작업 진행"

R (Result):
  "2주 만에 지연분을 만회하여 원래 일정에 맞춰 완료했습니다.
   고객 만족도 조사에서 5점 만점에 4.8점을 받았고,
   이후 추가 프로젝트 3건을 수주했습니다."

좋은 답변 구조:

1. 미션과 연결:
   "팔란티어의 미션인 '세계에서 가장 중요한 기관을 돕는 것'에
   깊이 공감합니다. 단순히 소프트웨어를 만드는 것이 아니라
   실제 세상의 문제를 해결하는 것에 가치를 둡니다."

2. FDE 역할의 매력:
   "기술과 비즈니스의 교차점에서 일하는 FDE 역할이
   제 성향과 완벽하게 맞습니다. 코드만 작성하는 것이 아니라
   고객의 문제를 직접 해결하고 가치를 눈으로 확인할 수 있습니다."

3. 구체적 경험과 연결:
   "[이전 경험]에서 고객과 직접 소통하며 기술 솔루션을
   구축한 경험이 FDE의 핵심 역량과 일치합니다."

답변 포인트:

1. AI 윤리의 중요성 인정:
   "AI가 의사결정에 점점 더 많이 사용되면서
    공정성, 투명성, 책임성이 매우 중요합니다."

2. 팔란티어의 접근법 이해:
   "팔란티어는 인간이 루프 안에 있는(Human-in-the-loop) AI를
    추구한다고 이해하고 있습니다. AI가 제안하되
    최종 결정은 인간이 하는 구조입니다."

3. 본인의 입장:
   "기술의 강력함만큼 책임감 있는 사용이 중요하며,
    FDE로서 고객이 AI를 윤리적으로 활용하도록
    가이드하는 역할도 수행해야 한다고 생각합니다."

주제: SQL + Python + 데이터 엔지니어링 기초

Week 1-2: SQL 마스터
  - LeetCode SQL 50 문제
  - Window Functions 집중 학습
  - CTE, Recursive Queries 연습
  - 매일 2-3문제 풀기

Week 3-4: Python 데이터 처리
  - Pandas 핵심 (merge, groupby, pivot, apply)
  - PySpark 기초 (DataFrame API)
  - 데이터 정제 패턴 (null 처리, 타입 변환, 중복 제거)

Week 5-6: ETL/ELT 파이프라인
  - Apache Airflow 기초
  - 데이터 웨어하우스 개념 (Star Schema, Snowflake)
  - 간단한 ETL 프로젝트 구축

Week 7-8: 데이터 모델링
  - 정규화 vs 비정규화
  - Dimensional Modeling (Kimball 방법론)
  - Ontology 사고방식 연습 (객체-관계 설계)

주제: React/TypeScript + API + 시스템 설계

Week 9-10: React/TypeScript
  - React Hooks 심화
  - TypeScript 핵심 (인터페이스, 제네릭, 유틸리티 타입)
  - 대시보드 컴포넌트 구축 실습

Week 11-12: Backend API
  - REST API 설계 원칙
  - Python FastAPI 또는 Java Spring Boot
  - 인증/인가 (OAuth, RBAC)

Week 13-14: 시스템 설계
  - 데이터 파이프라인 아키텍처
  - 실시간 vs 배치 처리
  - 확장성 패턴 (파티셔닝, 캐싱, 큐)

Week 15-16: 클라우드/인프라
  - AWS/GCP 기본 서비스
  - Docker/Kubernetes 기초
  - CI/CD 파이프라인

주제: 커뮤니케이션 + 비즈니스 + 팔란티어 플랫폼

Week 17-18: 고객 응대 스킬
  - HEARD/LAST 프레임워크 반복 연습
  - De-escalation 롤플레이
  - Active Listening 훈련

Week 19-20: 프레젠테이션/데모
  - 스토리텔링 구조 학습
  - 기술 데모 연습 (실제 데이터 기반)
  - 타이밍 연습 (15분, 30분, 60분)

Week 21-22: 도메인 지식
  - 타겟 산업 1-2개 심화 학습
  - 산업 보고서 읽기 (McKinsey, Deloitte)
  - 해당 산업의 KPI, 프로세스, 규제 이해

Week 23-24: 팔란티어 플랫폼 학습
  - Foundry 공식 문서 정독
  - YouTube: Palantir Tech Talks
  - 커뮤니티 포럼 참여

주제: 면접 실전 준비

Week 25-26: 코딩 면접 연습
  - SQL: 하루 2문제 (고급)
  - Python: 데이터 처리 문제 집중
  - 시스템 설계 모의 면접 2-3회

Week 27-28: 케이스 스터디 연습
  - BRIDGE 프레임워크 적용 연습
  - 동료와 모의 면접 (고객 역할극)
  - 산업별 케이스 3-5개 준비

Week 29-30: 행동 면접 연습
  - STAR 답변 10개 준비
  - "Why Palantir" 답변 정제
  - 윤리 AI 질문 준비

Week 31-32: 최종 리뷰
  - 풀 모의 면접 (5라운드)
  - 약점 영역 보완
  - 자신감 관리, 컨디션 조절

목적: Ontology 설계 + 데이터 파이프라인 + 대시보드 구축 능력 증명

기술 스택:
  - Python (PySpark) + SQL
  - React/TypeScript (대시보드)
  - PostgreSQL + Apache Spark

구현 내용:
  1. 공급망 Ontology 설계
     - Object Types: Supplier, Order, Product, Warehouse
     - Links: supplies, contains, stored-in
     - Properties + Actions 정의

  2. ETL 파이프라인
     - CSV/API 데이터 소스 --> 정제 --> 분석 데이터셋
     - PySpark Transforms 패턴 적용
     - 데이터 품질 체크 포함

  3. 대시보드
     - 실시간 공급자 성과 모니터링
     - 지연 예측 알림
     - 드릴다운 분석 기능

GitHub 리포에 포함할 것:
  - README: 설계 의사결정 과정 설명
  - 아키텍처 다이어그램
  - 데모 영상 (2-3분)

목적: 비즈니스 분석 + 고객 소통 능력 증명

프레젠테이션 형태:
  - 3개 산업 (제조, 금융, 의료) 각 1개 케이스
  - 각 케이스 10-15 슬라이드

케이스 1: 글로벌 제조사 품질 관리
  - 문제 정의: 불량률 3% --> 목표 1%
  - 데이터 분석: 불량 패턴 식별
  - Foundry 솔루션 설계
  - ROI: 연간 5억원 절감

케이스 2: 은행 AML 모니터링
  - 문제 정의: 사기 탐지 정확도 60%
  - 데이터 분석: 거래 패턴 네트워크
  - Foundry 솔루션 설계
  - ROI: 위양성 50% 감소

케이스 3: 병원 환자 흐름 최적화
  - 문제 정의: 응급실 대기 시간 4시간
  - 데이터 분석: 환자 경로 최적화
  - Foundry 솔루션 설계
  - ROI: 대기 시간 50% 단축

목적: 실제 고객 대응 능력을 영상으로 증명

시나리오 3개 (각 5-7분):

시나리오 1: 분노한 고객 De-escalation
  - 설정: 대시보드 장애로 경영진 보고 실패
  - FDE 역할: HEARD 프레임워크 적용
  - 결과: 즉시 조치 + 재발 방지 계획 제시

시나리오 2: Scope Creep 관리
  - 설정: 3번째 요구사항 추가 요청
  - FDE 역할: 건설적 No + Phase 분리 제안
  - 결과: 현재 범위 합의 + 향후 로드맵

시나리오 3: 경영진 데모
  - 설정: CFO에게 15분 ROI 데모
  - FDE 역할: 스토리텔링 기반 프레젠테이션
  - 결과: Phase 2 예산 승인 획득

촬영 팁:
  - 친구/동료와 역할극 녹화
  - 각 시나리오 후 자기 분석 포함
  - "왜 이 접근법을 선택했는지" 해설