title: "The Twelve-Factor App 개인적 해석 1/2"
description: "web app, SaaS와 같은 서비스형 소프트웨어를 구축하기 위한 일종의 Best Practice인 Twelve-Factor 앱에 대한 개인적 해석 1/2"
cleanUrl: /sw-engineer/twelve-factor-app-1
ogImage: "<https://anyflower.notion.site/image/https%3A%2F%2Fprod-files-secure.s3.us-west-2.amazonaws.com%2F7570d2fc-66b1-4e23-bb3c-ff7b56842b0d%2F2efa5b50-7046-4a99-820e-24bceb4c38ad%2FUntitled.png?table=block&id=024eb3a9-a407-4d5d-8654-4bbbd043d634&spaceId=7570d2fc-66b1-4e23-bb3c-ff7b56842b0d&width=2000&userId=&cache=v2>"
floatFirstTOC: right
이미지 출처: https://www.codemotion.com/magazine/wp-content/uploads/2022/05/12-factor-app-process-1024x791.png
web app, SaaS와 같은 서비스형 소프트웨어를 구축하기 위한 일종의 Best Practice인 Twelve-Factor 앱에 대한 개인적 해석이다. 얼마 전에야 우연히 마주쳤는데, Google이나 Red Hat, Wikipedia에도 소개되는 등 꽤나 유명한 듯. 알고보니 무려 2011년에 발행되었다고. 알게 모르게 이미 따르고 있는 관례가 대부분이지만 이들 중 중요한 사항을 추출하고 명시화했다는 점이 유의미해보인다. 다음은 주로 참조한 문서.
Google Cloud에서의 Twelve-Factor App 개발 | 클라우드 아키텍처 센터
아래는 한국어로 번역된 The Twelve-Factor App 방법론 링크이다. 여담으로, 번역을 누군가 해줘서 고맙기는 한데, 요즘엔 자동 번역 품질이 너무 좋다보니 그 고마움이 반감되고는 하는게 함정. 오히려 잘못된 의역의 위험이 줄기에 이를 더 선호하기도. 실제 아래 번역에서 그 위험성이 보인다. backing service를 백엔드 서비스라 번역을…
Google Cloud 문서의 표현을 그대로 옮긴다.
Twelve-Factor 설계를 활용하면 앱 구성요소를 분리할 수 있으므로 각 구성요소를 쉽게 바꾸거나 원활하게 확장 또는 축소할 수 있습니다. 이러한 요소는 모든 프로그래밍 언어 또는 소프트웨어 스택과는 별개이므로 Twelve-Factor 설계를 다양한 앱에 적용할 수 있습니다.
One codebase tracked in revision control, many deploys (버전 제어로 추적되는 단일 코드베이스, 다수의 배포)
이미지 출처 : https://12factor.net/codebase
요즘에 이렇게 사용하지 않는 경우가 있나 싶기도. 여튼, Git과 같은 버전 관리 시스템을 사용하고, 단일 app에는 단일의 독립적 (Git) repository를 사용하란 이야기이다.
GitOps 시대의 git branching 모델 : TBD(Trunk Based Development) 관점에서 위의 단일 repo에 대응하는 다수의 환경은 developer 1, 2 경우 개별 branch로 표현되고 staging은 trunk (main 또는 master) branch에, production은 trunk branch의 특정 commit에 version tagging된 무엇일 듯. 관련 Red Hat 문서는 배포 스크립트 조차도 단일 codebase로의 통합을 논하는데, GitOps를 위한 Git 관리 전략에서는 application code와 configuration code 분리를 논한다는 데 충돌이 있다. 개인적으로는 RedHat이 좀 과격히 해석한 것이 아닌가 싶다.
