안녕하세요, Shrijith Venkatramana입니다. 저는 모든 커밋에서 실행되는 AI 코드 리뷰어인 git-lrc를 만들고 있습니다. 개발자들이 이 프로젝트를 발견할 수 있도록 Star Us를 눌러주세요. 꼭 한번 사용해 보시고 제품 개선을 위한 피드백을 공유해 주세요.

대규모 언어 모델 (Large Language Models, LLM)은 텍스트를 생성하는 일을 놀라울 정도로 쉽게 만들었습니다.

하지만 신뢰할 수 있는 AI 애플리케이션을 구축하는 것은 완전히 다른 문제입니다.

단순히 "프롬프트를 보내고 응답을 받는" 데모 단계를 넘어서면, 다음과 같은 실제적인 문제들에 빠르게 직면하게 됩니다:

프롬프트 관리 (Prompt management)
구조화된 출력 (Structured outputs)
다단계 워크플로우 (Multi-step workflows)
도구 호출 (Tool calling)
관찰 가능성 (Observability)
평가 (Evaluation)
모델 전환 (Model switching)
프로덕션 디버깅 (Production debugging)

많은 팀이 이러한 문제들을 관리하기 위해 OpenAI, Anthropic, Gemini 또는 로컬 모델을 중심으로 커스텀 프레임워크를 직접 만들게 됩니다.

이 지점에서 Genkit이 등장합니다.

원래 Google에서 개발한 Genkit은 워크플로우, 도구, 관찰 가능성, 평가 및 프로덕션 준비성 (Production readiness)에 초점을 맞추어 AI 기반 애플리케이션을 구축하기 위한 프레임워크를 제공합니다.

온라인의 대부분의 예제는 Node.js에 집중되어 있지만, Genkit은 이제 Go에 대한 지원을 확대하고 있어, 완전히 별개의 애플리케이션 스택을 도입하지 않고도 AI 기능을 원하는 백엔드 엔지니어들에게 흥미로운 선택지가 되고 있습니다.

이 글에서는 실질적인 예제를 구축하며 Genkit이 실제 AI 시스템을 구조화하는 데 어떻게 도움이 되는지 살펴보겠습니다.

Genkit이 존재하는 이유

대부분의 AI 애플리케이션은 다음과 같이 진화합니다:

1단계:

response := callLLM(prompt)

모든 것이 단순해 보입니다.

2단계:

다음과 같은 것들이 필요해집니다:

재시도 로직 (Retry logic)
프롬프트 버전 관리 (Prompt versioning)
JSON 출력 (JSON outputs)
도구 통합 (Tool integrations)
트레이싱 (Tracing)
메트릭 (Metrics)
인간 검토 워크플로우 (Human review workflows)

이제 코드베이스에 AI 전용 인프라가 쌓이기 시작합니다.

Genkit은 첫날부터 이러한 빌딩 블록을 제공하려고 시도합니다.

이를 다음과 같이 생각하면 됩니다:

"LLM SDK"라기보다는 "AI 워크플로우를 위한 Spring Boot""

Go용 Genkit 설치하기

새 프로젝트를 생성합니다:

mkdir genkit-demo
cd genkit-demo

...

Genkit을 설치합니다:

go get github.com/firebase/genkit/go/ai

사용하는 프로바이더 (Provider)에 따라 프로바이더 플러그인 (Provider plugins)도 설치해야 합니다.

Gemini의 경우:

go get github.com/firebase/genkit/go/plugins/googleai

첫 번째 AI 호출

간단한 생성 (Generation)부터 시작해 보겠습니다.

package main

