Heroku

배포는 Heroku 원격 저장소로 푸시하는 것과 같다. GitHub에 푸시하는 방식과 동일하다. Heroku가 언어를 감지하고 의존성을 설치하고 앱을 빌드해 릴리스한다. 배포가 잘못되면 롤백은 명령 하나다. 금요일에 출시하는 부담이 줄어든다.

앱은 dyno에서 실행된다. Heroku가 대신 관리해 주는 가벼운 컨테이너다. 확장은 숫자 하나다. 웹 트래픽용 dyno를 더 추가하거나 백그라운드 작업용 워커 dyno를 돌린다. 머신을 프로비저닝하거나 스케줄러를 조정하지 않는다. 그럼 함정은 어디에 있을까? dyno는 단위당 청구되고, 웹 dyno 여러 개에 24시간 도는 워커까지 필요한 바쁜 앱은 눈치채지 못하는 사이 작은 월 청구서를 훨씬 큰 금액으로 바꿔 놓을 수 있다.

Heroku는 Postgres, Redis, Kafka를 애드온으로 제공하며 모두 CLI 명령 하나로 준비하고 연결한다. 자격 증명은 앱 설정에 자동으로 들어가므로 연결 문자열을 손으로 다룰 일도, 운영 비밀번호를 잘못된 환경 파일에 붙여 넣을 위험도 없다. 그게 전부다.

Heroku는 공식 buildpack을 통해 Node.js, Python, Ruby, Java, Go, PHP, Scala, Clojure를 실행한다. 스택은 사용자가 고르고 플랫폼이 맞춘다. 그게 요점이다. 이 유연성 덕분에 작은 팀은 특정 호스트의 제약에 맞추려고 작동하는 코드를 다시 쓰지 않고 이미 아는 언어를 계속 쓸 수 있다.

데이터베이스 외에도 애드온 마켓플레이스는 로깅, 모니터링, 이메일, 검색 등을 아우른다. 각 애드온은 앱에 붙고 같은 대시보드에 나타난다. 다섯 개의 별도 서비스에 가입해 그 자격 증명을 새벽 두 시에 손으로 설정에 꿰매 넣지 않고도 운영 도구를 빠르게 갖추는 방법이다.

Pipelines는 스테이징과 운영 앱을 연결해 빌드를 환경 사이로 승격하게 해 준다. review apps는 pull request마다 임시 인스턴스를 띄우므로 동료가 병합 전에 실제 URL을 클릭할 수 있다. 작은 팀이 추가 도구 없이 지속적 전달을 얻는다. CI 설정은 필요 없다.

Heroku는 이제 Model Context Protocol(MCP) 지원을 제공해 AI 에이전트가 표준화된 인터페이스로 플랫폼 리소스와 상호작용하게 한다. 앱과 에이전트를 같은 토대 위에 연결하려는 Salesforce의 행보의 일부다. 에이전트 주도 워크플로를 만드는 개발자에게는 수많은 맞춤형 통합을 손으로 엮지 않고 앱의 실시간 맥락과 컴퓨팅 자원에 닿는 방법이다.