안녕하세요. TOKIUM 디지털라이즈 팀의 kztm입니다. 저희는 오퍼레이션 부서(영수증 등의 서류 데이터화를 담당하는 부서)의 현장을 지원하는 시스템 개발을 담당하고 있으며, 저는 그중에서 데이터화를 보조하는 AI 기능의 개발 및 개선을 담당하고 있습니다.

이번에 이야기하고 싶은 것은, 이 AI 기능의 개선 작업을 과감하게 시스템의 사용자인 오퍼레이션 부서 멤버들에게 맡겨 보았다는 것입니다. 최근 비즈니스 멤버들도 Claude Code를 사용하여 업무를 수행하는 트렌드가 오고 있는 가운데, 이러한 시도가 어떤 느낌일지 궁금해하시는 분들에게 힌트가 된다면 좋겠습니다.

본 기사에서 공유할 내용

• 시스템 사용자에게 AI 기능 개발을 맡기기 위해 했던 일 (선긋기와 발판 마련)
• 1사이클을 돌려본 결과 얻은 것 (시스템 사용자의 자율 주행과, 도출된 기반 개선 제안)
• 맡겨보고 나서 보인 과제 (자동화의 정도, 엔지니어 측에서 흡수해야 할 구조적인 부분)

모티베이션

오퍼레이션 부서 멤버들에게 맡겨본 동기는, AI 모델의 정밀도 향상에는 도메인 전문가(Domain Expert)가 직접 피드백을 주는 루프가, 엔지니어가 사이에 서서 추측으로 데이터를 만지는 것보다 더 빠르고 본질적일 것이다라는 가설입니다. 매일 데이터에 접하고 있는 현장 인력이 직접 모델을 교육하는 것이 더 타당할 것이라고 생각했습니다.

사내에는 적임자가 있었습니다. 오퍼레이션 부서 데이터과 멤버로, 데이터 입력 작업자의 관리와 입력 품질 개선 등을 담당하고 있는 분입니다. 평소 업무는 Google Apps Script (GAS)와 스프레드시트로 진행하고 있으며, 최근에는 Claude Code로 업무를 진행하는 일도 늘어나고 있었습니다.

실제로 맡겨본 후, 본인으로부터 다음과 같은 소감을 들었습니다.

지금까지는 개선안을 내어 엔지니어에게 의뢰할 뿐이라, 구현 난이도를 완전히 파악하지 못하는 부분이 있었습니다. 이번에 직접 엔지니어의 영역에 발을 들여 튜닝을 체험한 것은 매우 큰 경험입니다.

실제 실수의 내용을 제 눈으로 확인하고 직접 AI를 교육함으로써, 현장 주도로 더욱 스피디하게 정밀도를 높여갈 수 있는 가능성을 느끼고 있습니다.

무엇을 맡기고, 무엇을 맡기지 않을 것인가

AI 모델의 학습 사이클은 대략 다음과 같은 흐름으로 돌아갑니다.

이 사이클의 어느 부분을 맡기고, 어느 부분을 엔지니어가 담당할 것인가. 처음에 결정한 것은 전문성의 경계선을 어디에 그을 것인가였습니다. 위의 그림에서 나타낸 사이클 전체를 시스템 사용자에게 맡기고, 그것을 뒷받침하는 발판(검증 환경의 인프라·매뉴얼·툴)을 엔지니어가 담당하는 구성으로 했습니다. 특히 출력 분석에 대해서는 오퍼레이션 부서가 매일 분석을 수행하고 있기 때문에 경험을 풀 활용할 수 있다고 생각합니다.

또한, 검증까지의 작업을 모두 자동화하여 블랙박스로 만들어 버리면 향후 개발 업무의 확장에 영향을 줄 것이라 생각하여, 수작업을 섞기도 하고 있습니다 (이 부분에 대해서는 후술하겠습니다만, 무엇을 자동화할 것인지는 앞으로 결정해 나가고자 합니다).

다음 그림과 같이 선긋기를 정리했습니다. 양자를 잇는 발판(엔지니어가 준비하는 매뉴얼·인프라 환경·툴 세트)에 대해서는 다음 섹션에서 구체적으로 설명하겠습니다.

준비한 3가지 발판

시스템 사용자에게 작업을 맡기기 위해, 엔지니어 측에서 다음과 같은 3가지 발판을 준비했습니다.

