neozest : neo+zest

사내 프로세스 혁신 도구로서의 가능성을 점검해 보다.

1/ 꽤 오래전(이래봤자 올해 초였을 것 같은데) 지인들 모임에서 Dify.AI 에 대한 이야기를 나눴다. 당시만 해도 '디파이'라고 하면 탈중앙화 금융을 일컫는 DeFi가 먼저 떠오르던 시절이다. 지금도 크게 다르지 않다. 이런 현실 속에서도 LLM이 현업 프로세스 혁신의 영역으로 점점 가까이 다가오면서 드디어 우리나라에서도 Dify를 다루는 책이 나왔다. 나 역시 슬쩍슬쩍 곁눈질하던 터라, 이번 기회에 책을 읽으면서 Dify의 지향점과 현재 상태를 점검해 보고 싶었다.

2/ <Dify AI, 코드 없는 미래>는 번역서가 아니라 국내 엔지니어가 집필한 책이다. 국내에서 Dify에 관한 책을 누가 적을 수 있을까 했는데, 김정욱 저자님은 태디노트님과 함께 국내 AI 도입의 최전선에서 활동하시는 분이었다. 일단 브레인크루 멤버라는데서 +1.

3/ Dify는 대화형 AI 애플리케이션과 AI Agent를 손쉽게 만들 수 있도록 설계된 노코드 플랫폼이다. 정의야 어떻게 되었든 나의 관심사는 명확하다. AI를 이용하여 사내 프로세스를 개선하는, 이른바 PI(Process Innovation)활동에 이 도구를 적용할 수 있는가 하는 점이다. 

이 책은 다음과 같이 구성되어 있다.

1장: LLM/AI에 대한 일반적인  이해

2장: LLM에서 원하는 결과를 도출하기 위한 프롬프트 작성법

3장: 정보의 정확성을 올리기 위한 RAG 시스템

4장: 궁극적으로 우리가 원하는 에이전트의 가능성 옅보기

5장: 실제 워크플로 개선에 사용할 수 있는지 여부 살펴보기

6장:  이전 내용을 종합한 실습 프로젝트를

Dify가 뭔지, 어떤 작업을 수행할 수 있는지 이해도를 높이기에 충분한 구성이다.

4/ 기술 격동의 시절이다. 어떤 도구를 선택하는지가 이른바 엔지니어의 몸값에도 영향을 준다. Dify... 이 책을 읽으면서 다뤄본 Dify는 아직은 아쉬움이 많이 남는 플랫폼이다. 코드를 작성할 수 있는 개발자라면 n8n이 더 유용하고, 코드와 거리가 먼 사용자라면 사용자라면 구글의 Opal 서비스나 Agentspace같은 서비스가 더 와닿지 않을까 싶다. 결국 Dify가 강점을 가질 수 있는 부분은 구매냐 구축이냐(Buy vs Build)의 고민에서 구축을 선택했을 때 제시할 수 있는 대안이라는 점이다.

5/ 사내에서 이미 n8n을 활용하고 있는데, Dify도 사용할 수 있게 호스팅해달라고 요청했다. 클라우드 서비스에 가입해서 잠깐 사용해 보긴 했지만,  사내에 직접 구축해서 충분히 사용해 봐야 정확한 판단을 내릴 수 있을 것 같다. Opal의 최대 단점은 기업 환경에서 사내 시스템과의 연동이 힘들다는 것인데, Dify는 Opal과 같은 시스템을 사내에 구축하고, 이를 MCP를 통해 다른 사내 시스템과 연동할 수 있겠다는 가능성이 보인다. 다만 관건은 얼마나 사용자들이 부담스럽지 않게 접근할 것인가인데, 결국 이 작업을 LLM의 도움을 받아 코드를 작성하지 않고도 수행할 수 있느냐가 핵심이 될 것이다.

6/ Dify. 비전은 훌륭하고 빠른 속도로 진화하고 있지만, 갈 길이 멀어 보인다. 하지만 어떠하랴. 오픈소스의 비전이라는게 원래부터 그런것 아니었나. AI 서비스, 특히 사내 서비스 도입/구축을 고민하시는 분들이 읽으면 도움이 되는 내용이 많다.

식상한 말이라 느껴지지만, "현장에 답이 있다"라는 말을 업계 선배들에게 자주 듣는다. 현장.. IT/소프트웨어 개발에서 현장이란 어떤 의미일까? 나는 실제로 사용자를 만나게 되는 그 지점을 말하는 것이라 생각한다. 개발 단계에서는 나와 소프트웨어만 존재했지만, 현장이라는 지점에 도달하면 내가 만든 소프트웨어를 사용하는 사람과 만나게 된다. 그 사람이 내가 만든 소프트웨어를 사용하는 모습을 보면서 내가 생각했던 사용시나리오가 실제 사용자와 이야기를 나누기 시작한다. 그 지점이 현장이다.

이 책은 오라클 컨설턴트로 오래 활동한 저자의 경험(에피소드)를 통해 원래 의도대로 동작하지 않아 발생한 문제를 어떻게 해결하는지, 그 과정에서 어떤 통찰을 얻었는지 담담하게 이야기한다. 마치 IT 현장에서 벌어지는 이야기 같아서 소설처럼 편안하게 읽을 수 있다. 편안하지만 읽다보면 머리를 띵 하고 치는 그런 편안함이랄까. 그 편안함 속에서 우리가 현장의 문제를 제대로 해결하려면 어떤 태도를 가지고 어떻게 접근해야 하는지에 대해 생각해 보는 시간을 가질 수 있었다.

