드래그앤드롭 프로세스 디자인의 실수와 리팩터 방법

드래그앤드롭 워크플로우가 망가지는 이유

비주얼 프로세스 에디터는 전체 흐름을 볼 수 있어서 안전해 보입니다. 하지만 다이어그램은 거짓말을 할 수 있습니다. 실제 사용자, 실제 데이터, 실제 타이밍 문제가 드러나면 깔끔해 보이던 워크플로우가 운영에서 실패할 수 있습니다.

많은 문제는 다이어그램을 체크리스트처럼 다루고, 실제로는 프로그램이라는 사실을 무시하는 데서 옵니다. 블록은 여전히 로직을 담고 있고, 상태를 만들고, 분기하고, 재시도하며 부작용을 일으킵니다. 그 부분들이 명확하지 않으면 "작은" 편집이 동작을 조용히 바꿔버립니다.

워크플로우 안티패턴은 반복적으로 문제를 일으키는 나쁜 형태입니다. 단일 버그가 아니라 습관 같은 것입니다. 예를 들어 다이어그램 한 구석에서 설정된 변수를 다른 곳에서 사용해 중요한 상태를 숨기거나, 흐름이 너무 커져 아무도 전체를 이해할 수 없게 만드는 식입니다.

증상은 익숙합니다:

• 같은 입력이 실행마다 다른 결과를 만듦
• 값이 어디서 바뀌었는지 알 수 없어 디버깅이 추측이 됨
• 작은 수정이 관련 없는 경로를 깨뜨림
• 수정이 분기를 더 늘림
• 실패 시 일부 단계만 적용된 채로 남음(일부는 성공, 일부는 실패)

먼저 비용이 적고 눈에 보이는 것부터 시작하세요: 명확한 이름, 단단한 그룹화, 죽은 경로 제거, 각 단계의 입력과 출력을 명확히 하기. AppMaster 같은 플랫폼에서는 Business Process를 집중적으로 유지해 각 블록이 한 가지 일만 하고 데이터를 공개적으로 전달하도록 하는 것이 흔한 방법입니다.

그다음 구조적 문제에 대해 더 깊은 리팩터링을 계획하세요: 얽힌 흐름 풀기, 의사결정 중앙화, 부분 성공에 대한 보상 추가. 목표는 더 예쁜 다이어그램이 아니라, 매번 동일하게 동작하고 요구가 바뀔 때 안전하게 변경할 수 있는 워크플로우입니다.

숨은 상태: 놀라움의 조용한 근원

많은 비주얼 워크플로우 실패는 하나의 보이지 않는 문제에서 시작합니다: 의존하지만 명확히 이름 붙이지 않은 상태입니다.

상태는 워크플로우가 올바르게 동작하기 위해 기억해야 하는 모든 것입니다. 변수(예: customer_id), 플래그(예: is_verified), 타이머와 재시도, 그리고 다이어그램 밖의 상태: 데이터베이스 행, CRM 레코드, 결제 상태, 이미 발신된 메시지 등이 포함됩니다.

숨은 상태는 그 "기억"이 예상치 못한 곳에 있을 때 나타납니다. 흔한 예는 변수처럼 동작하는 노드 설정(하드코딩된 ID, 기본 상태), 의도적으로 설정하지 않은 암묵적 기본값, 또는 데이터를 변경하지만 명확히 드러나지 않는 부작용입니다. 어떤 단계가 "체크"만 하는 것처럼 보여도 상태 필드를 업데이트하는 경우가 고전적인 함정입니다.

작은 편집을 할 때까지는 잘 동작하다가 문제가 발생하곤 합니다. 노드를 이동하거나, 서브플로우를 재사용하거나, 기본값을 바꾸거나, 새 분기를 추가하면 갑자기 워크플로우가 "무작위"로 동작하기 시작합니다. 변수 값이 덮어써지거나 플래그가 리셋되지 않았거나 외부 시스템이 약간 다른 값을 반환하기 때문입니다.

상태가 숨는 곳(깔끔해 보이는 다이어그램에서도)

상태는 대체로 다음에 숨습니다:

