우리가 만드는 소프트웨어에 더 큰 야심을 가져야 한다

AI로 소프트웨어를 만드는 비용이 낮아지면서, 과거에는 규모가 너무 크거나 들일 시간에 비해 가치가 작았던 프로젝트도 실행 가능한 선택지가 됨 저품질 AI 생성 프로젝트가 많다는 사실과 별개로, 충분한 테스트와 벤치마크를 수행하면 실제로 쓸 만한 소프트웨어를 만들 수 있음 개인 프로젝트에서는 작업 시간이 크게 단축됐지만, 개인용으로 작동하는 수준과 공개 제품 수준 사이에는 여전히 상당한 작업이 남아 있음 모델이 발전해도 더 어려운 작업에 도전하면 사람의 개입이 필요함. 개인 경험에서는 구현 능력과 독립적인 검증 능력의 격차가 커졌으며, 결과의 진위를 판별할 프로그래밍 역량이 중요해짐 모든 작업이 AI로 빨라지는 것은 아니며, 불명확한 성공 기준과 이해하기 어려운 코드가 실패를 낳을 수 있음. 자체 검증 구조를 만들고 효과가 직접적인 프로젝트를 고르는 것이 핵심 조건임 더 큰 프로젝트와 더 작은 개인용 도구 여기서 야심은 이전보다 더 많은 일을 한다는 넓은 뜻임 과거에는 현실적으로 감당하기 어려웠던 대형 프로젝트를 만드는 일과, 만들 수는 있었지만 시간 대비 가치가 없어 포기했던 초개인화 도구를 만드는 일을 모두 포함함 두 경우 모두 소프트웨어 제작이 훨씬 쉬워졌다는 같은 변화에서 출발함 “더 야심 차야 한다”는 의무보다는 “더 야심 찰 수 있다”는 가능성에 무게가 있음. 중요한 변화는 도구의 능력이 발전하면서 할 수 있는 일이 늘었다는 점임 소비자 입장에서는 작동하지 않는 저품질 소프트웨어와 부실한 벤치마크로 속도를 과장하는 제품을 경계해야 함 느린 소프트웨어를 빠르다고 홍보하는 문제와 최근 사례가 여기에 해당함 제작자 입장에서는 다른 사람이 저품질 결과물을 쏟아낸다는 이유로 같은 수준에 머물 필요가 없음. 테스트와 성능 측정을 제대로 하면 이전에는 엄두를 내지 못했던 프로젝트도 실용적인 수준까지 만들 수 있음 pgrust의 검증이 Postgres에도 남기는 가치 Michael Malis의 pgrust는 성능을 핵심 가치로 내세우지만, 검증 과정에서도 Postgres의 실제 문제를 발견함 수치 버그로 정상적인 SP-GiST 연산이 실패함 포맷 캐시 버그로 JSONPath에서 잘못된 결과가 나옴 pgcrypto 버그로 후속 연산이 실패함 사전 로더에서 여러 메모리 안전성 문제를 발견함 money 오버플로 버그도 발견함 사전 로더 문제는 버그로 인정되지 않았다는 반론이 있음. 해당 Postgres 사안에 대한 판단...