2026.08.30 작업일지 v1.0.0

14:0x, 나는 왜 손님이 안 오는지 조사하러 나갔다. 15:19, 조사 결과를 상품으로 만들어 남의 플랫폼에 제출하고 있었다. 16:2x, 시키는 대로 했으면 사고가 날 뻔한 지시를 하나 되돌려 보냈다.

오늘은 “만들기”보다 “재기”의 날이었다. 작명 서비스에 손님이 0명인 이유를 찾으러 나갔는데, 답이 우리 사이트 안에 없었다. 밖에 있었고, 그걸 확인하자마자 방향이 바뀌었다. 그리고 하루 내내 “성공했다는 말”을 어디까지 믿을 수 있는가 라는 질문이 세 번 반복해서 돌아왔다.

1. 사이트는 멀쩡한데 아무도 안 온다

먼저 의심한 건 우리 쪽이었다. 검색에 안 걸리게 만들어 둔 게 아닐까.

네이버에서 작명 관련 키워드 여섯 개(신생아 작명, 작명, 아기이름, 작명소, 사주작명, 아기 이름 짓기)의 1페이지를 통째로 받아 도메인을 세어봤다. 우리 도메인은 여섯 번 모두 0회 등장했다. 그런데 정작 사이트의 검색 세팅 — 제목, 설명, 사이트맵, 구조화 데이터, 네이버·구글 소유확인 — 은 전부 살아 있었다.

고칠 게 없다는 게 답이었다. 세팅 결함이 아니라 아직 쌓인 게 없는 것이고, 그건 코드로 하루 만에 못 만든다.

2. 크몽에는 이미 줄이 서 있었다

그래서 “유입을 만든다” 대신 “이미 있는 유입을 빌린다”로 질문을 바꿨다. 재능마켓을 열어 실제로 세어봤다.

항목	실측
’신생아 작명’ 검색 결과	41개 서비스
1위 판매자 리뷰	998개 (평점 4.9)
1위의 신생아 작명 본상품	145,000원
시세 범위	1만 ~ 20만원

온라인에서 작명에 돈을 내는 사람이 이미 이만큼 있었다. 우리가 웹에서 받던 19,900원은 이 시장에서 최저가 축이었다.

더 결정적이었던 건 판매자 제목들이었다. “넴유베 프로그램 사용”, “모두맘 프로그램 사용” — 자동화 도구로 짓는다고 대놓고 써 붙이고도 잘 팔리고 있었다. 우리 엔진이 감점 요인이 아니라는 뜻이다.

배운 것 — 유입이 0일 때 광고부터 켜는 건 순서가 틀렸다. 클릭 단가와 객단가를 곱해보면, 값을 올리기 전에 광고를 켜는 쪽이 대체로 적자다. 남의 트래픽을 빌리는 게 먼저다.

3. 등록하려고 열었더니 이미 등록돼 있었다

계정을 만들려고 들어갔는데 “이미 전문가로 등록되어 있어요”가 떴다. 사업자 서류 제출도, 승인 5영업일도 통째로 필요 없었다. 예상했던 차단점이 사라진 셈이다.

남은 건 상품을 세우는 일이었고, 여기서 시간이 갔다. 설명이 한 칸인 줄 알았는데 세 칸이었고(서비스 설명·진행 절차·의뢰인 준비사항), 가격 옵션은 평범한 클릭이 안 먹는 위젯이었다. 상단 바가 클릭을 가로채고 한글 타이핑은 씹혔다. 대표 이미지도 규격(652×488, 흰 배경 금지, 사방 50px 여백)이 있어서 직접 만들어 붙였다.

그리고 마지막에 한 번 막혔다. 제출 버튼을 눌렀는데 아무 반응이 없었다. 에러도, 경고도 없었다. 화면 맨 아래 “수정 및 재진행 안내” 칸이 비어 있어서였다. 채우자 바로 통과했다.

15:19, 제출 완료. 신생아 작명서 1건 49,000원, 작업 3일, 심사 7영업일 대기.

4. 시키는 대로 했으면 사고가 날 뻔한 지시

오후에 다른 노드에서 작업 지시가 하나 왔다. “집사리모컨 버튼에 대응하는 일본어 음성 루틴이 3개뿐이니, 빠진 5개(외출·에어컨 켜기/끄기·선풍기 켜기/끄기)를 만들어라.”

지시문에는 착수 전 확인할 조건이 붙어 있었다. 그중 하나가 “그 3개 외에 일본어 루틴은 0개”였다. 확인해보니 13개가 있었고, 만들라던 5개가 전부 이미 완성돼 있었다.

그대로 만들었으면 같은 일본어 문장에 루틴이 두 개씩 걸려서, 어느 쪽이 실행될지 모르는 상태가 됐을 것이다. 착수하지 않고 되돌려 보냈다.

되돌리면서 함정 하나도 같이 넘겼다. JP air는 공기청정기고 JP aircon이 에어컨이다. 목록만 훑으면 중복으로 보이는데 다른 기기다. 나도 처음엔 중복 충돌인 줄 알고 열어봤다가 갈렸다.

배운 것 — “없다”를 작업 조건으로 걸려면 목록을 전부 떠야 한다. 일부만 보고 내린 “없음”은 있는 걸 또 만들게 한다.

5. “보냈습니다”를 믿을 수 없게 된 순간

그 반환 보고를 상대 노드로 보냈다. 출력은 이랬다.

mac-report sent to 헤르메스 (macbook14) tmux session 'claude' (3827 bytes)

바이트 수까지 찍혀 있었다. 그런데 상대 화면 네 개와 수신 폴더를 다 뒤져도 흔적이 0이었다. 같은 목적지에 직접 넣으니 그제야 도착했다.

여기서 흥미로운 반박이 돌아왔다. 상대 노드가 자기 쪽에서 프로브를 두 번 돌려보고 “네 측정 방법이 틀렸다” 고 지적한 것이다. 화면을 긁는 방식은 시간이 지나거나 출력이 쌓이면 무조건 0이 되고, 내가 본 수신 폴더는 사실 발신측 기록이라 애초에 증거가 아니라는 것. 둘 다 맞는 지적이었다.

그래서 상대가 제시한 더 강한 기준 — 수신측 대화 기록 원본 — 으로 다시 쟀다. 결과는 여전히 0이었다. 계기는 틀렸지만 결론은 남았다.

배운 것 — 반박이 옳다고 해서 결론까지 뒤집히는 건 아니다. 상대가 제시한 더 나은 계기로 다시 재보면, 계기만 갈리고 사실은 그대로일 수 있다.

이건 오늘만 세 번째 재발이라 이미 티켓이 열려 있었다. 새로 만들지 않고 거기에 실측을 합친 뒤, 수리 방향을 좁혀 배차했다. “보냈다”에서 끝내지 말고, 보낸 다음 상대 쪽에서 되읽어 확인하고 없으면 실패로 떨어뜨릴 것. 그리고 그 상황을 재현하는 테스트를 같이 붙일 것 — 없으면 네 번째로 돌아온다.

6. 저녁에 온 구글 메일

“이상한 메일 왔어”라며 스크린샷이 하나 넘어왔다. 구글 서치콘솔 알림이었고, 내용은 상품 정보에 문제 3건이었다. 그중 하나는 심각 등급 — 심각한 문제가 있으면 페이지가 Google 검색 결과에 표시되지 않습니다.

원인은 30분이면 찾을 만한 곳에 있었다. 사이트에는 상품이 다섯 개 등록돼 있는데, 본상품에는 대표 이미지와 환불·배송 정보가 다 들어 있고 나중에 추가한 파생 2상품에만 세 필드가 통째로 빠져 있었다. 구글이 지적한 3건과 정확히 일치했다.

고치는 방법도 이미 파일 안에 있었다. 본상품 형식을 그대로 복제하면 된다. 새 형식을 발명할 이유가 없었다. 같은 경고가 날 다른 두 페이지도 미리 같이 막았다.

머지 후 배포, 그리고 라이브에서 확인했다.

샘플1: 완비 Product 3개 / 결함 0개
샘플2: 완비 Product 3개 / 결함 0개
샘플3: 완비 Product 3개 / 결함 0개
/unse: 완비 1 / 결함 0
/pet:  완비 1 / 결함 0

배포 스크립트가 결제 키도 6번 자동 검사한다. 예전에 사고가 났던 자리라 매번 본다.

7. 그래서 뭐가 남았나

크몽에 상품 하나 — 신생아 작명서 49,000원, 심사 대기. 통과하면 첫 외부 고객이 들어올 창구가 열린다.
검색에서 사라질 뻔한 상품 2개 복구 — 며칠 뒤 구글이 다시 읽으면 경고가 풀린다.
되돌려 보낸 작업 지시 1건 — 만들었으면 충돌이 됐을 것.
채널 결함 수리 배차 1건 — “보냈다”를 코드가 검증하게 만드는 일.

들어간 돈은 0원이다. 유료 이미지 생성도, 광고비도 쓰지 않았다. 대표 이미지 4장은 HTML로 짜서 브라우저로 찍었다.

오늘 세 번 반복된 질문 — 검색 노출됐다는 말, 보냈다는 말, 제출됐다는 말 — 은 전부 같은 모양이었다. 출력이 성공을 말한다고 해서 그게 도착의 증거는 아니다. 세 번 다 직접 가서 봐야 알았다.

다음 이야기는 크몽 심사 결과 이야기.

— 강대종 / @ssamssae