해커뉴스(Hacker News) 댓글 반응 요약

1. 점진적 배포와 스케일링 전략 부재 (Start Small)

• '빅뱅' 방식의 필연적 실패: 국가 단위 프로젝트를 한 번에 배포하는 것은 자살행위임. 작은 단위(마을→도시→국가)로 순차 검증하며 확장하는 전략 필수.
• 제품 vs 시스템의 차이: 왓츠앱 같은 단일 제품과 달리, 복잡한 엔터프라이즈 시스템은 초기부터 거대한 스케일을 감당해야 하므로 접근법이 달라야 함.
• 핵심 솔루션: "작게 만들고, 검증 후 기능을 추가하라"는 원칙이 무시되고 있음.

2. 경영진의 무능과 책임 회피 (Management Issues)

• 책임 없는 권력 구조: 프로젝트 실패 시 개발자는 야근으로 수습하지만, 결정권자인 경영진은 책임을 지지 않거나 오히려 보너스를 챙기는 모순적 구조 비판.
• 기술 이해도 결여: 기술적 난이도를 무시한 비현실적 일정 강요와 '나쁜 소식'을 듣기 거부하는 상명하복 문화가 문제 해결을 가로막음.
• 정치적 의사결정: 기술적 적합성보다 사내 정치나 외부 벤더와의 관계(리베이트 등)에 의해 솔루션이 결정되는 경향.

3. 통제 불가능한 요구사항과 복잡성 (Complexity & Scope Creep)

• 프로세스 단순화 선행 부재: 피닉스 프로젝트 사례처럼 8만 개의 급여 규칙을 정리하지 않고 그대로 전산화하려는 시도가 근본 원인. 엉망인 오프라인 프로세스는 엉망인 디지털 시스템을 낳을 뿐임.
• 잦은 요구사항 변경: 프로젝트 진행 중 경영진이나 고객의 변덕으로 인한 과업 범위 확장(Scope Creep)이 프로젝트를 늪으로 빠뜨림.

4. 개발자 문화와 잘못된 인센티브 (Developer Culture)

• 이력서 주도 개발 (RDD): 프로젝트 성공보다 본인의 이직에 유리한 최신 유행 기술(프레임워크)을 무리하게 도입하여 기술적 부채를 가중시킴.
• 학습의 단절: 2~3년 주기의 잦은 이직(Job Hopping) 문화로 인해, 개발자가 자신이 만든 코드의 장기적 실패를 목격하고 교훈을 얻을 기회가 차단됨.
• 재발명 집착: 검증된 기존 솔루션을 활용하기보다 자신의 자아 실현을 위해 처음부터 코드를 다시 짜는 비효율적 관행.

5. 소프트웨어 공학의 특수성 (Engineering Nature)

• 물리적 제약 부재: 건축/하드웨어와 달리 소프트웨어는 물리적 제약이 없어 무한한 복잡성을 허용하게 되며, 이것이 통제 불능 상태를 유발함.
• 과거 학습 부재: 타 공학 분야는 실패(예: 다리 붕괴)를 철저히 분석하고 교훈을 남기지만, 소프트웨어 업계는 "이번엔 다르다"며 과거의 실수를 반복하는 'YOLO'식 개발 행태를 보임.