일상의 Forward Deploy — Claude로 내 옆의 사람들에게 가치 선물하기

들어가며

Forward Deploy Engineer라는 직무가 있습니다. 고객 현장에 직접 들어가 그들의 문제를 듣고, 즉시 솔루션을 만들어 가져다주는 엔지니어죠. Palantir에서 처음 알려졌고, 최근에는 OpenAI와 Anthropic 같은 AI 회사들도 이 역할을 적극 채용하고 있습니다. 일반적인 소프트웨어 엔지니어가 사양서를 받아 안에서 만드는 사람이라면, Forward Deploy Engineer는 사양서가 없는 곳으로 직접 걸어 들어가 그것을 함께 그려내는 사람입니다. 이 직무를 처음 접했을 때, 저는 회사라는 맥락 안에서만 가능한 일이라고 생각했습니다. 고객사가 있고, 계약이 있고, 풀어야 할 비즈니스 문제가 있어야 비로소 시작되는 일이라고요. 그런데 어느 순간부터 다른 생각이 들기 시작했습니다. 내 주변에도 현장이 있고, 풀어야 할 문제가 있다. 봉사자의 분주함, 시험을 준비하는 지인의 막막함, 동료의 반복되는 수고. 이런 것들이 누군가에게는 매일의 진짜 문제입니다. 그리고 지금 우리 손에는, 몇 년 전이라면 상상하기 어려웠던 도구가 쥐어져 있습니다. AI가 일정 수준의 소프트웨어를 만드는 데 드는 시간을 극적으로 줄여주었기 때문이죠. 이 글에서 나누고 싶은 이야기는, 결국 그 두 가지가 만났을 때 일어난 일입니다. 회사 밖의 현장에서, 제가 만든 무언가가 누군가에게 작은 선물이 될 수 있겠다는 가능성. 두 개의 사례를 통해 그 과정을 풀어보고, 마지막에는 그 과정에서 제가 배운 엔지니어링적인 통찰까지 함께 나눠보려 합니다. ---

첫 번째 선물: 교회 카페 키오스크

문제는 늘 관찰에서 시작된다

제가 다니는 교회에는 작은 카페가 있습니다. 예배 전후로 사람들이 모여 음료를 주문하고, 봉사자 한두 분이 그 주문을 받아 음료를 만들어 건네는 곳이죠. 어느 주일, 카페 앞을 지나가다 봉사자 분이 쏟아지는 주문 메모와 결제 응대를 동시에 처리하느라 정신없이 움직이는 모습을 보았습니다. 카페 앞으로는 줄이 길게 늘어서 있었고, 기다리는 분들의 표정에는 약간의 지친 기색이 있었습니다. 문제가 보였습니다. 한정된 봉사자 인력으로는 주문 접수와 음료 제조를 동시에 감당하기 어렵고, 사용자 입장에서는 줄이 길어 카페 이용 자체가 부담이 되는 상황이었습니다. 그날 저는 작은 MVP를 만들어 봉사자 분들께 보여드려보자고 마음먹었습니다. image

가장 단순한 솔루션 설계하기

문제를 봤으니, 솔루션을 설계할 차례였습니다. 그런데 여기서 중요한 결정이 있었습니다. 얼마나 작게 시작할 것인가. 문제를 풀기 위한 가장 단순화된 최소 솔루션은 두 가지 핵심 결정을 담고 있었습니다. 첫째, 바리스타용 화면입니다. 봉사자가 종이 메모 대신 화면으로 주문을 실시간으로 확인할 수 있도록 했습니다. 다만 별도의 POS 단말기를 도입하면 비용이 부담되고, 봉사자가 새로운 기기 사용법을 익혀야 하는 진입 장벽도 생깁니다. 그래서 교회에 이미 있는 태블릿을 활용한다는 가정 하에, 태블릿 화면 비율에 최적화된 인터페이스를 만들기로 했습니다. 둘째, QR 코드 기반 주문입니다. 사용자용 키오스크 단말기를 별도로 마련하면 비용이 또 추가됩니다. 게다가 한 대만 두면 결국 그 앞에 다시 줄이 생기죠. 대신 QR 코드를 카페 곳곳에 붙여두고, 사용자가 자기 스마트폰으로 스캔해 주문하도록 했습니다. 모두가 이미 들고 있는 단말기를 키오스크로 만든 셈입니다. 이 두 결정 모두 비용 제약을 디자인으로 푼 결정이었습니다. 그리고 동시에 지금 당장 시작할 수 있는 형태이기도 했죠. 어떤 솔루션이 좋은 솔루션인지를 가르는 기준 중 하나는, 이 솔루션이 현실에서 즉시 실행 가능한가 하는 점이라고 저는 생각합니다. image image

