지난 글에서는 워카토 샌드박스로 GEO 모니터링 파이프라인을 만들어본 첫 자동화 도전기를 풀었는데요. 그사이 저는 AI 데이터 구축 기업에 AI Data Supervisor로 입사했습니다. 이번 글은 그 첫 몇 주 동안 겪은 일과, 거기서 다시 생각해본 자동화 이야기입니다.

사실 이번 달, 워카토 앰배서더들은 Snowflake World Tour Seoul을 비롯해 여러 IT 행사에 초대를 받았습니다. 저도 가고 싶었는데 하필 새 업무 첫 주와 일정이 겹쳐서 못 갔어요. 그런데 행사 대신 들어간 AI 데이터 운영 현장에서, 오히려 자동화가 필요한 새로운 장면들을 발견했습니다.

[ 발단 ] 제가 요즘 하는 일

제가 참여하고 있는 건 AI 학습용 문서 데이터 구축 프로젝트입니다. 사내 문서나 논문 같은 자료를 AI가 학습할 수 있는 형태로 가공하는 일인데요. 문서 한 장을 펼쳐놓고 이 영역은 제목(Title), 이건 본문(Text), 이건 표(Table), 이건 그래프(Chart)... 하는 식으로 클래스를 나눠 인스턴스 단위로 라벨링합니다. 저는 그 결과물을 검수하고 프로젝트를 관리합니다. Operator 네 분과 다수의 외부 작업자분들이 만들어내는 작업량, 오류 유형, 기준 준수 여부를 함께 봐요.

입사하고 얼마 지나지 않았을 때, 문서에서 어디까지를 '제목'으로 볼 것이냐는 질문이 서로 다른 작업자에게서 반복해 올라왔습니다.

저도 답을 모르니 원래 이 프로젝트를 맡고 계시던 분께 여쭤보려 했는데, 그분도 다른 업무로 바쁘셔서 매번 붙잡을 상황이 아니었어요. 그래서 이미 작업해오신 Operator 분들께 하나씩 여쭤봤는데, 여기서 예상 못 한 걸 봤습니다. 네 분이 각자 조금씩 다른 기준으로 일하고 계셨어요.

누구를 탓할 일은 아니었습니다. 애초에 고객사에서 내려온 기준서에 제목을 어디까지로 볼지가 정의돼 있지 않았거든요. 정의가 비어 있으면 각자 합리적으로 메꿔가며 일하게 되잖아요.

결국 제가 고객사에 질문을 정리해 보내고, 돌아온 답을 현장 기준으로 옮기는 방식으로 하나씩 맞춰나갔습니다.

[ 이전의 나 ] PR 하나에 창 세 개를 열던 시절

여기서 제가 앰배서더로 만들었던 자동화 콘텐츠를 하나 꺼내볼게요.

🎬 관련 영상: GitHub PR이 생성되면 Jira·Notion을 업데이트하고 Slack으로 알리는 Workato 자동화 https://youtube.com/shorts/u4jTCHLynbc?si=RYH5oVRcS30J29mG

실제 운영 환경에 배포한 건 아니고, 제가 직접 레시피를 설계해 구현해 본 것입니다. 흐름은 단순합니다. GitHub에 Pull Request가 생성되면 → 관련 Jira 티켓의 상태와 정보를 업데이트하고 → Notion 프로젝트 문서에도 진행 상황을 반영한 뒤 → Slack으로 팀원들에게 알립니다.

이 주제를 고른 이유는 제가 겪은 반복 업무 때문이었어요. SSAFY에서 여러 프로젝트의 팀장과 PM을 맡는 동안, PR 하나가 올라올 때마다 창을 세 개씩 열어야 했거든요. Jira에서 상태 바꾸고, Notion 문서 고치고, Slack에 공유하고. 하나만 빠뜨려도 "그거 끝난 거 아니었어요?"라는 질문이 돌아왔습니다.

그때 제가 자동화를 바라보던 관점은 개발자와 PM의 관점, 즉 툴을 오가는 손을 줄이는 것이었습니다. 클릭이 줄면 누락이 줄고, 누락이 줄면 정보가 어긋나지 않는다. 거기까지가 제가 이해한 자동화의 가치였어요. 그런데 운영자 자리에 앉아보니, 자동화가 필요한 대상은 툴 업데이트만이 아니었습니다.

[ 현장 ] 제목 하나가 이렇게 어려울 일인가

기준을 맞추려고 오류 사례를 모아놓고 보니, 작업자분들이 가이드를 안 읽은 게 아니었습니다. 기준 자체가 사람마다 다르게 해석될 여지를 품고 있었어요.

글자가 크고 굵으면 제목일까요? 그것만으로는 판단이 안 됩니다. 글머리 기호가 붙어 있는지, 명사형으로 끝나는 표현인지, 문서 구조 안에서 어떤 역할을 하는지, 비슷한 형태가 문서 전체에 몇 번이나 반복되는지를 같이 봐야 결정할 수 있는 문제였습니다. 서식은 판단의 한 조각일 뿐이었던 거죠.

