비즈니스 앱용 PostgreSQL vs Firebase — 실용적 고려사항

대부분의 비즈니스 앱이 실제로 필요로 하는 것

비즈니스 앱은 보통 화려하진 않지만 중요한 것들입니다: 운영용 내부 도구, 고객 포털, 관리자 패널, 지원 대시보드 등. 이러한 앱은 수익, 고객, 일상 업무와 밀접하기 때문에 데이터베이스 선택은 유행이 아니라 실제 워크플로우를 따라야 합니다.

대부분의 비즈니스 앱은 익숙한 데이터 형태를 갖습니다. 고객과 사용자, 그리고 상태를 거치는 객체들이 있습니다: 주문, 송장, 티켓, 반품, 작업 등. 또한 시스템을 안전하고 설명 가능하게 만드는 그림자 데이터도 필요합니다: 감사 로그, 타임스탬프, 누가 무엇을 언제 왜 바꿨는지 기록하는 데이터.

세 가지 요구사항이 반복해서 나타납니다:

• 정확성(숫자가 맞고 업데이트가 사라지지 않음)
• 명확한 접근 제어(팀이나 고객 간에 누가 무엇을 볼 수 있고 수정할 수 있는지)
• 리포팅(필터, 내보내기, 수동 작업 없이 기본 질문에 답하기)

이것이 보통 PostgreSQL vs Firebase를 고민하게 만드는 출발점입니다.

팀이 목록, 필터, 월간 보고서를 자주 다룬다면 데이터를 깔끔하고 일관되게 질의할 수 있는 능력이 매일 필요해집니다. 앱이 라이브 업데이트와 오프라인 우선 워크플로우에 기반한다면 실시간 동기화가 복잡한 조인보다 더 중요할 수 있습니다.

실용적인 선택 방법은 앱이 반드시 답해야 하는 일상적인 질문 세 가지를 적어보는 것입니다. 예: “미수금이 있는 고객은 누구인가?”, “지난 7일 동안 무엇이 변경되었나?”, “지난달 에이전트별로 해결한 티켓 수는?” 이 질문들이 비즈니스 운영의 핵심이라면, 이를 쉽게 그리고 신뢰성 있게 만들어 주는 데이터베이스를 선택하세요.

AppMaster 같은 노코드 플랫폼 위에서 빌드한다면 전체 제품 관점(데이터 모델, 비즈니스 로직, 접근 규칙, 사람들이 매일 사용하는 화면)을 생각하는 것도 도움이 됩니다. 앱이 커질 때 이 요소들이 일관성을 유지하게 해 주는 선택이 최선입니다.

리포팅과 분석: SQL이 가장 도움이 되는 곳

리포팅은 단순히 데이터에 질문을 던져 신뢰할 수 있는 답을 얻는 것입니다. SQL은 행 필터링(지난 분기), 그룹화(지역별), 테이블 조인(고객 + 송장), 합계나 평균 계산 같은 일상적 조작에 익숙하게 설계되어 있어 이 과정을 단순하게 만듭니다.

예를 들어 누군가가 즉석에서 “지난 분기 지역별 수익을 신규/재방문 고객으로 나눠 보여줘”라고 물으면 PostgreSQL에서는 보통의 쿼리입니다. Firebase 스타일의 문서형 데이터에서는 그 정확한 질문에 맞춰 데이터를 미리 모양을 맞추거나 많은 레코드를 끌어와 직접 계산하는 추가 코드를 써야 하는 경우가 많습니다. 그 결과 느린 리포트나 정의 불일치가 생기기 쉽습니다.

비즈니스 팀은 보통 피벗형 합계(주별, 지역별, 제품별), 드릴다운 테이블(지역 클릭 시 해당 지역의 송장 보기), 재무나 운영용 CSV 내보내기, 스케줄에 따라 새로고침되는 대시보드를 원합니다. SQL은 이런 스타일에 자연스럽게 맞습니다.

리포트는 오랜 기간 사용되기 때문에 스키마 변경이 조용히 문제를 일으킬 수 있습니다. 필드를 변경하거나 상태를 분리하거나 다중 통화를 추가하면 오래된 리포트의 의미가 아무도 모르게 바뀔 수 있습니다. PostgreSQL의 명확한 스키마를 이용하면 쿼리를 업데이트하고 뷰를 추가하며 정의를 안정적으로 유지할 수 있습니다.