디자인은 무드를 입히는 일

기능 설계가 끝났으니 다음은 만드는 단계인데, 본격적인 작업 전에 먼저 Claude로 디자인 시안을 뽑았습니다. 일관된 디자인 언어를 가진 시안을 먼저 가지고 있어야, 이후 어떤 화면을 만들어도 통일된 인상을 줄 수 있기 때문입니다. 프롬프트의 핵심은 교회 인테리어 무드를 입히는 것이었습니다. 제가 다니는 교회는 큰 유리 통창으로 자연광이 들어오고, 따뜻한 노란빛 조명이 공간을 감싸는 분위기를 가지고 있습니다. 시안을 그릴 때 이 두 가지 — 넓은 빛, 따뜻한 톤 — 가 시각적으로 묻어나도록 유도했습니다. 직관적으로 사용할 수 있는 정보 구조 위에, 이 카페만의 무드를 덧입히는 작업이었죠. 디자인 시안 단계부터 이 점을 중요하게 생각했습니다. 선물은 기능만으로는 완성되지 않습니다. 같은 기능이라도, 받는 사람의 환경과 어울리는 모습으로 다가갈 때 비로소 선물답게 느껴진다고 저는 생각하거든요. 일반적인 SaaS 키오스크 템플릿을 그대로 가져다 썼다면 기능은 같았겠지만, 그건 우리 교회 카페의 키오스크가 아니라 그냥 키오스크였을 겁니다.

피드백, 그리고 무엇을 미룰 것인가

MVP가 어느 정도 완성되었을 때, 주변에 보여드리며 반응을 수집했습니다. 받은 피드백은 대략 이런 것들이었습니다. 여기서 중요한 결정을 내려야 했습니다. 모든 피드백을 다 반영할 것인가? 저는 그러지 않기로 했습니다. 우선순위를 매긴 결과는 이랬습니다. 카페 봉사자 본인의 요청은 가장 우선순위가 높았습니다. 결제 흐름은 카페 운영의 핵심이고, 알림 기능은 사용자 만족도에 직결되기 때문입니다. 폰트 변경도 즉시 반영했습니다. 비용이 거의 들지 않으면서 사용성을 분명히 개선하는 일이었으니까요. 네트워크 환경 제약 역시 즉시 대응했습니다. 이미지 최적화와 캐싱 전략을 적용해 느린 회선에서도 부담 없이 동작하도록 만들었습니다. 판매 보고서는 연기했습니다. 당사자의 요구사항이 아니었고, 당장 급한 일도 아니었습니다. 매출 분석은 분명 가치 있는 기능이지만, 지금 이 솔루션이 풀어야 할 가장 절박한 문제는 주문 흐름의 병목이었습니다. 그것이 풀리지 않은 상태에서 보고서 기능을 더하는 것은, 받는 사람에게 필요 없는 무게를 더하는 일이었습니다. 판매 보고서가 우선순위에서 밀린 이유는 단순합니다. 당사자의 요구사항이 아니었고, 결제 흐름이나 알림처럼 봉사자가 일하는 데 필수적인 항목도 아니었기 때문입니다. 결국 누구의 문제를 풀고 있는가라는 기준 위에서 우선순위가 갈린 셈이고, 카페 봉사자가 덜 분주해지고 사용자가 덜 기다리는 것 — 이 두 가지가 이 프로젝트의 업무 규칙이었습니다. 다른 것들은 모두 그 다음의 이야기였고요. 이 부분은 글의 마지막에서 다시 한 번 다루겠습니다. image

하네스 엔지니어링: 바르게 만드는 것이 가장 빠르다