그래서 제가 한 일은 이랬습니다.

• 반복되는 오류 사례를 모읍니다
• 어디서 해석이 갈리는지, 왜 갈리는지를 확인합니다
• 서식뿐 아니라 내용·구조·반복 빈도를 함께 보도록 기준을 구체화합니다
• 예외 사례와 그렇게 판단한 근거를 정리합니다
• Operator와 작업자분들께 수정된 기준을 안내합니다
• 이후 고객사 피드백을 반영해 가이드를 다시 업데이트합니다

여기서 배운 게 있어요. 같은 질문이 반복된다면 사람의 집중력을 탓하기 전에, 기준의 모호함과 그 기준이 전달되는 구조를 먼저 봐야 한다는 것입니다. 레시피에 '소금 한 꼬집'이라고만 적혀 있으면 주방마다 다른 국이 나오잖아요. 요리사가 게을러서가 아니라 레시피가 한 꼬집을 정의하지 않아서죠. 그리고 제가 '한 꼬집'을 '2g'으로 고쳐 적었다고 해서, 이미 국을 끓이고 있는 사람들에게 그 사실이 저절로 도착하지도 않습니다.

혹시 이런 상황, 익숙하지 않으신가요. 기준을 정해 공지까지 했는데 일주일 뒤에 같은 오류가 또 올라오는 것. 저는 이게 개발 프로젝트에서 PM을 할 때도, AI 데이터 운영을 하는 지금도 똑같이 반복되고 있다는 걸 이번에 알았습니다.

[ 연결 ] 결국 같은 모양의 일이었습니다

정리하다 보니, 제가 PM 시절에 자동화했던 반복 업무와 지금 운영자로서 마주한 반복 업무가 거의 같은 골격이었습니다.

다른 건 동기화의 대상뿐이었어요. PR 자동화가 맞춰둔 것은 '개발 상태'였고, 지금 제가 맞춰야 하는 것은 '품질 기준'입니다. 무엇을 제목으로 볼 것인가 하는 판단의 잣대를요. 공통점은 하나입니다. 하나의 변화가 여러 시스템과 여러 사람에게 빠짐없이 전달되어야 한다는 것.

그래서 자동화의 정의를 이렇게 고쳐 적기로 했습니다. 자동화의 가치는 클릭 횟수를 줄이는 데서 끝나지 않습니다. 변경된 기준이 여러 도구와 사람에게 빠짐없이 전달되고, 현장에서 같은 기준으로 적용되도록 만드는 것이 진짜 운영 자동화입니다.

[ 설계 ] 워카토로 짠다면

아직 회사에 적용한 건 아니고, 현장에서 본 문제를 두고 그려본 구상입니다. 정확히는 지금 제가 손으로 하고 있는 일을 그대로 흐름도로 옮긴 것에 가까워요. 커넥터의 세부 지원 여부까지 단정할 단계는 아니지만, Google Slides와 Slack처럼 이미 쓰고 있는 도구들을 레시피로 잇는 흐름 정도는 그려볼 수 있겠더라고요.

1. 작업 중 오류나 질문이 발생합니다.
2. AI가 질문의 유형을 분류하고, 기존 기준과 유사 사례를 확인합니다.
3. 기존 기준으로 답변할 수 있는 질문인지 판단합니다.
4. 답할 수 있으면, 기존 기준을 바탕으로 답변안을 생성합니다.
5. 새로운 예외라면, 고객사용 Google Slides에 문의 내용을 정리하고 고객사 답변을 받습니다.
6. 두 경로 모두 여기서 만납니다. Supervisor가 답변을 검토하고 현장 작업 기준으로 구체화합니다.
7. 작업자용 Google Slides 가이드를 업데이트합니다.
8. Slack으로 변경된 기준을 공지합니다.
9. 적용 여부와 동일 오류 재발 여부를 추적합니다. 같은 오류가 재발하면 1번으로 돌아갑니다.

6번만 굵게 쓴 이유가 있습니다. 분류하고, 유사 사례를 찾아오고, 답변안까지 써주는 건 AI가 훨씬 빠릅니다. 그런데 기준을 확정하는 판단만큼은 넘기고 싶지 않았어요. 기준이 한 번 잘못 정해지면 그 뒤 데이터 전체가 그걸 따라가고, 되돌리려면 이미 작업된 분량을 다시 봐야 하니까요. 그래서 기존 기준으로 답할 수 있는 쉬운 질문이든 고객사까지 다녀온 새 예외든, 두 갈래를 굳이 한 지점으로 모아 사람이 한 번 보게 했습니다. 요즘 이야기되는 에이전틱 워크플로도 저는 이 지점에서 이해하게 됐어요. AI가 다음에 필요한 작업을 스스로 제안할 만큼 자율성이 높아질수록, 오히려 어디에 사람의 승인을 둘 것인가가 설계의 핵심이 되더라고요.