비즈니스 앱에 PostgreSQL과 Firebase를 비교할 때, 리포팅이 결정적 역할을 하는 경우가 많습니다. PostgreSQL 기반 도구(예: AppMaster처럼 데이터를 PostgreSQL에 모델링하는 플랫폼)는 나중에 새로운 질문을 던질 때 분석과 내보내기를 더 단순하게 만들어 줍니다.

트랜잭션과 데이터 무결성: 조용한 데이터 오류를 피하기

비즈니스 앱에서 신뢰를 깨뜨리는 가장 빠른 방법은 화면에는 맞아 보이지만 내부적으로는 잘못된 숫자입니다. 여기서 트랜잭션과 무결성 규칙이 중요합니다.

간단한 재고 흐름을 상상해 보세요. 고객이 상품 3개를 구매하면 (1) 주문 생성, (2) 재고 감소, (3) 결제 또는 송장 기록을 해야 합니다. PostgreSQL에서는 이 단계를 하나의 트랜잭션으로 묶어 모두 성공하거나 모두 실패하게 할 수 있습니다. 어떤 단계가 실패하면(재고가 음수가 되거나 결제 기록을 만들 수 없을 때) 모든 변경이 롤백됩니다. 반만 완료된 주문이 남지 않습니다.

Firebase에서는 여러 경로나 문서에 걸쳐 데이터를 업데이트하는 경우 부분 쓰기가 발생하기 쉽습니다. Firebase는 트랜잭션 스타일 업데이트를 제공하지만 재시도, 오프라인에서의 동기화, 여러 레코드에 흩어진 업데이트 등을 직접 설계해야 합니다. 동일한 “주문 + 재고 + 결제” 변경이 분리된 쓰기로 처리되면 네트워크 문제로 재고만 감소하거나 주문이 없거나 기관 회계 항목이 없어진 상태가 될 수 있습니다.

PostgreSQL은 또한 잘못된 데이터가 저장되는 것을 애초에 막는 제약으로 보호합니다. 고유한 송장 번호, 외래 키(주문이 실제 고객을 가리키도록), 결제 필수 필드, 재고가 음수로 떨어지지 않도록 하는 체크 규칙 등은 각 화면에서 다시 구현할 필요 없는 안전망을 제공합니다.

재무와 컴플라이언스 흐름에서는 강한 일관성이 특히 중요합니다: 잔액, 승인, 감사 로그, 환불 같은 것은 나중에 대사(reconcile)해야 합니다. 실수를 통해 금전적 손해나 규제 리스크가 발생할 수 있는 부분은 데이터베이스가 자동으로 정확성을 강제할 수 있는 쪽을 선호하는 것이 유용한 규칙입니다.

AppMaster로 빌드하면 이는 PostgreSQL에서 핵심 비즈니스 레코드를 모델링하는 것으로 자연스럽게 매핑됩니다. Data Designer에서 테이블과 관계를 모델링하고 데이터베이스 규칙으로 오류를 초기에 잡을 수 있습니다.

접근 제어와 멀티테넌트 안전성

앱에 여러 종류의 사용자가 있다면 접근 제어는 선택 사항이 아닙니다. 간단한 시작점은 admin, manager, agent, customer 같은 역할을 두고, view, edit, approve, export, manage users 같은 실제 액션에 권한을 묶는 것입니다.

PostgreSQL과 Firebase를 비즈니스 앱 관점에서 비교할 때 가장 큰 차이는 규칙을 안전하게 어디에 강제할 수 있는가입니다. PostgreSQL에서는 데이터에 가까운 곳에 권한을 유지할 수 있습니다. 이는 한 실수로 다른 회사의 레코드가 노출되는 멀티테넌트 앱에서 중요합니다.

행 수준 접근(멀티테넌트)

많은 비즈니스 앱은 “같은 테이블, 다른 테넌트” 구조가 필요합니다. 예를 들어 매니저는 회사의 모든 티켓을 보고, 에이전트는 할당된 티켓만 보고, 고객은 자신의 것만 보도록 하는 규칙입니다.

PostgreSQL에서는 tenant_id 열과 행 수준 정책(row-level policies) 또는 일관된 쿼리 패턴으로 이를 처리하는 경우가 많습니다. 장점은 예측 가능성입니다: 어떤 화면이나 API 엔드포인트가 데이터를 다루든 동일한 규칙이 적용됩니다.

