“원샷”으로는 안 된다 — Granola의 Mehedi Hassan이 말하는 AI 제품 엔지니어링
📺 원본 영상: You can’t just one shot it — Mehedi Hassan, Granola 🎙️ 채널: AI Engineer 📅 정리 일자: 2026-05-11 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(데모 화면, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
Granola의 프로덕트 엔지니어 Mehedi Hassan은 이 강연에서 LLM 기반 AI 기능을 실제 제품에 녹여내는 과정이 얼마나 생각보다 복잡한지를 솔직하게 이야기한다. 강연의 핵심 테제는 제목 그 자체다. 단번에 뚝딱 만들어내는 “원샷(One-shot)” 개발로는 프로덕션 수준의 AI 경험을 만들 수 없으며, 반복적인 실험과 관찰을 가능하게 하는 엔지니어링 인프라가 먼저 갖춰져야 한다는 것이다. 강연은 크게 세 가지 주제를 다룬다. AI 기능의 현실적인 복잡성, Granola 내부에서 구축한 트레이싱(Tracing) 툴링, 그리고 Electron 데스크탑 앱을 웹 셸(Web Shell)로 전환하여 테스트 속도를 획기적으로 끌어올린 사례다.
Granola가 만드는 것
Granola는 회의 메모 앱이다. 시스템 오디오와 마이크 오디오에 동시에 접근하여 실시간 전사(Transcription)를 제공하고, 회의가 끝나면 자동으로 정리된 노트를 생성해 준다. 이 앱의 핵심 철학은 “방해하지 않는다(not get in your way)“는 것으로, 사용자가 의식하지 않아도 자연스럽게 작동하는 경험을 지향한다. 강연자가 강조하는 점은, Granola가 단순한 전사 도구에 머물지 않는다는 것이다. 사용자가 전사 내용 위에 자신의 메모를 직접 추가할 수 있고, AI는 그 두 가지 입력을 함께 고려하여 최종 노트를 생성한다. 이렇게 만들어진 결과물이 단순 전사보다 훨씬 사용자의 실제 필기 스타일에 가깝다는 것이 Granola의 차별점이다.
01:06 - Granola 데모: 이전 발표자의 내용을 전사하고 AI가 자동으로 회의 노트를 생성하는 화면
AI 기능을 “원샷”하면 벌어지는 일
강연자는 Granola에 채팅(Chat) 기능을 구현하는 상황을 예시로 든다. 사용자가 특정 회의나 여러 회의에 걸친 내용에 대해 질문하면, Granola가 답변해 주는 기능이다. 코드 몇 줄로 LLM API를 연결하는 것 자체는 어렵지 않다. 그러나 실제 사용자들이 이 기능을 사용하기 시작하면 곧바로 현실의 벽에 부딪힌다. 할 일 목록을 제대로 뽑아주지 못하고, 웹 검색 응답이 너무 느리고, 사용자가 평소 쓰는 이메일 문체로 초안을 작성해 주지 못한다. 심지어 “내 회의 코칭을 해달라”는 요청에 축구 코치 이야기를 늘어놓는 상황도 벌어진다. 강연자에 따르면, 이는 범용 챗봇을 만들 때 필연적으로 마주치는 문제들이다. LLM을 특정 사용 사례에 맞게 다듬는 일은 처음 보기보다 훨씬 까다롭다.
웹 검색 하나만 해도 이렇게 복잡하다
웹 검색 기능을 예로 들면 이 복잡성이 더욱 뚜렷하게 드러난다. 대부분의 LLM 제공사는 웹 검색 툴을 단 한 줄의 코드로 추가할 수 있다고 홍보한다. 그러나 강연자는 이것이 제공사들이 믿게 만들고 싶은 이야기일 뿐이라고 잘라 말한다. 실제로 들어가 보면, 복잡한 쿼리에서 토큰 사용량과 비용이 폭발적으로 늘어나는 문제가 있다. 회당 약 10펜스(pence) 수준의 비용이 발생할 수 있는데, 수백만 명의 사용자를 대상으로 하면 전혀 현실적이지 않은 규모가 된다. 더 심각한 문제는 외부 종속성이다. 강연자의 팀이 경험한 것처럼, 어느 날 갑자기 모델 제공사가 업데이트를 배포하면서 웹 검색 품질이 하락하는 일이 발생했고, 팀은 그 원인을 파악하지 못한 채 그저 다른 제공사로 갈아타는 것 외에 선택지가 없었다. 강연자는 이 경험을 통해 “웹 검색만을 전문으로 하는 수십억 달러 규모의 회사들이 존재한다는 사실 자체가, 그것이 단순히 파이프라인에 툴 하나 추가하는 문제가 아님을 말해준다”고 강조한다.
02:51 - 웹 검색 기능의 복잡성을 설명하는 시점 — 토큰 비용 폭증 문제 및 제공사 의존성 논의
맞춤형 출력, 한 가지 프롬프트로는 불가능하다
출력의 다양성 문제도 핵심 과제다. Granola가 생성하는 회의 요약 노트는 직군에 따라 기대하는 바가 완전히 다르다. 영업 담당자는 고객과의 다음 단계에 집중하는 요약을 원하고, 엔지니어는 액션 아이템이나 블로커(Blocker), 혹은 Linear 티켓으로 바로 연결될 수 있는 항목을 기대한다. 인사팀은 또 전혀 다른 형태의 정리를 원할 것이다. 강연자는 “하나의 프롬프트로 모든 사람을 만족시킬 수 없다”고 단언하며, LLM은 다루기 까다롭고 원하는 방향으로 동작하게 만들기 위해서는 내부를 깊이 이해해야 한다고 말한다. 문제는 LLM의 동작 방식이 블랙박스처럼 보인다는 것이다. Granola 팀이 택한 해법은, 그 블랙박스 안으로 직접 뛰어들어 정확히 무슨 일이 일어나고 있는지를 파악하는 것이었다.
블랙박스를 열다 — 내부 트레이싱 툴 구축
LLM 동작을 제대로 이해하기 위해 Granola 팀은 자체 트레이싱(Tracing) 툴을 구축하기로 결정했다. 강연자는 흥미롭게도 이 트레이싱 툴 자체를 LLM으로 “원샷”했다고 말한다. 복잡한 내부 인프라 툴은 아이러니하게도 원샷이 꽤 잘 먹히는 영역이기 때문이다. 이 툴을 통해 팀은 에이전트 루프(Agent Loop)의 시작부터 끝까지 모든 툴 호출(Tool Call)을 완전히 가시화할 수 있게 되었다. 각 툴 호출의 이유, 검색 트레일(Search Trail), 추론 트레일(Reasoning Trail), 그리고 정확히 원하는 방식으로 구조화된 비용 정보까지 한눈에 파악할 수 있다.
04:44 - Granola가 자체 구축한 내부 트레이싱 툴 UI — 에이전트 루프의 툴 호출 흐름 시각화 화면
이 툴이 특별한 이유는 단순히 엔지니어만을 위한 것이 아니라는 점이다. UI는 엔지니어뿐 아니라 프로덕트, 데이터, 고객 경험(CX) 팀 모두가 사용할 수 있도록 설계되었다. AWS CloudWatch에 들어가 복잡한 쿼리를 날려야만 오류 원인을 파악할 수 있는 상황에서 벗어나, 누구든 인터페이스 상에서 에이전트의 동작 흐름을 처음부터 끝까지 추적할 수 있게 된 것이다. 강연자에 따르면 Granola의 공동창업자도 이 툴을 직접 사용하며 에이전트 루프를 처음부터 끝까지 따라가 정확히 무엇이 잘못되었는지 파악한다고 한다. 기술적으로는 AI SDK를 래핑(Wrapping)하여 데이터베이스에 저장하는 비교적 단순한 구조지만, 강연자는 프론트엔드, 즉 사람들이 실제로 사용하는 UI가 가장 중요한 부분이라고 강조한다.
05:06 - 트레이싱 툴의 데이터 구조와 UI 상세 — 검색 트레일, 추론 트레일, 비용 정보가 구조화된 화면
Electron 앱을 웹 셸로 — 실험 속도를 끌어올리다
LLM의 도움으로 더 많은 변형(Variant)을 빠르게 만들 수 있게 되면서, Granola 팀은 새로운 병목에 부딪혔다. Granola는 데스크탑 앱이다. 하나의 기기에서 동시에 하나의 인스턴스만 실행할 수 있다는 뜻이다. 새로운 기능이나 변형을 테스트하려면 Electron 앱을 로컬에서 실행하고 의존성을 설치해야 했으며, 동료에게 같은 변형을 테스트해 달라고 요청하면 그 동료도 똑같은 과정을 거쳐야 했다. 웹 앱이라면 당연히 누리는 프리뷰 링크 방식의 협업이 불가능했다.
이 문제를 해결하기 위해 팀은 Electron 앱의 프론트엔드를 웹 셸(Web Shell)로 분리하여 온라인에 배포하는 방식을 택했다. 구체적으로는, Electron의 메인 프로세스와 렌더러 프로세스(Renderer Process) 구조에서 IPC(Inter-Process Communication, 프로세스 간 통신) API, 즉 시스템 API를 웹 환경에서는 웹 표준(Web Standards)으로 폴백(Fallback)하도록 추상화했다. React 라우터, 세션, 쿼리 레이어도 마찬가지로 웹 표준을 따르도록 이동시켰다. 결과적으로 렌더러 레이어가 Electron에 의존하지 않게 되었고, 동일한 프론트엔드 코드가 웹 앱으로도 그대로 실행될 수 있게 되었다.
이 변화의 효과는 즉각적이었다. CI/CD 파이프라인에 통합되어, 이제 Pull Request(PR)를 열면 자동으로 프리뷰 링크가 생성된다. 팀원 누구든 링크만 열면 해당 변경사항을 바로 테스트할 수 있다. 여기서 한 발 더 나아가, Cursor와 같은 AI 코딩 도구가 PR이 열리면 자동으로 프리뷰 링크에 접속해 기능을 테스트하고 스크린샷을 해당 PR에 업로드한다. 사람의 개입 없이 자동화된 시각적 검증이 이루어지는 것이다.
07:18 - Electron 앱의 IPC 추상화 및 웹 셸 전환 아키텍처 다이어그램 설명 화면
Q&A — Tauri 전환을 고려한 적 있는가
강연 후 질의응답에서 Tauri(Rust 기반 데스크탑 앱 프레임워크)로의 전환을 검토한 적이 있는지에 대한 질문이 나왔다. 강연자는 몇 차례 검토한 적이 있다고 인정했다. 그러나 현재 Electron이 제공하는 API가 팀의 니즈를 충족시키고 있고, Tauri를 직접 시도해 봤을 때 팀이 가장 중요하게 생각하는 성능상의 유의미한 이득을 체감하지 못했다고 말했다. 또한 Tauri의 API가 아직 변화가 많은 상태라는 점도 전환을 주저하게 만드는 요인 중 하나로 언급되었다. 결국 논의는 있었으나 현재로서는 전환하지 않기로 결정한 상태다.
마무리 — 피드백 루프가 마법을 만든다
강연 전체를 관통하는 메시지는 간결하다. AI 시대에도 “원샷”은 유효하지 않다. LLM이 개발 생산성을 높여주는 것은 사실이지만, 그것이 프로덕션에서 사용자를 만족시키는 AI 기능을 처음 한 번에 만들 수 있다는 뜻은 아니다. 강연자는 이것을 테니스 경기에 비유한다. 개발자와 LLM이 공을 주고받듯 반복적으로 실험하고 관찰하는 피드백 루프를 구축해야 한다는 것이다. 그 루프가 잘 돌아갈 때, 최종 사용자가 경험하는 기능은 “그냥 작동하는 것”이 아니라 “마법처럼 느껴지는 것”이 된다.
결국 Granola 팀이 공유한 두 가지 인프라 투자 — 내부 트레이싱 툴과 웹 셸 전환 — 는 모두 이 피드백 루프를 빠르고 넓게 만들기 위한 수단이었다. LLM의 동작을 관찰하고 이해하는 능력, 그리고 다양한 변형을 신속하게 테스트하고 비교하는 능력. 이 두 가지가 갖춰졌을 때 비로소 좋은 AI 제품을 만들 수 있다는 것이 강연자의 결론이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | You can’t just one shot it — Mehedi Hassan, Granola |
| 채널 | AI Engineer |
| 발표자 | Mehedi Hassan (Product Engineer, Granola) |
| 리포트 작성 | 2026-05-11 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.