AI 업무 자동화라는 말이 남의 이야기처럼 들리던 시절, 저는 점검 시즌마다 똑같은 양식의 문서를 수십, 많게는 수백 건씩 손으로 채웠습니다. 평가표 한 장을 열어 항목만 바꾸고, 복사하고, 다시 항목을 바꾸는 일. 분석하고 판단할 시간이 정작 제일 부족했습니다. 서식을 채우는 데 하루가 다 갔으니까요. 그게 엔지니어가 할 일인가 싶으면서도, 마감은 마감이라 손은 계속 움직였죠.
제 분야인 발전·에너지 연구는 의외로 문서 노동이 많습니다. 안전 점검표, 위험성평가서, 성능 보고서. 같은 틀에 숫자와 문장만 갈아끼우는 작업이 끝도 없이 이어지거든요. 그러다 보면 정작 중요한 질문 — 이 설비가 왜 이렇게 거동하는가 — 은 뒤로 밀립니다. 손이 바빠서 머리가 놀았던 셈이죠.
밖에서 보면 엔지니어는 설비를 들여다보고 데이터를 분석하는 사람처럼 보입니다. 그런데 현실은 모니터 절반이 문서 작업으로 채워져 있죠. 같은 양식을 백 번 채우다 보면, 내가 연구를 하는 건지 서식을 옮겨 적는 건지 헷갈릴 때가 있습니다. 그 답답함이 변화를 찾게 만든 출발점이었습니다.
지난 1년 사이 이 풍경이 바뀌었습니다. 정확히는 제가 일하는 방식 자체가 바뀌었습니다. 오늘은 AI 업무 자동화가 발전 현장의 엔지니어 한 사람의 하루를 어떻게 재편했는지, 자랑이 아니라 관찰의 기록으로 풀어보려 합니다. 거창한 도구를 산 게 아닙니다. 반복을 기계에 넘기고 사람은 검증으로 올라간 것, 딱 그 변화입니다.
반복 양식 문서를 채우는 AI 업무 자동화의 첫걸음
가장 먼저 손을 댄 건 반복 양식 문서였습니다. 안전 점검표나 평가표처럼, 틀은 똑같고 내용만 바뀌는 문서 말이죠. 이런 건 사실 사람이 할 일이 아니죠. 그런데도 오래 사람 몫이었던 이유는, 한글 문서(hwpx)나 엑셀 같은 국내 업무 양식을 자동으로 다루기가 까다로웠기 때문입니다.
원본 데이터에서 최종 양식까지, 3단계 AI 업무 자동화
흐름은 단순합니다. 원본 데이터를 넣으면, AI가 중간 검증용 형식으로 한 번 정리하고, 그다음 최종 양식으로 떨굽니다. 저는 이걸 세 단계로 나눠 씁니다. 데이터를 그대로 최종 문서로 직행시키지 않는 게 핵심이죠. 중간에 사람이 눈으로 훑을 수 있는 단계를 일부러 끼워 넣거든요.
- 원본 데이터 — 측정값, 점검 결과 같은 날것의 입력
- 중간 검증 — 사람이 읽고 고칠 수 있는 가벼운 형식(마크다운 등)으로 1차 정리
- 최종 포맷 — hwpx·docx·xlsx 등 제출용 양식으로 변환
▲ 원본 데이터 → 중간 검증 → 최종 포맷, 검증 단계를 가운데 끼운 3단계 흐름
이 가운데 단계가 있느냐 없느냐가 신뢰의 분기점입니다. 데이터를 곧장 최종 문서로 만들면, 틀린 값이 들어가도 알아채기 어렵습니다. 하지만 중간에 사람이 읽을 수 있는 형식으로 한 번 펼쳐 두면, 이상한 숫자가 눈에 걸리거든요. 가장 자주 빠뜨리는 게 바로 이 검증 자리입니다.
처음에는 저도 이 중간 단계를 건너뛰고 싶었습니다. 한 번에 최종 문서까지 가면 더 빠르니까요. 그런데 몇 번 데이고 나서 생각이 바뀌었습니다. 자동으로 만든 평가표에 단위가 어긋난 값이 하나 끼어 있었는데, 그게 최종본까지 그대로 흘러간 적이 있거든요. 다행히 제출 전에 잡았지만, 식은땀이 났습니다. 그 뒤로는 중간 검증 단계를 절대 빼지 않습니다.
며칠이 몇 시간으로 — AI 업무 자동화가 바꾼 체감
형식 변환과 대량 처리도 같이 풀렸습니다. docx를 hwpx로 바꿀 때 폰트가 깨지던 문제, 수백 페이지짜리 PDF를 묶으면서 페이지 번호와 목차를 다시 매기던 일. 손으로 하면 반나절씩 잡아먹던 작업이죠. 이걸 규칙으로 박아두니 클릭 한 번에 끝납니다.
체감으로 말하면 이렇습니다. 예전엔 반복 문서 한 묶음에 며칠이 들었습니다. 지금은 검수를 포함해도 몇 시간이면 됩니다. 단순노동이 사라진 자리에 “검수만 하면 되는 일”이 남은 거죠. 일이 줄어든 게 아니라 일의 종류가 바뀐 겁니다. 손을 쓰던 자리에 눈과 판단이 들어왔습니다.
특히 국내 업무에서 발목을 잡던 게 한글 문서였습니다. 보고서는 결국 hwpx로 제출해야 하는데, 이걸 자동으로 다루는 게 쉽지 않았거든요. 폰트가 깨지거나, 표 칸이 어긋나거나, 페이지 번호가 뒤죽박죽이 되기 일쑤였죠. 그런데 그 변환 규칙을 한번 제대로 잡아두니, 그다음부터는 같은 양식이라면 거의 손이 가지 않습니다. 처음 규칙을 세우는 데 들인 며칠이, 그 뒤로 아낀 수십 일을 생각하면 가장 남는 투자였던 셈이죠.
발표자료를 만드는 에이전트 분업, AI 업무 자동화의 두 번째 장면
두 번째 장면은 발표자료입니다. R&D 일을 하다 보면 발표자료 만드는 데 시간이 정말 많이 들어갑니다. 내용보다 정렬에, 색 맞추기에, 폰트 통일에 시간이 새거든요. 슬라이드 50장을 만들면, 50장의 여백을 일일이 손으로 맞췄던 게 솔직한 현실이었습니다.
기획·빌드·검증, 세 역할로 나눈 AI 업무 자동화
제가 쓰는 방식은 발표자료 작업을 세 명의 AI 작업자에게 나눠 맡기는 겁니다. 한 명은 자료를 조사하고 구성을 잡고, 한 명은 그 구성대로 슬라이드를 빌드하고, 마지막 한 명은 결과를 원래 의도와 비교해 검증하죠. 이렇게 역할을 나눠 일하는 AI 작업자를 흔히 AI 에이전트라고 부릅니다. 시키면 여러 단계를 알아서 처리하는, 일종의 디지털 분업 팀인 셈이죠.
▲ 기획 → 빌드 → 검증, 세 에이전트로 역할을 나눈 분업 구조
이 방식의 핵심은 분업 자체가 아닙니다. 디자인 규칙을 한 곳에 못 박아두는 데 있죠. 색, 폰트, 레이아웃을 한 파일에 정의해 두고 모든 슬라이드가 그걸 참조하게 합니다. 그러면 슬라이드마다 손으로 정렬하던 일이 통째로 사라집니다. 사람이 머리로 유지하던 “일관성”을 규칙으로 코드화한 거죠.
한 명이 모든 걸 다 하지 않게 나눈 데에도 이유가 있습니다. 빌드하는 쪽과 검증하는 쪽을 분리하면, 자기가 만든 걸 자기가 채점하는 함정에서 벗어나거든요. 사람도 마찬가지지만, 만든 사람은 오류를 잘 못 봅니다. 그래서 마지막 검증 역할에는 “원래 의도와 비교하라”는 임무만 또렷이 줍니다. 단순한 구조인데, 결과물의 안정성이 확실히 올라갑니다.
비슷한 고민을 AI 도구별로 비교해 본 적도 있는데, 발표자료 자동 생성은 도구마다 강점이 꽤 갈립니다. 직접 써 본 기록은 AI 발표자료 제작 도구를 비교한 글에 정리해 뒀습니다. 어느 단계를 자동화하고 어느 단계를 손에 남길지 가르는 게 결국 관건이더군요.
매번 같은 품질을 보장하는 AI 업무 자동화
이렇게 하면 매번 같은 품질이 나옵니다. 사람은 컨디션에 따라 결과가 흔들리지만, 규칙은 흔들리지 않거든요. 어제 만든 슬라이드와 오늘 만든 슬라이드의 톤이 같습니다. 발표 전날 밤에 여백 맞추느라 밤을 새우는 일도 없어졌죠. 이게 주는, 의외로 큰 안도감입니다.
오해는 마시길 바랍니다. AI가 발표 내용을 대신 생각해 준다는 뜻이 아닙니다. 어떤 메시지를 던질지, 어떤 데이터를 앞세울지는 여전히 제 머릿속에서 나옵니다. AI가 가져간 건 그 메시지를 슬라이드라는 형식에 옮겨 담는 노동이죠. 생각은 사람이, 정렬은 기계가. 이 분담이 자리 잡으니 발표 준비의 무게가 확 가벼워졌습니다.
영문 논문을 한글로 재조판하는 AI 업무 자동화
세 번째는 영문 논문입니다. 발전·에너지 R&D에서 영어 논문은 일상이죠. 새 기술을 좇으려면 결국 원문을 봐야 하거든요. 그런데 영어로 읽는 것과, 읽고 정리해서 동료와 나누는 것은 전혀 다른 노동입니다. 후자가 훨씬 무겁죠.
그림과 수식 위치를 지키는 AI 업무 자동화
그래서 영문 논문 PDF를 한글 PDF로 재조판하는 흐름을 만들었습니다. 단순 번역이 아닙니다. 읽기 순서, 그림 위치, 수식 자리를 원본 그대로 보존한 채로 본문만 한국어로 바꾸는 거죠. 번역기 돌려서 텍스트만 뽑으면 그림과 수식이 다 흩어지는데, 그걸 막는 게 이 작업의 까다로운 부분입니다.
여기서 빠지면 안 되는 게 용어집입니다. 같은 단어를 누구는 “효율”, 누구는 “능률”로 옮기면 문서가 엉망이 되거든요. 발전 분야는 용어 하나하나가 의미가 정해져 있어서, 표기가 흔들리면 동료가 글을 신뢰하지 않습니다. 그래서 전문용어집을 단일 기준으로 박아두고 모든 번역이 그걸 참조하게 했습니다. 사람이 매번 기억해서 맞추던 일을 규칙으로 옮긴 거죠.
검토 게이트를 남겨 둔 AI 업무 자동화
중요한 건 여기에도 사람 검토 게이트를 두 군데 박아뒀다는 점입니다. 한 번은 구조가 제대로 잡혔는지 확인하고, 한 번은 최종본을 원문과 대조하죠. 자동화하되 판단은 사람이 한다는 원칙이 가장 잘 드러나는 사례입니다. 논문을 잘못 이해한 채 그럴듯하게 번역해 두면, 그게 더 위험하거든요.
결과만 보면 번역과 정리에 들던 시간이 크게 줄었습니다. 게다가 한번 재조판해 두면 그대로 아카이빙까지 됩니다. 읽고, 정리하고, 보관하는 세 가지가 한 흐름으로 묶인 거죠. 예전엔 논문 하나 제대로 정리하는 데 반나절을 썼는데, 지금은 검토 시간만 남았습니다.
덤으로 생긴 변화가 하나 더 있습니다. 예전엔 영어가 부담스러워서 미뤄두던 논문이 책상에 쌓였거든요. 정리하는 데 시간이 걸린다는 걸 아니까, 자꾸 뒤로 미뤘죠. 그런데 정리 부담이 줄어드니 손이 더 자주 갑니다. 더 많이 읽게 됐다는 게 어쩌면 시간 단축보다 큰 변화일지도 모르겠습니다. 결국 연구자가 더 많이 읽는다는 건, 그 자체로 일의 질이 올라간다는 뜻이니까요.
AI를 도구에 연결하는 MCP, AI 업무 자동화의 토대
여기까지 읽으면 한 가지 의문이 들 겁니다. AI는 채팅창 안에만 있는데, 어떻게 한글 문서를 만들고 PDF를 묶느냐는 거죠. 답은 연결에 있죠. AI를 실제 도구에 붙여주는 규격이 따로 있거든요.
콘센트 규격 같은 MCP가 여는 AI 업무 자동화
이 연결 규격을 MCP라고 부릅니다. AI를 외부 도구와 데이터에 이어주는 표준이죠. 콘센트 규격을 떠올리면 쉽습니다. 규격만 맞으면 어떤 기기든 꽂아 쓸 수 있듯, MCP를 통해 AI에 한글 문서 도구, 브라우저 자동화, 파일 작업 도구를 붙입니다. 표준이 궁금하면 Model Context Protocol 공식 문서에 규격이 공개돼 있습니다. AI 업무 자동화가 채팅을 넘어 실제 일로 내려오는 다리가 바로 이겁니다.
저는 환경을 셋으로 나눠 씁니다. 가벼운 질문은 웹, 복잡한 작업은 데스크톱 앱, 로컬 파일을 다루거나 코드를 실행할 일은 명령줄 도구(CLI)로. 용도가 다르면 도구도 다른 게 맞거든요. 한 곳에서 다 하려다 오히려 느려지는 경우가 많습니다.
도구가 모여 작업대가 되는 AI 업무 자동화
여기에 화면 분할, OCR, 파일명 일괄 변경 같은 생산성 도구를 곁들이면, “AI + 도구”가 하나의 작업대가 됩니다. AI가 머리라면 MCP로 연결한 도구들이 손발인 셈이죠. 이 토대를 깔아두는 게 처음엔 번거롭지만, 한번 깔면 나머지 사례들이 그 위에서 굴러갑니다.
솔직히 이 연결 작업이 제일 진입 장벽이 높았습니다. 문서 자동화나 번역은 결과가 바로 눈에 보이는데, 도구를 연결하는 일은 한참 만져야 첫 결과가 나오거든요. 며칠을 끙끙댄 날도 있었습니다. 그래도 권하고 싶은 이유는, 이 단계를 넘기면 AI가 채팅 상대에서 실제 동료로 바뀌기 때문입니다. 말로만 답하던 AI가 파일을 만들고 브라우저를 띄우기 시작하면, 체감이 완전히 달라집니다.
이런 도구를 직접 묶어 쓰는 환경을 어떻게 만드는지, 그 입문 과정은 클로드 스킬 개념과 등록 방법을 정리한 글에서 좀 더 풀어 뒀습니다. Python을 모르는 엔지니어도 시작할 수 있는 수준에서 출발하면 됩니다. 제가 그랬으니까요.
일하는 방식이 바뀐다 — AI 업무 자동화가 남긴 것
네 가지 사례를 늘어놨지만, 제가 진짜 하고 싶은 말은 따로 있습니다. AI가 제 일을 “대신”해 준 게 아니라는 겁니다. AI 업무 자동화의 본질은 대체가 아니라 재편이죠. 반복은 기계로 내려가고, 사람은 설계와 검증과 판단으로 올라갑니다. 일의 무게중심이 통째로 이동한 셈입니다.
사람의 몫이 더 또렷해지는 AI 업무 자동화
흥미로운 건, 자동화를 깊이 할수록 사람이 할 일이 더 또렷해진다는 점입니다. 서식 채우기에서 풀려나니, “이 데이터가 맞는가, 이 판단이 옳은가”라는 질문에 시간을 쓰게 되거든요. 현장에서 10년 넘게 일하면서 늘 부족하다고 느낀 게 바로 그 시간이었습니다. 손이 비니 비로소 생각할 여유가 생겼습니다.
물론 공짜는 아닙니다. 검증은 여전히 사람 몫이거든요. AI는 그럴듯하게 틀리는 데 능숙합니다. 틀린 숫자도 자신 있게 써 내려가죠. 그래서 제 자동화 흐름 곳곳에는 사람 검토 게이트가 박혀 있습니다. 자동화의 끝에 사람의 눈을 남겨두지 않으면, 빠른 만큼 빠르게 틀립니다.
그래서 저는 “AI에게 맡긴다”는 말을 좋아하지 않습니다. 맡긴다기보다 같이 일한다는 쪽이 정확하거든요. 반복은 AI가 빠르게 처리하고, 그 결과가 맞는지는 제가 봅니다. 발전 설비를 다룰 때 계측값 하나도 두 번 확인하는 습관이 있는데, 자동화에도 같은 습관을 그대로 들고 왔습니다. 도구가 바뀌어도 엔지니어의 기본 자세는 안 바뀌더군요.
그래서 시작점은 늘 같습니다. 가장 자주, 가장 똑같이 반복하는 일을 하나 고르는 것. 거기서 출발하면 되죠. 거창한 시스템부터 그리지 말고, 손이 제일 아픈 한 가지를 먼저 기계에 넘겨보세요. 그 한 가지가 풀리면, 나머지는 의외로 따라옵니다.
저도 처음부터 네 가지를 다 만든 건 아닙니다. 반복 문서 하나를 자동화해 보고, 그게 통하니까 욕심이 생겨 발표자료로, 다시 논문으로 넓혔거든요. 한 번 효과를 체감하면 그다음은 자연스럽게 손이 갑니다. 거꾸로 처음부터 모든 걸 한꺼번에 바꾸려 들면, 대개 시작도 못 하고 지칩니다. 작게 시작해서 효과를 눈으로 확인하는 것, 그게 제가 권하는 유일한 순서입니다.
□ 가장 자주·똑같이 반복하는 문서 작업 한 가지를 먼저 고른다
□ 원본 데이터에서 최종 양식으로 직행시키지 말고, 중간 검증 단계를 끼운다
□ 색·폰트·용어 같은 규칙은 한 곳에 모아 단일 기준으로 박아둔다
□ 작업이 여러 단계면 기획·빌드·검증으로 역할을 나눠 맡긴다
□ AI를 채팅창에만 두지 말고 MCP로 실제 도구에 연결한다
□ 용도별로 환경을 나눈다 (가벼운 건 웹, 로컬 파일·코드 실행은 CLI)
□ 자동화 흐름 끝과 중간에 반드시 사람 검토 게이트를 남긴다
□ 마지막 검증은 사람의 몫임을 잊지 않는다 — AI는 자신 있게 틀린다
일하는 방식이 바뀐다는 말은 추상이 아닙니다. 며칠이 몇 시간이 되고, 손이 비고, 그 빈손에 판단이 들어찹니다. 제 분야인 발전·에너지 연구에서 그 변화를 직접 겪고 보니, 결국 남는 질문은 하나더군요. 기계에 넘길 수 있는 일에 나는 아직도 며칠을 쓰고 있지 않은가. 거기서부터 다시 시작하면 됩니다.