• 변수처럼 동작하는 노드 설정(하드코딩된 ID, 기본 상태)
• 이전 단계의 암묵적 출력("마지막 결과 사용")
• 읽기만 하는 단계가 쓰기도 하는 경우(DB 업데이트, 상태 변경)
• 과거 동작을 기억하는 외부 시스템(결제, 이메일/SMS 제공자, CRM)
• 분기가 바뀐 뒤에도 계속 실행되는 타이머와 재시도

대부분의 놀라움을 막는 규칙

상태를 명시적으로 이름 붙이세요. 값이 나중에 중요하면 명확한 이름의 변수로 저장하고 한 곳에서 설정하며 작업이 끝나면 리셋하세요.

예를 들어 AppMaster’s Business Process Editor에서는 중요한 출력은 노드가 이전에 실행되었다는 사실만으로 "있다고 아는" 것이 아니라 일급 변수로 취급하세요. status를 payment_status로 이름 바꾸고, 확인된 결제 응답 후에만 설정하는 작은 변화가 다음 달에 흐름이 바뀔 때 수시간의 디버깅을 절약해줍니다.

스파게티 플로우: 다이어그램이 읽히지 않을 때

스파게티 플로우는 연결선이 여기저기 얽히고 단계가 놀랍게 되돌아가며 조건이 너무 깊게 중첩되어 아무도 확대/스크롤 없이 기본 경로를 설명할 수 없는 비주얼 프로세스입니다. 다이어그램이 냅킨 위에 그린 지하철 지도처럼 느껴진다면 이미 대가를 치르고 있는 것입니다.

이로 인해 리뷰가 신뢰할 수 없게 됩니다. 사람들은 엣지 케이스를 놓치고 승인은 느려지며 한 구석의 변경이 먼 곳을 깨뜨릴 수 있습니다. 인시던트 동안에는 "마지막으로 실행된 단계가 무엇인가?"나 "왜 이 분기로 들어갔나?" 같은 기본 질문에 답하기 어렵습니다.

스파게티는 보통 선의에서 자랍니다: 한 번만 쓰려고 작동하는 분기를 복사-붙여넣기하거나, 압박 속에 임시 수정 추가, 예외 처리를 중첩 조건으로 쌓기, 재사용 가능한 서브프로세스를 만들지 않고 이전 단계로 되돌아가기, 비즈니스 규칙·데이터 포맷팅·알림을 같은 블록에 섞기 등입니다.

흔한 예는 온보딩입니다. 처음엔 깔끔하지만 무료 체험, 파트너 추천, 수동 검토, VIP 처리용으로 별도 분기가 늘어납니다. 몇 스프린트 지나면 다이어그램에 "문서 수집"으로 여러 곳에서 되돌아가고 환영 이메일을 보내는 곳이 여러 군데 생깁니다.

더 건강한 목표는 단순합니다: 공통 케이스용 하나의 메인 경로와 예외용 명확한 사이드 경로. AppMaster’s Business Process Editor 같은 도구에서는 반복 로직을 재사용 가능한 서브프로세스로 추출하고, 분기를 의도별로 이름 붙이며(예: "Needs manual review"), 루프를 명시적이고 제한되게 유지하는 것이 흔한 방법입니다.

결정 과부하와 규칙 중복

흔한 패턴은 긴 조건 노드 체인입니다: A를 체크하고, 나중에 다시 A를 체크하고, 다른 세 곳에서 B를 체크합니다. "한 규칙만 더"라는 생각으로 시작하지만 워크플로우는 작은 변경이 큰 부작용을 일으키는 미로가 됩니다.

더 큰 위험은 여기저기 흩어진 규칙들이 서서히 서로 어긋나는 것입니다. 한 경로는 신용 점수가 높아 신청을 승인합니다. 다른 경로는 오래된 단계가 "전화번호 누락"을 강제 차단으로 처리해 같은 신청을 막습니다. 각각은 지역적으로 합리적일 수 있지만 합쳐지면 일관되지 않은 결과를 만듭니다.

중복 검사들이 충돌을 일으키는 이유

같은 규칙이 다이어그램 곳곳에 반복되면 한 복사본만 업데이트하고 다른 복사본은 놓칩니다. 시간이 지나면 비슷해 보이지만 다른 검사들이 생깁니다: 하나는 "country = US", 다른 하나는 "country in (US, CA)", 세 번째는 대리로 "currency = USD"를 사용합니다. 워크플로우는 실행되지만 예측 불가능해집니다.