피드백을 반영해 기능을 쌓아가다 보면 어느 순간 무언가가 어긋나기 시작합니다. 새로 추가한 알림 기능이 결제 흐름의 다른 부분을 깨뜨리거나, 디자인 일관성이 무너지거나, 이전에 잘 동작하던 화면이 갑자기 멈추거나. 특히 AI 에이전트가 코드를 빠르게 만들어내는 환경에서는 이런 일이 더 자주, 더 조용히 일어납니다. 저는 이 문제를 하네스 엔지니어링으로 풀었습니다. image 하네스 엔지니어링은 AI 에이전트가 일관되고 안전하게 작업할 수 있도록 그 주변 환경을 설계하는 일을 말합니다. 이 하네스를 두 종류로 나누어 이야기해 볼 수 있을 것 같습니다. 소프트 하네스는 자연어로 작성된 지침입니다. "이런 식으로 코딩해줘", "이 컨벤션을 지켜줘" 같은 안내죠. 반면 하드 하네스는 도구, 환경, 제약 사항으로 구성된 실제적인 가드레일입니다. 테스트 커버리지 임계값, 린트 규칙, 타입 검사, 커밋 시점의 자동 검증 같은 것들이죠. 저는 하드 하네스가 하네스 엔지니어링의 핵심이라고 생각합니다. 자연어 지침은 권유에 가깝지만, 도구가 거는 제약은 불가능을 만드는 일이거든요. 권유는 잊혀질 수 있지만, 통과하지 않으면 커밋이 안 되는 검사는 잊혀지지 않습니다. 이 카페 키오스크 앱에는 100% 테스트 커버리지와 린트 규칙 준수를 매 커밋마다 강제했습니다. 효과는 두 갈래로 나타났습니다. 첫째, 기능을 쌓아 가더라도 일관성이 유지됐습니다. 새 기능이 들어와도 회귀 테스트가 기존 동작을 보장해주었고, 추가된 기능도 처음부터 테스트와 함께 작성되었습니다. 추가적으로, 테스트를 강제한다는 것은 경계 설정을 유도하는 효과까지 가져왔습니다. 테스트하기 어려운 코드는 보통 결합도가 너무 높거나 책임이 너무 많은 코드인데, 테스트 커버리지를 채워야 한다는 제약이 자연스럽게 코드를 잘 분리된 형태로 밀어붙였습니다. 둘째, AI 에이전트가 길을 잃지 않았습니다. 에이전트가 기능을 구현하는 도중에도, 커밋 단계에서 즉시 피드백이 돌아옵니다. 테스트가 깨지면 멈추고 고쳐야 하고, 린트 오류가 나면 통과시켜야 합니다. 이로써 에이전트가 일관성 없는 코드를 계속 생성하다 스스로 만든 미로 속에 갇히는 일이 일어나지 않습니다. 매 단계마다 길을 다시 정렬하게 되는 거죠. 결과적으로 앱의 구현 속도와 안정성이 동시에 보장됩니다.
바르게 만드는 것이 가장 빠릅니다.
이 한 줄이 카페 키오스크 프로젝트에서 제가 얻은 가장 큰 교훈입니다. AI로 빠르게 만들 수 있는 시대일수록, 오히려 바르게 만드는 일을 강제하는 환경이 더 큰 차이를 만든다는 것. 빠름과 견고함은 반대말이 아니라, 같은 것의 다른 이름일 수 있다는 것입니다. ---

두 번째 선물: 공시 시험 준비 앱

지인의 어려움이 보였을 때

두 번째 사례는 더 가까운 곳에서 시작됐습니다. 지인이 공시 시험을 준비하고 있었는데, 어느 날 공부 동기를 유지하기가 어렵다는 말을 했습니다. 어디까지 진도가 나갔는지, 시험까지 얼마나 남았는지, 지금 페이스로 가면 시험 전에 회독을 몇 번 할 수 있는지 — 이런 것들이 막연하게 느껴진다는 것이었습니다. 저는 도와야겠다고 생각했고, 동시에 머릿속이 빠르게 부풀어 올랐습니다.

처음의 욕심

처음에 제가 만들고 싶었던 기능들의 목록은 거창했습니다. 쓰면서도 멋지다고 생각했습니다. 그리고 실제로 이런 기능들이 모두 모이면 정말 강력한 시험 준비 도구가 될 거라고 믿었습니다. 문제는 단 하나였습니다. 이걸 다 만들고 있다가는 지인의 시험 준비 기간이 다 끝납니다. 하고 싶은 게 너무 많으면 시간만 가고 아무것도 진행되지 않습니다. 이 진리를 저는 또 한 번 배웠습니다. 그리고 욕심을 잘라냈습니다. 이 거창한 기능 모두는 미루기로 했습니다.