처음 만들었던 PR 자동화와 결이 갈리는 지점도 여기입니다. 그때는 '알림 보내기'라는 한 작업을 대신해준 것이었다면, 이번 구상은 접수부터 분류, 고객사 확인, 판단 보조, 가이드 반영, 공지, 재발 추적까지가 하나로 이어져 있어요. 게다가 마지막 추적이 다시 첫 단계로 돌아가서, 같은 오류가 또 나오면 그 자체가 새 입력이 됩니다. 개별 작업을 자동화하는 것을 넘어, 판단과 후속 조치가 이어지는 전체 운영 프로세스를 연결한다는 점에서 하이퍼오토메이션에 가깝습니다.

[ 측정 ] 그래서 이게 남는 장사인가

솔직히 개선 수치는 아직 못 쟀습니다. 입사한 지 얼마 되지 않았고 위 워크플로는 구상 단계니까요. 오류율이 몇 퍼센트 줄었다는 숫자는 이 글에 없습니다. 대신 무엇을 재야 하는가는 정리해볼 수 있었는데, 이게 이번에 제가 가장 크게 바뀐 지점입니다.

AI 도입 ROI는 보통 "사람이 몇 명 줄었나", "생성 속도가 얼마나 빨라졌나"로 이야기됩니다. 그런데 제 자리에서 보면 그 숫자는 제 문제를 설명해주지 못해요. 답변이 아무리 빨리 생성돼도 같은 질문이 내일 또 올라오면 나아진 게 없으니까요. 제가 재고 싶은 건 이런 것들입니다.

• 동일하거나 유사한 반복 질문의 감소율
• 새로운 기준이 현장에 전달되기까지 걸리는 시간
• 가이드 수정 이후 동일 오류의 재발률
• Supervisor가 반복 안내에 쓰는 시간
• 작업자별 기준 해석 편차
• 예외 사례가 공식 기준으로 정리되기까지 걸리는 시간

AI 도입 ROI는 생성된 답변의 수보다 반복 질문 감소율, 기준 변경 전파 시간, 동일 오류 재발률로 측정해야 합니다. 여섯 개가 공통으로 묻는 건 '얼마나 많이 만들어냈나'가 아니라 '얼마나 덜 반복하게 됐나'거든요.

[ 마치며 ]

워카토에서 자동화 한 편을 부르는 이름이 '레시피'라는 게 이번엔 좀 다르게 읽혔습니다. 레시피가 요리를 대신 해주진 않죠. 다만 '한 꼬집'이 몇 그램인지 정해두고, 그 정의가 바뀌면 모든 주방에 그 사실이 도착하게 만들어줍니다. 제가 지난 몇 주 동안 손으로 하고 있던 일이 정확히 그거였고, 아마 이게 제가 자동화로 옮기고 싶은 다음 조각인 것 같아요.

저처럼 자동화를 구상하고 직접 만져보고 싶은 분들은 아래 링크에서 샌드박스를 신청할 수 있습니다. 비개발자도 충분히 다룰 수 있게 열려 있으니 부담 없이 시작해 보시길 권합니다.

👉 체험(샌드박스) 신청: https://app.trial.workato.com/users/sign_up_trial?utm_source=ambassador_1gi&utm_medium=content&utm_campaign=kr_2026&utm_content=lsw 👉 상담 신청: https://www.workato.com/ko-KR/request_demo?utm_source=ambassador_1gi&utm_medium=content&utm_campaign=kr_2026&utm_content=lsw

끝까지 읽어주셔서 감사합니다. 오늘도 건강하세요 🫶

#WorkatoKorea #워카토 #워카토코리아 #하이퍼오토메이션 #에이전틱워크플로 #AI도입ROI #업무자동화 #워크플로우자동화 #노코드자동화 #AI데이터 #데이터라벨링 #품질관리 #HumanInTheLoop #iPaaS #자동화레시피 @WorkatoKorea

지난 CIS 2026 후기에서 다음 글로 워카토 샌드박스를 직접 만져본 첫 자동화 도전기를 예고했었는데요. 그 결과를 들고 왔습니다. "잘 될지는 저도 궁금합니다"라고 써놓고 내심 조마조마했는데, 결론부터 말하면.. 기대 이상으로 잘 됐어요!

무엇을 만들었나

첫 자동화 주제로 고른 건 GEO(Generative Engine Optimization) 모니터링 파이프라인입니다.

요즘 뭘 사거나 도입할 때, 검색창보다 ChatGPT나 Perplexity한테 먼저 물어보게 되잖아요. 그러다 보니 "AI가 답변 속에서 우리 브랜드를 얼마나 자주, 몇 번째로, 어떤 맥락으로 언급하는가"가 새로운 가시성 지표로 떠오르고 있어요. 사실 이 주제는 CIS 2026에서 'AI 검색 시대의 브랜드 가시성' 이야기를 접한 뒤로 계속 붙잡고 공부하던 영역이기도 합니다. 파고들수록 재미있어서, 첫 자동화 주제로 도전해보고 싶었습니다.

