sgkstudio.
엔지니어링

브라우저 자동화 표 삽입 실패, 원인은 클릭 순서였다

브라우저 자동화 표 삽입 실패의 진짜 원인은 화면이 아니라 명령을 쪼개어 보내는 방식에 있었습니다. 저희는 네이버 블로그에 글을 자동으로 올리는 프로그램으로 표가 든 글을 발행하다가, 마크다운 표가 편집창에서 표로 바뀌지 않고 텍스트 그대로 남는 일을 반복해서 만났습니다. 화면 좌표를 다시 재고 클릭 위치를 몇 번이나 고쳐도 결과는 같았습니다. 원인을 찾고 보니 문제는 좌표가 아니라, 마우스와 키보드를 흉내 내는 명령 하나하나가 서로 완전히 독립된 프로그램 실행이라는 점이었습니다 — 키를 누른 채 유지해야 하는 동작이 명령과 명령 사이에서 풀려 버리고 있었습니다.

2026-09-04네이버 블로그 자동 발행 표 변환 결함 조사 — 2026년 6월 15일 발견, 그날 함께 나온 결함 3건 중 세 번째가 표 변환 실패여러 줄 선택 실패 원인 확인 — 명령을 한 줄씩 나눠 반복 실행할 때와 한 번에 묶어 실행할 때의 결과 대조행 추가 버튼 활성화 조건 확인 — 좌표 클릭·오른쪽 버튼 메뉴·호버 후 더블클릭 세 가지 시도 비교, 2026년 6월 23일 해결 확정

증상: 표만 유독 텍스트로 남았다

글을 올리는 자동화 프로그램은 제목과 본문을 채우고, 글씨체를 지정하고, 소제목 서식을 입히는 일까지는 문제없이 해냈습니다. 문제는 표에서만 났습니다. 줄마다 세로줄 기호로 칸을 나눈 마크다운 표기를 편집창에 붙여 넣고 표 버튼을 눌러 진짜 표로 바꾸려 하면, 화면에는 표가 아니라 세로줄 기호가 그대로 남은 텍스트 뭉치만 보였습니다.

이 프로그램은 화면 속 정확한 위치, 즉 가로세로 좌표를 계산해 그 지점을 누르는 방식으로 동작했습니다. 좌표가 어긋나지 않도록 매번 브라우저 창을 같은 크기(1900x1040)로 고정해 두고, 그 안에서 좌표를 정했습니다. 그런데 창 크기를 고정하고 좌표를 다시 재도 표만은 계속 텍스트로 남았습니다.

표가 들어간 글은 비교표나 체크리스트처럼 정보를 정리해서 보여줘야 하는 글에서 자주 씁니다. 완성된 글의 조건에는 마크다운 표를 진짜 표로 바꾸는 것이 처음부터 들어 있었고, 표 하나가 텍스트로 남으면 그 글 전체를 손으로 다시 다듬어야 했습니다. 어떤 글에 표가 들어갈지는 미리 정해지지 않으니, 표 변환이 안정적으로 되는지는 매일 발행이 돌아가는 데 걸린 전제였습니다.

2026년 6월 15일 발행에서는 결함이 한꺼번에 셋 나왔습니다. 1번은 제목이 본문과 다른 글씨체로 나간 것, 2번은 이전 글로 이어지는 링크가 통째로 빠진 것, 그리고 3번째가 지금 이 글에서 다루는 표였습니다. 앞의 둘은 손볼 자리가 분명했지만, 표는 몇 번을 다시 시도해도 같은 자리에서 막혔습니다.

2026년 6월 15일 발행에서 함께 발견된 결함 3건 표. 1번 제목 글씨체 오류(제목 칸), 2번 이전 글 링크 누락(글 끝), 3번 마크다운 표가 텍스트로 남음(표 자리)
같은 날 발견된 세 결함 중 표만 원인이 다른 층에 있었다

왜 자동화 도구가 표를 못 알아볼까?

처음 의심한 것은 편집창 자체였습니다. 화면을 만든 쪽에서 사람이 아닌 프로그램이 보내는 입력을 걸러 낸다고 짐작했습니다. 마우스 클릭과 키 입력을 흉내 내는 도구가 아무리 좌표를 정확히 맞춰도, 편집창이 사람 손이 아니라고 판단해 표로 바꾸는 동작만 골라 무시하는 것처럼 보였습니다.