하나에 집중하고, 빠르게 구현하기

남긴 기능은 단 하나였습니다. 현재 공부 페이스 추적. 오늘까지 얼마나 진도를 나갔는가, 시험까지 며칠 남았는가, 지금 페이스로 가면 시험 전에 몇 회독이 가능한가. 이 세 가지를 한 화면에서 보여주는 것. 그것뿐이었습니다. 지인에게 이 앱을 빠르게 출시해 전달했습니다. 받은 반응은 이랬습니다.
"공부 페이스랑 시험 전 회독 예상을 확인할 수 있어서 좋다. 혹시 알림 기능도 만들어 줄 수 있을까?"
알림 기능. 이건 사실 카페 키오스크 앱에서 한 번 미뤄둔 기능이기도 했습니다. PWA 알림은 구현 경험이 없었고, 특히 iOS에서는 사용자가 직접 웹앱을 홈 화면에 추가해야만 알림을 받을 수 있다는 제약이 있어서, 일정상 카페 앱에서는 우선순위에서 밀려나 있었습니다. 그런데 시험 앱에서는 지인이 직접 요청한, 가장 절실한 기능이었습니다. 저는 당일 바로 구현해서 전달했습니다. iOS 홈 화면 추가 가이드까지 포함해서요. 그리고 이때 쌓은 PWA 알림 구현 노하우는, 나중에 카페 키오스크 앱으로 자연스럽게 옮겨졌습니다. 한 사람을 위한 선물에서 얻은 작은 경험이, 다른 사람을 위한 선물의 재료가 되어 돌아온 셈입니다. image

빠른 출시의 선순환

이 두 번째 사례에서 저는 빠른 출시와 선택과 집중이 만들어내는 선순환을 확인했습니다. 먼저, 사용자의 신뢰를 얻을 수 있습니다. 거창한 청사진을 보여주는 것이 아니라, 작아도 동작하는 무언가를 손에 쥐여주는 것. 이게 신뢰의 시작이었습니다. 만약 제가 망각 곡선 알고리즘까지 다 만들어서 한 달 뒤에 들고 갔다면, 지인은 그 사이에 이미 자신만의 다른 방법을 찾아냈을 것이고, 제 솔루션은 늦게 도착한 선물이 되었을 겁니다. 그리고 그 신뢰 위에서 비로소 사용자가 진짜 원하는 것이 무엇인지가 드러납니다. 알림 기능은 제가 처음에 그렸던 거창한 기능 목록 어디에도 없었습니다. 사용자가 직접 써보지 않았다면 그 필요는 영원히 발견되지 않았을 겁니다. 마지막으로, 진짜 필요가 발견되면 다시 빠른 출시를 할 수 있게 됩니다. 알림은 당일에 전달했고, 다시 그 위에서 다음 피드백이 흘러옵니다. 빠른 출시 → 신뢰 → 진짜 필요의 발견 → 다시 빠른 출시. 이 선순환이 시작되면, 솔루션은 점점 받는 사람의 모양에 맞춰 자라납니다. 처음부터 완벽한 솔루션을 설계하려 할 때보다 훨씬 더 정확한 모양으로 말이죠. ---

진짜 어려움은 코드가 아니라 사람