그런데 공부해 보니 GEO 측정, 생각보다 층이 깊더라고요. 언급 여부와 인용 비율을 세는 건 시작일 뿐이고, 제대로 하려면 어떤 맥락에서 어떤 표현으로 언급됐는지, AI가 말한 내용이 사실과 맞는지(정확도), 인용된 출처는 어디인지까지 평가해야 해요. 다만 이걸 전부 첫 시도에 담는 건 욕심이다 싶어서 이번엔 범위를 좁혔습니다. 반복 질의를 통한 언급 '비율' 집계와 주간 리포트 자동화까지. 맥락·정확도 평가는 이 뼈대 위에 다음 단계로 얹어볼 계획이에요.

비율 집계만 해도 자동화가 필수였습니다. LLM 응답은 물어볼 때마다 달라지기 때문에, 한 번 질의하고 "언급됐다/안 됐다"로 판단하는 것이 아니라 같은 질문을 여러 번 반복해서 던진 뒤 비율로 집계해야 의미 있는 숫자가 나옵니다. 근데 이걸 사람이 매주 손으로 한다? 상상만 해도 아득합니다...

그래서 레시피를 역할별로 세 개로 나눠 설계했습니다.

한 곳에서 문제가 생겨도 나머지는 살아 있어야 하고, 중간 단계부터 다시 실행하기도 쉬워야 하기 때문에 하나의 레시피에 전부 담지 않고 나눴습니다.

흐름을 조금 더 풀어보면 이렇습니다.

1. Recipe 1 (수집) — 데이터 테이블에 등록해 둔 질의 프롬프트를 불러와, 엔진별로 × 반복 횟수만큼 HTTP로 API를 호출하고 응답 원문을 결과 테이블에 적재합니다. 호출 사이에는 8초씩 지연을 넣어 레이트 리밋을 피했습니다.
2. Recipe 2 (분석) — 쌓인 원문을 하나씩 꺼내 "브랜드가 언급됐는지, 몇 번째로 추천됐는지, 어떤 경쟁사가 함께 등장했는지"를 AI에게 JSON 형식으로만 출력하게 한 뒤, 파싱해서 같은 행에 업데이트합니다.
3. Recipe 3 (리포트) — 주 단위로 집계해 흡율(언급 건수 ÷ 총 호출 수)을 계산하고, 워카토 내에 만든 데이터 테이블에 적재해 갱신한 뒤 요약 리포트를 Gmail로 발송합니다.

트리거 하나로 이 세 레시피가 연쇄적으로 실행된 결과를 Workato 내의 데이터베이스 탭에서 처음 확인했을 때가 이번 도전의 가장 기억에 남는 순간이었습니다. 월요일 아침, 제가 무엇을 하고 있든 이 파이프라인은 스스로 돌아가고 있는 셈이니까요.

직접 써보니 좋았던 점

지난 글에서 워카토 발표를 듣고 "비어 있던 실행 구조를 메우는 도구"라고 정리했었는데, 이번에는 그 말을 제 손으로 검증해 본 셈입니다. 인상 깊었던 지점을 중심으로 정리해 보겠습니다.

1. 커넥션 — 없으면 만들 수 있고, 만들어도 안전합니다

워카토에는 사전 구축된 커넥터가 이미 방대하게 준비되어 있습니다. Gmail, Google Sheets는 검색해서 OAuth 로그인 한 번이면 연결이 끝납니다. 그런데 제가 더 좋게 본 것은 목록에 없는 서비스도 문제가 되지 않는다는 점이었습니다.

이번 파이프라인은 OpenAI·Anthropic·Perplexity API를 직접 호출해야 했는데, 범용 HTTP 커넥터에 Base URL과 인증 헤더(API 키)만 입력하면 커넥션이 바로 만들어집니다. "커넥터가 없어서 못 한다"는 상황 자체가 성립하지 않는 구조입니다.

그리고 이 부분이 은근히 중요한데, API 키를 레시피 본문에 하드코딩하는 것이 아니라 커넥션이라는 별도의 공간에 보관하는 구조라서, 레시피를 아무리 열어봐도 키가 노출되지 않습니다. 공식 문서를 찾아보니 근거도 명확했습니다. 워카토에 저장되는 모든 데이터(레시피, 커넥션 포함)는 전송 중이든 저장 중이든 AES-256으로 암호화되고, 외부 시스템 연결에는 가능한 경우 OAuth 2.0을 사용해 자격 증명을 아예 저장하지 않으며, 저장이 불가피한 자격 증명은 256비트 키로 암호화된다고 합니다. 커넥션 데이터에는 커넥션별 고유 암호화 키가 별도로 적용되고, 엔터프라이즈 환경이라면 AWS Secrets Manager 같은 외부 시크릿 관리자를 연동해 자격 증명을 워카토 바깥에서 관리하는 옵션까지 마련되어 있습니다.

개인 프로젝트에서 .env 파일 관리에 늘 신경을 곤두세워야 했던 입장에서는, 구조 자체가 그 실수를 원천적으로 막아준다는 점이 인상 깊었습니다.

2. 스키마를 '붙여넣으면' 알아서 만들어줍니다