Firebase에서는 보안 규칙이 강력하지만 데이터 구조를 엄격히 관리해야 합니다. 비정규화된 데이터는 읽기 속도를 빠르게 하지만 데이터의 사본마다 테넌트 경계를 지키는지 보장하기 어렵게 만들 수 있습니다.

감사와 승인

접근 제어는 단순히 “누가 볼 수 있나”뿐 아니라 “누가 무엇을 언제 바꿨나”이기도 합니다. 초기에 감사 로그를 계획하세요: 레코드를 누가 생성/편집했는지 기록하고, 민감 필드(상태, 가격, 은행 정보)의 히스토리를 보관하며, 관리자 작업(역할 변경, 내보내기, 삭제)을 로깅하고 위험한 변경에 대한 승인 흐름을 지원하세요.

승인 워크플로는 직무 분리를 돕습니다. 한 사람이 환불을 요청하면 다른 사람이 승인합니다. AppMaster 같은 플랫폼은 이러한 흐름을 시각적으로 모델링하면서 PostgreSQL을 진실의 원천으로 유지할 수 있습니다.

실시간과 오프라인: Firebase가 더 적합한 경우

앱이 즉시 반응해야 하고 사용자가 화면에서 변화를 지켜보는 동안 업데이트가 보이길 기대한다면 Firebase가 개발 속도와 사용자 경험 면에서 유리합니다.

전형적인 실시간 사용 사례는 라이브 채팅, 프레즌스 표시(온라인, 입력 중, 보고 있음), 라이브 상태 보드(대기열 및 단계), 빠른 알림(새 티켓 할당), 간단한 체크리스트의 경량 협업 등입니다.

오프라인 모드는 현장 팀, 창고, 또는 연결이 불안정한 소매점에서는 선택 기능이 아닙니다. Firebase의 클라이언트 측 캐싱과 동기화는 오프라인 동작을 직접 구현하는 것보다 훨씬 ‘내장된’ 느낌을 줄 수 있습니다.

단점은 질의 능력입니다. Firebase는 “이 고객의 최신 20개 메시지 보여줘” 또는 “이 컬렉션 변경을 구독해” 같은 작업에는 좋지만 복잡한 필터, 조인, 월말 리포팅이 필요할 때는 불편합니다. 그 부분에서 PostgreSQL이 특히 강합니다(재무, 감사, 분석).

또한 기대치를 정하는 것이 도움이 됩니다. 비즈니스 사용자에게 ‘실시간’은 보통 네트워크 문제 중에도 완벽한 순서 보장이 아니라 1~2초 이내의 업데이트를 의미합니다. 앱이 짧은 충돌(두 사람이 같은 노트를 동시에 편집)이나 잠시의 충돌을 감내하고 깔끔하게 해결할 수 있다면 Firebase는 강력한 선택이 될 수 있습니다.

AppMaster 같은 노코드 도구 안에서 PostgreSQL과 Firebase를 비교할 때 현실적인 접근은 실시간 기능이 정말로 필요한 몇몇 화면에만 Firebase 스타일을 예약하고, 나머지 시스템은 나중에 리포팅하기 쉬운 데이터 모델에 기반하도록 유지하는 것입니다.

확장과 비용: 먼저 아프게 되는 것은?

PostgreSQL vs Firebase를 비교할 때 ‘확장’은 보통 세 가지 압력으로 나뉩니다: 동시에 접속하는 사용자 증가, 영구적으로 보관되는 데이터 증가, 자동화·모바일·통합에서 들어오는 쓰기 증가.

PostgreSQL에서는 첫 번째 고통이 보통 하나의 바쁜 데이터베이스에서 모든 일을 하게 될 때 나타납니다. 대시보드가 느려지거나 일일 리포트가 시간 초과되거나 무거운 쿼리 하나가 다른 작업을 끌어내리는 식입니다. 해결책은 대개 지루하지만 효과적입니다: 인덱스 개선, 리포트용 테이블과 트랜잭션 테이블 분리, 캐싱, 분석을 리플리카로 옮기기 등.

