스타트업에 AWS Cognito를 써봤다. 다시는 안 쓸 것이다.
I Used AWS Cognito for a Startup. I Wouldn't Do It Again
스타트업 인증 시스템을 구축하며 AWS Cognito를 사용한 개발자가 겪은 악몽 같은 경험을 솔직하게 풀어낸 글. 문서의 혼란, Amplify v6의 파괴적인 변경, 로컬 개발의 어려움, 제한적인 커스터마이징, 그리고 되돌릴 수 없는 설정 실수까지. 개발자 경험을 우선시해야 한다는 교훈을 전한다.
그건 업그레이드가 아니라 인질극이었다.
HN 토론
117- wilkystyle
Cognito 문서를 읽다 보면, 누군가 세 개의 다른 매뉴얼을 가져다가 블렌더에 넣고, 맛을 내기 위해 약간 오래된 Stack Overflow 답변을 뿌려 놓은 것 같은 느낌이 든다.
이것은 기본적으로 모든 AWS 문서에서 경험하는 바와 같다. 거의 항상 (1) 실제로 쓸모없을 정도로 너무 높은 수준이거나, (2) 너무 장황해서 내가 파악하려는 내용에 도달하기 전에 걸러내야 할 방대한 양의 불필요한 정보가 있는 경우다.
한 가지 예로, 최근에 AWS Partner Central 계정을 AWS Management 계정과 연결해야 했는데, 그 과정과 문서가 몹시 복잡했다: https://docs.aws.amazon.com/partner-central/latest/getting-...
- solatic
다음에는 AWS 서비스 통합 편의성보다 개발자 경험을 우선시하는 도구를 고르겠다. Cognito 문제를 디버깅하는 데 잃은 시간이면 유료 인증 제공업체를 몇 년 동안 이용할 수 있었을 것이다.
원한다면 사용자 비밀번호 해시를 내보내서 다른 공급업체로 원활하게 마이그레이션할 수 있게 해주는 유료 인증 제공업체가 얼마나 될까?
인증의 핵심 문제는 (a) 로그인 화면이 인증되지 않은 사용자에게 표시되는데, 여기에는 공격자도 포함되며, 그들은 사용자 비밀을 탈취하려고 DDoS부터 정교한 악성 입력까지 모든 수단을 동원하기 때문에, 이미 대규모 프로덕션 규모로 운영되고 프로덕션에서 많은 시행착오를 겪은 무언가를 선택하고 싶다는 점과, (b) 관리형 공급업체를 이용해야 하는 필요성이 로컬 개발, 공급업체 독립성, 데이터 이식성, 그리고 기타 모범 개발 사례(TM)와 상당히 상충된다는 점이다.
물론 AWS Cognito는 형편없다. 여러 면에서 제품이 정체된 느낌이다. 제품을 출시하고, 작동하게 하고, 안정적으로 만들기 위해 절충하는 것은 짜증난다. 하지만 솔직히 말해서, (b)를 (a)보다 선호하지 않는 한(특히 방화벽 뒤의 인트라넷 애플리케이션처럼 그러한 공격에 취약하지 않은 경우에는 그렇게 할 때가 있다) Keycloak 같은 것을 선택하지 않는 한, Cognito보다 훨씬 나쁜 선택을 할 수도 있다(으, Okta, 으).
- patwolf
Cognito에 대한 내 경험은 작성자의 경험과 정확히 일치한다. 예전에는 주로 Auth0를 사용했지만, 비용이 더 저렴해서 새 프로젝트에는 Cognito로 전환했다.
이메일 주소가 대소문자를 구분하는 것이 마음에 들지 않고, 이제 그것을 바꾸고 싶다고? 죄송하지만, 새 사용자 풀을 처음부터 만들어야 한다. 마이그레이션할 방법이 없다.
- mannyv
Cognito 팀과 비밀번호 재설정에 대해 이야기했던 기억이 난다. 비밀번호를 설정할 수 있는 것이 필수 기능이라고 그들과 논쟁했었다. 그들은 "아니요, 재설정 흐름을 거치지 않아도 되는 경우가 왜 있겠어요? 그건 보안 문제예요."라고 했다. 물론 몇 주 후에 모든 관리자가 그렇게 해야 하기 때문에 그들은 그 기능을 추가했다. 그래서 어느 시점에는 운영 경험이 전혀 없는 사람들이 그 기능을 작업하고 있었다.
Cognito의 두 가지 장점은 (1) 로컬에 자격 증명 없이 서비스에 로그인할 수 있게 해주고, (2) Cognito 자격 증명을 통해 AWS 리소스에 대한 액세스를 제공할 수 있다는 것이다. 아마 지금은 그렇게 할 수 있겠지만, 많은 솔루션은 여전히 기기 내 키를 요구한다... 이것은 명백한 보안 문제다.
또한, 자체 백엔드를 인증에 사용하면 인증이 Cognito 안에 갇히지 않기 때문에 관리가 더 쉬웠다.
- cldcntrl
Cognito에는 정말 거친 부분이 있는데, 이 글은 그 중 어떤 것도 언급하지 않는다.
예를 들어 Cognito를 통해 SAML 통합을 제대로 구현해 본 적이 있다면 그 흐름이 얼마나 난해한지 알 것이다. 실제로 서비스를 중단시키는 버그를 고치기 위해 Cognito 팀과 협력해야 했다.
확실히 AWS의 가장 세련된 서비스는 아니지만, 안팎을 안다면 사용할 만하다.
- mikigraf
백업이나 이런 서비스에서 기대할 수 있는 다른 기본 기능에 대해서는 말도 꺼내지 마라. AWS는 인수(Auth0나 Wristband 같은 작은 회사?)를 통해 서비스를 재구축하거나, 그냥 없애버려야 한다. 그 대신, 기업들이 의존하는 중요한 서비스가 림보 상태에 갇혀 있다.
- nater5000
AWS Cognito가 가장 쉬운 인증 서비스가 아니라는 데 동의하지 않는 것은 아니지만, 일단 파악하고 나면 다른 서비스만큼 잘 작동한다.
나는 작성자가 설명한 것과 똑같은 고통(그리고 훨씬 더 많은)을 겪었다. 하지만 중요한 것은 일단 그 고통을 겪고 나면 그것을 처리하는 방법을 안다는 것이다. 소프트웨어에서는 한 번만 파악하면 끝이다.
Cognito 사용량을 엄청나게 확장했다고 말할 수는 없지만, 모든 것을 AWS에 유지하는 것이 그 번거로움을 감수할 만하다고 말할 수 있다(적어도 상황에 따라 다르지만). Cognito는 실제 사용자 지정 옵션을 많이 제공한다(호스팅 UI는 초기 테스트에만 좋고, 그 후에는 버려라). 그리고 물론 LLM은 다른 인증 서비스와 마찬가지로 Cognito를 쉽게 처리할 수 있다. 내가 Cognito를 설정할 때 LLM을 사용할 수 있는 특권은 없었지만, 여전히 내가 선호하는 인증 방법이고 Claude도 그것에 걸려 넘어지지 않는다.
- dabinat
개인적으로 나는 특정 공급업체에 묶여 있고, 해당 공급업체가 형편없는 서비스를 제공하거나 가격을 크게 올리면 전환하기 어려운 기술 위에 내 사업을 세우지 않을 것이다.