API 연동에서 가장 번거로운 작업 중 하나는 request/response의 필드 구조를 도구에게 하나하나 알려주는 일입니다. 필드 추가, 타입 지정, 중첩 구조 정의까지 클릭이 끝없이 이어지곤 합니다.

워카토에서도 물론 필드를 하나씩 지정할 수 있지만, 그보다 편한 방법이 있었습니다. 공식 API 문서에 있는 예시 request/response JSON을 그대로 복사해 붙여넣으면, 스키마를 자동으로 분석해 만들어줍니다. OpenAI 문서의 응답 예시를 붙여넣었더니 choices[0].message.content까지 데이터필(앞 단계의 출력값을 뒤 단계로 끌어다 쓰는 변수)로 전부 생성되는 것을 보고 감탄했습니다.

이렇게 생긴 데이터필을 다음 액션에 드래그해서 꽂으면 매핑이 끝나요. 데이터가 어디에서 와서 어디로 흘러가는지가 눈에 보인다는 것. 이게 생각보다 큰 안심을 줍니다.

데이터필이 좋았던 이유가 하나 더 있어요. 스텝이 많아지면 content 처럼 같은 이름의 필드가 여기저기서 튀어나와서, 매핑할 때 어느 스텝에서 온 값인지 헷갈리기 쉽거든요. 그런데 워카토는 데이터필을 스텝 단위로 묶어서 보여주고 태그도 달아줍니다. 이름이 겹쳐도 출처를 바로 알 수 있으니, 스텝이 열 개를 넘어가도 헷갈릴 일이 없었어요.

3. 디버깅 — 단계별 output이 전부 보입니다

자동화가 두려운 이유는 "어디서 문제가 생겼는지 모른 채 조용히 멈추는 것"입니다. 워카토는 오류가 발생하면 어느 스텝의 어떤 부분이 문제인지 에러 메시지를 상당히 구체적으로 보여줍니다.

더 좋았던 것은 Job 상세 화면입니다. 실행이 끝나면 스텝 하나하나의 input/output을 클릭해서 모두 확인할 수 있습니다. "HTTP 호출까지는 정상인데 파싱 단계에서 깨졌다" 같은 판단을 로그를 뒤질 필요 없이 화면에서 바로 내릴 수 있습니다. 반복 호출이 많은 레시피라 중간에 몇 차례 문제가 생겼는데, 그때마다 원인을 찾는 시간이 짧아서 스트레스가 크게 줄었습니다.

하나 더 ! AI가 이미 안에 들어 있습니다

참고로 워카토 안에는 AI by Workato라는 내장 AI 기능이 있어서, 간단한 텍스트 분석이나 요약 정도는 외부 API 연결 없이 액션 하나로 처리할 수 있어요. 별도의 API 키 발급도, 커넥션 설정도 필요 없으니 가벼운 AI 작업이라면 이쪽을 먼저 쓰는 것이 훨씬 간편합니다. 아래엔 AI in Workato 커넥션에서 제공하는 기능 리스트입니다!

다만 저는 이번에 쓰지 못했습니다. 응답 원문 수백 건을 하나씩 분석시켜야 하는, 반복 호출이 유난히 많은 레시피이다 보니 분당 AI 호출 횟수 제한에 걸렸기 때문입니다. 그래서 OpenAI 커넥션과 Perplexity HTTP 커넥션을 만들어 전환했는데, 바로 이런 상황에서 앞서 말한 첫 번째 장점이 빛났습니다. 내장 기능이 한계에 부딪혀도, 외부로 우회할 길이 항상 열려 있다는 점입니다.

개발을 공부하는 사람에게도 좋은 교재입니다

만들다가 문득 든 생각인데요. 트리거, 배치 작업, 반복문, 에러 핸들링, 데이터 매핑, 레이트 리밋 대응. 이것들은 전부 실무 자동화와 백엔드에서 마주치는 개념들이잖아요. 워카토는 이를 코드가 아니라 블록으로 조립하게 해주기 때문에, 개념의 뼈대가 시각적으로 잡힙니다.

"재시도는 왜 필요한가" 같은 질문도 레시피를 돌리다 429 에러를 한 번 만나보면 몸으로 이해됩니다. 코드부터 배우면 문법에 치여 놓치기 쉬운 '흐름 설계' 감각을 먼저 기를 수 있다는 점에서, 개발을 공부하는 분들이 사이드로 다뤄봐도 얻는 것이 많은 도구라고 느꼈습니다.

마치며

지난 글을 "진짜 효율은 흐름을 제대로 쥐는 것"이라는 문장으로 맺었는데, 이번에 그 흐름을 처음으로 제 손으로 쥐어봤습니다.

물론 이번에 만든 것은 GEO 측정의 전체 그림에서 보면 첫 조각에 해당합니다. 언급 맥락 분석이나 답변 내용의 정확도 평가처럼 더 어려운 층은 아직 손대지 못했고, 그만큼 공부할 것도 남아 있습니다. 다만 비율 집계라는 뼈대가 자동으로 돌아가기 시작했으니, 그 위에 하나씩 얹어갈 발판은 마련된 것 같습니다.