Firebase에서는 비용 폭탄이나 데이터 모델의 ‘핫 스팟’이 먼저 문제로 나타나는 경우가 많습니다. 작은 UI 기능 하나가 많은 읽기를 유발하고, 실시간 리스너가 이를 곱하기 때문에 비용이 예상보다 커집니다. 비용은 읽기·쓰기·저장 공간·클라이언트 연결 빈도에 의해 결정됩니다.

비용 예측에 영향을 주는 것

PostgreSQL 비용은 보통 서버 크기와 저장소(및 백업)에 대해 지불하기 때문에 예측하기 쉽습니다. Firebase는 초기에는 저렴할 수 있지만 사용량 기반 과금이기 때문에 설계 선택 하나가 비용에 큰 영향을 미칠 수 있습니다.

간단한 압력 테스트 방법은: 사용량이 10배로 늘어나면 비용과 성능이 어떻게 되는가를 물어보는 것입니다.

운영 오버헤드(평이한 용어로)

PostgreSQL은 백업, 마이그레이션, 모니터링, 튜닝에 신경 써야 합니다. Firebase는 일상 운영의 일부를 줄여주지만 데이터 모델링, 보안 규칙, 사용량 지표에 더 신경 써야 합니다.

AppMaster 같은 플랫폼으로 빌드하면 예측 가능한 리포팅을 위해 PostgreSQL로 시작하고, 정말 필요할 때 실시간 부분을 추가할 수 있어 전체를 재구축하지 않아도 됩니다.

과도하게 고민하지 않고 선택하는 단계별 방법

PostgreSQL vs Firebase 사이에서 고민될 때는 데이터베이스 기능이 아니라 일상의 작업에서 시작하세요. 이 결정 프로세스는 대부분의 경우에 해결책을 줍니다.

1. 핵심 워크플로 세 가지를 적고 절대 실패하면 안 되는 부분에 표시하세요(송장 생성, 결제 환불, 지원 티켓 종료 등). 이런 부분에서 실수가 금전 손실이나 기록의 혼란을 초래한다면 PostgreSQL과 엄격한 트랜잭션을 선택하세요.
2. 사람들이 얼마나 자주 새로운 질문을 데이터를 대상으로 할지 결정하세요. “지난 분기 지역·담당·제품별로 보여줘” 같은 질문이 주간 단위로 자주 나온다면 SQL 리포팅은 핵심 요구사항입니다.
3. 한 페이지에 권한 구조를 스케치하세요. 몇 개의 역할이면 되나요, 아니면 테넌트별 규칙과 행 수준 안전이 필요한가요? 복잡할수록 서버 측 제어와 감사 친화적 데이터의 이점이 커집니다.
4. 실시간과 오프라인에 대해 솔직해지세요. 업데이트를 즉시 볼 수 있어야 하나요(디스패치, 채팅, 현장 팀), 아니면 네트워크가 불안정한 환경에서 작업을 계속할 수 있어야 하나요? 후자라면 Firebase 스타일 동기화가 그만한 가치가 있습니다.
5. v1의 기본값을 정하고 아직 지원하지 않을 기능을 적어두세요(예: v1에는 오프라인 모드 없음, 대시보드 외의 즉석 리포팅 없음). 이렇게 하면 계획에 없는 하이브리드로 서서히 빠지는 것을 막을 수 있습니다.

간단한 예: 일일 파이프라인 리포트와 재무로의 깔끔한 인수인계를 필요로 하는 내부 영업 앱은 보통 PostgreSQL 우선이 적절합니다. 나중에 “누가 이 딜을 편집 중인지” 같은 실시간 뷰가 필요하면 그 화면에 실시간 기능을 추가하되 진실의 원천은 안정적으로 유지하세요.

AppMaster로 빌드하면 Data Designer에서 PostgreSQL 모델링으로 시작하고, 정말 필요한 곳에만 실시간 스타일 업데이트를 추가할 수 있어 전체를 다시 쓰지 않아도 됩니다.

하이브리드가 의미가 있을 때(그리고 아닐 때)

PostgreSQL과 Firebase가 서로 다른 역할을 명확히 맡을 때 하이브리드는 잘 작동합니다. 두 시스템이 동일한 비즈니스 데이터를 모두 소유하려 하면 금방 혼란스러워집니다. 현실적으로 하이브리드는 강한 트랜잭션과 리포팅을 빠른 실시간 업데이트와 섞는 경우가 많습니다.