좋은 리팩터는 결정을 하나로 통합해 작고 명확한 결과 집합을 내놓는 것입니다. AppMaster’s Business Process Editor에서는 관련 검사를 하나의 결정 블록으로 그룹화하고 분기를 의미있게 만드는 경우가 많습니다.

결과는 단순하게 유지하세요. 예를 들면:

• Approved
• Needs info
• Rejected
• Manual review

그다음 흐름 전반에 작은 결정을 뿌리는 대신 모든 것을 그 하나의 결정 지점을 통해 라우팅하세요. 규칙이 바뀌면 한 번만 업데이트하면 됩니다.

구체적 예: 가입 검증 워크플로우에서 이메일 형식을 세 군데서 검사(OTP 전, OTP 후, 계정 생성 전)한다면 모든 검증을 "Validate request" 결정으로 옮기세요. 결과가 "Needs info"면 사용자가 무엇이 빠졌는지 정확히 알려주는 하나의 메시지 단계로 라우팅하고, 나중에 일반 오류로 실패하게 하지 마세요.

부분 성공 후 보상 단계 누락

가장 비용이 큰 실수 중 하나는 워크플로우가 전부 성공하거나 전부 실패한다고 가정하는 것입니다. 현실의 흐름은 자주 중간에 성공합니다. 나중 단계가 깨지면 엉망이 됩니다: 돈은 결제되었고 메시지는 발송되었고 레코드는 생성되었지만 되돌릴 방법이 없습니다.

예: 고객 카드에서 결제를 한 뒤 주문을 생성하려고 하는데 인벤토리 서비스 타임아웃으로 주문 생성이 실패합니다. 결제는 성공했고 주문이 없으니 서포트는 항의 이메일을 받고 재무는 결제를 확인하지만 시스템에는 매칭되는 주문이 없습니다.

보상(compensation)은 부분 성공 후 실패할 때 실행되는 "되돌리기"(또는 "안전 상태로 만들기") 경로입니다. 완벽할 필요는 없지만 의도적이어야 합니다. 일반적 접근법은 작업을 역전시키기(환불, 취소, 초안 삭제), 결과를 안전한 상태로 전환(예: "Payment captured, fulfillment pending" 표시), 컨텍스트와 함께 수동 검토로 라우팅, 재시도가 중복 청구나 중복 전송을 막도록 멱등성 체크를 사용하는 것입니다.

보상을 어디에 두느냐가 중요합니다. 모든 정리를 다이어그램 끝의 하나의 "error" 박스에 숨기지 마세요. 위험한 단계 옆에 놓으세요. 그때는 결제 ID, 예약 토큰, 외부 요청 ID 같은 필요한 데이터가 아직 있을 때입니다. AppMaster 같은 도구에서는 일반적으로 호출 직후에 이러한 ID를 저장한 뒤 성공 vs 실패로 즉시 분기하는 방식입니다.

유용한 규칙: 외부 시스템과 통신하는 모든 단계는 다음 두 질문에 답해야 합니다: "우리가 무엇을 변경했나?" 그리고 "다음 단계가 실패하면 어떻게 되돌리거나 통제할 수 있나?"

외부 호출에 대한 약한 오류 처리

많은 실패는 워크플로우가 시스템을 벗어나는 순간 나타납니다. 외부 호출은 느린 응답, 일시적 장애, 중복 요청, 부분 성공 등 지저분하게 실패합니다. 다이어그램이 "호출이 성공했다"고 가정하고 계속 진행하면 사용자는 누락된 데이터, 이중 청구, 잘못된 시점에 전송된 알림을 보게 됩니다.

먼저 실패할 수 있는 단계를 표시하세요: 외부 API, 결제 및 환불(예: Stripe), 메시지(이메일/SMS, Telegram), 파일 작업, 클라우드 서비스 등입니다.

두 가지 흔한 함정은 타임아웃 누락과 무작정 재시도입니다. 타임아웃이 없으면 느린 요청 하나가 전체 프로세스를 멈출 수 있습니다. 재시도는 규칙 없이 하면 상황을 악화시키기도 합니다. 예: 같은 메시지를 세 번 보내거나 서드파티 시스템에 중복 생성을 할 수 있습니다.

