Power Automate vs Graph API: 업무 자동화, 언제 무엇을 쓰나
4 분 소요
Microsoft 365 환경에서 “이 업무를 자동화하고 싶다"고 하면 경로가 둘 나옵니다. 클릭으로 흐름을 조립하는 Power Automate, 그리고 실무 입문 시리즈에서 다뤄 온 Graph API 직접 호출입니다. 같은 목적지에 도착하는 다른 교통수단이라서 “뭐가 더 좋냐"는 질문은 성립하지 않고, “이 작업에는 어느 쪽이 맞느냐"만 성립합니다. 이 글은 그 판단 기준을 정리합니다.
두 도구의 정체 #
- Power Automate: 트리거(메일 도착, 폼 제출, 일정 시각)와 액션(행 추가, 승인 요청, 메시지 전송)을 커넥터로 이어 붙이는 로우코드 자동화 서비스입니다. 커넥터는 Microsoft 365 전반은 물론 서드파티 SaaS까지 수백 종 이상 제공됩니다. 내부적으로는 상당수 커넥터가 결국 Graph API를 호출합니다.
- Graph API: 같은 데이터와 기능을 코드에서 직접 호출하는 REST API입니다. 언어 제약이 없고, 앱 등록과 권한 관리(실무 입문 #2)를 직접 합니다.
즉 둘의 관계는 경쟁이라기보다 포장의 차이입니다. Power Automate는 Graph(및 각 서비스 API)를 시민 개발자가 쓸 수 있게 포장한 층이고, 포장이 곧 강점이자 한계가 됩니다.
Power Automate가 이기는 경우 #
- 트리거 기반의 가벼운 흐름: “폼이 제출되면 Excel에 행을 추가하고 Teams에 알린다” 같은 흐름은 15분이면 만들어집니다. 같은 것을 코드로 하면 웹훅 수신부, 인증, 배포 인프라부터 세워야 합니다.
- 승인 흐름: 승인 요청 카드 발송, 응답 대기, 결과 분기가 내장 기능입니다. 사람의 결재가 끼는 자동화에서는 이 내장 승인 하나가 개발 며칠 치를 대신합니다.
- 현업 주도(시민 개발): 부서 담당자가 자기 업무를 직접 자동화할 수 있다는 것 자체가 가치입니다. IT 팀의 백로그를 거치지 않습니다.
- 연결의 폭: 서드파티 SaaS까지 포함한 커넥터 생태계는 개별 API를 일일이 배우는 비용을 없애 줍니다.
Graph API가 이기는 경우 #
- 볼륨과 성능: 수만 건 처리, 병렬 호출, 배치 요청, 스로틀링 대응(실무 입문 #7) 같은 것은 코드의 영역입니다. Power Automate는 흐름 실행 횟수·API 호출량에 한도와 성능 제약이 있어 대량 처리에 맞지 않습니다.
- 복잡한 로직: 조건이 몇 단계로 중첩되고 데이터 변환이 많은 흐름은 로우코드 캔버스에서 오히려 읽기 어려워집니다. 화면 가득한 중첩 조건 블록은 코드 20줄보다 유지보수가 힘듭니다.
- 엔지니어링 수명 주기: 자동화가 “부서 편의"를 넘어 “운영 시스템"이 되는 순간 버전 관리, 코드 리뷰, 테스트, CI/CD, 환경 분리가 필요해지고, 전부 코드 쪽이 압도적으로 성숙합니다.
- 세밀한 권한 통제: 앱 권한의 범위를 최소로 설계하고 감사하는 통제는 직접 앱 등록 쪽이 명확합니다. Power Automate의 연결은 만든 사람의 계정 권한으로 동작하는 경우가 많아, 그 사람의 퇴사·이동이 흐름의 장애로 이어지는 고전적 사고 패턴이 있습니다.
숨은 변수: 라이선스와 소유권 #
기술 비교만으로 결정하면 두 가지 복병을 만납니다.
- 프리미엄 커넥터와 라이선스: 기본 Microsoft 365 라이선스에 포함되는 표준 커넥터와 달리, HTTP 커넥터를 포함한 프리미엄 커넥터·기능은 별도 Power Automate 라이선스가 필요합니다. “무료인 줄 알고 만들었는데 확장하려니 유료"가 되는 지점이 여기입니다. 반면 Graph API 호출 자체에는 별도 과금이 없습니다(인프라 비용은 별도).
- 소유권과 수명: 개인 계정에 묶인 흐름은 그 사람과 함께 사라집니다. 부서 업무에 쓰이는 흐름은 공유 소유권·서비스 계정으로 만들고 목록을 관리해야 하며, 이것이 안 되는 조직에서는 “아무도 모르는 흐름이 갑자기 멈추는” 사건이 반복됩니다.
실무 분업 기준: 섞어 쓰는 것이 정답입니다 #
정리하면 판단 축은 세 개입니다. 볼륨(건수·빈도), 복잡도(로직·변환), 수명(일회성 편의인가 운영 시스템인가). 셋 다 낮으면 Power Automate, 하나라도 높으면 Graph 쪽으로 기울입니다.
| 상황 | 권장 |
|---|---|
| 폼 제출 → 기록 → 알림, 하루 수십 건 | Power Automate |
| 사람 승인이 끼는 결재성 흐름 | Power Automate (내장 승인) |
| 수천〜수만 건 일괄 처리, 야간 배치 | Graph API |
| 시스템 간 연동, 복잡한 변환·분기 | Graph API |
| 조직 표준 자동화(온보딩 등 운영 시스템) | Graph API + CI/CD |
그리고 이 둘은 이어 붙일 수 있습니다. 흔한 하이브리드가 무거운 처리는 Graph를 쓰는 백엔드(Azure Functions 등)가 맡고, 트리거와 사람 상호작용(승인, 알림)은 Power Automate가 맡는 구조입니다. 각자 잘하는 일을 맡기면 됩니다.
정리 #
- Power Automate는 Graph를 포함한 API들을 로우코드로 포장한 층입니다. 경쟁 관계가 아니라 포장의 차이입니다.
- 트리거 기반의 가벼운 흐름, 내장 승인, 현업 주도 자동화는 Power Automate가 빠르고 쌉니다.
- 볼륨, 복잡한 로직, 버전 관리·CI/CD, 세밀한 권한 통제가 필요해지는 순간 Graph API가 맞습니다.
- 프리미엄 커넥터 라이선스와 개인 계정 종속이라는 두 복병을 설계 단계에서 확인해야 합니다.
- 판단 축은 볼륨·복잡도·수명 세 가지이고, 트리거·승인은 Power Automate + 무거운 처리는 Graph 백엔드라는 하이브리드가 실무 표준입니다.