안녕하세요, MakeAI 기술팀이에요. 올해부터 매주 화요일에 기술 블로그를 쓰기로 했어요. 제품 자랑보다는 작업 노트에 가깝게 쓰려고 해요. 잘 된 것만 골라 쓰지 않고, 실패한 실험이나 아직 못 푼 문제도 솔직하게 남길게요.
첫 글이니까 저희가 올해 집중하는 세 가지 문제를 먼저 정리해 볼게요.
1. 추출은 "맞다"보다 "확인할 수 있다"가 중요해요
문서 AI 데모는 거의 항상 성공해요. 잘 고른 문서 한 장에서 표를 뽑고, 필드를 채우고, JSON을 보여주면 다들 고개를 끄덕이시거든요. 문제는 그 다음이에요. 실제 업무에서는 이 결과를 누가, 어떻게 믿을 거냐가 전부예요.
작년 한 해 동안 배운 게 하나 있어요. "정확도 몇 %"라는 숫자는 도입 결정에 생각보다 영향을 거의 안 줘요. 담당자분들이 실제로 물어보시는 건 이런 거예요.
- 이 값은 원본의 어디에서 읽은 거예요?
- 모델이 자신 없어 하는 항목은 어떤 거예요?
- 틀렸을 때 누가 잡아내요?
그래서 올해부터 모든 추출 결과에 원본 좌표, 신뢰도, 대조 기준을 같이 붙이고 있어요. 도면 파서에서는 부품표 행을 클릭하면 도면 위 부품 위치가 열리고, 한글 파서에서는 표의 셀 하나가 원본 어느 문단에서 왔는지 따라갈 수 있어요. 저희끼리는 이걸 "확인 가능한 추출"이라고 불러요. 이 블로그에서 제일 자주 나올 주제일 거예요.
2. 폐쇄망에서 안 돌아가면 없는 거나 마찬가지예요
저희 고객 중 상당수가 공공기관, 금융사, 제조사예요. 문서가 밖으로 나갈 수 없는 곳이 대부분이죠. API 키 하나로 부르는 대형 모델은 이런 환경에서 아예 선택지가 아니에요.
그래서 저희는 작은 모델을 잘 만드는 일에 집중하고 있어요. 범용 대형 모델을 쫓아가는 대신 한글 문서, 기계 도면, 보험 서류처럼 좁은 영역에서 GPU 한두 장으로 돌아가는 모델을 만들어요. 이 방향이 맞는지 실험한 결과는 상반기 안에 블로그에 올릴게요. 작은 모델이 이기는 조건과 지는 조건을 숨기지 않고 쓸 생각이에요.
배포 쪽에서는 "설치형"이 도커 이미지 하나 넘겨드리는 일이 아니라는 걸 계속 배우고 있어요. 모델 가중치 반입 절차, GPU 드라이버 버전, 업데이트 경로, 로그 반출 규정까지 전부 제품의 일부더라고요. 이 경험도 체크리스트로 정리해서 공유할게요.
3. 에이전트는 만드는 것보다 운영하는 게 어려워요
작년 하반기부터 에이전트 제품을 두 가지 만들고 있어요. 하나는 말로 업무를 시키면 사내 시스템이랑 연동해서 처리해 주는 업무 자동화 에이전트고, 다른 하나는 그런 에이전트들을 지켜보고 평가하는 운영 도구예요.
두 번째 제품을 만들게 된 이유는 단순해요. 첫 번째 제품을 운영하다 보니 필요했거든요. 프롬프트 한 줄 바꿨더니 어떤 업무가 망가졌는지, 어제보다 토큰 비용이 왜 두 배가 됐는지, 어떤 도구 호출이 실패했는지 모르면 에이전트를 실제 업무에 붙일 수가 없어요.
에이전트 글은 권한 설계, 트레이싱, 회귀 평가, 비용 귀속 같은 운영 이야기 위주로 쓸게요. "에이전트가 이런 것도 해요" 같은 글은 이미 세상에 충분히 많으니까요.
블로그는 이렇게 운영할게요
- 매주 화요일 한 편씩 올려요. 분량보다 따라 해 볼 수 있는 내용을 우선해요.
- 숫자를 쓸 때는 어떤 데이터로 어떤 조건에서 쟀는지 같이 써요. 조건을 못 쓰는 숫자는 아예 안 써요.
- 고객 문서는 절대 그대로 싣지 않아요. 예시는 공개 문서이거나 저희가 만든 샘플이에요.
다음 주에는 한글(HWP) 파일 속이 어떻게 생겼는지 뜯어보는 글로 시작할게요. 한국에서 문서 AI를 하면서 HWP를 피해 갈 수는 없고, 그 구조를 제대로 아는 게 파서 품질의 절반이거든요. 읽어 주셔서 고마워요!