데이터 엔지니어링이 8할, AI에 사정하는 프롬프트 2할
올해 AI의 큰 파도에 휩쓸려(?), 8월 부로 AX TF의 리드를 맡게 되었다. 그 스토리도 언젠가 써야겠지만 우선 매주의 인사이트를 전달드립니다.
'AX'라는 유령이 조직을 배회하고 있다. 그러나 AX는 태생적으로 역설적이다. 대부분의 조직이 사전 과정인 DT, DX를 건너뛰고 AX를 도입하고 일부 과정에 적용하기 때문이다. 이 부분 역시 책 한 권이 나올 정도이지만 오늘은 우선 AX 작업과 조직의 효용을 시그모이드 함수를 통해 설명드려보겠습니다.
AI를 공부하고 활용하다 보면 딥러닝 활성화 함수 중 시그모이드(Sigmoid) 함수를 배우게 됩니다. x축 기준 -2 정도까지는 거의 변화가 없다가 특정 지점을 통과하는 순간 출력이 급격하게 증가합니다.
AX(AI Transformation)를 통한 효율화 역시 그러합니다. 회사의 경비 정산 프로그램을 예로 들어볼까요? 먼저 적용 기술에 대해서 리서치를 진행하고 연구해봐야 합니다. OCR이라면 Deepseek OCR부터 pytorch 기반의 EASYOCR까지, RAG 관련 논문이라면 BGE-M3, BM-25 같은 기술들을 검토하게 됩니다.
이 과정에서 단순 기술 뿐만 아니라 여러 환경에서 조직에 반영할 수 있을지 파악해야 합니다. 현업 환경에서 보안상 문제가 없는지, GPU 사양에서는 맞는지, 로컬에서 구동 가능한지. (여기서 대부분은 폐기되거나 경량 모델이 나올 때까지 기다려야 하게 되는데...)
더불어 그보다 중요한 것이 있습니다. 우리가 풀어야 할 문제의 크기와 솔루션의 크기를 대조해보는 일입니다. 대부분의 조직에서 처리할 데이터는 연구를 위한 것이 아니라 실무에 가깝죠. 테라바이트(TB) 단위가 아니며 자율 주행처럼 모호하고 비정형성이 높은 데이터도 아니다. 오히려 영수증, 이체증 등 정형화된 서류에 가깝습니다. 그렇다면, 저도 종종하는 말이지만 우리는 AGI는 물론 GPT-4까지도 필요가 없는 경우가 많습니다.
특히, 제가 비전공자이며 논문도 아직 어려워하기에 구현해나가면서 실수와 우연으로 인해서 실제로 배우는 것이 더 많습니다. 실제로 Deepseek OCR 뒤에 RAG와 LLM을 연동하면서 이번 주에 구현해보려 했습니다. 하지만 해외 구현 사례를 레퍼로 넣어주다보니 보면 정규표현식(RegEx)만으로도 OCR 과정에서 원하는 기능이 동시에 가능할 수 있다는 것을 알게 되었죠. 실제로 그 부분을 해결하니 LLM 호출 없이도 규칙 기반으로 대부분의 문서 텍스트 추출과 유형화가 가능했기에 처리 시간은 절반 이하로 줄일 수 있었습니다. 그러나 동시에 이 과정은 첫 한 번 돌리는 데까지만 4~5시간이 훌쩍 지나기도 합니다.
이 과정까지가 시그모이드 함수에서 투입 대비 효용이 나오지 않는 구간입니다.
이후부터는 코드와 업무 효율이 동시에 급증합니다. OCR 사례로 돌아가면 인간이 하나하나 열어봐야 했던 문서 추출이 10초 내외로 텍스트 데이터화된다. '그거 구현하는 시간이면 이미 다 봤겠다.' 일견 타당합니다. 그러나 며칠 동안 영수증과 증빙 서류, 사업비 가이드만 검토하다 퇴근했던 경험을 떠올려보면 사람은 일 자체에 대해 느끼는 효용감이 시그모이드 함수의 역함수처럼 감소합니다. AX를 하면서 이 부분을 많이 간과합니다. 그냥 GPU, API 비용 외에 직원들의 EX도 고려를 해야 합니다. 이것이 AX를 도입할 때 비용/시간 외에 반드시 함께 봐야 하는 '효용감의 축'이죠.
AX 초기이고 작은 조직을수록 해결한 과제가 '데이터를 활용 가능한 형태로 바꾸는 일'일 것입니다. 그렇기 때문에 다른 업무에도 쉽게 적용이 가능합니다. 가장 복잡한 이미지 데이터가 텍스트화되었다면 해결할 수 있는 지점이 많아집니다.
1차원적인 문제는 대부분 용이하게 해결되며 확장성이 극대화되는 구간이죠. 예를 들어 보고서 작성에도 적용이 가능합니다. (대부분 보고서 성능 저하의 원인은 추출과 청킹 문제 8할, 프롬프트 2할이라고 생가합니다.) 나아가 학습시키지 못했던 데이터도 학습데이터화 할 수 있게 됩니다.
이런 학습 과정에서 조직과 AX 담당자는 적용 가능성과 ROI에 대해 일종의 강화학습을 하게 됩니다. '생각보다 이런 기능은 필요 없네', '어차피 뒤에 GPT-4o급 추론 모델을 쓸 거면 OCR 정확도가 이 정도로 높을 필요는 없고 추론이 보정해주네.' 조직과 담당자가 스스로 체감하며 학습이 극대화되는 구간입니다.
2에서 8의 구간
그러나 다시 지난한 상황에 빠집니다. 이 과정은 대부분 추론과 상상, 1차원적인 접목이기 때문이다. (아직 유저 피드백은 받기 전이다.) 확장성을 높이려 다른 데이터를 보면 표준화가 되어 있지 않은 경우가 많습니다.
그래서 그 데이터를 표준화하기 위해 수십 번 데이터 추출 방법을 고민한다. 어떤 가이드는 'ㅇ조 ㅇ항'과 '*'를 기준으로 데이터를 청킹(자르기)할 수 있다. 하지만 다른 규정집이나 가이드는 그런 정규화가 전혀 없을 수도 있습니다. 그럼 어떻게 자르죠?
AX가 바이브 코딩으로 다 된다고 생각하시면 오산입니다. AX의 8할은 데이터 엔지니어링이고 이는 고독하고 외로운 길입니다. (특히나 QA팀이 별도로 없다면 더욱...) 저 역시 왜 데이터 시각화(pyplot)가 필요한지 몰랐다가 최근 강화학습을 하며 절감하게 됩니다.
우리가 처리해야 할 파일명은 다음 예시처럼 다양합니다. reg화 되지 않는..
썼던_구체적인_상황.png
비목_세목_금액.png
kakaotalk_그냥캡처했어요.png
데이터를 자르고 출력하고 오류를 계에에에속 수정합니다. '이건 특이한 영수증인데 부가세가 없어도 이체증이 아니고 은행명이 없고 식당명이나 카페 같네? 그럼 영수증이야.' 이 예외처리를 스코어로 반영해서 코드로 다시 넣어야 합니다.
가이드는 더합니다. '2천만 원 이상은 이행보증도 체크해야 하고 사전 소통 내용도 증빙해야 해.' 이 모든 것을 계속 맞춰보고 조율해나가야 합니다. 이때는 '바이브 코딩'과 AI도 크게 도움은 안 됩니다다. 테스트 코드(TDD)를 짜보라고 해도 자신에게 유리한 데이터셋을 만들어 통과시켜버리기 때문입니다. 결국 유저 피드백을 받고 엔지니어 스스로가 검증하며 계속 테스트해야 합니다. 아니면 이제 지원한 팀으로부터 '(GPT는 해주는데) 이것조차 안 되는 되요?'를 직면하게 됩니다. (어? 그 데이터를 GPT에 넣어도 되나요?)
2에서 8의 구간
그러나 저 '지옥주'를 통과하며 엔지니어의 코딩 실력은 오히려 증가합니다. 왜냐면, 바이브 코딩이 '탄로(?)'나는데 전체 실행에 4~5시간이 걸리니 '여기서부터 여기까지, 정확히 이 부분만 실행하는 코드'를 요구하며 시스템 이해도를 높여가기 때문입니다.
마치, 이 과정은 팔란티어(Palantir)의 FDE(Forward Deployed Engineer) 모델을 연상시키죠. FDE는 소프트웨어를 연구실에서 만드는 것이 아니라 고객사에 파견되어 그들의 '엉망인' 실제 데이터와 현실 환경 속에서 부딪히며 문제를 해결하는 엔지니어이며, AX는 오히려 험지를 걸어가야 합니다. 그 과정에서 유저 피드백을 받고 표준화되지 않은 현실과 싸우며 끊임없이 코드를 조율해나가야 합니다. 이처럼 달성 가능한 목표를 약간 상회하는 어려운 문제와 데이터를 의도적으로 직면해야 합니다. '바이브 코딩' 몇 번으로 해결되거나 데이터를 뜯어볼 필요도 없고 재설계조차 하지 않는 과업에서는 많은 것을 배울 수 없기 때문입니다.
그렇게 이 시그모이드 함수를 거쳐 AX 담당자는 한 번 더 '딥러닝'을 하게 됩니다. 저러한 시행착오, 즉 FDE로서의 현장 경험이 쌓이면 다음 프로젝트에서는 조직에 적용하기 전에 한 번 더 '이게 정말 적용 가능한가?'를 스펙과 비즈니스 관점에서 먼저 생각하게 됩니다.
이러한 시그모이드 함수가 다시, 더 높은 차원에서 반복되는 것입니다.