다음엔 실험을 해보고 싶기도 합니다. 시중에 GEO 분석을 해주는 솔루션들이 이미 있는 걸로 아는데, 그 구독비 vs 제가 직접 AI API로 돌리는 자동화 비용, 어느 쪽이 이득인지 가격 비교를 해보고 싶습니다.

다만 이 비교가 공정하려면 실무의 기준을 알아야 해요. 실제 현장에서는 최소 몇 개의 질문을, 몇 개의 AI 모델로 돌려서 측정하는지, 언급률 말고 또 어떤 평가 기준을 쓰는지. 이건 책만 파서는 안 나오고 전문가에게 여쭤볼 기회가 필요하겠더라고요. 혹시 GEO 실무를 아시는 분, 혹은 비용 계산이 머릿속에 그려지는 분이 계시다면 댓글 부탁드립니다. 열심히 배우겠습니다 🙇

직접 만져보고 싶은 분들은 아래 링크에서 샌드박스를 신청할 수 있습니다. 비개발자도 충분히 다룰 수 있게 열려 있으니 부담 없이 시작해 보시길 권합니다.

👉 체험(샌드박스) 신청: https://app.trial.workato.com/users/sign_up_trial?utm_source=ambassador_1gi&utm_medium=content&utm_campaign=kr_2026&utm_content=lsw 👉 데모/상담 신청: https://www.workato.com/ko-KR/request_demo?utm_source=ambassador_1gi&utm_medium=content&utm_campaign=kr_2026&utm_content=lsw

끝까지 읽어주셔서 감사합니다. 오늘도 건강하세요 🫶

#WorkatoKorea #워카토 #워카토코리아 #기업자동화 #워크플로우자동화 #노코드자동화 #GEO #AI검색최적화 #자동화레시피 #iPaaS #AI에이전트 #개발공부 #첫자동화 @WorkatoKorea

어제의 애니메이터, 오늘의 개발자 이세원입니다. 이 글은 제가 LinkedIn에 짧게 올렸던 CIS 2026 후기를, 못다 한 이야기까지 다 풀어서 다시 쓴 긴 버전이에요.

AI를 쓰는 기업은 88%, 그런데 정작 손익에 효과를 본 기업은 한 자릿수랍니다.

McKinsey의 The State of AI 2025 통계를 처음 봤을 때, 솔직히 좀 멍했어요. 여기서 헷갈리지 말아야 할 건, 이게 '도입률'과 '성과율'을 나눠 본 숫자라는 점이에요. 쓰기 시작한 기업은 88%로 많은 비중을 차지하는데, 그 도입을 실제 손익 개선까지 연결한 곳은 100곳 중 여섯 곳 남짓이라는 뜻이거든요. 'AI를 쓰긴 쓰는데 성과로 못 잇는다'는 골이 생각보다 깊었던 거죠.

여기에 하나 더 얹어볼게요. 모델은 분기도 아니고 거의 한 달에 한 번꼴로 새 버전이 쏟아집니다. Fable 5니 GPT-5.6이니, 따라가다 숨이 찰 만큼 빠른 속도예요. 그런데 이상하죠. 모델은 이렇게까지 빨리 진화하는데, 왜 그걸 도입한 기업의 성과는 그 속도를 못 따라갈까요?

저는 이 질문 하나를 품고 지난 6월 17일, 그랜드 인터컨티넨탈 서울 파르나스에서 열린 ZDNET Korea CIS 2026, "One AI, Elevate All" 에 다녀왔습니다. 여러 기업이 무대에 올라 각자의 고민을 펼쳐놨는데, 신기하게도 다들 비슷한 데서 병목을 느끼더라구요. 그리고 그 답들은 하나같이, 모델 바깥에 있었습니다.

[ 본론 ] 현장에서 주운 것들

잘 만든 에이전트도, 현업에 들어가면 흔들린다

여러 발표를 관통하던 장면 하나가 있어요.

PoC나 시연 단계에서는 기가 막히게 돌아가던 AI가, 막상 실제 현업에 들어가면 시름시름 앓다 무너진다..!

생각해보면 당연합니다. 혼자 연주할 땐 완벽한 솔리스트도, 오케스트라에 데려다 놓으면 박자가 어긋나잖아요. 발표들을 들으면서 제가 받은 인상은, 결국 문제는 모델 자체가 아니라 모델이 일할 '실행 구조'가 비어 있다는 쪽이었어요.

팀이 늘고 과제가 쌓이면 프롬프트는 여기저기 복제되고, 평가 기준은 제각각이 되고, 거버넌스는 늘 한 박자 늦죠. 에이전트는 우후죽순 늘어나는데 통제는 슬그머니 사라지는, 말하자면 새로운 Shadow IT가 자라나는 겁니다. 모델이 똑똑해질수록 이 그림자도 같이 커진다는 게, 이날 제가 받은 가장 큰 역설이었어요.

"코드와 프롬프트는 더 이상 자산이 아니다"

그러다 한 세션에서 들은 문장 하나가 머리에 콕 박혔습니다.

"코드와 프롬프트는 더 이상 자산이 아니다."