3번째 Skill에는, 예를 들어 다음과 같이 Claude Code에 의뢰하면 적절한 스크립트를 선택하여 실행해 줍니다.

이 검증 결과의 json 파일로 AI 출력의 정밀도나 틀린 데이터를 시각화해줘

1사이클을 돌려보고 알게 된 것

실제로 맡겨보니 몇 가지 깨달은 점이 있었습니다.

개발 용어의 벽이 남는다

우선, 당연한 이야기라면 당연한 것이지만, 개발 작업은 엔지니어만이 평소에 사용하는 용어들로 가득 차 있다는 점입니다. Claude Code로 작업한다고 해도 이 '터미널 (Terminal)'이 무엇을 의미하는지의 문제도 있고, 파일을 찾을 수 없다는 커맨드 에러(Command Error)가 발생해도 패스(Path)가 설정되어 있는지에 대한 관점이 없는 경우도 있습니다. 이러한 본질적이지 않아 보이는 정보들은 가급적 의식시키고 싶지 않으면서도, 어느 정도는 누락될 수밖에 없을지도 모릅니다.

예상 밖: 시스템 사용자로부터 기반 시스템에 대한 제안이 나옴

가장 흥미로웠던 점은 그 이후에 나온 제안의 방향성입니다. 저는 프롬프트 (Prompt) 미세 조정이나 데이터 증강 방법과 같은 지엽적인 개선 제안을 예상하고 있었습니다. 이 필드는 이렇게 고쳐 쓰자, 이 부분의 학습 데이터를 늘리자 하는 정도의 입도(Granularity)를 가진 이야기 말입니다.

실제로 나온 것은, 학습 사이클 (Learning Cycle) 자체를 되돌림 없이 돌리기 위한 기반 시스템 (Infrastructure System)에 대한 제안이었습니다. 분석 과정 등에서 수정된 데이터는 시스템적으로 일원화되는 것이 좋겠다 등, 사이클 전체를 한 번 통과하며 구조적인 측면에서 과제를 느끼는 방향으로 사고가 움직인 듯합니다.

데이터 입력 워커 (Worker) 관리를 본업으로 하는 사람만이 가질 수 있는 시선으로, 이를 엔지니어 측의 태스크로 수용하여 다음 사이클까지 정비하는 방향으로 진행하고 있습니다.

전부 자동화하지 않는다는 선택

처음부터 특정 태스크를 전부 자동화한 시스템을 넘겨주는 선택지도 있었습니다. 에러가 나지 않고, 망설임이 없으며, 누르면 결과가 나오는 시스템입니다.

이것을 선택하지 않은 이유는, 수작업을 전부 자동화하여 현장을 단순한 오퍼레이터 (Operator)로 만드는 것이 아니라, 일부러 손맛을 남겨두어 엔지니어와 같은 관점에서 시스템의 구조를 생각하게 하기 위해서입니다. 이번에 시스템 사용자 측으로부터 기반 시스템에 대한 제안이 돌아온 것을 고려하면, 이 설계 판단이 효과가 있었다고 느끼고 있습니다.

그렇다고는 해도, 본질에서 벗어나는 부분(인프라 정비나 시스템 개수 등)은 지원 측에서 흡수해야 할 영역입니다. 작업 효율과 이해도의 균형은 정기적으로 대화하며 조금씩 맞춰 나갈 것입니다.

다음에 할 일

이제 막 1 사이클을 돌린 참이라 보이는 것은 한정적입니다. 다음 사이클에서는 현장에서 나온 요구사항을 바탕으로, 엔지니어는 더욱 고도화된 MLOps 기반 구축(자동화 및 데이터 파이프라인 (Data Pipeline) 정비)에 집중합니다. 본인의 작업 효율과 이해도는 정기적인 대화를 통해 확인하며, 지원과 도전의 균형을 조정해 나갈 것입니다.

학습 사이클을 넘겨주었다기보다, 현장의 전문가와 엔지니어의 전문성 경계를 조금씩 움직이는 시도가 되고 있다는 것이 1 사이클을 마친 소감입니다. 이번에는 현장의 전문가 측이 사이클 운용에 발을 들여놓으며 구조적인 측면의 깨달음을 돌려주었습니다. 다음은 제 측에서 그 깨달음을 기반 시스템에 반영할 차례이며, 또다시 새로운 경계선이 그어질 것이라고 생각합니다.