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 서비스, 특히 사내 서비스 도입/구축을 고민하시는 분들이 읽으면 도움이 되는 내용이 많다.

"한빛미디어 서평단 <나는리뷰어다> 활동을 위해서 책을 협찬 받아 작성된 서평입니다."

대 AI 시대, AI가 소프트웨어 개발 현장에 본격적으로 도입되면서 단순한 도구의 변화의 범위를 뛰어넘는, 새로운 개발 패러다임이 등장하는 느낌을 받고 있습니다. 이번에 읽은 책은 구글 크롬팀의 애디 오스마니의 저작  '바이브 코딩 너무 개발자 생존법'("Beyond Vibe Coding: From Coder to AI-Era Developer")입니다. 이 책은 최근 개발자들이 겪고 있는 변화의 본질을 이야기하며, 프로덕션 레벨의 AI 보조 개발 프로세스에 대한 현실적인 가이드를 제시하고 있습니다.

바이브 코딩으로 대변되는 AI 개발 방법론들은 프로토타이핑 단계의 혁신을 가속화하고 있지만, 프로덕션 수준의 소프트웨어를 개발하려면  더 구조화된 접근 방식이 필요하다고 생각합니다. 저자 역시 'AI 보조 엔지니어링'을 통해 바이브 코딩의 창의성과 전통적인 엔지니어링의 체계성을 결합한 구조적 접근방식을 통해, 단순 동작하는 코드를 넘어 유지보수가 가능한 안전한 코드를 작성하는 프로세스를 고민하고 있습니다.

애디 오스마니는 70% 문제라고 표현하는데, AI도구를 통한 개발은 70%까지는 빠르게 진행시키지만, 나머지 30%의 완성은 엔지니어가 문제와 시스템을 해결해야 쉽게 완성할 수 있다고 이야기합니다.  저도 처음 AI가 나왔을 때 대졸 신입 사원으로 인식했다가 지금은 대학원 나온 차장급 인재로 이야기를 많이 합니다. 소프트웨어 개발에서 AI에게는 양(많은 코드, 기본 구조를 갖추기 위한 골격 코드)를 맡기고, 인간은 질(복잡한 로직과 아키텍처)를 맡음으로써 서로 윈윈하는 모델을 만들 수 있다는 주장에 공감합니다. AI 기술의 발전은 놀라운 수준임이 분명하지만, 우리가 소프트웨어를 통해 해결하고자 하는 문제의 본질적 복잡성을 생각한다면 애디의 주장이 맞지 않을까요? 결국 이 시대의 변화속에서 개발자에게 요구되는 것은 복잡성을 풀어내는 능력이라고 생각되었습니다.

 책은 시대의 변화를 이야기하는데, 정작 엔지니어에게 필요한 것은 그동안 인류가 쌓아온 소프트웨어 공학의 철학과 절차, 원칙이 아닌가 하는 조금은 역설적인 생각이 이 책을 읽다가 들었습니다. 결국 살아남는(?) 강한 개발자가 되려면 기본기를 탄탄히 알아야 하고, 문제의 복잡성을 파악하고 관리하면서, 무엇을 어떻게 왜 만들지 결정하는 창의적이고 분석적인 사고를 할 수 있는 주체가 되어야 한다는 점... 앞으로의 커리어를 이어나가는데 여러 생각의 꼭지를 제공해 줍니다.

요즘 지인들을 만나면 AI는 경험을 증폭시켜주는 도구라는 이야기를 많이 나눴는데, 이 책은 주니어와 시니어들이 AI라는 새로운 도구를 어떻게 받아들여야 할지, 팀 업무 속에서 어떻게 융합시킬지 고민하는 분들에게 도움이 될 것 같습니다. 읽는데 부담이 가거나 하는 수준의 번역은 아니었는데, 아쉬운 부분은 있습니다.

이 책 읽으신 분들은 저자의 유튜브 동영상도 함께 보시면 좋겠네요.