일반적인 패턴은 PostgreSQL을 진실의 원천으로 두고 Firebase를 라이브 피드로 사용하는 것입니다. 예를 들어 지원 대시보드는 Firebase로 새 티켓을 즉시 보여주고, 티켓 자체의 상태·담당자·SLA 타임스탬프 같은 핵심 필드는 PostgreSQL에 커밋합니다.

다른 패턴은 반대입니다: Firebase가 클라이언트 동기화와 오프라인 작업을 처리하고 PostgreSQL은 리포팅과 감사를 담당합니다. 이는 사진 업로드와 오프라인 노트가 필요한 현장 팀에 맞을 수 있지만 월간 리포트와 규정 준수를 위한 깔끔한 SQL 테이블을 유지합니다.

일관성이 가장 어렵습니다. 가장 안전한 접근은 정보 쓰기에는 한 곳만 두고, 외부로 퍼뜨리는 방식으로만 사용하는 것입니다.

데이터를 일관되게 유지하는 방법

한 가지 규칙을 사용하세요: 한 번 쓰고 팬아웃하라(write once, then fan out). 팬아웃하는 데이터는 최소화하고 읽기 모델과 알림에만 집중하세요.

각 워크플로에 대해 어느 시스템이 트랜잭션을 소유하는지 결정하세요(결제, 승인, 재고 업데이트 등). 동일한 필드를 두 시스템이 소유하지 않게 하세요. TicketCreated, StatusChanged 같은 불변 이벤트로 동기화하고 재생이 중복 청구나 중복 집계를 초래하지 않도록 설계하세요.

하이브리드가 나쁜 생각인 경우

실시간으로 많은 필드에 대해 엄격한 일관성이 필요하거나(예: 재무 원장) 팀이 동기화 문제를 모니터링·디버그할 역량이 없으면 하이브리드를 피하세요. 가장 큰 경고 신호는 동일한 필드의 두 출처(예: 상태가 Firebase와 PostgreSQL 둘 다에 존재)입니다. 이것이 무음 불일치의 시작입니다.

AppMaster로 빌드한다면 트랜잭션 테이블은 PostgreSQL에 두고 실시간 피드는 파생 뷰로 취급해 마스터 레코드로 삼지 않는 것이 안전합니다.

예시 시나리오: 영업과 지원이 하나의 앱에서

중견 기업을 상상해 보세요. 두 팀이 같은 내부 앱을 사용합니다: 영업은 파이프라인(리드, 딜, 단계)을 추적하고, 지원은 티켓을 운영합니다. 매니저는 두 팀을 합친 주간 리포트를 원합니다. 이 지점에서 PostgreSQL vs Firebase 문제가 현실로 다가옵니다.

일부 동작은 항상 정확해야 합니다. 두 사람이 동시에 클릭해도 지원 리드가 티켓을 할당할 때 티켓은 정확히 한 사람에게 할당되고 변경 사항이 기록되어야 합니다. 딜을 "Proposal"에서 "Won"으로 옮기고 예상 수익을 업데이트하며 송장 요청을 트리거하는 것도 트랜잭션 중심 순간입니다. 이런 경우 강한 규칙과 명확한 감사 추적이 필요합니다.

다른 부분은 속도와 프레즌스에 관한 것입니다. 지원 에이전트는 큐가 즉시 업데이트되는 것, 댓글이 누군가 입력하는 동안 나타나는 것, 중복 답변을 피하기 위한 "누가 보고 있는지" 표시를 선호합니다. 영업팀도 실시간 협업을 좋아하지만 실시간 업데이트 누락의 비용은 할당 오류보다 보통 낮습니다.

리포팅은 조용히 커지는 요구입니다. 매니저는 주간 KPI(첫 응답 시간, 해결 시간, 승률, 파이프라인 커버리지), 딜과 티켓의 전체 변경 이력, 재무용 내보내기(기간별 수익, 환불, 지원 비용 태그)를 요구할 것입니다.

현실적인 분할은 진실의 원천을 PostgreSQL에 두는 것입니다(딜, 티켓, 할당, 상태 이력, 사용자 역할). 이렇게 하면 무결성과 리포팅이 깔끔하게 유지됩니다. Firebase는 실시간 협업이 필요한 부분(타이핑 표시, 접속 상태, 라이브 큐 뷰, 단기 채팅 스타일 댓글)에만 사용하고 해당 데이터는 일시적(디스포저블)으로 취급하세요.