import (
...

이는 일반적인 LLM 호출과 유사하지만, 애플리케이션이 이 단계를 넘어 성장할 때 Genkit의 진가가 더욱 분명하게 드러납니다.

구조화된 출력 (Structured Outputs): AI 텍스트 파싱 중단하기

AI 시스템에서 가장 흔히 발생하는 실수 중 하나는 모델에게 텍스트를 반환하도록 요청한 다음 이를 수동으로 파싱 (Parsing)하는 것입니다.

다음과 같은 방식 대신:

Name: John
Score: 87
Risk: Medium

스키마 (Schema)를 사용하세요.

고객 지원 티켓 분류기를 상상해 보세요.

type TicketClassification struct {
    Category string `json:"category"`
    Priority string `json:"priority"`
...

프롬프트 (Prompt):

이 지원 티켓을 분류하세요.

스키마와 일치하는 JSON을 반환하세요.

이제 다운스트림 서비스 (Downstream services)가 결과를 안전하게 소비할 수 있습니다.

실제 활용 사례:

리드 자격 검증 (Lead qualification)
리스크 분석 (Risk analysis)
송장 추출 (Invoice extraction)
고객 지원 라우팅 (Customer support routing)
계약서 검토 (Contract review)

구조화된 출력은 프롬프트의 취약성 (Fragility)을 극적으로 줄여줍니다.

다단계 AI 워크플로 (Multi-Step AI Workflows) 구축하기

대부분의 프로덕션 AI 시스템은 여러 단계를 포함합니다.

예시:

고객 이메일 도착.

워크플로 (Workflow):

이메일 요약
감성 분석 (Sentiment detection)
실행 항목 추출 (Action items extraction)
응답 초안 생성
사람의 검토를 위해 전송

프레임워크가 없다면:

Controller
 ├─ LLM Call #1
 ├─ LLM Call #2
...

로직을 유지 관리하기가 어려워집니다.

Genkit을 사용하면 워크플로를 플로우 (Flow)로 모델링할 수 있습니다.

summaryFlow := genkit.DefineFlow(
    g,
    "summarizeCustomerEmail",
...

플로우는 흩어져 있는 LLM 호출이 아니라 재사용 가능한 애플리케이션 구성 요소가 됩니다.

도구 호출 (Tool Calling): 모델이 시스템을 사용하게 하기

AI 모델이 모든 것을 알고 있어야 한다는 것은 흔한 오해입니다.

실제로는 다음과 같습니다:

모델은 추론 (Reasoning)해야 합니다.

시스템은 사실 (Facts)을 제공해야 합니다.

주문 추적 어시스턴트를 상상해 보세요.

모델에게 주문에 대해 가르치는 대신:

주문 #78291
상태: 배송됨
운송사: FedEx
...

도구 (Tool)를 노출합니다.

func GetOrderStatus(orderID string) string {
    return "Shipped"
}

모델은 다음과 같이 결정합니다:

주문 정보가 필요합니다.
도구 호출 (Call tool).
결과 읽기 (Read result).
...

이 패턴을 통해 다음을 수행할 수 있습니다:

데이터베이스 조회 (Database lookups)
CRM 접근
내부 API (Internal APIs)
재고 시스템 (Inventory systems)
지식 베이스 (Knowledge bases)

많은 엔터프라이즈 AI 시스템은 본질적으로 다음과 같습니다:

LLM + 도구 (Tools)

이 아니라

LLM + 더 많은 프롬프팅 (More Prompting)

관찰 가능성 (Observability): 대부분의 팀이 너무 늦게 깨닫는 기능

사용자가 다음과 같이 보고한다고 가정해 봅시다:

"AI가 엉망인 답변을 내놓았어요."

추적 (Tracing) 없이는 눈을 감고 있는 것과 같습니다.

즉시 다음과 같은 질문들이 생겨납니다:

어떤 프롬프트 (Prompt)가 사용되었는가?
어떤 모델 (Model)이 답변했는가?
어떤 컨텍스트 (Context)가 제공되었는가?
어떤 도구 호출 (Tool calls)이 실행되었는가?
비용이 얼마나 들었는가?

Genkit은 AI 워크플로 (Workflows)의 디버깅을 훨씬 쉽게 만들어 주는 관찰 가능성 (Observability) 기능을 포함하고 있습니다.

전통적인 디버깅:

87번 라인에서 오류 발생

AI 디버깅:

프롬프트 (Prompt)
→ 컨텍스트 (Context)
→ 도구 호출 (Tool Calls)
...

이것은 종종 관리 가능한 프로덕션 시스템과 몇 주간의 혼란 사이의 차이를 만듭니다.

실제 사례: AI 기반 장애 요약 (Incident Summaries)

당신이 플랫폼 팀을 운영하고 있다고 상상해 보세요.

모든 장애 (Incident)는 다음을 생성합니다:

Slack 메시지
알림 (Alerts)
로그 (Logs)
Jira 티켓

엔지니어들은 장애 보고서를 작성하는 데 시간을 보냅니다.

Genkit 워크플로는 다음과 같은 일을 할 수 있습니다:

장애 데이터 수집
타임라인 요약
근본 원인 지표 (Root cause indicators) 식별
사후 분석 보고서 (Postmortem) 초안 작성
후속 조치 제안

의사 흐름 (Pseudo-flow):

알림 (Alerts)
   ↓
요약 (Summarization)
...

이것이 바로 Genkit이 빛을 발하는 반복 가능하고 다단계인 프로세스의 전형적인 유형입니다.

모델 이식성 (Model Portability)은 대부분의 팀이 예상하는 것보다 더 중요합니다

초기 단계의 팀들은 종종 하나의 모델을 영원히 사용할 것이라고 가정합니다.

현실은 다음과 같습니다:

가격 정책 변경
새로운 모델 등장
성능 변화
컴플라이언스 (Compliance) 요구사항 발생

오늘의 선택:

Gemini

6개월 후:

Anthropic

12개월 후:

로컬 모델 (Local model)

애플리케이션 로직 (Application logic)을 모델 제공자 (Model providers)로부터 분리하는 프레임워크는 마이그레이션 (Migration)의 고통을 줄여줍니다.

Genkit은 이러한 분리를 권장합니다.

하단의 모델들이 진화하는 동안에도 여러분의 워크플로 (Workflow) 로직은 상대적으로 안정적으로 유지됩니다.

Genkit 도입 시 흔히 하는 실수

1. 단순한 SDK처럼 취급하는 것

Genkit은 워크플로 (Workflows), 도구 (Tools), 스키마 (Schemas), 그리고 평가 (Evaluation)를 포괄적으로 수용할 때 가장 가치 있습니다.

단순히 텍스트 생성 (Text generation) 용도로만 사용하는 것은 그 가치의 상당 부분을 활용하지 못하는 것입니다.

2. 과도한 자동화

모든 프로세스가 자율화(Autonomous)될 필요는 없습니다.

많은 성공적인 시스템은 다음과 같은 방식을 사용합니다:

AI → 인간 검토 (Human Review) → 실행 (Action)

대신 다음과 같은 방식을 사용합니다:

AI → 실행 (Action)

3. 평가 (Evaluations)를 무시하는 것

오늘 작동하는 워크플로가 다음과 같은 상황 이후에는 성능이 저하될 수 있습니다:

프롬프트 (Prompt) 변경
모델 업그레이드 (Model upgrades)
데이터 변경 (Data changes)

평가는 단위 테스트 (Unit testing)만큼이나 진지하게 다뤄져야 합니다.

마치며

현재 AI 생태계에는 모델 제공자가 부족하지 않습니다.

많은 팀에게 실제로 필요한 것은 이러한 모델들을 둘러싼 더 나은 인프라 (Infrastructure)입니다.

Genkit은 단순한 API 호출과 프로덕션급 (Production-grade) AI 시스템 사이의 실질적인 간극을 메워줍니다. Genkit은 워크플로를 구축하고, 도구를 통합하며, 동작을 모니터링하고, 모델이 변화함에 따라 애플리케이션을 진화시킬 수 있는 구조화된 방법을 제공합니다.

Go 개발자들에게 이는 특히 가치 있는 일인데, AI 기능을 별도의 JavaScript 스택으로 강제하는 대신 기존 백엔드 서비스 내에 공존할 수 있게 해주기 때문입니다.

이제 흥미로운 질문은 더 이상 다음과 같지 않습니다: