2026-11-02 (월) 개발일지
오늘은 두 갈래였다. 하나는 매일 도는 예약 발행 스크립트에서 검토 지적을 그대로 받아들일지 원문을 확인해서 되돌릴지 판단한 일이고, 다른 하나는 폰 앱에서 “작업 중인데 대화창이 멈춰 보인다”는 문제를 트리거 조건까지 파고들어 고친 일이다. 뒤쪽은 고치는 것보다 테스트가 조용히 빠져 있던 걸 찾아내는 데 시간이 더 걸렸다.
trend-posts — 검토 지적 2건 중 1건은 README 원문과 어긋나서 거부했다
예약 발행 스크립트는 3개 저장소를 골라 X(영어)와 Threads(한국어)에 각각 예약하는 일을 한다. 이번 실행에서 독립 검토가 4건 통과, 2건 수정 판정을 냈다.
t1 지적은 문장 3곳이었다. “Puppeteer 스크립트는 접속 주소만 바꿔 붙여요”는 주소를 붙이는 것처럼 읽히니 “바꾸면 그대로 써요”로, “모델 없이 다시 돌려요”는 주어가 없으니 “다시 돌릴 수 있어요”로, “사용 통계는 … 끄기 전까지 보내요”는 통계가 보내는 주체처럼 읽히니 “기본으로 보내요. 끄려면 LIGHTPANDA_DISABLE_TELEMETRY=true예요”로 바꾸라는 것이었다. README 156행, 200~203행, 298행을 근거로 달고 있었다. 셋 다 원문 대조가 되니 그대로 받았다. 수정 후 497/500자.
문제는 x2였다. “No policy, no permission.”을 “Refused calls name the rule.”로 바꾸라는 지적이었고, 이유는 README에 default-deny 문구가 없다는 것이었다. 그런데 README 62행은 “decides it against your policy … or refuses and names the rule”라고만 말하고, 226행에 “a missing policy permits nothing” 이 그대로 있었다.
검토가 근거 없다고 한 문장이 README 226행에 그대로 있었다. 지적을 받아들이지 않고 원문을 유지했다.
x2는 268/280자 그대로 나갔다. 검토를 무조건 신뢰하지 않은 게 이번 실행에서 가장 값어치 있는 판단이었다.
예약 단계에서도 한 번 걸렸다. Threads의 OpenBot 글 1차 시도에서 날짜·시간을 넣은 뒤 예약 표시가 뜨지 않았다. 게시 버튼은 누르지 않은 상태였고, 프로필에 즉시 올라간 글이 없는 걸 먼저 확인한 다음 재시도해서 성공했다. 예약 목록에서 세 글이 각각 1건씩만 있는지 다시 셌다 — 중복 없음.
최종적으로 6건 모두 예약 목록에서 날짜(2026-11-04), 시간(10:00/10:05/10:10), 본문 첫 줄까지 확인했다. X는 275/280·265/280·272/280, Threads는 497/500·410/500·374/500이었고, X 본문에 한글이 섞였는지와 금지어도 같이 검사해 전부 통과했다.
lepons 모바일 — 작업 중 대화가 멈춰 보인 건 폴링 주기가 아니라 갱신 조건 때문이었다
폰 앱 대화창에서 에이전트가 일하는 동안 진행 상황이 갱신되지 않는다는 문제가 남아 있었다. 처음엔 갱신 주기가 길어서라고 봤다. 주기를 줄이면 되겠거니 하고 갱신 코드를 열었는데, 조건이 “터미널 출력이 2.5초 멈춰야” 였다.
여기서 가설이 뒤집혔다. 작업 중에는 스피너와 진행 줄 때문에 출력이 계속 나온다. 조건을 만족할 순간이 없으니 갱신 자체가 일어나지 않는다. 주기가 아니라 트리거가 문제였다.
- 작업 중에는 출력과 무관하게 3초마다 갱신
- 내용이 그대로면 화면을 다시 그리지 않음
- “•••” 표시에 터미널 상태 줄뿐 아니라 실행 중인 명령(
❯ Bash · npm test)도 함께 표시
실제 세션 기록 파일을 PC가 폰에 보내는 방식 그대로 넣어 확인했다. 한 번 갱신에 약 23KB였고, 명령 설명까지 펼쳐서 나왔다. 모바일 테스트 35개 통과, 타입체크 통과. 실기기는 아직 안 돌려 봤다.
이 과정에서 PC 쪽에 넣었던 사진 첨부·사용량 수동 새로고침·슬래시 명령 표시를 전부 빼고 모바일만으로 다시 짰다. PC exe를 건드리지 않기로 한 이상, 폰이 PC에 보낼 수 있는 건 글자(최대 2,000자)와 몇 개의 키뿐이라 사진 파일을 넘길 통로가 없다. 첨부 버튼은 빼고, 새로고침은 PC가 이미 읽어 둔 최신 값을 다시 받는 동작으로 바꿨다. PC 쪽은 파일별 변경 줄 수가 작업 전과 같아진 것까지 확인했다(index.ts 48, server.test.ts 26, transcript.ts 2).
lepons 테스트 — 통과한 줄 알았던 첨부 테스트가 앵커 불일치로 조용히 빠져 있었다
PC 쪽 변경 후 테스트 615개 중 3개가 깨졌다. 응답에 v 필드가 추가돼 deep-equal이 어긋난 것, 상태 코드가 404 대신 200이 나온 것. 앞의 둘은 예상된 스키마 변경이라 테스트를 새 필드에 맞춰 고치면 됐다.
진짜 문제는 그다음이었다. 첨부 관련 테스트를 새로 써 넣었는데, 나중에 보니 파일에 아예 들어가지 않았다. 앵커 문자열이 맞지 않아 조용히 건너뛴 것이었다. 테스트가 통과한 게 아니라 없었던 것이다.
다시 cat >>로 붙이자 컴파일이 깨졌다. server.test.ts 429·430행에서 TS1125: Hexadecimal digit expected. 셸이 백슬래시를 삼켜서 경로 문자열이 \x 형태로 남은 탓이었다. 경로를 forward slash로 바꿔 같은 인용 로직을 유지했다.
그다음엔 200 !== 401이 났다. 인증 테스트에서 토큰 자리에 undefined를 넘겼는데, 그게 “기본 토큰”으로 해석돼 인증이 통과해 버린 것이었다. 테스트 쪽 버그라 잘못된 토큰을 명시적으로 넘기게 고쳤다.
한 가지 더. 폰 앱 lint를 돌리려고 expo lint를 실행했더니 ESLint 9를 자동 설치하고 설정 파일까지 만들었다. 의도한 변경이 아니라 그 부작용은 되돌렸다. 결과적으로 폰 lint는 이번에도 못 돌렸다 — 프로젝트에 ESLint 설정이 없는 상태를 그대로 두기로 했다.
최종적으로 PC 617개 테스트 통과, 타입체크 rc=0. 남은 건 실기기 확인과, PC가 최근 80개 기록만 보내기 때문에 아주 긴 작업에서 맨 위 요청이 잘리는 문제다. 후자는 PC를 업데이트할 때 같이 손봐야 한다.
오늘의 한줄
검토 지적도 테스트 결과도 원문과 실행 로그까지 확인하기 전엔 사실이 아니다 — 오늘은 README 226행 한 줄과 조용히 빠진 테스트 하나가 그걸 증명했다.