아이폰 앱을 사용하다 보면 예상치 못한 오류로 갑자기 종료되는 '크래시' 현상을 경험하곤 해요. 이러한 크래시 현상은 사용자에게 불편함을 줄 뿐만 아니라, 개발자에게는 앱의 안정성을 개선하기 위한 중요한 단서가 됩니다. 하지만 크래시 리포트만으로는 정확한 원인을 파악하기 어려울 때가 많죠. 이때 필요한 것이 바로 '심볼리케이션(Symbolication)'이라는 과정이에요. 이 글에서는 아이폰 앱 크래시에서 심볼리케이션이 무엇인지, 왜 중요한지, 그리고 어떻게 이루어지는지 자세히 알아보도록 할게요.
아이폰 앱 크래시가 발생했을 때 생성되는 크래시 리포트는 앱이 어떤 부분에서 문제를 일으켰는지에 대한 정보를 담고 있어요. 하지만 이 정보는 그대로 보면 실제 코드의 함수 이름이나 변수 이름 대신, 기계어 주소나 임의의 식별자로 표시되어 있어 사람이 이해하기 어려운 경우가 많답니다. 마치 암호처럼 말이죠.
심볼리케이션은 바로 이 어려운 크래시 리포트를 사람이 이해할 수 있는 형태로 '해석'해주는 과정을 의미해요. 크래시 리포트에 포함된 메모리 주소를 실제 코드의 함수명, 클래스명, 변수명 등 의미 있는 이름으로 바꾸어주는 것이죠. 이렇게 심볼리케이션이 완료된 크래시 리포트를 통해 개발자는 앱에서 어떤 함수 호출 중에 문제가 발생했는지, 어느 변수에서 오류가 생겼는지 등을 명확하게 파악할 수 있게 된답니다.
예를 들어, 크래시 리포트에 `0x100456789` 와 같은 주소만 찍혀 있다면 이게 정확히 어떤 코드인지 알기 어렵잖아요. 하지만 심볼리케이션을 거치면 `ViewController.viewDidLoad()`와 같이 사람이 이해하기 쉬운 형태로 바뀌는 거예요. 이는 앱의 디버깅 및 안정성 확보에 필수적인 과정이라고 할 수 있어요. 마치 의사가 환자의 증상을 정확히 진단하기 위해 정밀 검사를 하듯, 개발자는 심볼리케이션을 통해 앱의 '병명'을 정확하게 알아내는 것이랍니다.
안드로이드 앱 개발에서도 비슷한 개념으로 '매핑 파일'을 이용하여 스택 트레이스를 복원하는 과정이 있어요. 이는 크래시 리포트의 난독화된 코드를 실제 코드와 연결시켜주는 역할로, 아이폰의 심볼리케이션과 그 목적을 같이 한다고 볼 수 있죠 (참고: [크래시 없는 안드로이드 앱 구축: 리포팅 시스템의 역할과 실전 활용](https://blogdeveloperspot.blogspot.com/2023/08/blog-post_48.html)).
따라서 심볼리케이션은 단순히 기술적인 용어를 넘어, 사용자 경험 개선과 앱 품질 향상을 위한 개발 과정의 핵심이라고 이해하시면 좋을 것 같아요.
| 심볼리케이션 전 | 심볼리케이션 후 |
|---|---|
| 알 수 없는 메모리 주소 (예: 0x100456789) | 의미 있는 함수/변수 이름 (예: `loginButtonTapped()`) |
| 크래시 원인 파악의 어려움 | 정확한 원인 분석 및 문제 해결 용이 |
| 개발 시간 및 비용 증가 가능성 | 효율적인 디버깅 및 개발 주기 단축 |
아이폰 앱의 심볼리케이션 과정은 단순히 기술적인 호기심을 충족시키는 것을 넘어, 앱의 성공에 결정적인 영향을 미치는 중요한 요소예요. 특히 앱 스토어 심사 과정에서도 앱의 안정성은 매우 중요하게 평가되는데요, 만약 앱이 잦은 크래시로 인해 사용자에게 불편을 준다면 심사 과정에서 문제가 발생하거나, 출시 이후 사용자들의 부정적인 평가로 이어질 수 있어요. (참고: [AppStore 심사 중 문제 발생 및 해결방법](https://adjh54.tistory.com/681))
심볼리케이션은 개발자가 앱의 크래시 원인을 정확히 파악하고 신속하게 수정할 수 있도록 돕는 역할을 해요. 오류 보고서에 포함된 난독화된 메모리 주소만으로는 어디서 문제가 발생했는지 추측하기 어렵지만, 심볼리케이션 과정을 거치면 어느 함수에서, 어떤 조건에서 크래시가 일어났는지 구체적으로 알 수 있게 됩니다. 이는 곧 문제 해결 시간을 단축하고, 앱의 안정성을 획기적으로 향상시키는 결과를 가져오죠.
생각해보세요. 사용자가 앱을 사용하다가 갑자기 종료되는 경험은 매우 불쾌하죠. 이런 경험이 반복되면 사용자는 앱을 삭제하거나 부정적인 리뷰를 남기게 될 가능성이 높아요. 심볼리케이션을 통해 크래시를 효과적으로 관리하고 수정하는 것은 곧 사용자 만족도를 높이고, 앱의 긍정적인 평판을 유지하는 데 직접적으로 기여하는 일이랍니다. 즉, 사용자에게 매끄럽고 안정적인 사용 경험을 제공하기 위한 개발자의 필수적인 노력이라고 볼 수 있어요.
또한, 복잡한 코드를 가진 대규모 앱의 경우, 심볼리케이션 없이 크래시를 추적하는 것은 거의 불가능에 가까워요. 수많은 함수와 객체들이 얽혀있는 코드에서 정확한 오류 지점을 찾는 것은 마치 미로 찾기와 같거든요. 심볼리케이션은 이 미로의 출구를 명확하게 가리켜주는 나침반 역할을 하는 셈이죠.
결론적으로, 아이폰 앱 크래시 심볼리케이션은 앱의 품질을 보증하고, 사용자 경험을 최적화하며, 궁극적으로는 앱의 성공 가능성을 높이는 데 필수적인 과정이라고 강조해도 지나치지 않아요.
| 이점 | 설명 |
|---|---|
| 정확한 오류 분석 | 크래시 발생 지점의 함수 및 코드 라인을 명확히 파악할 수 있어요. |
| 신속한 문제 해결 | 개발자가 문제를 빠르게 인지하고 수정할 수 있어 개발 시간을 단축해요. |
| 사용자 경험 향상 | 앱 안정성 개선으로 사용자 만족도를 높이고 긍정적인 피드백을 유도해요. |
| 앱 품질 경쟁력 강화 | 안정적인 앱은 사용자에게 신뢰를 주며, 경쟁 앱과의 차별점을 만들어요. |
아이폰 앱의 심볼리케이션 과정은 주로 Xcode라는 Apple의 통합 개발 환경(IDE)을 통해 이루어져요. 크래시 리포트를 Xcode로 가져오면 Xcode가 자동으로 심볼리케이션을 시도하게 되죠. 이 과정에서 가장 중요한 요소는 바로 '디버그 심볼(Debug Symbol)' 또는 'dSYM 파일'이라고 불리는 파일이에요.
dSYM 파일은 앱이 빌드될 때 함께 생성되는 특별한 파일인데, 마치 앱의 '설명서'와 같은 역할을 해요. 이 파일 안에는 앱의 코드에 대한 정보, 즉 각 메모리 주소가 어떤 함수나 변수에 해당하는지에 대한 정보가 담겨 있어요. 따라서 크래시 리포트와 dSYM 파일이 모두 있어야만 정확한 심볼리케이션이 가능하답니다.
일반적인 심볼리케이션 과정은 다음과 같이 진행돼요:
탈옥(Jailbreak) 커뮤니티에서도 크래시 리포트의 심볼리케이션은 중요한 주제로 다뤄지고 있어요. (참고: [Crash Reporter의 크래시 로그는 어떻게 읽나요?](https://www.reddit.com/r/jailbreak/comments/1buubk/how_to_read_crash_reporters_crash_logs/?tl=ko)) 이는 일반 사용자뿐만 아니라, 개발자 커뮤니티에서도 크래시 문제를 해결하기 위한 노력이 활발히 이루어지고 있음을 보여줍니다.
이처럼 심볼리케이션은 단순히 기술적인 행위를 넘어, 앱의 완성도를 높이기 위한 중요한 디버깅 도구라고 할 수 있어요.
| 필수 요소 | 설명 |
|---|---|
| 크래시 리포트 (.crash 파일) | 문제 발생 시 시스템이 기록한 오류 정보 |
| dSYM 파일 | 앱 빌드 시 생성되는 디버그 심볼 정보 파일 (특정 빌드 버전과 일치해야 함) |
| Xcode | 심볼리케이션을 수행하는 주요 도구 |
아이폰 앱 개발자라면 크래시 리포트를 받았을 때, 심볼리케이션은 거의 필수적인 과정이라고 생각하시면 좋아요. 특히 다음과 같은 상황에서 심볼리케이션의 필요성이 더욱 커진답니다.
1. 사용자로부터 크래시 리포트를 받았을 때: 앱이 사용자 기기에서 예기치 않게 종료되었다는 피드백을 받았다면, 해당 크래시 리포트를 확보해야 해요. 이 리포트를 심볼리케이션하면 어떤 코드에서 문제가 발생했는지 구체적인 원인을 파악할 수 있게 됩니다. 특히 App Store Connect 등에서 수집되는 크래시 리포트는 심볼리케이션 없이는 매우 제한적인 정보만을 제공해요.
2. 앱 스토어 심사 준비 또는 이후 문제 분석: 앱 스토어 심사 과정에서 앱의 안정성은 매우 중요한 요소입니다. 만약 심사 과정에서 크래시 관련 이슈가 발견되거나, 심사 통과 후에도 사용자 리뷰 등을 통해 크래시 보고가 들어온다면, 이를 분석하기 위해 심볼리케이션이 필요해요. 앱의 출시 버전과 동일한 dSYM 파일을 확보하는 것이 중요하죠.
3. 베타 테스트 기간 동안: 새로운 기능을 추가하거나 기존 기능을 개선한 버전을 베타 테스터에게 배포했을 때, 그들이 보고하는 크래시 리포트들을 분석하는 것은 앱의 안정성을 확보하는 데 매우 중요해요. 베타 테스트 단계에서 심볼리케이션을 통해 발견된 오류를 수정하면 정식 출시 버전의 품질을 크게 높일 수 있습니다.
4. 성능 문제 디버깅: 크래시가 직접적으로 발생하지 않더라도, 앱이 비정상적으로 느려지거나 응답하지 않는 ANR(Application Not Responding)과 유사한 상황을 겪을 수 있어요. 이런 경우에도 스택 트레이스를 분석하기 위해 심볼리케이션이 유용하게 활용될 수 있습니다. (참고: 안드로이드의 ANR은 앱 크래시와는 다르지만, 입력에 응답하지 않는 상태를 의미하며, 이를 분석하는 데도 유사한 맥락의 작업이 필요해요.)
5. 릴리스 노트에 크래시 수정 내용 포함: 앱 업데이트 시 릴리스 노트에 '크래시 수정'과 같은 내용을 포함시키는 것은 사용자에게 앱이 지속적으로 개선되고 있음을 알리는 좋은 방법이에요. 하지만 어떤 크래시를 수정했는지 명확히 파악하려면 심볼리케이션을 통한 분석이 선행되어야 합니다.
정리하자면, 앱 개발 및 유지보수 과정에서 발생하는 '문제'를 '해결'하기 위한 모든 단계에서 심볼리케이션은 개발자의 든든한 지원군이 되어준다고 할 수 있어요. 특히 릴리스된 앱의 크래시를 분석할 때는 해당 릴리스 버전의 dSYM 파일이 반드시 필요하며, 이를 통해 정확한 원인 규명이 가능해진답니다.
| 상황 | 심볼리케이션의 역할 |
|---|---|
| 사용자 크래시 리포트 접수 | 보고된 크래시의 정확한 원인 규명 |
| App Store Connect 크래시 분석 | 앱 스토어에 등록된 앱의 성능 문제 추적 |
| 베타 테스트 피드백 | 테스트 버전에서의 문제점 사전 파악 및 수정 |
| 성능 저하 문제 분석 | 느린 속도나 비정상적인 동작의 원인 탐색 |
아이폰 앱 개발자라면 심볼리케이션 과정을 효율적으로 활용하여 앱의 품질을 높이는 것이 중요해요. 몇 가지 실용적인 팁을 드리자면 다음과 같아요.
1. dSYM 파일 관리 철저히 하기: 가장 중요한 것은 앱의 각 빌드 버전별로 정확한 dSYM 파일을 안전하게 보관하는 거예요. 앱 스토어에 배포되는 릴리스 빌드는 물론, 내부 테스트 빌드라도 크래시 리포트가 발생할 가능성이 있다면 해당 빌드의 dSYM 파일을 반드시 저장해두세요. App Store Connect에서 다운로드받은 dSYM 파일은 버전 정보가 포함되어 있으니, 이를 활용하면 관리가 수월합니다. dSYM 파일 없이는 심볼리케이션이 무의미해지니까요!
2. Xcode의 Organizer 활용하기: Xcode의 Organizer 창은 크래시 리포트와 dSYM 파일을 관리하고 심볼리케이션을 수행하는 데 매우 편리한 기능을 제공해요. 크래시 리포트를 Xcode로 드래그 앤 드롭하거나, Archive 된 빌드를 선택하여 관련 dSYM 파일을 쉽게 찾아 심볼리케이션을 진행할 수 있습니다. 복잡한 명령줄 도구 없이도 직관적으로 작업할 수 있다는 장점이 있어요.
3. 타사 분석 도구 활용 고려: Firebase Crashlytics, Sentry와 같은 타사 크래시 리포팅 및 분석 도구를 사용하면 심볼리케이션 과정을 더욱 자동화하고 효율화할 수 있어요. 이러한 도구들은 dSYM 파일을 업로드하면 자동으로 심볼리케이션을 수행하고, 크래시 리포트를 시각적으로 보기 좋게 정리하여 제공합니다. 또한, 크래시 트렌드 분석, 충돌 빈도 등을 파악하는 데도 유용하답니다.
4. 코드 난독화(Obfuscation)와 심볼리케이션의 관계 이해: 보안상의 이유로 코드를 난독화하는 경우도 있는데, 이 경우 심볼리케이션이 더 복잡해질 수 있어요. 난독화된 코드는 심볼리케이션 후에도 완전히 원래의 이름을 복원하지 못할 수 있으므로, 개발자는 보안과 디버깅 용이성 사이의 균형을 고려해야 합니다. 일반적으로는 릴리스 빌드에서는 디버깅 정보가 최소화되고, 심볼리케이션을 위한 dSYM 파일은 별도로 관리하는 것이 일반적입니다.
5. 크래시 수정 후 철저한 테스트: 심볼리케이션을 통해 크래시 원인을 파악하고 코드를 수정한 후에는 반드시 해당 문제가 해결되었는지, 그리고 수정으로 인해 다른 문제가 발생하지는 않았는지 철저하게 테스트해야 해요. 회귀 테스트(Regression Test)를 통해 앱의 전반적인 안정성을 확인하는 것이 중요합니다.
이러한 팁들을 활용하여 심볼리케이션 과정을 체계적으로 관리한다면, 앱 개발 과정에서 발생하는 크래시 문제를 더욱 효과적으로 해결하고 사용자에게 안정적인 서비스를 제공할 수 있을 거예요.
| 팁 | 설명 |
|---|---|
| dSYM 파일 관리 | 모든 빌드 버전의 dSYM 파일을 안전하게 보관해요. |
| Xcode Organizer 활용 | 직관적인 인터페이스로 심볼리케이션을 간편하게 수행해요. |
| 타사 분석 도구 사용 | 자동화된 심볼리케이션 및 심층 분석 기능을 활용해요. |
| 난독화 고려 | 보안과 디버깅 용이성 사이의 균형을 맞춰요. |
| 수정 후 철저한 테스트 | 수정된 사항이 제대로 적용되었는지, 다른 문제는 없는지 확인해요. |
아이폰 앱 크래시 심볼리케이션에 대한 이해를 돕기 위해 관련 정보를 몇 가지 더 소개해 드려요. 이러한 자료들은 심볼리케이션의 기술적인 측면뿐만 아니라, 앱 개발 및 품질 관리 전반에 대한 통찰력을 제공할 수 있답니다.
1. iOS 앱 심볼: 나무위키의 "[iOS/애플리케이션](https://namu.wiki/w/iOS/%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98)" 항목에서는 iOS 애플리케이션과 관련된 다양한 정보를 다루고 있어요. 심볼에 대한 개념적인 이해를 넓히는 데 도움이 될 수 있습니다. (참고: 나무위키의 내용은 위키 특성상 편집될 수 있습니다.)
2. Adobe Illustrator 심볼: Adobe Illustrator와 같은 그래픽 디자인 툴에서도 '심볼'이라는 개념이 사용돼요. 이는 객체를 복제하고 수정할 때 원본 심볼을 기반으로 한다는 점에서 프로그래밍에서의 심볼과는 다르지만, '반복적인 요소를 효율적으로 관리한다'는 공통된 맥락을 가지고 있다고 볼 수 있어요. (참고: [ADOBE®ILLUSTRATOR®](https://helpx.adobe.com/archive/kr/illustrator/cc/2015/illustrator_reference.pdf))
3. Philips Lumify 앱: Philips Lumify 앱과 같이 실제로 App Store를 통해 제공되는 다양한 앱들이 있어요. 이러한 앱들이 사용자에게 안정적인 경험을 제공하기 위해 내부적으로 크래시 리포트와 심볼리케이션 과정을 거치고 있을 거예요. (참고: [Lumify 진단 초음파 시스템](https://www.philips.com/c-dam/b2bhc/master/feature-details/ultrasound-lumify-global-resources/user-korean.pdf))
4. Cisco AnyConnect 클라이언트: Cisco AnyConnect와 같은 클라이언트 애플리케이션도 충돌 보고서를 포함하는 기능을 제공할 수 있어요. 이는 다양한 소프트웨어에서 크래시 리포팅 및 디버깅이 중요한 부분을 차지함을 보여줍니다. (참고: [Cisco AnyConnect Secure Mobility Client 관리자 설명서](https://www.cisco.com/c/dam/en/us/td/docs/security/vpn_client/anyconnect/anyconnect41/administration/guide/Localization/b_AnyConnect_Administrator_Guide_4-1-ko_KR.pdf))
이 외에도 다양한 분야에서 '심볼'이라는 용어가 사용되지만, 아이폰 앱 크래시 맥락에서의 심볼리케이션은 코드의 실행 흐름을 파악하기 위한 필수적인 디버깅 도구라는 점을 기억해주시면 좋겠습니다.
| 용어 | 설명 |
|---|---|
| 크래시 리포트 (Crash Report) | 앱 비정상 종료 시 생성되는 오류 정보 파일 |
| dSYM 파일 | 앱의 디버깅 정보를 담고 있는 파일로, 심볼리케이션에 사용돼요. |
| Xcode | Apple 개발자들이 사용하는 통합 개발 환경 (IDE) |
| App Store Connect | Apple 앱 스토어에 앱을 관리하고 배포하는 플랫폼 |
Q1. 심볼리케이션되지 않은 크래시 리포트로는 무엇을 알 수 있나요?
A1. 심볼리케이션되지 않은 크래시 리포트에서는 주로 앱이 어떤 스레드에서 충돌했는지, 충돌 당시의 메모리 상태, 마지막으로 실행된 함수들의 주소 목록 등을 확인할 수 있어요. 하지만 이 정보만으로는 정확히 어떤 코드의 어떤 함수에서 문제가 발생했는지 파악하기 어렵습니다.
Q2. dSYM 파일이 없으면 심볼리케이션이 불가능한가요?
A2. 네, 정확한 심볼리케이션을 위해서는 해당 빌드 버전과 일치하는 dSYM 파일이 반드시 필요해요. dSYM 파일은 메모리 주소를 실제 코드 심볼(함수명, 변수명 등)로 변환해주는 역할을 하기 때문입니다.
Q3. App Store Connect에서 다운로드 받은 dSYM 파일은 어떻게 사용하나요?
A3. App Store Connect에서 다운로드 받은 dSYM 파일을 Xcode의 Organizer 창으로 가져와 해당 크래시 리포트와 연결하면 심볼리케이션을 진행할 수 있습니다. 각 빌드 버전별로 정확한 dSYM 파일을 관리하는 것이 중요해요.
Q4. 릴리스 빌드에서 심볼리케이션을 위해 디버깅 정보를 활성화해야 하나요?
A4. 일반적으로 릴리스 빌드에서는 성능 최적화와 보안을 위해 디버깅 정보를 최소화하는 경우가 많아요. 하지만 크래시 리포트를 분석하여 심볼리케이션을 해야 하는 경우에는 'Debug Information Format' 설정을 'DWARF with dSYM File'로 하여 dSYM 파일이 생성되도록 설정해야 합니다.
Q5. 크래시 리포트 분석에 시간이 너무 오래 걸려요. 어떻게 해야 하나요?
A5. 타사 분석 도구(Firebase Crashlytics, Sentry 등)를 활용하면 심볼리케이션 및 크래시 분석 과정을 자동화하고 효율화할 수 있어요. 또한, 자주 발생하는 크래시 유형을 우선적으로 분석하는 전략을 세우는 것도 도움이 됩니다.
Q6. 심볼리케이션된 크래시 리포트도 이해하기 어려울 수 있나요?
A6. 네, 심볼리케이션을 통해 함수명 등은 알 수 있지만, 복잡한 로직이나 동시성 문제로 인한 크래시는 여전히 분석에 어려움이 있을 수 있어요. 이런 경우에도 스택 트레이스, 메모리 덤프 등 추가적인 정보를 활용하여 심층적으로 분석해야 할 때가 있습니다.
Q7. 크래시 리포트와 ANR(Application Not Responding)은 같은 건가요?
A7. 아니요, 다릅니다. 크래시는 앱이 비정상적으로 종료되는 것이고, ANR은 앱이 사용자 입력에 응답하지 않는 상태를 말해요. 둘 다 사용자 경험에 부정적인 영향을 주지만, 발생 원인과 분석 방법에는 차이가 있습니다. 하지만 두 경우 모두 스택 트레이스 분석이 중요한 디버깅 도구로 활용될 수 있다는 공통점이 있습니다.
Q8. 심볼리케이션 후에도 동일한 크래시가 계속 발생한다면 어떻게 해야 하나요?
A8. 동일한 크래시가 반복된다면, 단순한 버그 수정만으로는 해결되지 않는 근본적인 문제일 수 있어요. 코드 로직, 데이터 구조, 외부 라이브러리 연동 문제, 또는 비동기 처리 방식 등을 더 깊이 있게 검토하고 재설계해야 할 수도 있습니다. 경우에 따라서는 앱 아키텍처 전반을 점검해야 할 수도 있어요.
Q9. 심볼리케이션된 크래시 리포트의 함수 이름이 너무 길거나 복잡해요.
A9. 네, Swift나 Objective-C와 같은 언어의 특성상 함수 이름이 길거나 복잡하게 보일 수 있어요. 하지만 이는 컴파일러가 코드의 정보를 최대한 담고 있기 때문이며, 해당 이름의 패턴을 익히면 어떤 기능을 수행하는 함수인지 파악하는 데 도움이 될 수 있습니다.
Q10. 앱에서 사용하는 외부 라이브러리나 프레임워크의 크래시는 어떻게 심볼리케이션하나요?
A10. 외부 라이브러리나 프레임워크도 자체적으로 dSYM 파일을 생성하거나 제공하는 경우가 많습니다. 앱의 dSYM 파일과 함께 해당 라이브러리의 dSYM 파일도 확보하여 함께 심볼리케이션하면, 라이브러리에서 발생한 크래시의 원인도 분석할 수 있습니다. 다만, 라이브러리 개발사의 지원 정책에 따라 다를 수 있습니다.
본 글은 아이폰 앱 크래시 심볼리케이션에 대한 일반적인 정보 제공을 목적으로 작성되었으며, 전문적인 개발 조언을 대체할 수 없습니다. 실제 개발 및 디버깅 과정에서는 Apple 공식 문서 및 개발자 커뮤니티의 최신 정보를 참고하시기 바랍니다.
아이폰 앱 크래시 발생 시, 심볼리케이션은 난독화된 크래시 리포트를 사람이 이해할 수 있는 코드 정보(함수명, 변수명 등)로 변환하여 정확한 원인 분석을 가능하게 하는 필수적인 과정이에요. 이를 위해 Xcode와 dSYM 파일이 필요하며, 개발자는 dSYM 파일을 철저히 관리하고 타사 분석 도구를 활용하는 등의 방법을 통해 앱의 안정성을 높일 수 있습니다.