교통비 신청은 하는 일 자체는 단순하지만, 은근히 번거롭습니다.

저희 회사에서는 지금까지 Excel로 신청해 왔지만, 신청하는 쪽도 확인하는 쪽도 매번 나름대로 수고가 들었습니다.

특히 관리부에서는 신청이 도착할 때마다 다음과 같은 작업을 수행했습니다.

• 신청 내용 확인
• 출발역과 도착역을 Web 검색
• 신청된 운임이 맞는지 확인
• 문제가 없으면 승인

건별로 보면 대단한 작업은 아닙니다.

다만, 매번 똑같이 검색하고 확인하는 것은 역시 번거롭습니다 (웃음)

교통계 API 이용도 고려해 보았지만, 사내 신청 확인만을 위해 이용료나 러닝 코스트 (Running Cost)를 들이는 것은 맞지 않는다는 생각이 들었습니다.

그래서 이번에는 Dify를 사용하여 AI 리뷰가 포함된 교통비 신청 워크플로우를 작성했습니다.

이번에 작성한 워크플로우에서는 다음과 같은 처리를 수행합니다.

• 신청 내용 입력 체크
• Web 검색을 이용한 운임 확인
• AI에 의한 신청 내용 리뷰
• 관리부로의 승인 요청
• 승인·반려 분기
• Markdown 형식의 신청 기록 생성
• Nextcloud로의 저장
• 메일을 통한 결과 통지

처음에는 좀 더 단순한 플로우를 상정하고 있었지만, 실제로 운용하는 것을 고려하다 보니 최종적으로는 상당히 본격적인 구성이 되었습니다.

직원
↓
교통비 신청
...

이번 설계에서 가장 의식한 것은 AI에게 최종 판단을 맡기지 않는 것입니다.

AI가 수행하는 것은 어디까지나 리뷰입니다.

• 입력 내용에 부자연스러운 점이 없는지
• 신청 경로와 목적에 모순이 없는지
• Web 검색으로 확인된 운임과 신청 금액이 일치하는지
• 관리부가 추가로 확인하면 좋을 점은 없는지

이러한 정보를 정리하여 관리부에 전달합니다.

반면, 다음과 같은 판단은 AI에게 시키지 않았습니다.

• 승인
• 반려
• 지급 금액의 최종 결정

최종 판단은 반드시 사람이 수행합니다.

AI에게 전부 맡기는 것이 아니라, 사람이 판단하기 쉬운 재료를 AI가 모아주는 역할 분담을 했습니다.

교통비 확인이라고 하면 교통계 API를 사용하는 방법이 떠오릅니다.

하지만 이번에는 사내 이용이 전제입니다.

그렇기 때문에,

• API 이용료를 쓰고 싶지 않다
• 전용 API 관리를 늘리고 싶지 않다
• 소규모 이용에는 조금 과하다

라는 이유로 교통계 API는 사용하지 않았습니다.

대신 OpenAI의 Web 검색 기능을 이용하고 있습니다.

AI에게는 검색 결과를 근거로 운임을 확인하게 합니다.

검색할 수 없거나 충분한 근거를 얻을 수 없는 경우에는 '판정 불가'로 처리하여, 추측으로 운임을 결정하지 않도록 하고 있습니다.

AI 리뷰가 끝나면 관리부로 승인 요청이 전송됩니다.

관리부는 신청 내용과 AI 리뷰를 확인하고,

• 승인
• 반려

둘 중 하나를 선택합니다.

AI가 확인 작업을 보조하고, 마지막은 사람이 판단하는 형태입니다.

이러한 구성으로 함으로써, AI를 사용하면서도 업무상의 책임 범위를 모호하게 만들지 않을 수 있었습니다.

관리부에 보내는 메일에는 다음과 같은 정보를 정리해 두었습니다.

• 신청 ID
• 신청자
• 이용일
• 경로
• 신청 금액
• AI 평가
• AI 코멘트
• 승인 화면으로의 링크

메일을 보는 것만으로도 신청 내용과 AI 리뷰의 개요를 파악할 수 있습니다.

