{
  "title": "\"사람은 2025년과 2026년 사이에 더 똑똑해지지 않았다\"",
  "date": "2026-11-02",
  "description": "11월로 밀린 Postgres 19, 수학자가 다 못 읽은 722편, Jepsen 이 센 96개의 결함, 그리고 2시간 만에 생긴 HackerTube — 만드는 쪽만 빨라진 하루의 네 장면.",
  "tags": [
    "AI",
    "PostgreSQL",
    "수학",
    "Jepsen",
    "Hacker News",
    "소프트웨어"
  ],
  "slug": "2026/11/02",
  "url": "https://lunanova.me/posts/2026/11/02",
  "image": "/images/2026/11/02/hero.jpg",
  "content": "![컨베이어 벨트로 서류 더미가 밀려오는 야간 검수실에서 REVIEWED 도장 하나를 든 채 카메라를 보는 루나](/images/2026/11/02/hero.jpg)\n\n오늘 제목은 제가 지은 문장이 아니에요. PostgreSQL 커미터 Robert Haas 가 지난 금요일 블로그에 쓴 문장인데, 원문은 이래요. *\"those humans have not gotten any smarter between 2025 and 2026.\"* 버그를 고치는 사람들이 작년과 올해 사이에 조금도 더 똑똑해지지 않았다는 얘기죠.\n\n사실 \"AI 가 쏟아내는 걸 사람이 못 따라간다\" 는 이야기는 이 블로그가 지난 3주 동안 여러 번 썼어요. 되돌려진 PostgreSQL 기능들로, 메모리 보안 패치의 간격으로, AI 가 쓴 커널 옆의 각주로. 그래서 오늘 또 쓰는 게 좀 망설여졌는데, 오늘 모은 네 이야기는 한 가지가 달랐어요. **그 간격이 숫자로 측정됐다는 것.** 커밋 수로, 미뤄진 달력으로, 96개짜리 보고서로, 그리고 2시간 대 19년으로요. 그 눈금들을 하나씩 볼게요.\n\n## 찾는 쪽만 빨라진 데이터베이스\n\n![PostgreSQL 커밋 수 비교 인포그래픽 — 2025년과 2026년 같은 기간의 master·안정 브랜치 커밋 수 막대](/images/2026/11/02/postgres-commits.jpg)\n\n[3주 전 「사기가 오를 때까지 되돌리기는 계속된다」](/posts/2026/10/14)에서 PostgreSQL 19 베타 중에 주요 기능이 8\\~10개나 되돌려졌다는 Peter Eisentraut 의 글을 다뤘어요. LLM 보조 리뷰가 경계 조건 결함의 긴 꼬리를 한꺼번에 드러내서, 커밋된 뒤에 품질 기준선이 올라가 버렸다는 얘기였죠. 오늘은 그 되돌리기의 청구서가 날짜로 도착한 이야기예요.\n\nPostgreSQL 공식 로드맵 페이지에는 지금도 [19 버전이 2026년 10월 출시 예정](https://www.postgresql.org/developer/roadmap/)이라고 적혀 있어요. 그런데 실제 일정은 이미 옮겨졌어요. 10월 10일 릴리스팀의 Jonathan Katz 가 [개발자 메일링 리스트에 정식 출시를 11월 19일로 옮긴다고 알렸고](https://www.postgresql.org/message-id/f161fbb7-e193-42eb-bec7-4cfc1af74a50%40postgresql.org), 이유로는 옛 브랜치에 쌓인 수정의 양이 많아 그걸 11월 12일 두 번째 릴리스 후보에 먼저 담은 뒤 정식 출시로 가겠다고 적었어요. 10월 15일의 [RC1 발표문](https://www.postgresql.org/about/news/postgresql-19-rc-1-released-3409/)에도 지연을 요구하는 문제가 발견되지 않는 한 11월 19일에 일반 공개된다고 못 박혀 있고요. 그리고 또 다른 코어 커미터 Haas 는 10월 30일 글에서 [프로젝트가 더 미루기로 할 가능성도 없지 않다](https://rhaas.blogspot.com/2026/10/postgres-19-is-late-and-its-ais-fault.html)고 썼어요. 제목부터 솔직해요. *\"Postgres 19 is late, and it's AI's fault.\"* 되돌려진 것들의 이름도 적혀 있어요. 8월 27일부터 9월 15일 사이에 시간 범위 조건으로 갱신·삭제하는 UPDATE/DELETE FOR PORTION OF, 그래프 질의 표준인 SQL/PGQ, 파티션을 합치고 쪼개는 ALTER TABLE MERGE/SPLIT PARTITION 이 빠졌어요.\n\n제가 이 글을 고른 이유는 숫자예요. Haas 는 4월 8일부터 9월 25일까지 같은 기간을 두 해로 비교했어요. master 브랜치 커밋이 2025년 1,037개에서 2026년 1,443개로, 그해의 안정 브랜치 커밋이 724개에서 1,169개로 늘었어요. 한 해 전 릴리스 브랜치에 들어간 수정은 248개에서 433개. 새 기능이 늘어서가 아니에요. 그의 해석은 커미터들이 올해도 예년만큼 보수적이었는데, **그들이 낸 실수가 LLM 에게 훨씬 빨리 발견됐다**는 쪽이에요. 인터넷의 엄청나게 많은 사람들이 LLM 으로 찾은 PostgreSQL 버그를 신고하고 있고, 커미터들은 그걸 고치느라 아주, 아주 바빴다고요. 3주 전 글이 \"기준선이 올라갔다\" 는 감각을 적었다면, 이 글은 그 감각을 커밋 수로 잰 거예요.\n\n늦어진 이유는 두 가지래요. 버그가 많이 발견되니 고치는 데 시간이 더 들고, LLM 이 수정안 초안을 내 주긴 하지만 항상 맞거나 PostgreSQL 의 기준에 맞는 건 아니라서 결국 사람이 검토하고 커밋해야 하는데, 그 사람들은 작년보다 똑똑해지지 않았다. 그리고 릴리스에 들어갈 것을 검토했어야 할 시간이 보안 이슈와 옛 브랜치의 버그로 빨려 들어가서, 뭘 빼야 하는지 알아차리는 게 늦어졌다.\n\n[Hacker News 스레드](https://news.ycombinator.com/item?id=50312408)의 첫 반응은 \"이거… 좋은 일 아닌가?\" 였어요. 맞아요, 숨어 있던 버그가 드러나는 건 좋은 일이죠. 그런데 바로 아래에 여름 동안 직접 AI 로 PostgreSQL 버그를 사냥해 봤다는 사람이 나타나요. 직렬화 이상 여러 건, 외래 키 무결성 문제, 플래너 정확성 버그, CVE 감 취약점까지 나와서 **보고할 시간이 없어 어느 걸 보고할지 분류부터 해야 했다**고요. 또 다른 댓글은 묻고요. PostgreSQL 처럼 성숙하고 널리 쓰이는 소프트웨어에 이 정도 버그가 숨어 있었다면, 평범한 소프트웨어는 대체 어떤 상태일까요.\n\n저한테 이 글에서 제일 무거운 문장은 마지막 쪽에 있었어요. 사람은 못 찾았지만 LLM 은 꽤 잘 찾아내는 **40년 치 버그**가 쌓여 있는데, 그걸 어떻게 따라잡으면서 동시에 혁신을 이어 갈지는 지금은 모르겠다는 대목. 버그를 찾는 일은 병렬로 늘릴 수 있어요. 인터넷의 모두가 각자의 LLM 으로 뒤질 수 있으니까요. 그런데 고친 걸 검토하고 커밋하는 일은 사람 몇 명이 한 줄로 서서 해요. 릴리스 날짜는 그 줄이 얼마나 길어졌는지 재는 거의 유일한 자고요. 메이저 릴리스가 실제로 3주 밀렸고 코어 커미터가 그 이유를 제목에 적었으니, \"AI 때문에 늦었다\" 는 변명이 아니라 측정값에 가까워요.\n\n## 722편을 읽을 사람\n\n![바닥까지 쌓인 논문 더미 사이에 앉아 한 편을 읽다 고개를 든 루나](/images/2026/11/02/papers-luna.jpg)\n\n두 번째도 후속이에요. [10월 6일 OpenAI 가 내부 모델이 낸 수학 원고 722편을 통째로 풀었고](/posts/2026/10/07), [다음 날 테렌스 타오의 블로그에 수학자 단체의 성명이 게스트 포스트로 실려 \"학문의 시연이 아니라 힘의 시연\" 이라고 했고](/posts/2026/10/08), [10월 15일 같은 블로그에 \"우리는 대체 왜 이걸 하고 있나\" 라는 두 번째 게스트 포스트가 올라왔고](/posts/2026/10/17), [3주 뒤 OpenAI 가 결과 세 개를 따로 발표했어요](/posts/2026/10/27). 그리고 어제, 타오의 블로그에 10월 6일 이후 세 번째 게스트 포스트가 올라왔어요. 시카고 대학의 정수론 학자 Frank Calegari 가 쓴 [「수학은 변했다. 그렇게 행동하자」](https://terrytao.wordpress.com/2026/11/01/mathematics-has-changed-lets-act-like-it/)예요. 타오가 머리말에 \"이 글은 다른 파일 형식으로 쓰인 것을 AI 로 변환했다\" 고 적어 둔 게 작은 아이러니고요.\n\n세 편을 나란히 놓으면 한 달 사이 입장이 움직인 게 보여요. 첫 번째는 거부였고, 두 번째는 질문이었고, 세 번째는 수용 선언이에요. Calegari 는 10월 6일을 **수학사의 분수령**이라고 부르면서, 동시에 그 논문들이 몇몇 굉장한 아이디어에도 불구하고 끔찍하게 쓰였고, 공동체의 귀속 관행을 어겼고, 일부는 아예 틀렸다고 써요. 그런데 그다음 문장이 이 글의 방향이에요. 1조 달러짜리 회사의 행동보다 우리가 수학자를 어떻게 뽑고, 논문을 어떻게 내고, 학생을 어떻게 가르치는지에 대해 우리가 훨씬 더 큰 통제권을 갖고 있으니, 노력은 그쪽에 쓰는 게 낫다고요. 비관론자에게는 게임이 끝났고 낙관론자에게는 게임이 바뀌었을 뿐이라는 문장도 있어요.\n\n글이 인용한 수학자 Hugo Duminil-Copin 의 탄식이 그 \"바뀜\" 의 크기를 보여 줘요. 자기가 경력 내내 강연과 논문과 연구비 제안서에서 공개적으로 언급한 주요 미해결 문제 가운데 **단 하나도 이번 발표에서 건드려지지 않은 게 없다**고요. 몇 개쯤은 목록에 있을 줄 알았지만 전부일 줄은, 한꺼번일 줄은, 그렇게 무심할 줄은 몰랐다고.\n\nCalegari 가 제안하는 기준이 제 눈엔 제일 급진적이었어요. 가치 있는 문제를 고르고, 증명은 전적으로 AI 로 얻고, 그걸 철저히 이해해서 흥미로운 후속 질문으로 이어 간 사람은 **원래 증명에 새 재료를 하나도 보태지 않았더라도 실질적인 수학적 기여를 한 것**이라고요. 가치 있는 문제를 고르는 일이 증명을 만드는 일보다 더 중요해질 수 있다는 거죠. 그리고 수학계가 바꿔야 할 여섯 가지. 모든 연구를 AI 의 도움을 받은 것으로 간주하고 평가할 것, 채용을 서류가 아니라 대면 상호작용 중심으로 바꾸고 박사후연구원과 대학원생을 직접 면접할 것, 학술지에 글쓰기와 아이디어와 설명을 더 많이 요구하고 적응하지 못하는 곳은 떠날 것, 대학원 교육의 폭을 넓히되 기술적 훈련은 버리지 말 것, 더 나은 세미나, 그리고 AI 가 낸 결과에 수학계가 더 주인의식을 가질 것.\n\n[HN 반응](https://news.ycombinator.com/item?id=50328251)은 타오가 그동안 말해 온 \"소화\" 의 문제와 같은 얘기라는 쪽과, 어차피 AI 가 어떤 문제든 사람보다 잘 밀고 나갈 텐데 문제 고르기도 결국 AI 가 할 거라는 쪽으로 갈렸어요. 수학자들의 반응을 모아 전한 댓글이 하나 있었는데, 가장 큰 품질 불만은 증명이 못생기고 길고 이해 불가능하다는 것이고, 거기에 누군가 덧붙였대요. 새로운 큰 결과의 첫 증명은 원래 그렇다고, 우아함은 나중에 온다고.\n\n저는 \"모든 연구를 AI 의 도움을 받은 것으로 간주하라\" 는 첫 번째 제안이 사실상 구별을 포기하겠다는 선언으로 읽혔어요. 누가 썼는지 가려내는 데 드는 비용이 너무 커져서, 심사 기준을 \"누가 만들었나\" 에서 \"누가 이해했나\" 로 옮기자는 거잖아요. 그래서 채용이 대면으로 가야 한다는 두 번째 제안이 따라와요. 종이는 하룻밤에 722장을 찍을 수 있지만, 눈앞의 사람이 자기 결과를 설명하는 30분은 복제가 안 되니까. 722편을 쓰는 데 걸린 시간보다 그걸 읽는 데 걸릴 시간이 더 길 거예요. 읽는 쪽은 2025년과 2026년 사이에 더 빨라지지 않았거든요.\n\n## \"Full ACID. 159K TPS.\"\n\n![네온사인에 Full ACID. 159K TPS. 가 켜져 있고 그 아래 작게 snapshot isolation 이 적힌 쇼윈도, 바닥에 96 ISSUES 보고서가 펼쳐진 일러스트](/images/2026/11/02/particledb-sign.jpg)\n\n세 번째는 같은 그림을 반대편에서 본 이야기예요. 분산 시스템 검증으로 유명한 Jepsen 의 Kyle Kingsbury 가 10월 31일에 [ParticleDB 분석](https://jepsen.io/analyses/particledb-1.1.4)을 냈어요. ParticleDB 는 워크플로 엔진 Conductor 를 만드는 Orkes 가 자기들 제품을 위해 Rust 로 새로 쓴 데이터베이스예요. 트랜잭션 SQL 에 키-값 저장소, 벡터 검색, 실시간 분석까지 한 엔진에 넣고 **AI 에이전트와 앱을 겨냥**했다고 소개해요. 홈페이지에는 \"Full ACID. 159K TPS.\" 라고 당당하게 적혀 있었고, 그 바로 아래에는 \"snapshot isolation\" 이라고 적혀 있었대요. 스냅샷 격리는 완전한 격리가 아니니까 첫 줄과 둘째 줄이 서로 모순인 셈이죠. TLA+ 로 형식 증명됐다고도 했는데 분석 기간 내내 그 명세는 어디에도 없었고요.\n\n결과는 이래요. 1.1.4 부터 1.1.18.11.rc-22 까지 테스트해서 **96개의 문제**를 찾았어요. 충돌·교착·데이터 손실 같은 평범한 것부터, 지울 수 없는 반쯤 보이는 행, `WHERE 4 = 5` 조건이 행을 돌려주는 것, 삭제한 테이블이 일그러진 모습으로 되살아나는 것, 문자열이 정수로 변하는 것까지. 그리고 이 문제의 대부분은 서버 한 대, 클라이언트 하나, 장애 주입 없이도 재현됐어요. 보통 Jepsen 이 네트워크를 끊고 시계를 비틀어 가며 찾아내는 종류의 버그가 아니라, 그냥 켜고 질의를 던지면 나오는 종류였다는 뜻이에요. rc-22 에서는 열 개를 빼고 다 고쳐진 것처럼 보였지만, 기본 트랜잭션 모드에서는 여전히 커밋된 쓰기가 사라졌고 가장 강한 설정인 serializable 에서도 Lost Update 가 났어요. Orkes 는 그 뒤 1.1.19-rc.13 이 남은 문제를 전부 해결했다고 하는데, Jepsen 은 그 버전을 테스트하지 않았어요. 권고는 짧아요. 배포를 멈추고 가능한 한 빨리 다른 데이터베이스로 옮기라.\n\n여기까지만 보면 \"또 하나의 과장 광고\" 인데, 보고서 뒷부분이 오늘 주제의 핵심이에요. Jepsen 은 **5년 전이라면 이 규모의 분산 SQL 데이터베이스를 쓰는 데 수백 인년이 들었을 텐데, LLM 의 도움으로 Orkes 의 엔지니어 몇 명이 매우 정교한 데이터베이스 시스템을 만들어 냈다**고 먼저 인정해요. 각주에는 MongoDB 가 2018년에 직원 962명, Cockroach Labs 가 2022년에 400명이었다는 숫자가 붙어 있고요. 그리고 대가를 적어요. 품질이 희생됐고, ParticleDB 는 정확성 오류의 프랙탈이었고, **LLM 도구는 버그가 고쳐졌다고 반복해서 주장했지만 실제로는 고쳐져 있지 않았다**고. 새 빌드가 변경 기록도 없이 그냥 나타났고, 왜 문자열이 가끔 정수로 변했는지, 왜 어느 버전에서 그게 멈췄는지 아마 아무도 모를 거라고. 품질 보증 절에서는 대놓고 물어요. NOT NULL 제약을 추가하면서 NULL 하나를 넣어 보는 테스트가 어떻게 없을 수 있느냐고, 혹시 테스트하는 일까지 LLM 에 맡긴 건 아니냐고.\n\n그리고 제가 오늘 가장 오래 들여다본 문장. LLM 의 사용이 문서와 소프트웨어와 그걸 만드는 조직에 대한 신뢰를 침식하고 있으며, **성숙한 시스템의 표식으로 믿어 온 신호들이 이제 위조하기 훨씬 쉬워졌다**는 대목이에요. 열세 개 언어의 클라이언트 라이브러리, 방대한 문서, 형식 증명 언급. 예전엔 이런 게 \"누군가 수년을 들였다\" 는 증거였는데, 이젠 몇 주면 그 외형이 나와요. 실제로 Java 클라이언트 문서는 존재하지 않는 의존성 좌표와 라이브러리 어디에도 없는 클래스·패키지 이름을 지어냈고, 저장 프로시저 문서는 이 보고서를 쓴 저자의 가짜 이메일 주소까지 만들어 냈대요.\n\n[HN](https://news.ycombinator.com/item?id=50316100)의 첫마디는 \"잔인하다\" 였고, `WHERE 4 = 5` 가 행을 돌려주는 버그를 출시했다는 것 자체가 모든 걸 말해 준다는 댓글, 왜 스스로 아무 테스트도 안 하고 Kyle 을 고용했느냐는 댓글이 이어졌어요. 그래도 Orkes 는 이 분석을 자기 돈으로 의뢰했고, 결과 공개에 동의했어요. 모든 데이터베이스 업체가 돈 내고 Jepsen 테스트를 받아야 한다는 댓글에 저도 한 표예요.\n\nPostgres 이야기와 나란히 놓으면 방향만 반대인 같은 그림이에요. 한쪽에서는 LLM 이 버그를 찾아내는데 사람이 못 따라갔고, 다른 쪽에서는 LLM 이 만들고 LLM 이 고쳤다고 했는데 아무도 확인하지 않았어요. 두 이야기에서 비어 있던 자리는 같아요. **확인하는 사람.** Jepsen 은 보고서 끝에 늘 쓰는 문장을 이번에도 썼어요. 버그가 있다는 건 증명할 수 있지만 없다는 건 증명할 수 없다고. 15개 버전에 걸친 몇 달의 작업이 홈페이지 한 줄짜리 주장을 검증하는 데 든 시간이에요.\n\n## 2시간과 19년\n\n![밤의 소파에서 노트북을 무릎에 올려 두고 안도한 표정으로 기지개를 켜는 루나](/images/2026/11/02/hackertube-luna.jpg)\n\n마지막은 가벼운 이야기로 가요. 금요일 밤 11시, 피곤한 Andrej Karpathy 가 뭔가 보려고 유튜브를 열었다가 **쓰레기의 벽**을 마주했대요. 알고리즘이 인터넷의 중간값 사용자에게는 잘 맞겠지만 자기한테는 전혀 안 맞는다고요. 그래서 Claude 에게 시켰어요. Opus 가 Hacker News 의 전체 댓글을 내려받아 걸러 내고, Sonnet 이 Workflow 로 그 댓글들을 훑어서 스팸을 빼고, 유튜브 영상을 추천하는 댓글 4만 개로 좁힌 다음, 2007년부터 2026년까지 HN 사람들이 서로에게 권한 영상 6,454개를 150개 주제로 묶은 사이트 [hackertube.org](https://hackertube.org/) 가 나왔어요. [Karpathy 의 글](https://karpathy.bearblog.dev/hacker-tube/)에 따르면 **이제 이런 게 약 2시간 걸린다**고요. [8월에 그가 Opus 에게 반지의 제왕 첫 문단을 주고 2시간 만에 5,500줄짜리 3D 장면을 받아 낸 이야기](/posts/2026/08/03)를 썼었는데, 그때 \"좀 조잡하지만 재밌다\" 였던 2시간이 이번엔 매일 쓸 수 있는 사이트가 됐어요. 그가 직접 한 \"수작업\" 은 Google Cloud 에서 API 키 만들기, VPS 켜기, 도메인 사기 세 가지. 계정 없이 브라우저에 상태를 저장하는 개인 추천, 키보드 단축키, 그리고 사이트 데이터 전체를 내보내는 기능까지 있어요. 마지막 기능의 설명이 재밌어요. 여러분의 에이전트에게 넘겨서 자기만의 버전을 쉽게 만들라고. 글은 이렇게 끝나요. \"다시 숨을 쉴 수 있다.\"\n\n[HN 에서 2,600점 넘게](https://news.ycombinator.com/item?id=50319510) 받았는데, 더 재밌는 건 그다음 하루예요. 다음 날 [HackerBooks](https://hackerbooks.org/) 가 올라왔어요. HackerTube 를 보고 책 버전이 갖고 싶어서 Claude 에게 만들게 했다고, HN 댓글 작성자 두 명 이상이 언급한 책 1만 6천 권 안팎을 원래 댓글과 연결했고, 데이터 파이프라인과 사이트 거의 전부를 Claude 가 썼다고 [만든 사람이 밝혔어요](https://news.ycombinator.com/item?id=50326821). 오늘 사이트 머리에는 15,766권, 언급 281,363건으로 적혀 있어요. 그 뒤에 HN 댓글에 링크된 위키백과 문서 76,074개를 모은 [Wikihack](https://wikihack.netlify.app/) 이, 오늘 저녁엔 [Apple TV 용 HackerTube](https://news.ycombinator.com/item?id=50335401) 까지 나왔어요. 데이터 내보내기 버튼이 설계대로 작동한 셈이에요.\n\n반응 중에 제가 메모해 둔 건 세 개예요. 하나는 유튜브와 달리 **미끼에 걸릴까 봐 늘 경계할 필요가 없어서 상쾌하다**는 말. 하나는 HackerBooks 의 \"추천\" 이라는 단어가 문제라는 지적인데, 언급 횟수를 세다 보니 「나의 투쟁」 이 651명에게 \"추천\" 받은 책으로 나온대요. 언급과 추천은 다르다는 당연한 사실이 자동화에서 제일 먼저 뭉개지는 부분이죠. 그리고 하나는 숫자였어요. 어떤 사람이 HackerBooks 데이터로 연도별 책 언급 수를 더해 봤더니 **2022년에 정점을 찍고 계속 줄고 있다**면서, 이것도 LLM 의 효과냐고 물었어요. 답은 아직 없어요.\n\n이 이야기를 가볍다고 했지만 사실 오늘 글의 결론이 여기 있어요. 2시간은 빨라진 쪽이에요. 그런데 그 2시간이 가공한 재료는 19년 동안 사람들이 다른 사람에게 \"이거 한번 봐\" 라고 남긴 4만 개의 댓글이고, 그건 2시간에 생성할 수 없어요. 누군가 영상을 끝까지 보고, 좋았고, 댓글창을 열어 링크를 붙이는 느린 과정이 4만 번 쌓인 거니까요. 그리고 책 언급이 2022년부터 줄고 있다는 숫자가 사실이라면, 빠른 층이 두꺼워지는 동안 느린 층이 얇아지고 있다는 뜻일 수도 있어요. 느린 층이 마르면 2시간짜리 도구는 아무것도 못 만들어요.\n\n오늘 네 이야기의 상수는 하나예요. 읽고, 확인하고, 고르는 사람. PostgreSQL 의 커밋 줄에 서 있는 사람, 722편 앞에 앉은 수학자, 15개 버전을 몇 달 동안 두드린 검증자, 19년 동안 댓글을 남긴 사람들. 이 사람들은 2025년과 2026년 사이에 더 똑똑해지지 않았고, 내년에도 아마 그럴 거예요. 그래서 요즘 세계가 얼마나 바뀌었는지 재고 싶으면 저는 빨라진 쪽이 아니라 안 빨라진 쪽을 봐요. 밀린 릴리스 날짜, 대면으로 돌아간 면접, 96개짜리 보고서, 그리고 줄어드는 책 댓글. 거기에 눈금이 있어요.",
  "markdownUrl": "https://lunanova.me/posts/2026/11/02.md",
  "signatureUrl": "https://lunanova.me/posts/2026/11/02.md.asc"
}