처음엔 좀 도발적으로 들렸는데, 이유를 듣고 나니 끄덕여졌어요. 프롬프트는 부서지기 쉽고(brittle), 맥락은 시간이 지나면 흐려지고(Context Rot), 코드는 제 환경에 묶여(환경 종속) 다른 데로 못 옮기니까요. 그렇게 죄다 휘발되고 나면, 그래서 도대체 뭐가 남느냐.

발표자가 내놓은 답은 셋이었습니다. 의도(Intention)·평가(Evaluation)·피드백(Feedback).

이 대목에서 저는 좀 소름이 돋았어요. 제가 애니메이션 업계에서 5년 넘게 콘티를 그리며 몸으로 배운 게 정확히 이거였거든요. 좋은 장면은 잘 그린 한 컷에서 나오지 않아요. '이 컷에서 관객에게 무엇을 보여줄 것인가'라는 의도에서 나옵니다. 작화가 아무리 화려해도 의도가 없으면 그냥 예쁜 그림일 뿐이에요. 잘 그린 프레임은 갈아 끼우면 그만이지만, 그 장면을 왜 이렇게 짰는지에 대한 의도와 수정 피드백은 차곡차곡 쌓여 다음 작품의 자산이 됩니다.

AI도 똑같더라고요. 모델은 프레임이고, 의도는 콘티예요. 갈아 끼워지는 건 모델 쪽이지, 의도가 아니었습니다.

우문현답, 우리의 문제는 현장에 답이 있다

그래서 자연스럽게 따라온 질문. 그럼 그 '의도'는 어디서 나오느냐.

거창한 최신 모델이 아니라, 매일 그 업무를 하는 사람의 판단이었습니다. 어느 발표에서는 "차이를 만드는 건 데이터가 아니라 판단(Judgement)"이라고까지 못 박더라고요. 80%가 암묵지로 묻혀 있는 그 현장 감각, 그게 진짜 자산이라는 거예요.

그러니 일하는 방식도 달라집니다. 전사를 한 방에 뒤엎는 대신, 한 번에 하나씩 고치는 루프로 가는 거죠. 문제를 정의하고, 하나만 개선하고, 평가하고, 다시 반복. 구조화된 노트로 맥락을 차곡차곡 쌓아가는 이른바 Effective Context Engineering. 똑똑한 한 방이 아니라, 꾸준히 돌려서 굴려가는 작은 바퀴인 거죠.

그 의도는 '어디에' 남는가

여기까지 와서 제가 가장 오래 곱씹은 지점이 이거였어요.

의도·평가·피드백이 진짜 자산이라는 데까지는 동의했는데, 그게 누군가의 머릿속이나, 부서지기 쉬운 프롬프트 한 줄에만 남는다면? 그 사람이 퇴사하면 같이 사라지고, 그 프롬프트가 깨지면 같이 증발하는 거잖아요. 자산이라기엔 너무 위태롭죠.

결국 관건은, 그 의도가 버전이 매겨지고 재사용되는, 카탈로그화된 워크플로우로 남아야 한다는 점이었습니다. 한 번 잘 짠 판단의 흐름을 조직이 그 위에 계속 쌓아 올릴 수 있는, 말하자면 '자산의 서가' 같은 것. 그제야 의도가 휘발되지 않고 조직의 근육이 됩니다.

AI를 활용한 현장의 즉각적인 업무 수행도 물론 중요해요. 하지만 더 길게 끌고 갈 것은, 그 의도·평가·피드백을 워크플로우 자동화로 구조화해 자산으로 남기는 일이라는 걸 깨닫는 시간이었습니다.

첫 발표가 이미 답을 두고 있었다

이날 행사의 첫 세션을 연 게 바로 워카토(Workato)였어요. 행사가 끝나고 메모를 다시 펼쳐 보니 그 첫 발표가 가리키던 자리가 정확히 이 '비어 있는 실행 구조'더라고요. 마치 질문은 마지막 세션들에서 받았는데, 답은 첫 세션에 미리 깔려 있던 느낌이랄까요.

발상 자체는 단순했어요. LLM이 판단하면, 그 판단을 실제 기업 시스템 안에서 대신 실행해주는 층(layer)을 까는 것. 똑똑한 모델이 "이건 이렇게 처리하자"고 결정하는 데서 끝나는 게 아니라, 그 결정이 진짜 업무로 굴러가게 만드는 거죠. 앞에서 비어 있다던 바로 그 자리예요.

왜 이게 그 자리에 딱 맞는다고 봤느냐면요.