재작업을 초래하는 흔한 실수

많은 팀이 데이터베이스 선택을 후회하진 않습니다. 대신 데이터 형태, 권한, 소유권에 대한 지름길을 후회합니다. PostgreSQL vs Firebase 논쟁에서 고통스러운 재작성은 보통 실시간 기능 하나를 위해 선택하고 그 결과로 둘째 날의 요구(리포트, 감사, 안전)를 잊었을 때 발생합니다.

흔한 패턴은 먼저 실시간 업데이트 중심으로 화면을 만들고 나중에 “지난 분기 지역별로 환불을 몇 건 했나?” 같은 기본 질문에 답하기 어렵고 느리다는 것을 발견하는 것입니다. 이후에 내보내기와 스크립트를 추가할 수는 있지만, 이는 깨끗한 리포팅 계층 대신 영구적인 임시 해결책이 되기 쉽습니다.

또 다른 문제는 멀티테넌트 앱에서 권한을 과소평가하는 것입니다. 처음에는 "사용자는 자기 회사만 볼 수 있다"라고 간단히 시작하지만 곧 역할, 팀, 레코드 소유자, 예외가 생깁니다. 이를 초기에 모델링하지 않으면 여러 곳에서 규칙을 패치하게 되고 여전히 에지 케이스를 놓치게 됩니다.

재작성으로 이어지는 실수들: 클라이언트가 제어하면 안 되는 필드(가격, 역할, tenant_id, 상태)를 편집하게 허용, 간단한 읽기 규칙으로 모든 것을 커버할 수 있다고 가정하고 복잡한 역할을 나중에 추가, 속도를 위해 데이터를 여러 시스템에 중복 저장하면서 소유권을 결정하지 않음, 안정적 스키마나 이벤트 이력이 없는 모델에 리포팅을 붙임, 누군가 "이걸 누가 언제 바꿨나?"라고 물어볼 때까지 감사 로그를 생략함.

노코드 도구에서도 민감한 업데이트는 백엔드 로직에 두어 검증하고 기록하며 규칙을 일관되게 강제하세요.

빠른 체크리스트와 다음 단계

PostgreSQL vs Firebase 사이에서 막혔다면 첫날에 앱이 반드시 해야 할 일을 중심으로 생각하세요. 목표는 완벽한 선택이 아니라 전체를 다시 쓰지 않고 변경할 수 있는 안전한 v1을 만드는 것입니다.

다음 질문에 예/아니오로 답해보세요:

• 사람들이 신뢰할 수 있는 멀티테이블 리포팅(필터, 조인, 내보내기, 대시보드)이 필요한가?
• 부분 저장이 허용되지 않는 엄격한 트랜잭션(금전, 재고, 승인)이 필요한가?
• 사용자가 오프라인 모드에서 작업해야 하나?(현장 업무, 창고, 열악한 수신 환경)
• 실시간 업데이트(라이브 큐, 채팅, 프레즌스, 긴급 알림)가 필요한가?
• 팀과 테넌트를 위한 강력한 접근 제어가 필요한가?(한 앱에 여러 고객)

그런 다음 한 문장으로 써보세요: 시스템 오브 레코드(진실이 어디에 있는가)와 동기/알림 레이어(기기가 업데이트를 받는 방식). 많은 팀은 혼란을 피하기 위해 진실의 원천을 한 곳에 두고 다른 도구는 속도와 사용자 경험을 위해 사용합니다.

하나의 워크플로를 골라 끝까지 완성한 뒤 다음으로 넘어가세요. 예: 주문 생성 -> 승인 -> 배송 -> 리포트에 표시. 그 단일 흐름이 빠르게 트랜잭션 누락, 리포팅 부족, 권한 문제를 드러냅니다.

빠르게 PostgreSQL 기반 비즈니스 앱을 진행하고 싶다면 AppMaster (appmaster.io)는 PostgreSQL에서 데이터 모델을 도와주고, 시각적으로 비즈니스 로직을 만들며 웹과 네이티브 모바일 앱을 배포할 수 있게 설계되어 있어 요구사항이 바뀔 때 실제 소스 코드를 생성해 줍니다.