저도 처음 Azure를 배울 때 정말 헷갈렸습니다. “App Registration이 있고, App Service도 있고, 그럼 뭐가 다른데?” 특히 회사에서 Databricks를 연결하고, PostgreSQL을 사용하라고 하면서 “App Registration도 해야 하나요?” 라는 질문을 받을 때마다 제대로 설명하기 어려웠습니다. 그런데 한 가지 깨달았습니다. 이 둘을 올바르게 이해하면 Azure의 80% 이상의 작업이 명확해진다는 것입니다. 이번 글에서는 정말로 실무에 필요한 개념들을 명확하게 정리해드리겠습니다.
가장 먼저 알아야 할 핵심: 완전히 다른 것들이다
App Registration과 App Service는 이름은 비슷하지만 역할이 완전히 다릅니다. 이것을 먼저 이해하면 나머지는 자동으로 따라옵니다. App Registration은 “신원 카드를 만드는 것”이고, App Service는 “실제 집을 짓는 것”이라고 생각하세요.
더 정확하게 설명하면 App Registration은 Microsoft Entra ID(이전 Azure AD)에서 애플리케이션을 등록하는 것입니다. 이것은 보안과 인증에 관련된 작업입니다. 반면 App Service는 실제 웹 애플리케이션을 클라우드에서 호스팅하는 서비스입니다. 이것은 인프라와 배포에 관련된 작업입니다.
생각해봅시다. 당신이 새로운 회사에 입사한다고 상상해보세요. 먼저 HR에서 직원 신분증을 만들어줍니다. 이것이 바로 App Registration입니다. 그 다음 회사의 사무실이라는 물리적 공간이 있어야 일을 할 수 있습니다. 이것이 바로 App Service입니다. 신분증(App Registration)이 없으면 보안상 회사 시스템에 접근할 수 없고, 사무실(App Service)이 없으면 일을 할 공간이 없습니다. 둘 다 필요하지만 완전히 다른 역할을 합니다.
App Registration: 신원을 Azure에 등록하는 일
App Registration이 정확히 뭘 하는지 설명해봅시다. App Registration은 당신의 애플리케이션이 Azure의 다른 서비스들과 안전하게 통신할 수 있도록 허가를 받는 과정입니다.
예를 들어, 당신이 만든 웹 애플리케이션이 Microsoft 365에 접근해야 한다고 합시다. 또는 Databricks에서 데이터를 가져와야 한다고 합시다. 또는 Azure Key Vault에서 보안 키를 꺼내야 한다고 합시다. 이런 모든 경우에 “당신의 앱이 누구인지”, “이 앱이 뭘 할 권한이 있는지” Azure가 알아야 합니다. 이것을 가능하게 해주는 것이 바로 App Registration입니다.
App Registration을 하면 다음 것들이 생성됩니다. 먼저 Application ID라는 것이 있습니다. 이것은 당신의 앱의 고유한 식별자입니다. 마치 주민등록번호처럼 전세계에서 유일합니다. 그 다음 Client Secret이라는 게 있습니다. 이것은 앱이 자신을 증명할 수 있는 암호같은 것입니다. 그리고 Redirect URI라는 것도 있습니다. 이것은 사용자가 로그인하고 나서 돌아올 주소입니다.
여기서 중요한 점은 App Registration은 “단순히 등록만 하는 것”이라는 것입니다. 아직 애플리케이션이 실제로 어디에서 실행되는지는 정의하지 않습니다. 등록만 하고 끝입니다. 실제로 실행되는 곳은 App Service 같은 다른 곳에서 합니다.
App Service: 실제로 애플리케이션을 실행하는 곳
App Service는 당신의 웹 애플리케이션이 실제로 돌아가는 곳입니다. 이것은 Platform as a Service(PaaS)라고 불리는데, 이것은 “당신이 코드만 작성하면 나머지는 우리가 관리할게”라는 뜻입니다.
App Service는 여러 가지 타입이 있습니다. 가장 인기 있는 것부터 순서대로 설명해드리겠습니다.
1위: Web Apps (웹 애플리케이션)
Web Apps는 가장 많이 사용되는 App Service 타입입니다. 당신의 웹사이트나 REST API를 호스팅하는 데 사용됩니다. .NET, Java, Node.js, Python, PHP 등 다양한 언어를 지원합니다. 당신이 Visual Studio나 VS Code에서 만든 웹 애플리케이션을 그대로 배포할 수 있습니다. 용량을 자동으로 조절할 수 있고, SSL 인증서를 쉽게 추가할 수 있고, CI/CD를 GitHub Actions나 Azure Pipelines로 자동화할 수 있습니다.
실제로 대부분의 회사 웹사이트, 내부 포털, 고객 대면 애플리케이션은 Web App에서 호스팅됩니다. 예를 들어 당신의 회사가 WordPress 블로그를 만들거나, React 기반의 대시보드를 만들거나, Spring Boot 백엔드를 만든다면 모두 Web Apps를 사용합니다.
2위: API Apps (API 애플리케이션)
API Apps는 REST API를 특별하게 최적화한 App Service 타입입니다. 기능적으로는 Web Apps와 거의 같지만, API를 중심으로 설계되었습니다. Swagger 문서 자동 생성, API 버전 관리, 개발자 포털 같은 API 전용 기능들이 내장되어 있습니다. 여러 클라이언트(모바일 앱, 웹 앱, 데스크톱 앱)에게 데이터를 제공하는 백엔드 API를 만들 때 사용합니다.
3위: Function Apps (서버리스 함수)
Function Apps는 특정 이벤트나 일정에 따라 실행되는 작은 코드 조각을 호스팅합니다. “서버리스”라고 불리는 이유는 당신이 서버를 관리할 필요가 없고, 필요할 때만 실행되기 때문입니다. 예를 들어, 누군가 파일을 업로드하면 자동으로 이미지를 리사이징하고 저장하는 함수를 만들 수 있습니다. 또는 매일 자정에 데이터를 정리하는 함수를 만들 수 있습니다. 사용한 만큼만 돈을 내기 때문에 가벼운 작업에 최적화되어 있습니다.
4위: Mobile Apps (모바일 백엔드)
Mobile Apps는 iOS, Android, Windows 같은 모바일 앱의 백엔드를 호스팅합니다. 푸시 알림, 오프라인 동기화, 인증 같은 모바일 앱에 필요한 기능들이 미리 내장되어 있습니다. 요즘은 Web Apps나 Function Apps로도 모바일 백엔드를 만들 수 있어서 사용량이 줄어들었지만, 여전히 필요한 경우가 있습니다.
5위: Logic Apps (워크플로우 자동화)
Logic Apps는 개발자가 아닌 사람도 사용할 수 있는 시각적 워크플로우 도구입니다. “만약 이메일이 오면 Slack에 알림을 보내고, 그 내용을 Excel에 기록하고, 나한테도 따로 알림을 줘”라는 식의 복잡한 자동화를 코드 없이 만들 수 있습니다. RPA(로보틱 프로세스 오토메이션)처럼 사용할 수 있습니다.
이제 실제 질문에 답해봅시다: Databricks는 어떻게 연결하나?
당신의 회사에서 “Databricks를 사용하되, 직원들이 회사 계정으로 로그인할 수 있게 해줘”라고 한다면 어떻게 할까요?
먼저 App Registration을 Azure Entra ID에서 해야 합니다. 이것은 “Databricks라는 애플리케이션이 회사의 신원 시스템(Azure Entra ID)과 연결될거야”라는 것을 등록하는 것입니다. Application ID와 Client Secret을 복사합니다. 그 다음 Databricks의 설정에서 이 정보들을 입력합니다. 그러면 직원들이 Databricks에 접근할 때 자동으로 회사 계정으로 로그인됩니다.
여기서 중요한 점은 Databricks 자체는 App Service가 아니라는 것입니다. Databricks는 독립적인 SaaS(Software as a Service) 서비스입니다. Databricks를 Azure에 호스팅하는 게 아니라, Databricks 회사가 제공하는 서비스를 사용하고, 단지 Azure의 신원 시스템(Entra ID)과 연결하는 것입니다. 따라서 필요한 것은 App Registration뿐입니다.
PostgreSQL은? 직접 연결할 수 있나요?
이번엔 다른 질문입니다. “App Service에서 PostgreSQL에 접근해야 하는데, 어떻게 하죠?”
가장 간단한 방법은 그냥 connection string을 사용하는 것입니다. “postgres://사용자이름:암호@서버주소:5432/데이터베이스이름” 이렇게 직접 연결합니다. App Registration이 필요 없습니다. PostgreSQL은 그냥 데이터베이스 서비스일 뿐, 인증이 필요한 Azure 서비스가 아니기 때문입니다.
하지만 더 보안적으로 좋은 방법이 있습니다. 바로 Managed Identity를 사용하는 것입니다. 이것은 “당신의 App Service가 이미 Azure의 신원을 갖고 있으니, 그 신원으로 PostgreSQL에 접근해”라는 뜻입니다. 이 방법을 쓰면 암호를 저장할 필요가 없어서 더 안전합니다.
App Registration을 명시적으로 등록할 필요는 없습니다. App Service를 만들면 자동으로 내부적인 신원이 생기기 때문입니다.
정리: 언제 뭘 해야 할까?
이제 패턴이 보일 것입니다.
당신이 Azure 서비스(Microsoft 365, Azure Key Vault, Databricks 같이 Entra ID와 연결된 서비스)와 상호작용해야 한다면 App Registration을 해야 합니다. 단순한 데이터베이스(PostgreSQL, MySQL, SQL Server)와 연결만 하려면 App Registration이 필요 없습니다. 직접 connection string으로 연결하거나, Managed Identity를 사용합니다.
그리고 언제든 애플리케이션을 실제로 클라우드에서 돌려야 한다면 App Service를 사용합니다. Web Apps, API Apps, Function Apps 중 당신의 목적에 맞는 것을 선택합니다.
실제 예시로 정리해봅시다
당신의 회사가 다음을 하고 싶다고 합시다. 한 가지는 웹 기반의 데이터 분석 대시보드를 만드는 것입니다. 다른 한 가지는 Databricks의 데이터를 이 대시보드에 표시하는 것입니다.
그러면 이렇게 합니다. 첫째, Azure Entra ID에서 App Registration을 합니다. 이것은 “이 대시보드 애플리케이션이 Databricks와 통신할 권한이 있다”는 것을 증명합니다. 둘째, App Service의 Web Apps에 대시보드 코드를 배포합니다. 셋째, Databricks에 App Registration의 정보를 입력해서 SSO(Single Sign-On)를 설정합니다. 넷째, 데이터는 PostgreSQL에 저장되어 있으니, 대시보드에서 PostgreSQL에 직접 연결하는 connection string을 사용합니다.
이런 식으로 작업하면 깔끔합니다. 각각의 서비스가 자신의 역할을 명확히 합니다.
2026년 기업에서 자주 하는 실수
많은 팀이 App Registration과 App Service의 차이를 모르면서 시간을 낭비합니다. 특히 다음과 같은 실수가 많습니다.
“Databricks를 사용하려면 App Service도 만들어야 하나요?”라고 묻는 경우가 있습니다. 아닙니다. Databricks는 독립적인 SaaS 서비스이므로, App Registration만 하면 됩니다. 앱을 호스팅할 필요가 없다면 App Service는 만들 필요 없습니다.
반대로 “PostgreSQL에 접근하려면 App Registration을 해야 하나요?”라고 묻기도 합니다. 아닙니다. PostgreSQL은 단순한 데이터베이스이므로, connection string으로 직접 연결하면 됩니다.
가장 흔한 실수는 이미 필요 없는 App Registration을 계속 유지하는 것입니다. 예를 들어, 과거에 특정 SaaS 서비스와 통합하기 위해 App Registration을 했는데, 나중에 그 서비스를 사용하지 않게 됐을 때도 App Registration을 삭제하지 않는 경우가 많습니다. 이건 보안 위험이 됩니다.
실무에서 확인할 체크리스트
당신이 새로운 Azure 프로젝트를 시작할 때 이 체크리스트를 사용하세요.
먼저 당신이 호스팅해야 할 애플리케이션이 있는가요? 있으면 App Service를 만들고 코드를 배포합니다. 당신의 애플리케이션이 Entra ID와 연결된 Azure 서비스(Databricks, Microsoft 365 API, Azure Key Vault 등)와 통신해야 하나요? 그럼 App Registration을 합니다. 당신의 애플리케이션이 데이터베이스에 접근해야 하나요? PostgreSQL이라면 connection string으로 직접 연결합니다. 더 보안적으로 하고 싶다면 Managed Identity를 사용합니다.
이 질서를 따르면, 당신의 Azure 아키텍처는 명확하고 유지보수하기 쉬워집니다.
최후의 조언
App Registration과 App Service는 완전히 다릅니다. 이것을 이해하는 순간 Azure가 훨씬 더 명확해집니다. App Registration은 “신원 등록”, App Service는 “애플리케이션 호스팅”이라고 딱 구분하면 됩니다. 그리고 각 서비스(Databricks, PostgreSQL 등)에 대해 “이 서비스는 Entra ID와 연결되어 있나? 아니면 그냥 데이터베이스나 SaaS 서비스인가?”라고 스스로에게 물어보면, 뭘 해야 할지 자동으로 답이 나옵니다.
이해가 명확해지면, 나머지 Azure 개념들도 훨씬 쉬워질 것입니다. App Registration과 App Service의 차이를 완벽히 이해한 당신이라면, 이제 Azure 엔터프라이즈 아키텍처의 대부분을 설계할 수 있습니다.