작은 자동화에서 시작된 Lemonbase Finance의 AX 여정

안녕하세요. Lemonbase에서 Finance와 HRM을 담당하고 있는 Jasmine입니다 🙂

Finance 업무는 정말 조심스럽습니다. 회사 매출 금액, 고객사 정보, 임직원 보상 내역처럼 민감하고 정확해야 하는 정보가 많기 때문입니다. AI를 잘 사용하는 건 중요하지만, 막상 업무에 어디에 어떻게 쓸지는 막막했어요. 그래서 이런 생각을 자주 하게 되었죠.

“AI를 활용하면 뭔가 할 수 있을 것 같은데, Finance 업무에서는 어디부터 시작해야 안전할까?”

처음부터 중요한 판단을 AI에게 맡기기보다는, 반복적이고 규칙이 분명한 일부터 안전하게 바꿔보기로 했습니다. 반복되는 업무를 그냥 견디는 대신, 기준을 정리하고, 예외를 확인하고, 도구로 만들어가기 시작한 것이죠. 그 첫 번째 실험이 바로 연봉계약서 PDF 자동 변환이었습니다.

시작은 정말 작은 자동화였습니다 📝

처음부터 웹 앱을 만든 건 아니었습니다. 시작은 훨씬 소소했습니다. 연봉계약서를 사람마다 PDF로 만들어 구글 드라이브에 업로드해야 하는 상황이 있었는데요. 시트 탭이 사람 수만큼 있고, 그걸 하나씩 내려받아 이름을 바꿔 저장해야 했죠. 매번 같은 규칙으로 하는 일이었지만, 수작업이다 보니 누락이나 파일명 오류가 생길 수 있는 업무였습니다. 그래서 이 과정을 Apps Script 수십 줄로 옮겼습니다.

• 시트를 돌면서 PDF를 만들고

• 드라이브 폴더에 자동 저장하고

• 결과를 로그 시트에 남기고

• 마지막으로 해당 크루가 서명할 수 있도록 서명 요청 봇까지 생성했습니다.

*Apps Script(데모)를 활용하여 시트 탭 이름에서 연도와 이름을 뽑아 PDF 파일명을 만듭니다.

*스크립트가 만들어낸 ‘연봉계약서’ (데모) — 사람마다 한 장씩, 파일명이 규칙대로 붙습니다. 예전에는 이걸 손으로 하나씩 내려받아 이름을 바꿔 저장했습니다.

이 작은 자동화는 생각보다 큰 전환점이 됐습니다. 단순히 시간을 줄인 것보다 더 중요했던 건, 민감한 문서를 사람마다 동일한 규칙으로 만들고 안전하게 처리할 수 있게 된 점이었어요. 이런 생각이 들었습니다.

“이런 반복 작업은 충분히 자동화할 수 있겠는데?”

처음부터 거창한 시스템을 만든 건 아니었지만, 이 경험 덕분에 Finance 업무에서도 민감한 판단은 사람이 하되, 반복되는 실행은 도구가 맡는 방식이 가능하다는 확신을 얻었습니다.

AX 해커톤에서 시작된 실험이 사내 Finance 사이트로 확장됐습니다 🧪

다음 계기는 사내 AX 해커톤이었습니다. Finance 업무 중에서도 유독 자주 받는 질문들이 있었어요.

“이번 달에 얼마 들어와요?”, “그 계약은 세금계산서 발행됐나요?”, “입금 예정일 지났는데 확인됐나요?”

질문은 단순해 보이지만 답을 찾는 과정은 단순하지 않았습니다. 계약서는 드라이브에, 세금계산서 발행 요청은 슬랙 스레드에, 입금 확인은 스프레드시트에 흩어져 있었거든요. 계약 담당자는 계약 한 건의 상태를 확인하려면 여러 창을 열어 대조해야 했고, 어떤 정보가 최신인지도 매번 다시 확인해야 했습니다.

해커톤에서는 이 복잡한 문제를 “계약과 입금 흐름을 한곳에서 볼 수 없을까?”라는 질문으로 바꿔봤습니다. 처음에는 로컬에서 돌아가는 작은 실험이었어요. 계약을 등록하고 예상 입금월과 금액을 입력하면, 세금계산서 발행 요청 상태와 실제 입금 여부까지 한 화면에서 확인할 수 있는 형태였습니다.

그렇게 처음 만든 버전은 “이 흐름이 실제 업무에 맞을까?”를 확인하는 프로토타입에 가까웠습니다. 화면을 만들어보고, 실제 계약 관리 흐름에 대입해보고, 놓치는 예외를 다시 정리했어요. 그렇게 하나씩 다듬다 보니 어느새 실제 업무에 쓸 수 있는 도구가 됐고, 결국 사내에서 쓰는 계약 관리 사이트로 정식 배포하게 되었고, 지금의 🍋Lemon-Finance 사이트는 계약 관리와 입금/지출 요청의 메인 도구로 사용되고 있습니다.

