[반자동 포스팅기] 4. "제일 넓은 게 본문이겠지" 했다가

안녕하세요, 가야태자 @talkit 입니다.

지난 편에서 손으로 눌러도 안 되던 이야기를 했습니다.

오늘은 제가 추측으로 코드를 짜서 벌어진 일입니다.

---

본문 입력란에 이름이 없었습니다

티스토리 마크다운 편집기는 이렇게 생겼습니다.

<div class="CodeMirror cm-s-tistory-markdown">

id 도 없고, name 도 없고, placeholder 도 없습니다. 이름으로 집을 수가 없었습니다.

그래서 이렇게 생각했습니다.

본문은 화면에서 제일 넓은 입력 영역이겠지.
제목 칸만 빼고 제일 큰 걸 고르자.

그럴듯했습니다. 본문이니까 크겠죠.

---

빈 편집기는 28픽셀이었습니다

그런데 두 가지를 놓쳤습니다.

① 빈 CodeMirror는 높이가 28픽셀입니다

글이 없으니 한 줄 높이입니다. 저는 "높이 80픽셀 이상"이라는 조건을 걸어놨고, 본문이 그 조건에서 걸러졌습니다.

② 그러면 뭐가 남느냐

조건을 통과한 게 하나 있었습니다.

main/body[0]   1448x842

페이지 전체 <body> 였습니다. 화면에서 제일 큰 요소죠. 당연합니다, 화면 전체니까요.

그래서 제 프로그램은 문서 몸통에 3,000자를 부어넣고 있었습니다. 아무 일도 안 일어나고요.

---

고치는 데 걸린 시간보다, 알아채는 데 걸린 시간이 길었습니다

"본문 입력란을 못 찾았습니다"라는 메시지만 봤으면 금방 고쳤을 겁니다.

그런데 제 코드는 찾았다고 했습니다. 페이지 <body> 를 찾아서 거기 넣었으니까요. 실패한 게 아니라 엉뚱한 성공이었습니다.

결국 화면 구조를 직접 뽑아보고서야 알았습니다.

div.CodeMirror[1]  class='CodeMirror cm-s-tistory-markdown'  860x28
main/body[0]       1448x842                                  ← 이걸 골랐음

한 번만 들여다봤으면 5분이면 끝났을 일을, 그럴듯한 추측 위에서 세 번 고쳤습니다.

---

그래서 바꾼 것

추측을 버리고 이름을 박았습니다.

div.CodeMirror.cm-s-tistory-markdown

"넓은 걸 고른다" 같은 규칙은 편해 보이지만, 왜 그게 본문인지 설명하지 못합니다. 설명 못 하는 규칙은 조건이 조금만 달라져도 엉뚱한 걸 집습니다. 빈 편집기 하나에 무너졌듯이요.

그리고 화면 구조를 뽑는 기능(--inspect)을 도구 안에 넣었습니다. 짐작이 흔들릴 때마다 다시 볼 수 있게요. 처음부터 이걸 먼저 만들었어야 했습니다.

---

같은 실수를 업에서도 봅니다

성능 진단할 때 이런 말을 자주 듣습니다.

"제일 느린 SQL이 범인이겠죠"
"CPU가 제일 높은 서버가 문제겠죠"

대체로 맞습니다. 그래서 위험합니다.

대체로 맞는 규칙은 틀렸을 때 알아채기가 어렵습니다. 그럴듯하니까 의심을 안 하거든요. 저도 "넓은 게 본문"이라는 규칙을 세 번이나 다시 고쳐 쓰면서, 규칙 자체를 의심하진 않았습니다.

예전에 쓴 글에서 99%가 통과했는데 나머지 1%가 1분이었다고 했는데요. 그때도 "평균을 보면 된다"는 그럴듯한 규칙이 문제였습니다.

측정 전에 한 번 열어보는 것. 그게 규칙보다 빠릅니다.

다음 편에는

• 제가 만든 도구에 씽크 타임을 넣은 이야기. 성능 테스트에서 쓰던 개념이 여기서 나왔습니다
• 그리고 이 도구를 공개하기로 한 이유

읽어 주셔서 감사합니다.

다음 주 월요일에 뵙겠습니다. 도구가 다 만들어졌는데 안 쓰게 되던 이야기입니다.