이럴 때 멱등성(idempotency)이 중요합니다. 간단히 말해 멱등한 동작은 다시 실행해도 안전한 동작입니다. 워크플로우가 단계를 반복해도 두 번째 청구, 두 번째 주문, 두 번째 "환영" 메시지를 만들지 않아야 합니다.

실용적 수정은 호출 전에 요청 키와 상태를 저장하는 것입니다. AppMaster’s Business Process Editor에서는 "payment_attempt: key=XYZ, status=pending" 같은 레코드를 작성한 뒤 응답 후에 "success" 또는 "failed"로 업데이트하는 방식이 간단하고 효과적입니다. 단계가 다시 실행되면 먼저 그 레코드를 확인하고 어떻게 처리할지 결정하세요.

신뢰할 수 있는 패턴은 다음과 같습니다:

• 타임아웃과 재시도 한계 설정(어떤 오류가 재시도 가능한지 정의)
• 호출 전에 요청 키와 현재 상태 저장
• 외부 호출 수행
• 성공 시 결과를 기록하고 상태를 완료로 표시
• 실패 시 오류를 기록하고 사용자 친화적 복구 경로로 라우팅

과중한 단계와 불분명한 책임

흔한 실수는 하나의 단계에 입력 검증, 값 계산, DB 쓰기, 사람 알림 등 네 가지 일을 조용히 넣는 것입니다. 효율적으로 느껴지지만 변경이 위험해집니다. 무언가가 깨지면 어떤 부분이 원인인지 모호하고, 안전하게 재사용하기도 어렵습니다.

과중한 단계를 발견하는 방법

단계 이름이 모호할 때(예: "Handle order") 한 문장으로 출력을 설명할 수 없다면 과중한 단계입니다. 입력 목록이 길고 그 중 일부만 사용된다면 또 다른 경고 신호입니다.

과중한 단계는 대개 다음을 혼합합니다:

• 검증과 변경(저장/업데이트)
• 비즈니스 규칙과 표현(메시지 포맷팅)
• 한 곳에서 여러 외부 호출
• 명확한 순서 없이 여러 부작용
• 불분명한 성공 기준(무엇이 "완료"를 의미하는가?)

명확한 계약을 가진 작은 블록으로 리팩터

큰 단계를 작은 블록으로 쪼개 각 블록이 하나의 작업만 하고 명확한 입력과 출력을 갖게 하세요. 간단한 네이밍 규칙이 도움이 됩니다: 단계는 동사(Validate Address, Calculate Total, Create Invoice, Send Confirmation), 데이터 객체는 명사로 이름짓기.

입력과 출력 이름도 일관되게 사용하세요. 예: 저장 이전에는 “OrderDraft”, 저장 이후에는 “OrderRecord”처럼 "order1/order2"나 "payload/result" 같은 이름 대신 의미가 명확한 이름을 쓰면 몇 달 후에도 다이어그램이 읽기 쉬워집니다.

패턴을 반복하면 재사용 가능한 서브플로우로 추출하세요. AppMaster’s Business Process Editor에서는 종종 "Validate -> Normalize -> Persist"를 공유 블록으로 이동해 여러 워크플로우에서 사용하는 식으로 보입니다.

예: 온보딩 워크플로우가 "사용자 생성, 권한 설정, 이메일 전송, 감사 로그"를 한 단계에서 처리한다면 이를 네 단계와 재사용 가능한 "Write Audit Event" 서브플로우로 분리하세요. 테스트가 쉬워지고 수정이 안전해지며 놀라움이 줄어듭니다.

지저분한 워크플로우를 단계별로 리팩터하는 방법

대다수 워크플로우 문제는 "한 가지만 더" 규칙이나 커넥터를 추가하다가 아무도 결과를 예측할 수 없게 된 데서 옵니다. 리팩터링은 흐름을 다시 읽기 쉽게 만들고 모든 부작용과 실패 케이스를 드러나게 하는 작업입니다.

먼저 해피 패스(happy path)를 시작에서 끝까지 하나의 명확한 선으로 그리세요. 메인 목표가 "주문 승인"이라면 모든 것이 정상일 때 필요한 필수 단계만 그 선에 있어야 합니다.

그다음 작은 패스로 작업하세요:

• 해피 패스를 일관된 단계 이름(동사 + 객체)으로 단일 전진 경로로 다시 그리기
• 모든 부작용(이메일 전송, 카드 청구, 레코드 생성, 티켓 생성)을 나열하고 각 부작용을 명시적 단계로 만들기
• 각 부작용 옆에 실패 경로를 추가하고, 이미 변경을 가한 경우 보상을 포함시키기
• 반복되는 조건을 하나의 결정 지점으로 바꾸고 거기서 라우팅하기
• 반복되는 블록을 서브플로우로 추출하고 변수 이름을 의미있게 바꾸기(payment_status가 flag2보다 낫다)

숨은 복잡성을 빠르게 찾는 방법은 묻는 것입니다: "이 단계가 두 번 실행되면 무엇이 깨지나?" 대답이 "이중 청구가 발생할 수 있다"거나 "메일이 두 번 전송될 수 있다"면 상태를 더 명확히 하고 멱등성을 확보해야 합니다.

예: 온보딩 워크플로우가 계정 생성, 플랜 할당, Stripe 결제, 환영 메시지 전송을 한다면 결제만 성공하고 환영 메시지가 실패했을 때 유료 사용자가 접근 권한 없이 남지 않게 해야 합니다. 위험한 호출 옆에 보상 분기를 추가하세요: 사용자를 pending_welcome으로 표시하고 메시지 재시도, 재시도 실패 시 환불 및 플랜 롤백 등.

AppMaster에서는 Business Process Editor 흐름을 얕게 유지하면 이 정리가 더 쉽습니다: 작은 단계, 명확한 변수 이름, "Charge payment"나 "Send notification" 같은 재사용 가능한 서브플로우를 만들어 어디서나 재사용하세요.

피해야 할 일반적인 리팩터링 함정

비주얼 워크플로우 리팩터링은 프로세스를 이해하기 쉽게 하고 변경을 안전하게 해야 합니다. 하지만 어떤 수정은 특히 시간 압박 속에서 새로운 복잡성을 추가합니다.

한 함정은 "혹시 몰라" 하며 오래된 경로를 그대로 두는 것입니다. 분명한 스위치, 버전 마커, 삭제 예정일이 없으면 사람들은 오래된 경로를 계속 테스트하고 참조하며 두 가지 프로세스를 유지하게 됩니다. 점진적 롤아웃이 필요하면 새 경로를 이름 붙이고 하나의 눈에 보이는 결정으로 게이트하고 오래된 경로를 언제 삭제할지 계획하세요.

임시 플래그는 또 다른 누수입니다. 디버깅이나 일주일짜리 마이그레이션을 위해 만든 플래그가 영구화되기 쉽습니다. 플래그는 상하기 쉬운 항목처럼 다루세요: 존재 이유 문서화, 소유자 지정, 제거 날짜 설정.

세 번째 함정은 모델을 바꾸지 않고 일회성 예외를 계속 추가하는 것입니다. "특별 케이스" 노드를 계속 삽입하면 다이어그램이 옆으로 자라고 규칙은 예측 불가능해집니다. 같은 예외가 두 번 이상 나오면 보통 데이터 모델이나 프로세스 상태를 업데이트해야 할 신호입니다.

마지막으로 비즈니스 규칙을 동작시키려고 관련 없는 노드 안에 숨기지 마세요. 비주얼 에디터에서 작동하게 하려는 유혹이 크지만 나중에 아무도 규칙을 찾을 수 없게 됩니다.

경고 신호:

• 거의 같은 일을 하는 두 경로가 약간 다름
• 의미 불분명한 플래그(예: "temp2"나 "useNewLogic")
• 한 사람만 설명할 수 있는 예외
• 출처가 명확하지 않은 여러 노드에 분산된 규칙
• 초기 단계를 개선하지 않고 실패 후에 추가된 "수정" 노드

예: VIP 고객에 대한 다른 승인 로직이 필요하면 세 군데에 숨겨진 검사를 추가하지 말고 한 번의 "Customer type" 결정을 추가해 거기서 라우팅하세요.

배포 전에 빠르게 확인할 체크리스트

대부분의 문제는 배포 직전에 드러납니다: 누군가 실제 데이터로 흐름을 실행하고 다이어그램이 설명할 수 없는 동작을 할 때입니다.

소리 내어 워크스루를 하세요. 해피 패스를 한 문장으로 설명하기 어렵다면 흐름에 숨은 상태, 중복 규칙, 그룹화해야 할 너무 많은 분기가 있을 가능성이 큽니다.