*계약 대시보드(데모)

만들다 보니 알게 된 것 😦

‘계약 관리’는 생각보다 훨씬 복잡한 작업이었습니다.

AI를 활용해서 코드를 만드는 것 자체는 생각보다 어렵지 않았습니다. 원하는 화면을 설명하고 기능을 하나씩 붙여볼 수 있었어요. 하지만 실제 업무에 쓰는 사이트는 단순히 동작하는 화면만으로는 부족했습니다. 계약 관리는 생각보다 많은 예외 사항을 가지고 있었기 때문이죠.

• 해외 계약: 국내 계약과 세금 처리 방식이 다른 경우

• 입금 일정 변경: 계약서에 적힌 일정과 실제 입금 일정이 달라진 경우

• 세금계산서 발행 대기: 발행을 요청했지만 아직 완료되지 않은 경우

• 입금 지연: 세금계산서는 발행됐지만 예정일까지 입금되지 않은 경우

이처럼 하나를 바꾸면 다른 화면과 매출 리포트에 줄줄이 영향을 줬습니다. 예를 들어 입금월 하나를 정하는 것도 단순하지 않았어요. 계약서상 지급 예정일을 기준으로 볼지, 세금계산서 발행일을 기준으로 볼지, 실제 입금일을 기준으로 볼지에 따라 월별 매출 계획과 실적이 달라졌습니다. 그래서 먼저 “우리가 이 화면에서 보고 싶은 숫자는 무엇인가”라는 근본적인 질문을 먼저 정리해야 했습니다.

예상 입금월을 어떻게 정의할지, 계획과 실적은 어떤 날짜 기준으로 볼지, 회차 계약의 금액은 어떻게 합산할지 같은 정책도 먼저 정리되어야 했습니다. 이때 “AI가 코드는 도와줄 수 있지만, 업무의 맥락과 정책은 결국 그 일을 가장 잘 아는 사람이 잡아야 한다.”는 것을 느꼈습니다. Finance 업무는 숫자 하나가 여러 화면과 리포트에 연결됩니다. 그래서 담당자가 직접 기획하고 검증했기 때문에 사이트를 실제 업무에 맞게 만들 수 있었고, 데이터의 정확성도 계속 확인할 수 있었습니다.

*계약 상세 화면(데모)

이제는 계약과 입금 흐름을 한곳에서 봅니다 🔎

예전에는 계약 상태, 발행 요청 상태, 입금 여부를 각각 다른 곳에서 확인해야 했습니다. 고객사 담당자가 바뀌거나, 세금계산서 발행 상태가 바뀌어도 이력을 한눈에 보기 어려웠어요. 지금은 계약 상세 화면에서 발행 요청을 진행하면 이미 등록된 업체명, 사업자번호, 금액, 수신 이메일 등이 자동으로 채워집니다. 담당자는 필요한 값을 확인하고 요청하면 됩니다.

입금 관리도 같은 흐름 안에 들어왔습니다. 입금 예정일이 지났는데 아직 들어오지 않은 건은 지연으로 표시되고, 미수금 합계도 함께 확인할 수 있어요.

*관리자 입금 관리 화면(데모)

결과적으로 Lemon-Finance는 단순한 계약 목록이 아니라, 🔑 계약이 매출과 현금 흐름으로 이어지는 과정을 관리하는 도구가 되었습니다. 흩어져 있던 스프레드시트와 슬랙 메시지를 하나의 사이트로 모으니, 업무를 확인하는 방식도 달라졌어요. 누군가에게 물어보고 답을 기다리는 대신, 먼저 화면에서 확인하고 필요한 액션을 이어갈 수 있게 된 것이죠.

계획이 있어야 실적을 볼 수 있습니다 📊

*현금 매출 계획 대비 실적(데모)

Finance 업무에서 자금 계획은 매우 중요합니다. 계약 등록 단계에서 예상 입금월과 예상 금액을 미리 입력해두면, 이후 실제 입금 내역과 비교할 기준이 생깁니다. 단순히 “얼마가 들어왔는지”를 확인하는 데서 그치지 않고, 우리가 예상한 흐름과 실제 현금 흐름이 어떻게 달라졌는지 볼 수 있게 된 것이죠.

이 기준이 생기면서 Finance 업무에서 나누는 대화도 달라졌습니다. 숫자를 다시 확인하는 시간은 줄고, 차이가 발생한 이유를 살펴보고 다음 액션을 정하는 데 더 집중할 수 있게 됐습니다.

Finance 관련 업무도 같은 자리로 모았습니다 🧾

