12-Factor App 재게시: Heroku 시대 원칙의 유효성과 환경 변수 비밀값 논쟁

12단계 MFA 데모인 줄 알았음. 폰을 다른 방에 두고 일하려 하면 SMS 번호 입력하라길래 그냥 노트북을 닫게 됨.

Heroku가 그때는 미래 같았는데, Azure 설정의 이상한 부분과 씨름할 때마다 우리가 더 단순한 미래를 잃었다는 생각이 듦.

Heroku는 너무 비싸진 뒤 인수됐음. 결국 AWS ECS로 갔는데 여전히 비싸도 고객들은 Heroku 청구서보다 Amazon 청구서는 덜 불평하더라.

Fly.io가 쉬운 배포 경험 일부를 되살리고 있음. Cloud Run도 제대로 된 서버리스라는 점에서 써볼 만함.

이 원칙은 아직도 유효함. 문제는 개발자가 몰라서인지, 며칠 안에 끝내라고 요구하는 관리층 때문인지 모르겠음.

지난 5년간 인턴과 주니어 약 50명을 뽑았는데, 내가 알려주기 전까지 이 방법론을 들어본 사람이 한 명도 없었음.

매번 읽을 때 포트 바인딩이나 연결 리소스가 너무 당연해서 무엇이 새로웠는지 궁금했음. JDBC 연결 문자열로 DB를 붙이는 정도를 말하는 건가 싶음.

포트 바인딩은 Tomcat이나 mod_php처럼 웹 서버에 모듈로 얹던 방식에 대한 반론이었음. 연결 리소스는 DB와 캐시를 코드 변경 없이 설정으로 교체하라는 뜻이고, 당시에는 앱과 DB를 같은 호스트에 함께 올리는 경우도 많았음.

지금은 뻔해 보여도 당시에는 컨테이너 이전의 웹 서버 운영 방식을 바꾸자는 얘기였음. Heroku가 클라우드 앱, 자동 확장, 컨테이너화를 바라보는 방식에 영향을 줬다고 봄.

WebSphere 같은 환경에서는 여러 앱이 힙을 공유하기도 했음. 12가지 원칙은 Heroku가 각 문제에 가진 해법을 팔기 쉽게 만든 면도 있지만, 당시 운영 문제도 실제로 심했음.

나는 10년 전 회사에서 일했는데 12가지 원칙을 전부 어기고 있었음. 지금 당연한 기준도 당시에는 아니었음.

15분만 읽어도 배울 점이 많고 여전히 유효하다고 봄. 다만 3장처럼 자격 증명을 환경 변수에 넣으라는 조언은 로컬 비밀값을 ~/.bashrc에 넣는 습관을 퍼뜨려서 문제였음.

설정 파일 대신 환경 변수로 옮기는 건 비밀값을 바꾸기 쉬워서임. Kubernetes Pod에 비밀값을 하나 또는 여러 개로 주입하고 있는데, 환경 변수 말고 무엇을 권하는지 궁금함.

12 Factor에는 환경 자체가 안전하다는 전제가 있음. 개발자가 프로덕션 환경 변수를 바꾸거나 코드 배포로 같이 바꿀 수 있다면 배포 파이프라인이 잘못된 것이고, .env는 소스에 커밋하면 안 됨.

앱에 비밀값을 전달할 방법은 어차피 필요함. 다른 방식도 결국 로컬 비밀값을 부주의하게 다루는 문제를 똑같이 겪는 것 아닌가?