간단한 사전 배포 점검

• 해피 패스를 한 번에 설명하세요: 트리거, 주요 단계, 종료 지점
• 모든 부작용을 각자 눈에 보이는 단계로 만들기(청구, 메시지 전송, 레코드 업데이트, 티켓 생성)
• 각 부작용에 대해 실패 시 어떻게 되돌릴지 결정하기(환불, 취소, 롤백, 수동 검토로 표시)
• 변수와 플래그 점검: 명확한 이름, 한 곳에서 설정, 수수께끼 같은 기본값 없음
• 복사-붙여넣기 로직 탐색: 여러 분기에서 같은 검사나 거의 같은 매핑 반복

대부분의 문제를 잡는 간단한 테스트

정상 성공, 가능성 있는 실패(예: 결제 거부), 이상한 엣지 케이스(선택 항목 누락) 이렇게 세 가지 케이스로 흐름을 실행해보세요. 시스템을 반쯤 완료 상태로 남기는 "어느 정도 동작"하는 단계가 있는지 관찰하세요.

AppMaster’s Business Process Editor에서는 이것이 종종 깔끔한 리팩터로 이어집니다: 반복 검사를 공유 단계로 모으고, 부작용을 명시적 노드로 만들고, 각 위험 호출 옆에 명확한 보상 경로를 추가하세요.

현실적인 예: 온보딩 플로우 리팩터

고객 온보딩 워크플로우가 사용자 신원 확인, 계정 생성, 유료 구독 시작 세 가지를 한다고 가정해보세요. 간단해 보이지만 실패가 발생하면 "대체로 작동"하는 흐름이 됩니다.

지저분한 버전

초기 버전은 단계별로 성장합니다. "Verified" 체크박스가 추가되고, "NeedsReview" 플래그가 추가되고, 더 많은 플래그가 붙습니다. 각 새 기능이 자체 분기를 추가하면서 "검증되었는가" 같은 검사가 여러 곳에 등장합니다.

곧 워크플로우는 이런 모습이 됩니다: 신원 확인, 사용자 생성, 카드 결제, 환영 이메일 전송, 워크스페이스 생성, 그리고 나중 단계가 그것에 의존하므로 검증을 다시 확인하기 위해 뒤로 점프. 결제는 성공했지만 워크스페이스 생성이 실패하면 롤백이 없어 고객은 요금은 청구되었지만 계정이 반만 생성된 상태가 되고 서포트 티켓이 쌓입니다.

리팩터

더 깔끔한 설계는 상태를 가시화하고 제어하는 것에서 시작합니다. 흩어진 플래그를 하나의 명시적 온보딩 상태로 대체하세요(예: Draft, Verified, Subscribed, Active, Failed). 그런 다음 "계속할 것인가?" 로직을 하나의 결정 지점에 둡니다.

보통 빠르게 고통을 줄이는 리팩터 목표:

• 명시적 상태를 읽고 다음 단계를 라우팅하는 하나의 결정 게이트
• 다이어그램 전반에 반복되는 검사는 없고 재사용 가능한 검증 블록만 존재
• 부분 성공에 대한 보상(결제 환불, 구독 취소, 워크스페이스 초안 삭제)
• 이유를 기록하고 안전하게 멈추는 명확한 실패 경로

그다음 데이터와 워크플로우를 함께 모델링하세요. "Subscribed"이면 구독 ID, 결제 ID, 제공자 응답을 한 곳에 저장해 보상이 추측 없이 실행되게 하세요.

마지막으로 의도적으로 실패 케이스를 테스트하세요: 검증 타임아웃, 결제 성공 후 이메일 실패, 워크스페이스 생성 오류, 중복 웹훅 이벤트 등.

이 워크플로우를 AppMaster에서 구축한다면 비즈니스 로직을 재사용 가능한 Business Processes에 유지하고 플랫폼이 요구가 바뀔 때 깔끔한 코드를 재생성하게 하면 오래된 분기가 남지 않도록 도움이 됩니다. 빠르게 리팩터 프로토타입을 만들고 싶다면(백엔드, 웹, 모바일 조각을 한 곳에서) AppMaster on appmaster.io는 바로 이런 종류의 엔드투엔드 워크플로우 빌드를 위해 설계되어 있습니다.