Hacker News 의견

• 서버리스는 초기 작은 프로젝트에는 좋았지만, AWS Lambda는 큰 애플리케이션에서는 유지보수 지옥임 (빌드, 의존성, 디버깅, 배포 느림 등)
  • 그럼에도 2019년에 배포한 Lambda 기반 리액트 웹앱이 아직도 아무 변경 없이 작동 중이라는 점은 인상적임
  • 유지보수 문제는 프레임워크 때문이라는 반론도 있으며, 모듈형 설계와 로컬 개발을 병행하면 대부분 해결 가능
  • Lambda는 종종 런타임 업데이트가 필요하며, 이는 오랫동안 문제 없다가 갑자기 중단되는 형태로 나타날 수 있음
  • 의존성이 적다면 업데이트는 쉽지만, 오래된 런타임에 의존하는 경우 미리 준비하는 것이 중요함
• 서버리스는 간헐적이고 상태 없는 워크로드에 적합하며, 내부/외부 JSON API에 잘 맞음
  • 하지만 지나친 감성적 서술보다는 서버리스가 전가의 보도가 아님을 명확히 설명했으면 더 좋았을 것이라는 의견
  • 서버리스는 자체 복구력이 좋고, 상태를 갖는 시스템(컨테이너 등)보다 운영 부담이 적음
  • 그럼에도 컨테이너의 개발 모델이 더 낫다는 의견도 있음 — 어디서든 실행 가능하지만, 상태 관리와 확장성에 한계 존재
• 컨테이너는 본질적으로 상태를 갖지 않으며, 상태를 추가할 수 있을 뿐임
  • 큰 조직에서는 결국 Kubernetes(K8s)가 표준이 되고, 이는 컨테이너의 간결함과는 거리가 있음
  • K8s도 플랫폼 팀이 있다면 단순하게 운영 가능하나, 그런 환경은 드물다는 지적
• GCP Cloud Run은 저평가된 서버리스 플랫폼으로, 사용 시점 기준으로만 비용을 청구해 경제적임
• AWS Lambda에서 Postgres 연결이나 bcrypt 사용은 가능하지만, 설정과 실행이 매우 번거로웠다는 피드백 있음
  • 드라이버를 직접 빌드해야 하고, libc 버전 차이로 인한 문제 발생
  • 로컬 테스트 환경도 명확하지 않아 시행착오가 많음
• 해당 글은 마치 Sliplane을 홍보하는 글처럼 보인다는 지적 있음
  • "비즈니스 로직을 Lambda에 넣기보단, 클라우드 환경을 프로그래밍하는 용도로 써야 한다"는 의견도 존재
  • 서버리스 덕분에 작은 팀이 큰 규모의 서비스를 운영 가능하지만, 복잡성 문제는 여전히 존재
  • 컨테이너 기술을 배운 사람이 자신의 경쟁력을 높이기 위해 모두에게 컨테이너 사용을 강요하는 것처럼 보인다는 비판도 있음
• 1세대 서버리스 플랫폼(AWS Lambda 등)은 확장성과 상태 관리에 어려움이 있음
  • 2세대 플랫폼은 컨테이너 기반 서버리스로 진화 중이나, 컨테이너에 상태를 추가하는 건 스케일링 시 큰 문제 유발
  • 예: "Docker volume 추가로 상태 유지"는 확장성을 고려하지 않은 위험한 조언임
  • 글에서 언급한 “10개 컨테이너로 확장 + 자체 DB 운영” 등의 내용은 현실적으로 불가능하거나 비효율적인 주장으로 평가됨
• 일부는 이 글을 "공정한 평가"라고 보지만, 다른 이들은 지나치게 감성적이거나 상업적 의도가 짙다고 판단