계약과 입금 관리에서 얻은 자신감은 다른 Finance 업무에도 이어졌습니다. 반복되지는 않지만, 한 번 할 때마다 정확성과 이력 관리가 중요한 업무도 같은 방식으로 바라보게 됐어요. 보증보험 발행 요청과 자금 지출 요청도 원래는 슬랙으로 오가던 일이었습니다. 지금은 Lemon-Finance에 요청을 등록하면 상태가 남고, 처리한 사람과 시점이 기록됩니다.

*보증보험 발행 리스트(데모)

*자금 지출 요청 리스트(데모)

찾아가지 않아도, 먼저 알려줍니다 🔔

아무리 서비스를 잘 만들어도 사람이 매일 들어와 확인하지 않으면 놓치는 일이 생길 수 있습니다. 그래서 매일 아침 슬랙으로 그날 확인해야 할 일이 먼저 가도록 만들었어요. 오늘 발행해야 할 세금계산서 목록, 오늘 지출 요청일이 돌아온 건, 입금 예정일이 지났는데 아직 들어오지 않은 건을 알려줍니다.

입금 지연 알림에는 담당자를 멘션합니다. 담당자를 멘션하는 이유는 책임을 묻기 위해서라기보다, 각자가 확인해야 할 일을 놓치지 않도록 맥락과 액션을 함께 전달하기 위해서예요. 채널에 숫자만 남기면 “누가 봐야 하는 일인지”가 흐려질 수 있기 때문입니다.

*입금 지연 알림 (데모)

AI가 모든 것을 해주는 건 아니었습니다

이번 과정을 겪으면서 가장 많이 느낀 건 이것입니다.

"AI는 만드는 속도를 빠르게 해주지만, 무엇을 어떻게 만들어야 하는지는 사람이 정해야 한다."

특히 Finance 업무는 1원이라도 오류가 나면 안 되기 때문에 숫자의 정확성이 중요합니다. 계약 하나의 상태, 입금 예상액, 예상 입금 월 등 모두 여러 화면과 리포트에 연결되기 때문입니다. 그래서 기능을 만들 때마다 이런 질문을 계속 해야 했습니다.

• 이 숫자는 어떤 기준일로 계산해야 하지?

• 이 상태가 바뀌면 어떤 화면에 영향을 주지?

• 예외 케이스는 어디까지 허용해야 하지?

• 사용자가 헷갈리지 않으려면 화면을 어떻게 보여줘야 하지?

• 권한과 보안은 어디에서 막아야 하지?

단순히 코드를 만드는 것보다, 정책을 정하고, 예외를 정리하고, 화면 흐름을 설계하고, 데이터를 검증하는 시간이 더 중요했습니다. 그래서 저는 오히려 이런 생각을 하게 됐어요.

"AI를 잘 쓰려면, 내 업무를 더 잘 알아야 한다."

업무를 가장 잘 아는 사람이 직접 만들고 검증할 수 있다는 점이 Finance AX에서 가장 큰 장점이었습니다.

그래도 확실히 업무는 가벼워졌습니다 🤗

물론 쉽지만은 않았습니다. 하나를 바꾸면 다른 곳에 영향이 가고, 생각보다 많은 예외 케이스를 마주해야 했습니다. 그럼에도 이 시도를 계속하게 된 이유는 명확합니다. 반복 업무가 실제로 줄었기 때문입니다.

연봉계약서를 하나씩 PDF로 저장하던 일, 계약 상태를 확인하기 위해 여러 문서를 열어보던 일, 입금 지연 건을 따로 세던 일이 많이 줄었습니다. 앞으로 레몬베이스 크루들은 Lemon-Finance 사이트에서 계약 관리와 입금 관리 정보를 확인할 수 있게 되었어요. 그리고 생각보다 좋았던 건, 흩어져 있던 스프레드시트를 하나의 사이트로 모으는 과정 자체였습니다. 개인 파일과 기억에 흩어져 있던 업무 규칙이 화면과 데이터로 남기 시작했습니다.

AX는 사람을 대체하는 거창한 변화라기보다, 실무자가 자신의 업무를 더 잘 이해하고, 더 안전하게 반복할 수 있도록 도구화하는 과정에 가까웠습니다. Finance 업무처럼 조심스럽고 민감한 영역에서도 시작은 작게 할 수 있습니다. 반복적이고 규칙이 분명한 일 하나를 골라 자동화해보고, 그 경험을 바탕으로 다음 업무를 조금씩 옮겨보는 것. Lemonbase의 Finance AX 여정도 그렇게 시작됐습니다.

연봉계약서 PDF 자동 변환이라는 작은 자동화에서 시작해, 지금은 계약 관리 사이트 배포까지 사내 도구 개발로 AI를 활용하고 있습니다. 앞으로도 반복되는 확인과 수작업은 시스템이 맡고, 사람은 판단과 검증에 더 집중할 수 있도록 계속 바꿔가려 합니다. 읽어주셔서 감사합니다!