무엇을 넘기고 무엇을 남길 것인가
자동화를 시작할 때 가장 흔한 실수는 «전부 자동으로»를 목표로 잡는 것이다. 그러면 대개 마지막 5퍼센트에서 무너지고, 무너진 자리를 수습하는 데 아낀 시간보다 더 든다.
실제로 해 보면 일은 두 종류로 갈린다. 틀렸을 때 되돌릴 수 있는 것과 되돌릴 수 없는 것이다. 원고를 잘못 만들었으면 다시 만들면 된다. 그런데 잘못된 글이 사내 게시판에 «등록»되면 이미 여러 사람의 알림에 떴다. 지운다고 안 본 것이 되지 않는다.
그래서 기준을 이렇게 잡았다. 되돌릴 수 있는 일은 전부 기계에, 되돌릴 수 없는 마지막 한 번은 사람에게. 이 한 줄이 파이프라인 전체의 모양을 정했다.
«자동화율 100퍼센트»가 목표가 아니라 «손이 가는 시간을 줄이는 것»이 목표다. 등록 버튼 한 번은 3초다. 원고를 쓰고 서식을 맞추고 붙여 넣는 40분과 바꾸는 3초라면, 그 3초는 남겨 두는 편이 이득이다.
파이프라인 6단계
전체는 여섯 단계다. 앞의 다섯은 사람이 안 보고 있어도 돌고, 마지막 하나만 사람을 기다린다.
중요한 것은 순서가 아니라 단계 사이에 «검사»가 들어간다는 것이다. 각 단계는 다음 단계로 넘어가도 되는 조건을 갖고 있고, 그 조건이 안 서면 거기서 멈춘다. 멈추지 않고 계속 가면 «틀린 것이 완성돼서» 나간다. 그게 가장 비싼 실패다.
1단계 — 재료는 «쓰는 순간»에 모인다
업무일지 자동화를 처음 시도하면 대개 «오늘 뭐 했지»에서 막힌다. 기억을 더듬어 쓰는 일을 기계가 대신할 수는 없다. 자동화의 시작은 글쓰기가 아니라 재료 적재다.
그래서 순서를 뒤집었다. 일을 하는 동안 그때그때 한 줄씩 남기고, 저녁에 그 줄들을 모아 원고를 만든다. 남기는 형식은 거창할 필요가 없다. 날짜, 무슨 일, 어디까지 갔는지, 막힌 것 — 네 가지면 원고가 나온다.
2026-08-31 10:20 | 견적 검토 | 3건 중 2건 회신 | 남은 1건은 도면 대기 2026-08-31 14:05 | 자료 정리 | 폴더 재분류 완료 | - 2026-08-31 16:40 | 회의 | 일정 조정 합의 | 다음 주 재확인 필요
이 정도만 있어도 «오늘 한 일 / 진행 중 / 다음에 할 일»로 갈라 쓸 수 있다. 반대로 이게 없으면 아무리 좋은 도구를 붙여도 첫 단계에서 멈춘다.
로그를 «나중에 몰아서» 적으면 결국 안 적게 된다. 이건 의지 문제가 아니라 구조 문제라, 적는 자리를 일하는 자리 «안»에 두는 것으로만 풀렸다. 별도 앱을 하나 더 열어야 하면 그 순간 끊긴다.
2단계 — 서식이 회차마다 같아야 하는 이유
원고 생성은 생각보다 쉬운 축에 든다. 재료가 있으면 정해진 틀에 넣는 일이기 때문이다. 어려운 것은 «같은 모양»을 유지하는 것이다.
회차마다 강조색이 달라지거나 제목 단계가 뒤바뀌면, 읽는 사람은 «누가 대충 썼다»고 느낀다. 내용이 같아도 그렇다. 그래서 서식은 코드가 아니라 규격 문서로 따로 빼 두고, 원고 생성기가 그걸 참조하게 했다.
여기서 한 번 크게 데었다. 틀을 복사해서 새 회차를 만들었더니 앞 회차의 내용이 일부 남아 있었다. 글자 수는 정상 범위라 검사도 통과했다. 발견은 «평소보다 분량이 크다»는 것에서 시작됐다. 두 편이 합쳐져 있었던 것이다.
«최소 분량»만 재면 이런 사고를 못 잡는다. 절마다 «각 1회»가 들어갔는지를 같이 세야 한다. 그리고 평소보다 «큰» 값도 신호로 봐야 한다. 작은 쪽만 의심하면 절반만 보는 것이다.
3단계 — 세션, 대부분 여기서 멈춘다
사내 시스템은 대개 로그인 뒤에야 글쓰기 화면이 열린다. 그리고 그 로그인은 자동화가 가장 건드리기 어려운 자리다.
이유는 기술이 아니라 정책이다. 계정 정보를 스크립트에 넣는 순간 그 스크립트는 «자격증명을 들고 있는 파일»이 된다. 백업에 섞이고, 실수로 공유되고, 로그에 찍힌다. 자동화 하나 만들려다 보안 사고를 만드는 셈이다.
그래서 로그인은 사람이 한다로 정했다. 사람이 평소처럼 브라우저에서 로그인해 두면, 자동화는 그 «이미 열려 있는 창»에 붙어서 일한다. 계정 정보를 어디에도 저장하지 않는다.
이 구조는 «자동화가 혼자 밤에 도는 것»을 포기하는 대신, 사람이 컴퓨터를 켜 둔 시간 안에서만 돈다. 처음에는 손해처럼 보였는데, 실제로는 밤에 혼자 돌다가 조용히 실패해 아침에 발견하는 일이 없어져 더 나았다.
세션에는 유효기간이 있다는 것도 같이 기억해야 한다. 긴 작업 중에 만료되면 그때부터 하는 모든 요청이 «성공»처럼 보이는 로그인 페이지를 받는다. 응답이 200이라고 성공이 아니다.
4단계 — 편집기가 진짜 관문이다
여기가 실제로 가장 오래 걸린 단계다. 게시판의 본문 입력창은 그냥 텍스트 상자가 아니라 자체 편집기인 경우가 많다. 그리고 편집기마다 «글자를 받는 법»이 다르다.
겪은 것을 정리하면 이렇다.
- 한 글자씩 타이핑하는 방식은 글자를 흘린다. 긴 본문을 넣으면 중간이 빠지거나 공백·문장부호가 사라진다. 길이를 세어 보기 전에는 눈치채기 어렵다.
- 값을 직접 대입하면 편집기가 모르는 채로 지나간다. 화면에는 글자가 보이는데 저장하면 빈 글이 된다. 편집기 내부 상태가 안 바뀐 것이다.
- 붙여넣기 이벤트를 만들어 보내는 방식이 가장 잘 통했다. 편집기가 «사람이 붙여 넣었다»고 인식해서 줄바꿈과 서식까지 살아 있는 채로 들어간다.
- 편집기가 서식을 자기 방식으로 바꿔 놓기도 한다. 색 표기를 다른 형식으로 저장하는 식이다. 넣은 그대로 남아 있을 거라고 가정하면 안 된다.
운영체제의 클립보드는 모든 창이 하나를 공유한다. 자동화가 클립보드를 쓰는 동안 다른 창에서 무엇을 복사하면 그게 섞여 들어간다. 실제로 한 창에서 복사한 내용이 전혀 다른 창의 본문에 붙은 적이 있다. 붙여넣기 «이벤트»를 합성해서 보내면 클립보드를 아예 안 거치므로 이 문제가 사라진다.
편집기와 씨름하다 보면 «왜 이렇게까지 해야 하나» 싶어진다. 그런데 이 단계가 자동화의 값어치가 실제로 나오는 자리다. 앞뒤는 몇 초씩이지만, 사람이 본문을 서식 맞춰 옮겨 넣는 일은 회차마다 십 분 넘게 걸린다.
브라우저 자동화에서 걸리는 자리를 더 넓게 정리한 글은 브라우저 자동화가 막히는 자리 8곳에 따로 두었다. 이 글에서는 게시판 등록에 걸리는 것만 다룬다.
5단계 — 첨부와 이미지
본문이 들어가면 대개 첨부가 남는다. 여기에도 함정이 하나 있다. 파일 선택 대화상자는 자동화가 건드릴 수 없는 경우가 많다. 운영체제가 띄우는 창이라 브라우저 바깥이기 때문이다.
대신 페이지 안의 파일 입력 요소에 파일을 «직접 얹는» 방법이 통한다. 대화상자를 아예 안 여는 것이다. 편집기 안에 이미지를 넣어야 한다면 본문 영역에 놓아 주는 방식도 쓰인다.
다만 이미지가 들어간 뒤 본문을 다시 조립하면 앞서 넣은 이미지가 통째로 날아간다. 순서가 정해져 있다는 뜻이다. 먼저 이미지를 넣고, 그다음에 글을 배치한다. 반대로 하면 처음부터 다시다.
넣은 직후 화면에 보이는 것으로 판단하지 않는다. 편집기를 닫았다가 다시 열어서 그대로 남아 있는지 본다. 자동 저장이 도는 편집기라면 «저장됨» 표시도 증거가 못 된다.
6단계 — 등록 직전에서 멈춘다
여기서 파이프라인은 손을 뗀다. 제목이 들어갔고, 본문이 들어갔고, 첨부가 붙었고, 분류가 선택된 상태로 화면을 남긴다. 사람은 화면을 훑고 등록을 누른다.
«그냥 눌러 주면 안 되나»라는 생각이 당연히 든다. 안 누르기로 한 이유는 세 가지다.
- 되돌릴 수 없다. 사내 게시판 글은 등록 순간 알림이 나간다. 잘못 나가면 지우는 것으로 해결되지 않는다.
- 내용의 책임은 사람에게 있다. 자동으로 만든 원고라도 올린 사람 이름으로 나간다. 한 번 읽고 누르는 것이 그 이름값이다.
- 버튼 라벨이 무엇을 하는지 모를 때가 있다. 「다음」처럼 생긴 버튼이 실제로는 게시인 경우를 겪었다. 라벨로 안전을 판단하면 안 된다.
실제로 이 자리에서 잡아낸 것이 여러 번이다. 원고 자체는 검사를 통과했는데, 사람이 보고 «이 내용은 아직 밖에 나가면 안 된다»고 판단한 경우가 대부분이었다. 그건 어떤 검사기도 못 잡는다.
«올라갔다»를 무엇으로 판정하나
자동화에서 가장 비싼 실패는 «안 됐는데 됐다고 판정하는 것»이다. 그러면 다음 회차가 그 위에 쌓이고, 발견은 한참 뒤에 된다.
그래서 판정 규칙을 따로 세웠다. 요지는 «화면이 어떻게 보이는가»가 아니라 «되돌릴 수 없는 수치가 변했는가»를 본다는 것이다.
- 작성창이 사라졌다 = 성공이 아니다. 실패해도 닫힐 수 있고, 성공해도 남을 수 있다.
- 성공 메시지도 증거가 아니다. 화면 문구는 서버 상태와 별개로 뜰 수 있다.
- 목록에서 글이 늘었는지를 센다. 등록 전후로 게시물 수를 재는 것이 가장 단단하다.
- 목록이 안 보이면 «없다»고 하지 않는다. 살아 있는 글 하나를 대조군으로 같이 찾아본다. 둘 다 안 보이면 그건 결과가 아니라 측정 실패다.
마지막 줄이 특히 중요하다. 시스템에 따라서는 없는 주소에도 정상 응답을 돌려주는 경우가 있다. 응답 코드만 보고 «있다»고 판정하면 계속 틀린다. 그럴 때는 제목이나 크기 같은 내용으로 판정해야 한다.
들인 시간과 돌아온 시간
정직하게 적으면, 이 파이프라인을 세우는 데는 여러 날이 들었다. 그중 절반 이상이 4단계 하나에 들어갔다.
돌아온 것은 회차당 시간이다. 원고를 쓰고 서식을 맞추고 옮겨 넣는 데 걸리던 시간이 확인하고 누르는 몇 분으로 줄었다. 매일 도는 일이라 이 차이는 한 달이면 회수된다.
다만 더 큰 이득은 다른 데 있었다. 서식이 회차마다 같아졌다는 것이다. 사람이 매번 손으로 맞출 때는 회차마다 조금씩 달랐다. 기계가 하니 같다. 읽는 쪽에서 보면 이쪽이 더 크게 느껴지는 변화였다.
편집기 자동화부터 손대지 않는 편이 낫다. 1단계 로그 적재만 세워도 원고 쓰는 시간이 눈에 띄게 줄고, 그게 없으면 나머지를 아무리 잘 만들어도 안 돈다. 자동화의 병목은 대개 마지막이 아니라 첫 칸에 있다.
자주 묻는 질문
계정 정보를 스크립트에 넣지 않고 어떻게 로그인된 화면에서 작업하나요?
사람이 평소처럼 브라우저에서 로그인해 둔 상태의 창에 자동화가 붙는 방식입니다. 자동화가 로그인을 «하는» 것이 아니라, 이미 로그인된 창을 «쓰는» 것입니다. 계정 정보를 어디에도 저장하지 않아도 되고, 회사의 접근 정책과도 부딪히지 않습니다.
본문이 중간에 잘리거나 글자가 빠지는데 왜 그런가요?
한 글자씩 입력하는 방식이면 편집기가 따라오지 못해 흘리는 경우가 많습니다. 붙여넣기 이벤트를 만들어 한 번에 보내는 쪽이 안정적입니다. 그리고 넣은 뒤에는 반드시 글자 수를 세어 원고와 맞는지 확인하세요. 눈으로는 잘 안 보입니다.
등록까지 완전 자동으로 하면 안 되나요?
기술적으로는 됩니다. 다만 되돌릴 수 없는 동작이라 권하지 않습니다. 특히 버튼 라벨이 실제 동작과 다른 경우가 있어서, 라벨만 보고 안전하다고 판단하기 어렵습니다. 확인하고 누르는 데 드는 몇 초와 잘못 나간 글을 수습하는 비용을 견줘 보면 답이 나옵니다.
자동 저장이 되니까 저장은 신경 안 써도 되지 않나요?
자동 저장 표시는 «편집기가 저장을 시도했다»는 뜻이지 «서버에 그 내용이 그대로 있다»는 보증이 아닙니다. 확인하려면 편집기를 닫았다가 새로 열어 내용이 남아 있는지 보는 편이 확실합니다.
어디부터 시작하는 게 좋나요?
작업 로그를 남기는 것부터입니다. 날짜, 무슨 일, 어디까지, 막힌 것 네 가지면 충분합니다. 재료가 없으면 원고 생성이 아예 안 되고, 재료가 있으면 나머지는 단계마다 하나씩 붙여 나갈 수 있습니다.
정리
매일 도는 일을 자동화할 때 실제로 정해야 하는 것은 도구가 아니라 경계였다. 되돌릴 수 있는 일과 없는 일을 가르고, 없는 쪽 하나만 사람에게 남긴다. 그 한 줄이 서면 나머지는 단계마다 붙여 나가면 된다.
그리고 자동화가 무너지는 자리는 대개 «기능이 없어서»가 아니라 «됐다고 잘못 판정해서»였다. 무엇을 근거로 끝났다고 말할 것인지를 먼저 정하는 편이, 어떤 도구를 쓸지 고르는 것보다 훨씬 오래 간다.