여기까지 읽으시면 모든 게 잘 흘러간 이야기처럼 보일 수 있는데, 솔직히 말씀드리면 그렇지 않습니다. 카페 키오스크 앱은 아직 적용되지 않았습니다. 이 글을 쓰는 지금도, 저는 여전히 설득 단계에 있습니다. 교회에는 디지털에 익숙하지 않은 어르신들이 많이 계십니다. 봉사자 분들 중에도 마찬가지입니다. 처음 보는 QR 코드 주문 흐름이 누군가에게는 자연스럽지만, 누군가에게는 낯설고 부담스러운 변화입니다. 내가 만든 선물이라고 해서 받는 사람이 자연스럽게 환영해 주리라는 보장은 없습니다. 오히려 받는 사람의 입장에서는, 익숙한 것을 바꾸자는 제안 자체가 부담이 될 수도 있습니다. 이 단계에 와서 저는 자신에게 자꾸 묻게 됩니다. 세 번째 질문에는 한 겹 더 깊은 함정이 있습니다. 사용자는 자신이 무엇이 정말로 필요한지 모르는 경우가 적지 않습니다. 그런 상태에서 특정 기능을 요구하기도 하고, 어떤 솔루션이 자신의 일상에 들어왔을 때 어떤 변화를 가져올지 미리 그려보기 어려운 경우도 많습니다. 그래서 만드는 입장에서는, 사용자가 요구한 것을 그대로 만들기만 해서는 충분하지 않을 때가 있습니다. 요구사항 너머의 진짜 의도까지 함께 보아야 합니다. 동시에, 만드는 사람에게는 책임질 수 있는 솔루션을 제시할 의무가 있습니다. 기술 부채, 보안, 운영 부담 같은 것들은 사용자가 보지 못하는 부분이지만, 솔루션이 오래 살아남기 위해서는 결국 만드는 사람이 짊어지고 가야 할 무게입니다. 그래서 때로는 사용자가 처음 말한 요구사항을 그대로 받지 않고, 더 나은 형태로 협상하는 일이 필요합니다. 받는 사람의 입장에서 진심으로 고민하여, 사용자가 말한 것보다 더 깊은 곳에 있는 진짜 필요를 향해 솔루션을 다듬어 가는 일. 이게 만드는 사람이 짊어진 책임의 모양이라고 저는 생각합니다. 그리고 그 결과물은 때로, 사용자가 처음 요구한 것이나 말한 것과는 다른 모습으로 도착하기도 합니다. 그래서 저는 객관적으로 묻게 됩니다. 정말 카페 봉사자 분들의 일이 줄어드는가? 사용자의 대기 시간이 의미 있게 짧아지는가? 줄어드는 시간과 익숙함을 잃는 비용 사이에서, 진짜 이득이 있는가? 이 질문에 답하기 위해서는 결국 고객과 끊임없이 대화하고, 협상하고, 그들의 입장에서 생각하는 일이 필요합니다. 코드를 짜는 시간보다, 솔루션이 받는 사람의 일상에 어떻게 들어갈지 상상하고 조율하는 시간이 더 길어지기도 합니다. 이게 Forward Deploy Engineer의 진짜 본질이라고 저는 생각합니다. 멋진 솔루션을 만드는 일이 아니라, 받는 사람이 자신의 손에 쥐고 자연스럽게 쓰게 만드는 일. 그래서 Forward Deploy의 진짜 어려움은 코드가 아니라, 사람을 향해 있습니다. 그리고 어쩌면 이 어려움이야말로, 회사 안의 Forward Deploy Engineer와 일상의 Forward Deploy 모두가 공유하는 가장 중요한 일일지도 모릅니다. 회사에서는 이걸 시니어 엔지니어가 해주거나, 별도의 PM이 해주는 경우가 많지만, 일상에서는 그 모든 역할을 자기가 짊어지게 됩니다. 코드를 만드는 사람이 동시에 협상하는 사람이고, 가르치는 사람이고, 부드럽게 권유하는 사람이 되어야 합니다. 쉽지 않습니다. 하지만 동시에, 이 부분이 가장 의미 있게 느껴지는 부분이기도 합니다. 결국 우리가 만드는 건 코드가 아니라 누군가의 하루이기 때문입니다. image ---

마무리: 업무 규칙과 도구