근거도 있었습니다. 표를 만들려면 마크다운 표의 여러 줄을 한꺼번에 선택해서 지우고, 빈 자리에 표 버튼을 눌러 기본 표를 새로 넣은 다음, 필요한 만큼 행을 늘려야 합니다. 이 중 여러 줄을 한꺼번에 선택하는 동작과 행을 늘리는 동작, 둘 다 유독 안 먹혔습니다. 클릭 한 번으로 끝나는 단순한 동작은 다 되는데, 무언가를 누른 채로 유지해야 하는 동작만 골라 실패하는 패턴이 처음의 의심을 더 굳혔습니다.

표 하나를 완성하는 데 필요한 절차 자체가 다른 서식보다 훨씬 길다는 점도 의심을 부추겼습니다. 글씨체를 바꾸는 데는 클릭 두 번이면 충분했지만, 표는 마크다운 줄을 전부 지우고, 빈 자리에 새 표를 넣고, 부족한 행을 늘리고, 칸마다 글자를 채우는 네 단계를 거쳐야 완성됐습니다. 단계가 많을수록 그중 하나가 조용히 실패해도 알아채기 어려웠고, 실제로 문제는 이 네 단계 중 두 번째와 세 번째에 몰려 있었습니다.

원인을 어떻게 좁혀 갔나

편집창이 정말 자동 입력을 가려내는지 확인하려면, 자동화 도구가 화면에 실제로 무엇을 보내고 있는지부터 봐야 했습니다. 명령을 하나씩 실행할 때마다 나오는 결과값을 그대로 찍어 확인하는 방법을 썼습니다.

줄 하나를 클릭해 선택하는 명령은 파란색 강조 표시가 그대로 나와 성공을 바로 확인할 수 있었습니다. 문제는 여러 줄을 누른 채로 선택하는 동작이었습니다. 키를 누르고 있는 상태에서 아래 방향키를 여러 번 눌러 범위를 넓히는 방식으로 짰는데, 이 명령을 한 줄씩 나눠 반복 실행하면 매번 아무것도 선택되지 않은 채로 끝났습니다. 한 번은 되고 두 번째부터 안 되는 게 아니라, 처음부터 한 줄도 선택되지 않았습니다.

행을 늘리는 버튼도 같은 방식으로 확인했습니다. 화면을 다시 찍어 좌표를 재고 정확히 클릭해도 반응이 없었고, 마우스 오른쪽 버튼으로 메뉴를 띄워 봐도 표 편집과는 상관없는 브라우저 기본 메뉴(잘라내기·복사·붙여넣기)만 나왔습니다.

좌표 자체가 틀렸을 가능성도 그때마다 확인했습니다. 화면을 다시 찍어 확대해 보고, 찍은 화면 속 위치를 실제 화면 좌표로 환산해 눌러야 할 지점과 겹치는지 대조했습니다. 좌표는 매번 정확했습니다. 이 대조를 반복하면서 의심의 방향이 좌표에서 다른 곳으로 옮겨 가기 시작했습니다.

알리바이: 편집창은 자동 입력을 막지 않았다

편집창이 자동 입력 자체를 막는다는 의심에는 알리바이가 있었습니다. 제목과 본문을 채우는 붙여넣기, 글씨체를 지정하는 클릭, 소제목 서식을 입히는 클릭은 전부 자동화 도구로 문제없이 됐습니다. 편집창이 자동 입력을 가려낸다면 이 동작들도 실패해야 했는데, 실패하지 않았습니다.

실패하는 동작에는 공통점이 있었습니다. 전부 누른 상태를 유지해야 하는 동작이거나, 마우스가 가까이 다가가야 반응하는 동작이었습니다. 반대로 성공한 동작은 전부 클릭 한 번이나 붙여넣기 한 번으로 끝나는 동작이었습니다. 편집창이 자동 입력 자체를 가려낸다면 이렇게 정확히 갈릴 이유가 없었습니다 — 편집창은 누가 입력을 보내는지가 아니라, 입력이 어떤 모양으로 들어오는지에만 반응하고 있었습니다. 이 갈림이 진짜 원인으로 이어지는 단서였습니다.

진짜 원인 — 명령마다 새 프로그램이 켜지고 있었다

