사용자와 단 한 명도 대화하기 전에 14,000줄의 코드를 만들었습니다. 제가 배운 것은 다음과 같습니다.

저자는 처음에는 풀 리퀘스트 내의 Python 코드 변경에 대한 적대적 테스트를 수행하도록 설계된 GitHub 앱인 LogoMesh를 개발했습니다. 이 앱은 적대적 입력을 생성하고 강화된 Docker 샌드박스에서 테스트를 실행하여 버그를 식별하는 것을 목표로 했습니다. 앱의 고급 기능과 기술적 정교함에도 불구하고, 심각한 문제에 직면했습니다. 실제 풀 리퀘스트에서 앱의 침묵률이 높았고, 보고된 많은 결과가 관련 없는 아티팩트였습니다. 결정적으로, 앱의 성능은 느렸고, 높은 지연 시간으로 원하는 시간 범위를 초과했습니다. 이는 저자가 근본적인 결함을 깨닫게 했습니다: 초기 가정을 검증하지 않고 구축했다는 것입니다. 저자는 진정한 문제점이 미래의 버그를 예방하는 것이 아니라, 기존의 프로덕션 버그를 처리하는 데 있다는 것을 깨달은 후 초점을 전환했습니다. 이 깨달음은 더 간단한 해결책으로 이어졌습니다: Sentry URL을 기반으로 실패하는 pytest를 생성하여 충돌을 재현하는 도구입니다. 이 도구는 Docker 샌드박스와 같이 LogoMesh를 위해 개발된 핵심 기술을 활용하지만, 다른 목적을 가지고 있습니다. 현재, 저자는 프로덕션 버그를 수정하기 전에 재현 테스트를 생성하는 것이 보편적인 문제인지 평가하고 있습니다. 그들은 적절한 사용자 입력 없이 또 다른 도구를 구축하는 대신, 실제 문제점을 해결하고 있는지 확인하기 위해 검증을 구하고 있습니다. 저자는 자신이 실제 문제를 해결하고 있는지, 아니면 단순히 개인적인 워크플로우 비효율성을 해결하고 있는지 의문을 제기합니다.