이 책의 역자분이 남긴 '옮긴이의 글'에서 가슴에 와닿는 문장이 있었는데 '문제를 올바르게 해결한다는 것은 결국 어디를 관찰할 것인지, 어떤 것을 무시할 것인지를 결정하는 과정'이다. 기본이지만, 늘 기본 지키기가 쉽지만은 않다.

책을 읽으면서 일머리, 특히 소프트웨어 개발과정에서의 일머리를 생각했다. 어떻게 보면 원서의 제목 <How to make things faster>보다 과한 느낌도 들지만, 한편으로는 이 책에서 저자가 말하고 싶었던 것이 일을 잘하기 위해 엔지니어는 어떻게 생각하는가를 고민한 내용이 잘 전달되는 것 같다.

책을 읽으면서 책 내용에 대해 내 생각을 메모로 남겼는데, 그걸 정리하면 다음과 같다. 

관찰이란 고객의 입장(관점)에서 서술되는 증상의 본질을 이해하는 것이다. 현장의 타격감(효용감, 효력감)을 고려하여 우선순위를 분석하고 문제를 해결하는 노력이 필요하다. 단순 지표가 아닌 실제 증상을, 실제 벌어지는 상황을 관찰하라는 저자의 말에 관찰가능성(observability)의 의미도 다시 생각해 보아야 겠다고 생각했다. 단순히 지표만 수집하는 것이 관찰가능성의 가치가 아니다.

항상 목적을 염두에 두고 증세를 분석하여 해결하는 노력은 어쩌면 개발자보다는 PO/PM에게 더 필요한 덕목일지 모르겠다. 우선순위 결정이 늦어질 수록 증상을 해결하는 시점 또한 늦어진다. 결국 빠른 의사결정이 빠른 해결로 이어진다.

102쪽에 소개된 이슈 보고의 정석도 좋았다. 1.재현 과정, 2. 기대동작 3.실제 동작. 이 세가지만 명확해 져도 문제 해결의 절반은 끝난 셈이다.

추적(trace)에 대해 저자가 제시한 원칙도 명쾌하다. "추적은 필요한 만큼 하되, 최대한 적게 해야 한다. 오동작하는 특정 기능만 추적할 수 없다면 그리 하라. 만일 그럴 수 없다면 하나의 프로그램 또는 하나의 애플리케이션, 또는 한명의 사용자만 추적하면 된다." 문제가 있을 때 특정 사용자에 관한 특정 시간내의 로그를 볼 수 있다는 넷플릭스의 원격 디버깅 기능이 생각났다. (관련 글을 본 적이 있는데, 찾을 수가 없다.)

33번 에피소드 "시퀀스 다이어그램의 왼쪽을 바라보자"는  김형국 대표님의 기획 강의 내용을 떠올리게 했다. 기획의 개입 시점이 앞으로 갈수록 그 기획의 임팩트는 커진다는 것인데, 시퀀스 다이어그램의 왼쪽은 더 이른 시점을 의미하고, 빠른 개입은 전체 흐름에도 큰 영향을 미친다. 기획이나 개발 모두에 적용된다는 생각이 들었다.

효율에 대해서도 생각해 볼 수 있는 구절이 많았다. 빠른 것이 마냥 효율이 좋은 것은 아니라는 말에서 평상시 놓치고 있었던 '낭비'에 대해 생각해 볼 수 있었다. 진정한 효율은 단순히 속도를 빠르게 하는 것이 아니라 전체 사이클에서 낭비를 줄이는 것이라는 생각도 들었다.

책에서 인상적인 구절이 있다. "자신이 답할 수 없는 질문을 맞닥뜨릴 경우 대부분의 사람들은 자신이 답할 수 있는 또다른 대체 질문으로 만족하는 경향을 보인다.... 보통 그렇게 대안으로 마련된 대체 질문들은 원래 질문보다 약화된 버전일 경우가 많다."는 구절. 저자는 결국 plain & straight question, 즉 직접적이고 명확한 질문을 해야한다고 강조했다. 불편하더라도 핵심을 찌르는 질문이 문제해결의 시작이라는 뜻으로 읽혔다.

멀티 태스킹, 즉 한번에 여러 업무를 수행하는데 대해서도 저자의 지적이 있었다. "컴퓨터는 겨우 몇 마이크로초 만에 컨텍스트를 전환할 수 있지만, 사람은 컨텍스트 전환에 약 25분이나 필요하다. 단순히 시간 낭비 이상의 고비용이 든다"는 주장인데, AI 도구가 많이 도입되면서 여러가지 업무를 전환하는 경우가 생기는데, 다시한번 곱씹어 봐야할 지적으로 느껴졌다.

예측하기 파트에서는 TDD가 떠올랐는데, TDD는 단순히 함수 개발에 국한되는 개념이어서는 안되고 미리 결과를 예측하고 개발 할 수 있는 마중물이어야 한다는 이야기로 들렸다. 최적화에는 두가지 스킬이 필요하다고 저자는 이야기한다. 첫번째는 올바른 질문을 하는 것. 두번째는 그 질문의 답을 구하는 것. 그만큼 올바른 질문을 하는 것이 중요하다.

현장에서 수많은 문제를 마주하며 경험을 쌓아온 저자의 생각이 녹아있는 책이다. 주니어보다는 약간의 경험이 있는 분들에게 더 재미있게 다가가는 책일 듯 하다. 이 이야기는 그때 나의 그 이야기와 비슷하네 하는 생각에 이 바닥은 동서고금을 막론하고 비슷하구나 하는 생각도 들었다.