자동화 도구는 명령 하나를 실행할 때마다 화면을 조작하는 프로그램을 새로 켜는 방식으로 짜여 있었습니다. 키를 누른 채 아래로 이동하는 동작을 한 줄씩 나눠 반복 실행하면, 각 실행이 서로 다른 프로그램이라 이전 실행에서 누르고 있던 키는 그 프로그램이 끝나는 순간 함께 풀렸습니다. 다음 실행은 아무것도 눌리지 않은 상태에서 다시 시작했습니다. 좌표도, 화면도, 편집창의 판단도 문제가 아니었습니다. 문제는 누른 상태라는 정보가 프로그램과 프로그램 사이를 넘어가지 못한다는 점이었습니다. 겉으로는 자동화 도구가 하나로 이어서 움직이는 것처럼 보였지만, 실제로는 명령 하나마다 처음부터 새로 켜지고 곧바로 꺼지는 프로그램의 연속이었습니다.

행 추가 버튼도 원인은 다르지만 뿌리는 같았습니다. 이 버튼은 마우스가 다가오는 움직임을 감지해야 활성화되면서 초록색으로 바뀌었는데, 좌표로 한 번에 이동해 클릭만 보내는 명령은 다가오는 움직임 자체를 건너뛰고 목표 지점에 곧바로 나타났습니다. 화면으로 보기에는 버튼 위에 마우스가 있어도, 그 버튼은 다가오는 움직임을 보지 못했으니 활성화되지 않았고, 활성화되지 않은 버튼을 누른 클릭은 그대로 무시됐습니다.

고친 방법 — 여러 줄 선택을 한 프로그램 안에 묶었다

해법은 좌표를 더 정확히 맞추는 게 아니라, 여러 단계로 쪼개져 있던 동작을 프로그램 하나가 처음부터 끝까지 처리하도록 묶는 것이었습니다. 줄 하나를 선택하는 동작은 세 번 클릭을 한 번에 처리하는 명령으로 바꿨습니다. 여러 줄을 선택하는 동작은 키를 누르고, 아래로 여러 번 이동하고, 끝으로 가고, 키를 떼는 과정 전부를 프로그램 하나가 처리하는 명령으로 바꿨습니다.

표 칸에 글자를 채우는 동작도 클립보드에 얹고 붙여넣는 과정을 한 번에 처리하는 명령으로 바꿨습니다. 원래는 글자를 클립보드에 담는 동작과 붙여넣는 동작을 따로 실행했는데, 태그를 여러 개 연달아 채우다 보면 앞서 담아 둔 글자가 뒤이은 다른 명령에 덮여 첫 번째 것만 들어가고 나머지는 사라지는 경합이 났습니다. 담기와 붙여넣기를 한 프로그램 실행 안에 묶자 이 경합도 함께 없어졌습니다.

표 자리를 만드는 절차도 함께 다시 짰습니다. 마크다운 표의 첫 줄을 세 번 클릭으로 통째로 선택한 뒤 지우고, 남은 빈 줄까지 한 번 더 지워 다음 줄을 그 자리로 끌어올리는 동작을 표의 줄 수만큼 반복했습니다. 칸을 나누는 구분선 줄도 같은 방식으로 지웠고, 표가 있던 자리에는 빈 줄 하나만 남겼습니다. 그 빈 줄에 커서를 두고 표 버튼을 누르면 기본 크기 표가 즉시 만들어졌고, 필요한 나머지 행은 이 뒤에 늘렸습니다.

여러 줄 선택과 표 칸 채우기 시도 비교 표. 키를 누른 채 반복 실행은 매번 선택 실패, 세 번 클릭으로 줄 선택 성공, 누르기·이동·떼기를 한 번에 처리해 여러 줄 선택 성공, 클립보드 얹고 붙여넣기를 한 번에 처리해 표 칸 채우기 성공
쪼개서 반복하면 실패하고, 한 프로그램 실행 안에 묶으면 성공했다

고친 방법 — 행 추가 버튼은 다가가는 움직임부터 만들었다

행 추가 버튼은 다른 방식으로 풀었습니다. 마우스를 목표 지점 근처로 먼저 옮긴 뒤 버튼 쪽으로 천천히 이동시켜, 편집창이 다가오는 움직임을 실제로 보게 만들었습니다. 버튼이 초록색으로 바뀌는 걸 확인한 다음에야 두 번 클릭을 보냈고, 그제야 행이 늘었습니다.

