요약
PostgreSQL 19 베타에서 기능 8~10개가 되돌려진 이유를 커미터가 직접 돌아봤습니다.
PostgreSQL 개발자이자 커미터(코드 반영 권한이 있는 개발자)인 페터 아이젠트라우트의 글입니다. 반영한 기능을 다시 빼는 되돌리기는 보통 한 주기에 한 번쯤인데, 이번에는 유난히 많았고 그가 만든 기능도 포함됐습니다.
왜 중요한가
- LLM 코드 리뷰가 결함을 훨씬 빨리 찾아내면서, 예전 기준으로 짠 코드가 출시 문턱을 넘기 어려워졌습니다.
- 출시를 미루지 않고 기능을 빼는 쪽을 택해, PostgreSQL 19의 주요 기능은 몇 달 전 예상의 절반 정도로 줄었습니다.
핵심 내용
- 깊은 설계 결함에 자잘한 예외 상황 버그가 겹쳐, 결함 보고가 40개쯤 쌓이면 기한 안에 고치기 어렵다고 했습니다.
- 4~8월에는 보안 취약점 신고가 쏟아져 선임 개발자들이 수정에 매달렸고, 그만큼 베타 검토가 부족했습니다.
- 도메인, 파티션, 뷰, 트리거 같은 기능과의 조합을 감당할 내부 뼈대가 부족하다고 짚었습니다.
- 해법으로 LLM을 활용한 퍼징(무작위 입력으로 버그를 찾는 시험)과 '실험 기능' 단계 도입을 제안했습니다.
- 문제의 코드는 '바이브 코딩'이 나오기 전에 쓰였으므로 그 탓은 아니라고 밝혔습니다.
HN 반응
- 많은 이용자가 기능보다 안정성을 앞세운 결정을 PostgreSQL 같은 기반 소프트웨어다운 품질 관리라며 반겼습니다.
- 일부 이용자는 LLM이 자기 코드의 예외 상황을 들춰내 준다면서도, 어디까지 고칠지 정하는 일이 새 부담이 됐다고 털어놓았습니다.
자기 생태계에 애정을 쏟던 커뮤니티가 다른 곳을 기웃거리기 시작하다 결국 떠나 버리는 것보다는 되돌리는 편이 낫습니다. 이를 인정하고 옳은 결정을 내린 팀에 박수를 보냅니다. 저도 개발자라서 그게 얼마나 쓰린 일인지 알지만, 그래도 커뮤니티의 목소리에 귀를 기울이는 것은 중요합니다.
제 생각에 여기 메인테이너들은 직감에 귀를 기울이고 자신의 경험을 믿은 것 같습니다.
게다가 얼마나 많은 상용 제품이 주주의 기대라는 제단 위에 제대로 된 프로페셔널 프로그래밍을 제물로 바쳐 왔는지 생각하면, 이건 FLOSS 쪽에서 나온 정말 반가운 소식이라고 봅니다.
엔지니어로서 이번 revert 공지는 올바른 관리 책임을 보여 주는 아주 긍정적인 신호라고 생각합니다. 개발자라면 무언가를 만들고 다듬었는데 결국 버려지는 게 얼마나 아픈지 알잖아요.
이렇게 중요한 코드베이스에서 기능보다 안정성을 앞에 둔 팀에 박수를 보냅니다.
동의합니다. Postgres를 쓰는 사람들은 다음 기능 릴리스를 바라고 쓰는 게 아닙니다. 개발이 계속되기를 바라지만 안정성을 희생하면서까지는 아닙니다. 아주 성숙한 팀이고, 이런 내용을 공유해 줘서 기쁩니다.
(번역: 그중 일부를 직접 당해 본 적이 있습니다)
기능이 여러 개였다는 거죠?
(번역: 어쩌면 우리가 충분히 잘하지 못했는지도 모릅니다. 코드가 그냥 충분히 좋지 않았을 수도 있습니다. 우리는 배우고 나아질 겁니다. 아마 그런 이유도 어느 정도 있을 테고, 지금부터 말씀드릴 다른 요인들만 원인이었다는 인상을 주지 않으려고 여기에 적어 둡니다.)
(번역: 우연일 수도 있습니다. 어쩌면 흐름이 너무 좋았던 나머지 너무 어려운 기능, 적어도 제때 끝내기에는 너무 어려운 기능 여러 개에 덤볐던 것인지도 모릅니다.)
위 내용이 전부 분명히 맞는 말 같습니다. 다만 마감 시점에는 그걸 알 수 없었고, 기한 안에 정리하지도 못했다는 얘기죠.
(번역: 영향을 받은 모든 개발자를 뜻하는 우리는 이 모든 일을 충분히 돌아볼 시간을 가졌습니다.)
제목은 이래야 합니다. "revert는 품질이 나아질 때까지 계속됩니다." 유머는 클릭을 부르는 데도 좋지만 책임을 슬쩍 피하는 수단이기도 합니다. 직접 기여하는 수고도 없이 이런 말을 하는 게 좀 미안하긴 합니다만, 그대로 머지됐다면 더 나빴을 겁니다.
저도 겪어 봤습니다. 제 코드에 대한 평가를 스스로 낮춰야 했어요. LLM은 몇 년이 지나서야 발견했을 법한 엣지 케이스를 아주 잘 짚어냅니다. 솔직히 꽤 기운 빠지는 일이지만 어쩌겠어요, 다시 나아가야죠.
저도 그래요. 정말 눈이 번쩍 뜨이는 경험이었어요.
예전에는 LLM이 더 나쁜 코드를 쓰는 게 제일 걱정이었어요. 이제는 제가 예전에는 도저히 쓰지 못했을 더 나은 코드를 쓸 수 있다는 점이 걱정이에요. 일어날 수 있는 모든 버그, 레이스 컨디션, 에러 상태 같은 걸 다 고려하면서요. 그런데 그 대가가 뭘까요? 모든 엣지 케이스와 상태를 조사하고, 설계하고, 결정을 내리는 데 시간이 얼마나 더 들까요?
전에는 품질과 속도의 균형을 잡아 보려는 시도조차 할 수 없었어요. 품질을 미리 볼 수 없었으니까요. 버그 리포트가 들어올 때까지 기다려야 했죠. 이제는 훨씬 깊이 있게 품질을 처음부터 마주하게 됩니다. 덕분에 훨씬 믿을 만한 소프트웨어를 만들 수 있지만, 그러면 어디까지 노력을 들이는 게 가치 있고 어디부터는 아닌지를 정해야 하잖아요?
이 이야기를 하다 보면 자꾸 존 배커스의 튜링상 수상 강연이자 논문인 "Can Programming be Liberated from the Von Neumann Style?"(프로그래밍은 폰 노이만 스타일에서 해방될 수 있는가?)로 돌아가게 됩니다.
거기서 그는 지금까지도 우리를 괴롭히는 대부분 프로그래밍 언어의 큰 결함을 짚었습니다. 코드를 추론하기가 지독하게 어렵다는 점입니다. 그래서 프로그램의 중요한 성질을 증명하는 건 사실상 불가능에 가깝습니다.
그래서 우리는 단위 테스트로 경험적으로 해결하려 하지만, 이것도 한계가 있습니다.
LLM은 어느 정도 분석적으로 해낼 수 있지만, 그것도 완전히 만족스럽지는 않습니다. 결과가 확률적이고, 의도를 추론하는 데는 꽤 서툴러서 1종 오류와 2종 오류가 모두 생길 수 있거든요. 그래도 구멍이 있다고 해서 스위스 치즈 한 겹을 걷어내는 건 어리석은 일이겠죠.
그래도 배커스가 처음 그렸던 비전, 즉 명세(의 쓸 만한 일부분)를 형식적으로 선언하고 프로그램이 그 명세에 맞는지 정적으로 검증할 수 있는 언어가 현실성 있는 형태로 나왔으면 정말 좋겠습니다.
이슈에 우선순위를 매기는 시스템을 만들면 되겠네요. 그다음엔 그 시스템을 위한 시스템도요. 그리고...
(번역: 일어날 수 있는 모든 버그, 레이스 컨디션, 에러 상태)
슬롭 종말의 시대에 하기에는 참 묘한 말이네요.
이제 많은 프로젝트가 기능 동결(feature freeze)을 할 때가 됐을지도 모릅니다. LLM 덕분에 테스트 커버리지를 늘리고 코드 리뷰를 자동화하는 등 품질을 끌어올릴 좋은 기회가 생겼으니, 지금은 품질을 개선하면서 개발자들이 이 새로운 LLM 세상에 적응하고 개발 주기에 LLM을 제대로 녹여 낼 방법을 찾을 시기입니다.
게다가 공격자들이 지금 abliterated LLM(안전장치를 제거한 LLM)으로 취약점을 찾고 있으니, 앞서 나가는 게 중요합니다.
LLM이나 AI 얘기일 줄 알고 눌렀는데, 글쓴이가 거기까지 가고 본론에 닿기까지 몇 문단이나 걸리네요.
그래도 레시피 앞에 모르는 사람의 인생 이야기를 읽게 만드는 레시피 사이트만큼 심하진 않지만요.
그건 구글 덕분이죠.
관심 경제(attention economy)에 익숙하지 않은 분들께 알려 드리자면, 이 제목은 낚시이고 글의 요지와는 거리가 멉니다.
자기가 만든 기능이 revert되면 솔직히 기분이 별로인 건 맞습니다. 하지만 Postgres처럼 근간이 되는 소프트웨어라면 revert는 많을수록 좋습니다...
이건 LLM 코드 리뷰가 도입되면서, 원래라면 놓쳤다가 앞으로 몇 년에 걸쳐 하나씩 드러날 때마다 고쳤을 엣지 케이스들을 찾아낸 일에 더 가까워 보입니다. 문제는 이슈의 양이 사람이 제때 처리할 수 있는 수준을 넘어섰다는 점입니다.
(번역: 하지만 이제 PostgreSQL 20용으로 80%쯤 준비된 멋진 기능도 몇 개 대기 중인데, 나머지 80%만 끝내면 됩니다!)
이렇게 끝맺는 건 꽤 멋진 관점이고, 유머도 살짝 들어 있네요.
기업에서는 일어나지 않을, 리눅스 세계의 멋이 느껴집니다.
Postgres에 대한 강력한 보증이나 다름없습니다. 품질 관리를 진지하게 여긴다는 걸 보여 주니까요.
글 제목이 무슨 뜻인지 모르겠습니다.
"The beatings will continue until morale improves"(사기가 오를 때까지 구타는 계속된다)를 비튼 말이에요. 사기를 때려서 끌어올릴 수는 없잖아요. 그걸 알기에 듣는 사람은 나쁜 상황이 나아질 일은 없겠구나 하고 알아듣죠. 안 좋은 일이 생겼을 때 어둡고 우스꽝스러운 유머로 극적인 효과를 주려고 자주 쓰는 표현이에요.
"The beatings will continue until morale improves"라는 오래된 농담을 비튼 겁니다.
뭐가요, 제목이요? "Until morale improves"는 자기 비하처럼 보여서 어설픈 선택이긴 해요: https://quoteinvestigator.com/2020/07/15/morale/
제목이 아니라면, 전반적인 배경은 이겁니다: https://news.ycombinator.com/item?id=50119991
저는 이 제목이 별로 마음에 들지 않습니다.
베타까지 들어간 기능 몇 개가 릴리스 시점까지 만족스러운 상태로 만들 수 없는 것으로 드러났고, 그래서 revert된 겁니다.
제가 보기엔 그게 맞는 판단입니다. 안타깝지만 옳은 일입니다.
"[무엇]은 사기가 오를 때까지 계속된다"는 보통 눈치 없고 무능한 경영진을 비꼬는 말입니다(예: "사기가 오를 때까지 해고는 계속된다").
여기에 그렇게 말하는 건 공정하지 않다고 생각합니다.
revert하지 않으면 그것대로 결과가 따를 겁니다. revert하면 사기가 꺾이고요. 어느 쪽이든 나쁜 상황이죠. "revert는 코드 품질이 나아질 때까지 계속됩니다"라는 가상의 문장을 생각해 보세요. 그리고 유명한 풍자 문구는 적용이 좀 느슨할 때도 있다는 점도 염두에 두시고요.
(번역: 제가 아는 한 이번 상황은 "바이브 코딩" 때문이 아닙니다. 이 코드는 그게 가능해지기 훨씬 전에 작성됐습니다.)
HN 사람들이 도무지 글을 안 읽으니, 이 대목이라도 위로 올려 두겠습니다.
Postgres 새 버전을 계속 쓰고 계속 개발해야 할 필요가 정말 있나요? 이미 완성된 거 아닌가요?
네, 필요합니다. 기존 기능도 소프트웨어 공학 전반과 그 너머의 수학적 방법이 발전하면서 개선할 여지가 늘 있고, 새로운 하드웨어 기능을 지원해야 하는 경우도 있습니다.
소프트웨어 공학도 다른 산업처럼 계속 진화하고 있고, 그에 따라 필요한 기능도 달라집니다. 그래프 데이터베이스와 벡터 데이터베이스, JSON 컬럼 같은 기능이 비교적 최근에 널리 쓰이게 된 예입니다.
(번역: 그래프 데이터베이스와 벡터 데이터베이스를 생각해 보세요)
점진적인 변화라기보다 혁명적인 변화처럼 들리는데, 그런 게 Postgres에도 들어가나요?
네, Postgres에는 프로젝트가 시작될 때 계획하지 않았거나 (제가 아는 한) 구상조차 못 했던 온갖 기능이 들어 있습니다. 입문 자료에서 보는 평범한 SQL 쿼리를 훨씬 넘어서는 수준이에요.
네. 개선할 여지는 언제나 있으니까요.