최근에 클린 아키텍처를 다시 공부하면서, 위 두 사례를 새롭게 비추는 통찰 하나를 얻었습니다. 클린 아키텍처는 소프트웨어를 업무 규칙과 세부 사항으로 구분합니다. 업무 규칙은 그 소프트웨어가 왜 존재하는지를 결정하는 핵심이고, 세부 사항은 그것을 어떤 기술과 형태로 구현할지에 대한 결정입니다. 데이터베이스, 프레임워크, UI 라이브러리, 통신 프로토콜 같은 것들은 모두 세부 사항입니다. 클린 아키텍처는 이렇게 말합니다.
세부 사항에 대한 결정은 가능한 한 미뤄야 하고, 언제든 교체할 수 있어야 한다. 소프트웨어는 업무 규칙을 지원하기 위해 존재한다.
이걸 처음 읽었을 때, 어쩐지 플라톤의 이데아론이 떠올랐습니다. 우리가 보는 현실 세계가 순수한 개념의 세계인 이데아의 그림자이듯이, 우리가 작성하는 소프트웨어의 코드와 기술 스택은 결국 그 소프트웨어가 풀고자 하는 진짜 업무 규칙의 투영에 가까워야 한다는 이야기입니다. 중요한 것은 이데아 — 즉 업무 규칙 — 입니다. 그림자가 본체를 흔들어서는 안 되죠. 이 관점에서 두 사례를 다시 보면, 사실 우리는 이미 클린 아키텍처가 말하는 것을 실천하고 있었습니다. 카페 키오스크 앱에서 100% 테스트 커버리지가 보호한 것은 무엇이었을까요? 결국 그건 카페 봉사자가 덜 분주해지고, 사용자가 덜 기다리는 업무 규칙이었습니다. 어떤 프레임워크를 쓰는지, 어떤 라이브러리로 알림을 구현하는지는 세부 사항이고, 그 세부 사항이 바뀌더라도 위 업무 규칙은 동일하게 보호되어야 했습니다. 하드 하네스는 결국 업무 규칙을 보호하기 위한 가드레일이었던 셈입니다. 공시 시험 앱에서 미뤄둔 거창한 기능들은 무엇이었을까요? 온톨로지 기반 AI 답변 엔진, 망각 곡선 알고리즘, 모의고사 분석 — 이 모든 것은 사실 세부 사항이었습니다. 그리고 한 단계 더 들어가 보면, 제가 결국 살린 공부 페이스 추적 기능조차도 본질적으로는 도구입니다. 이 프로젝트의 가장 깊은 곳에 있는 이데아는 더 단순했습니다. 지인이 시험에 합격하도록 돕는 것. 페이스 추적이든, 알림이든, 망각 곡선이든 — 이 모두는 그 본질을 위한 도구일 뿐입니다. 가장 순수한 요구사항에 집중하기 위해, 본질에 가장 가까운 최소 기능만 남기고 나머지는 미룬 것입니다. 그래서 저는 이 두 가지 경험에서 같은 결론에 도달합니다. 무엇을 만들지 결정하는 출발점은, "어떤 기술을 쓸까"가 아니라 "어떤 문제를 풀까"여야 한다. 그리고 그 문제 — 즉 업무 규칙 — 가 분명하게 잡혀 있다면, 우리는 가능한 한 세부 사항 결정을 미루고, 필요한 도구만 도구 상자에서 꺼내 쓸 수 있게 됩니다. 특정 기술을 쓰고 싶은 욕심이 아니라, 문제를 가장 가볍게 푸는 도구를 고르는 자유. AI는 그 도구 상자에서 가장 강력한 도구 중 하나입니다. 하지만 도구는 결국 도구일 뿐이고, 그 도구의 끝에는 늘 풀어야 할 문제 — 그리고 그 문제를 가진 사람 — 이 있어야 합니다. image ---

마치며

회사 안에서만 가능하다고 생각했던 Forward Deploy Engineer라는 역할은, 사실 우리 일상 곳곳에서 가능합니다. 카페에서 분주한 봉사자에게도, 시험을 준비하는 지인에게도, 어쩌면 옆 자리 동료에게도, 우리가 가진 도구와 시선으로 풀 수 있는 작은 문제들이 있습니다. AI 도구들은 이 일을 현실적으로 가능하게 만들어 주었습니다. 하지만 그 가능성을 정말 누군가에게 가닿는 선물로 바꾸는 일은, 여전히 우리의 몫입니다. 문제를 정확히 보는 일, 가장 작게 시작하는 일, 빠르게 보내드리고 다시 듣는 일, 그리고 끊임없이 이게 정말 선물인가를 자신에게 묻는 일. 이 글을 읽으시는 여러분 곁에도, 분명 누군가가 있을 겁니다. 매일 같은 어려움을 반복하는 누군가가요. 어쩌면 다음 선물의 수신자는, 이미 여러분 곁에 앉아 있을지도 모릅니다. Cluade 대전 밋업의 발표 내용을 재구성하였습니다.