표 칸을 채우면서는 부작용도 하나 새로 찾았습니다. 칸에 글자를 채울 때마다 행 높이가 아주 조금씩 늘어나면서, 처음 재 둔 좌표 6개 중 아래쪽 것들이 점점 표 바깥으로 밀려났습니다. 좌표가 밀린 채로 마지막 몇 칸을 클릭하면 표 바깥, 즉 본문 문장 한가운데를 찍어 글자가 그 자리에 그대로 끼어들었습니다. 첫 줄만 채운 뒤 좌표를 다시 재고, 1~2행마다 좌표를 다시 재는 방식으로 이 밀림을 막았습니다. 이미 본문으로 새 들어간 경우에는 마지막에 넣은 것부터 거꾸로 되돌리기 명령을 하나씩 반복해 본문을 원래대로 되돌린 뒤, 좌표를 다시 재서 빈 칸을 채웠습니다.

같은 실수를 막는 장치

이번 문제로 남긴 규칙은 하나입니다. 이 자동화 도구가 지원하는 명령은 열 가지(클릭, 더블클릭, 세 번 클릭, 구간 선택 클릭, 키 입력, 키 누르기, 키 떼기, 누른 채 이동, 붙여넣기, 타이핑)였는데, 이 중 누른 상태를 유지해야 하는 동작과 화면에 다가가는 움직임이 필요한 동작에는 반드시 한 번에 끝나는 명령만 쓰기로 정했습니다. 여러 개의 단순 명령을 이어 붙여서 흉내 내려는 시도는 금지했습니다.

확인 절차도 같이 남겼습니다. 표를 다 채운 뒤에는 화면을 다시 찍어 왼쪽 테두리의 행 추가 표시 개수를 세어 실제 행 수와 맞는지 확인합니다. 어긋나면 그 자리에서 되돌리기 명령으로 되돌린 뒤, 좌표를 다시 재서 다시 채웁니다. 이 확인 없이 표가 다 채워졌다고 넘어가지 않기로 했습니다. 눈으로 한 번 보기 좋아 보였다는 것과, 실제로 칸 수가 맞는다는 것은 다른 확인이었습니다.

행 추가 버튼 활성화 시도 비교 표. 좌표로 한 번에 이동해 클릭은 무시됨, 마우스 오른쪽 버튼 메뉴는 브라우저 기본 메뉴만 뜸, 근처로 옮긴 뒤 천천히 이동해 활성화 확인 후 두 번 클릭은 행 추가 성공
버튼은 다가오는 움직임을 봐야 켜졌다 — 도착 좌표만으로는 부족했다

그래도 표가 끝내 불안정하면 억지로 밀어붙이지 않기로 했습니다. 본문을 손상시키느니, 표 대신 구분선만 지워 읽기는 되는 상태로 두고 표 변환 자체는 다음 발행으로 넘기는 규칙을 남겼습니다. 같은 시도를 세 번 넘게 반복해도 풀리지 않으면 자동으로 물러나는 것도 이 규칙의 일부입니다. 좌표를 더 정밀하게 재는 쪽으로 계속 파고드는 대신, 어느 시점에서 멈추고 다음 기회로 미룰지를 미리 정해 둔 셈입니다.

이번에 정리한 규칙은 이 자동화 프로그램의 다른 자리에서도 반복해 걸렸던 문제와 뿌리가 같습니다. 자동 점검이 오히려 헛다리를 짚었던 이야기도 자동화가 통과시킨 것을 그대로 믿을 수 없었던 사례를 다룹니다. 브라우저 자동화나 반복 발행 파이프라인을 직접 설계해야 하는 상황이라면 상담에서 저희가 실제로 쓰는 방식을 더 자세히 나눌 수 있습니다.

같은 방식으로 우리 업무를 재보고 싶다면

이 글에 쓴 계측·판정·자동화는 저희가 실제로 매일 돌리는 방식 그대로입니다. 어떤 작업을 자동화할 수 있고 어디를 사람이 잡아야 하는지, 현재 업무 흐름을 놓고 같이 짚어 드립니다.

새 글이 올라오면 알려 드립니다

이런 계측 기록을 새로 쓰면 메일로 한 통 보냅니다. 광고나 판촉은 보내지 않습니다.