세부 내용을 확인하고 싶을 때만 승인 화면을 열면 되기 때문에, 관리부 측의 확인 작업도 상당히 편해졌습니다.

이번 개발은 이른바 **바이브 코딩 (Vibe Coding)**에 가까운 진행 방식이었습니다.

• 어떤 업무를 효율화하고 싶은가
• AI와 사람의 역할을 어떻게 나눌 것인가
• 어디까지 자동화할 것인가
• 실제로 사용해 보니 무엇이 다른가

와 같은 부분을 생각하며 요건이나 수정 내용을 ChatGPT에 전달했습니다.

한편, Dify의 DSL 작성이나 노드 구성, 변수 참조, 분기, Markdown 생성, Nextcloud 저장 등 구현의 대부분은 Codex에 맡기고 있습니다.

저 자신이 Dify상에서 수행한 것은 주로 다음과 같은 작업입니다.

• API 및 인증 정보 설정
• 일부 노드의 재작성
• 화면상의 세밀한 수정
• 테스트 실행
• 동작 확인
• Codex에 대한 수정 지시

Dify는 노코드 (No-code)・로코드 (Low-code) 툴이지만, 복잡한 워크플로우를 화면상에서 처음부터 구축하는 것은 나름대로 힘든 일입니다.

이번에는 요건을 문장으로 정리하여 Codex가 DSL을 작성하게 하고, Dify로 임포트하여 조정하는 방법을 택했습니다.

이러한 진행 방식이라면 Dify에서도 상당히 본격적인 플로우를 바이브 코딩으로 구축할 수 있습니다.

바이브 코딩이라고는 해도, 요청하자마자 한 번에 완성된 것은 아닙니다 (웃음)

특히 고생한 부분은 Dify의 버전과 DSL의 호환성입니다.

처음 생성한 DSL을 임포트(Import)했을 때, 일부 LLM 노드나 Human Input 노드가 정상적으로 열리지 않았습니다.

그래서,

• Dify 상에서 새로운 노드 생성
• 현재 Dify가 출력하는 DSL을 재익스포트 (Re-export)
• 해당 DSL을 기준으로 Codex에 수정을 요청
• 다시 임포트하여 동작 확인

이라는 흐름으로 수정했습니다.

AI에게 구현을 맡기는 경우라도, 실제로 구동하며 문제점을 찾아내고 올바른 정보를 되돌려주는 작업은 필요합니다.

다만, 처음부터 모든 것을 수작업으로 구성하는 것보다는 훨씬 짧은 시간 안에 완성까지 진행할 수 있었습니다.

• Dify 1.14 계열
• OpenAI GPT-5.6
• OpenAI Web 검색
• Code Node
• LLM Node
• Human Input
• 조건 분기
• HTTP Request
• Markdown 생성
• Nextcloud
• SMTP 메일 알림
• Codex

이번에 작성한 것은 교통비 신청이지만, 정말로 만들고 싶었던 것은 AI 리뷰가 포함된 신청 워크플로우의 공통 기반입니다.

이 메커니즘은 교통비 신청 외에도 응용할 수 있습니다.

앞으로는 다음과 같은 신청으로 전개해 나갈 예정입니다.

• 경비 신청
• 정기권 변경 신청
• 비품 구매 신청
• 결재(稟議) 신청

신청 내용에 따라 AI 리뷰의 관점은 달라지겠지만,

입력
↓
룰 체크 (Rule Check)
...

라는 기본 구성은 공통화할 수 있습니다.

우선 교통비 신청부터 실제로 운용하며, 개선해 나가면서 다른 신청으로 넓혀가고자 합니다.

본 툴은 주식회사 LYDIA에서 사내 사무 작업을 효율화하기 위해 개발했습니다.

실제로 운용하며 개선을 계속하고 있기 때문에, 새로운 아이디어나 깨달음이 있다면 다시 기사로 소개하겠습니다.

앞으로도 Embedded × DX × AI를 테마로, 실무에서 얻은 지견과 개발 사례를 발신하겠습니다.