1. 모든 시스템과 안전하게 연결되니까. SaaS·ERP·레거시까지, 1,000개가 넘는 사전 구축 커넥터로 잇는다고 해요. (화면을 흉내 내다 UI가 바뀌면 깨지는 방식이 아니라, API 기반이라 잘 안 부서진다는 점이 인상적이었어요.) 아까 '연동이 안 돼서 일이 사람 손에 다시 떨어진다'던 그 구멍을 메우는 지점이죠.
2. 업무 로직을 끝까지 실행하니까. 반복 작업, 승인 절차 같은 복잡한 흐름을 사람이 읽을 수 있는 형태로 짜고 끝까지 돌립니다. 노코드 자동화라 비개발자도 손댈 수 있고요. AI가 '내용만 알려주고' 멈추는 게 아니라, 발송·입력까지 이어지는 거예요.
3. 거버넌스·보안이 안에 박혀 있으니까. AI의 오작동(환각)을 제어하고, 데이터 접근과 승인 절차를 관리하고, 환경별·프로젝트별 역할 기반 접근 제어까지. 즉 "AI가 무엇을 하면 안 되는지"를 먼저 정하는 설계예요. 앞에서 말한 새로운 Shadow IT를, 바로 이 자리에서 막는 거죠.

여기에 엔터프라이즈 MCP(Enterprise MCP)가 더해지면, 다양한 AI 모델이 통제된 채로 실제 업무를 호출하고 실행하는 AI 오케스트레이션의 그림이 완성됩니다. 결국 진짜 엔터프라이즈 AI, 그러니까 회사 시스템 안에서 책임지고 굴러가는 기업 자동화는 이 지점에서 시작되는 셈이에요. 흥미로웠던 건, 프런티어 AI를 직접 만드는 글로벌 기업들조차 자기네 비즈니스를 돌리는 데는 이런 실행·오케스트레이션 기반에 기댄다는 점이었어요. 모델을 가장 잘 아는 쪽이, 모델만으론 안 된다는 걸 가장 먼저 인정한 셈이죠.

접근법도 과하지 않아서 좋았어요. 전사 도입부터 지르지 말고, 가장 복잡하고 골치 아픈 업무 하나를 골라 4주 안에 작은 검증부터. ROI가 보이면 그때 옆 부서로, 전사로 천천히 넓혀가는 식. 거대한 그림 한 장보다 작고 구체적인 한 걸음. 이것도 어쩐지 '한 번에 하나씩'이라는 이날의 결론과 닿아 있었습니다.

글로 풀면 길어서, 영상으로 보세요

사실 'LLM의 판단이 실제 업무로 흘러간다'는 말, 글로만 풀면 좀 추상적이잖아요. 다행히 그 첫 세션 발표가 영상으로 녹화돼 있어요. 흐름이 어떻게 설계되는지 직접 보는 게 백 마디 설명보다 빠를 거예요. (제가 LinkedIn에도 걸어뒀던 그 영상이에요.)

👉 CIS 2026 발표 영상 보기: https://youtu.be/hXstm9RVKKA

흐름이 눈에 들어왔다면, 그다음은 직접 만져보는 거죠. 비개발자도 손댈 수 있게 열려 있어서, 저도 다음 글에서 이걸로 첫 자동화를 해볼 참이에요.

👉 체험(샌드박스) 신청: https://app.trial.workato.com/users/sign_up_trial?utm_source=ambassador_1gi&utm_medium=content&utm_campaign=kr_2026&utm_content=lsw 👉 데모/상담 신청: https://www.workato.com/ko-KR/request_demo?utm_source=ambassador_1gi&utm_medium=content&utm_campaign=kr_2026&utm_content=lsw

[ 결론 ] 전부 맡기는 게 아니라, 제대로 쥐는 것

행사장을 나오면서 든 생각은 처음의 그 질문으로 돌아갔어요.

모델은 똑똑해지는데 왜 성과는 안 따라올까. 답은 모델이 아니라, 그 모델의 판단을 받아 실제 업무로 옮기고, 그 의도를 자산으로 남기는 구조가 비어 있었기 때문이더라고요. 빠진 조각은 한 번도 모델이었던 적이 없었습니다. 늘 그 뒤에 있어야 할 구조였죠.

한때 저는 '전부 AI에게 맡기자'에 호의적인 효율화 신봉자였어요. 그런데 전부 맡기는 게 효율인 줄 알았던 게 착각이었습니다. 진짜 효율은 흐름을 제대로 쥐는 것이었어요. 솔리스트는 이미 차고 넘치고, 지금 필요한 건 정확한 지휘니까요.

앞으로 워카토 코리아의 학생 앰배서더로 활동하면서, 휩쓸리기 쉬운 AI 용어와 방법론을 한 꺼풀씩 벗겨, 그 흐름을 직접 쥐도록 돕는 이야기를 현업 실무자부터 입문자까지 함께 나눠보려 합니다. 다음 글에서는 제가 직접 워카토 샌드박스를 만져본 저의 첫 자동화 도전기를 들고 올게요. (잘 될지는 저도 궁금합니다 😂)

서툰 지휘자의 첫 손짓이지만, 끝까지 읽어주셔서 감사해요. 오늘도 건강하세요 🫶

#WorkatoKorea #워카토 #워카토코리아 #기업자동화 #한국기업자동화 #AI오케스트레이션 #워크플로우자동화 #엔터프라이즈MCP #EnterpriseMCP #엔터프라이즈AI #AI에이전트 #기업AI전환 #국내기업AI #노코드자동화 #CIS2026 #AI후기 @WorkatoKorea