대신동 코드에서 STATUS_CONTROL_C_EXIT가 뜬다면? 모르면 손해 볼 꿀팁

Ctrl+C, 그 간단한 동작 뒤에 숨겨진 진실

우리가 매일 마주하는 Ctrl+C의 정체

우리가 개발이나 작업을 하다 보면 프로그램을 잠시 멈추거나 완전히 종료하고 싶을 때가 있죠. 그럴 때 습관적으로 누르게 되는 키 조합이 바로 Ctrl+C입니다. 이 두 개의 키를 누르면 마치 마법처럼 실행 중이던 프로그램이 뚝 멈추는데, 사실 이 간단한 동작 뒤에는 생각보다 훨씬 복잡하고 중요한 일들이 벌어지고 있답니다.

대부분의 사용자는 단순히 “프로그램이 꺼졌다”고만 생각하지만, 시스템 내부에서는 ‘시그널(Signal)’이라는 특별한 메시지가 전달되고, 이 시그널을 받은 프로그램은 정해진 절차에 따라 종료 과정을 밟게 돼요. 이 과정에서 발생하는 다양한 상태 중 하나가 바로 STATUS_CONTROL_C_EXIT인데, 이는 단순히 “종료”를 넘어선 의미를 담고 있습니다.

마치 사람이 갑작스러운 사고로 쓰러졌을 때 의사들이 사망 원인을 파악하는 것처럼, 프로그램의 종료 상태 코드도 그 프로그램이 왜, 어떻게 멈췄는지를 알려주는 중요한 단서가 된답니다.

STATUS_CONTROL_C_EXIT, 단순한 종료 코드가 아니다?

STATUS_CONTROL_C_EXIT는 운영체제가 특정 프로세스가 Ctrl+C 시그널, 즉 SIGINT(Interrupt Signal)를 받아서 종료되었다고 보고하는 상태 코드예요. 이 코드는 프로그램이 정상적으로 모든 작업을 마치고 스스로 종료한 것이 아니라, 외부의 요청(사용자의 Ctrl+C 입력)에 의해 강제로 종료되었다는 것을 의미하죠.

저도 예전에 한 프로젝트에서 개발하던 중, 사용자에게 제공되는 서비스가 간헐적으로 이상 종료되는 문제를 겪은 적이 있었어요. 밤낮으로 디버깅을 하다가 결국 STATUS_CONTROL_C_EXIT가 원인임을 밝혀냈는데, 당시에는 이 코드가 이렇게 큰 문제를 일으킬 수 있다는 걸 생각지도 못했죠.

이는 단순히 ‘종료’라는 행위 자체를 넘어서, 프로그램이 종료되기 전에 처리해야 할 중요한 작업들, 예를 들어 열려 있던 파일 닫기, 사용하던 메모리 해제, 데이터 저장 등의 ‘우아한 종료(Graceful Shutdown)’ 과정이 제대로 이루어지지 않았을 가능성을 내포하고 있습니다.

만약 이러한 후처리 없이 급하게 종료된다면, 데이터 손상이나 시스템 오류로 이어질 수 있어 정말 위험한 상태라고 할 수 있습니다.

개발자가 STATUS_CONTROL_C_EXIT를 알아야 하는 이유

예상치 못한 데이터 손실 방지

개발자라면 자신이 만든 프로그램이 어떤 상황에서든 안정적으로 동작하기를 바랄 거예요. 하지만 STATUS_CONTROL_C_EXIT와 같은 갑작스러운 종료는 예측할 수 없는 상황에서 데이터 손실을 유발할 수 있습니다. 예를 들어, 데이터베이스에 정보를 쓰고 있거나, 중요한 파일을 편집 중인 상황에서 Ctrl+C가 입력되면, 해당 작업이 미완료 상태로 중단될 수 있어요.

저도 한때 백업 스크립트를 짜면서 이 문제로 골머리를 앓은 적이 있어요. 백업 도중에 Ctrl+C로 스크립트가 멈추면, 부분적으로만 백업된 파일 때문에 전체 복구가 불가능해지는 상황이 발생하더라고요. 이런 상황을 막기 위해서는 프로그램이 종료 신호를 받았을 때, 진행 중이던 작업을 안전하게 마무리하고, 필요한 데이터를 저장한 후 종료하는 로직을 반드시 구현해야 합니다.

이는 단순히 프로그램의 안정성을 넘어 사용자의 소중한 데이터를 보호하는 책임감과 직결되는 문제죠.

리소스 누수와 시스템 안정성

프로그램이 실행될 때는 메모리, 파일 핸들, 네트워크 소켓 등 다양한 시스템 리소스를 할당받아 사용합니다. 정상적인 종료 과정에서는 이러한 리소스들이 깔끔하게 해제되어 시스템에 반환되죠. 하지만 STATUS_CONTROL_C_EXIT로 인해 프로그램이 갑작스럽게 종료되면, 할당했던 리소스를 제대로 반환하지 못하고 메모리 누수나 파일 핸들 누수 같은 문제가 발생할 수 있어요.

이런 누수가 반복되면 결국 시스템 성능 저하를 넘어 전체 서버가 불안정해지거나 멈추는 심각한 상황까지 초래할 수 있습니다. 특히 24 시간 내내 운영되어야 하는 서버 애플리케이션에서는 이러한 리소스 누수가 치명적이에요. 한 번은 제가 담당하던 실시간 데이터 처리 시스템에서 원인 모를 메모리 사용량 증가를 겪었는데, 나중에 알고 보니 특정 모듈이 Ctrl+C 종료 시 리소스를 제대로 해제하지 못하고 있었던 게 문제였습니다.

이런 경험을 통해 저는 프로그램 종료 시 리소스 관리가 얼마나 중요한지 뼈저리게 느꼈답니다.

운영 환경에서의 치명적인 결과

개발 환경에서는 Ctrl+C를 눌러도 크게 문제가 되지 않는 경우가 많지만, 실제 서비스가 운영되는 환경에서는 이야기가 달라집니다. 특히 금융 시스템, 의료 시스템, 혹은 대규모 트래픽을 처리하는 웹 서비스와 같은 곳에서는 STATUS_CONTROL_C_EXIT가 단순한 오류를 넘어 엄청난 재앙을 불러올 수 있어요.

예를 들어, 결제 시스템이 거래 처리 도중 갑자기 종료되면 고객의 돈이 사라지거나 중복 결제가 발생하는 등 금전적인 손실로 이어질 수 있습니다. 이런 상황은 단순히 고객 불만을 넘어 기업의 신뢰도에 치명적인 타격을 입힐 수 있죠. 저도 과거에 중요한 배치 작업 도중 Ctrl+C 때문에 작업이 꼬여서 새벽에 모든 팀원이 비상 출동했던 아찔한 기억이 있어요.

그때의 경험을 통해 운영 환경에서의 종료 처리는 단순한 에러 핸들링이 아니라 서비스의 연속성과 신뢰성을 지키는 핵심 요소라는 것을 깨달았습니다.

프로세스 생애 주기와 종료 상태

프로세스 제어와 SIGINT 시그널

프로세스 제어는 운영체제가 실행 중인 프로그램들을 관리하는 중요한 기능 중 하나입니다. 프로그램은 시작하고, 실행되고, 그리고 종료되는 일련의 생애 주기를 가지는데, 이 과정에서 다양한 시그널들을 통해 외부와 소통하게 됩니다. STATUS_CONTROL_C_EXIT의 핵심 원인인 SIGINT(Signal Interrupt)는 바로 이 시그널 중 하나예요.

우리가 Ctrl+C를 누르면, 터미널 드라이버가 이 입력을 감지하고 실행 중인 포그라운드 프로세스 그룹에게 SIGINT 시그널을 보내게 됩니다. 이 시그널은 “이제 그만 작업하고 종료해라”는 일종의 부드러운 명령인데, 프로그램은 이 시그널을 받아서 어떻게 처리할지 결정할 수 있어요.

기본적으로는 프로그램을 종료시키는 역할을 하지만, 개발자가 직접 시그널 핸들러를 등록해서 특정 작업을 수행하게 할 수도 있습니다. 저는 이 SIGINT 시그널을 활용해서 프로그램 종료 직전에 로그를 남기거나, 임시 파일을 정리하는 기능을 구현하곤 했죠.

자식 프로세스와 종료 코드

하나의 프로그램이 실행될 때, 때로는 다른 프로그램을 실행시키기 위해 ‘자식 프로세스’를 생성하기도 합니다. 예를 들어, 웹 서버가 요청을 처리하기 위해 스크립트를 실행하거나, 빌드 시스템이 컴파일러를 호출하는 경우가 여기에 해당하죠. 자식 프로세스는 부모 프로세스로부터 상속받은 환경에서 독립적으로 실행되다가, 자신의 작업을 마치거나 외부 시그널을 받으면 종료됩니다.

이때 자식 프로세스는 자신의 종료 상태를 나타내는 ‘종료 코드(Exit Status)’를 부모 프로세스에게 전달해요. exit(0)은 ‘성공적으로 종료’를 의미하고, 0 이 아닌 다른 값들은 일반적으로 ‘오류로 종료’되었음을 나타냅니다. STATUS_CONTROL_C_EXIT는 사실 윈도우 운영체제에서 Ctrl+C에 의해 프로세스가 종료될 때 내부적으로 발생하는 특정 상태 코드를 의미하는데, 리눅스/유닉스 계열에서는 SIGINT 시그널을 받아 종료될 경우, 프로세스의 종료 코드는 일반적으로 (SIGINT의 번호는 보통 2)인 이 됩니다.

이러한 종료 코드를 제대로 이해하고 활용하는 것은 복잡한 시스템에서 각 프로세스의 상태를 파악하고 문제 발생 시 원인을 분석하는 데 매우 중요합니다.

다양한 종료 상태(Exit Status)의 이해

프로그램이 종료될 수 있는 방식은 Ctrl+C 외에도 정말 다양합니다. 개발자가 의도적으로 함수를 호출하여 종료할 수도 있고, 치명적인 오류(예: 0 으로 나누기, 잘못된 메모리 접근)가 발생하여 운영체제에 의해 강제로 종료될 수도 있죠. 각 종료 방식은 고유한 ‘종료 상태(Exit Status)’를 가지며, 이 상태 코드를 통해 프로그램이 왜 멈췄는지에 대한 실마리를 얻을 수 있습니다.

종료 방식	설명	예상 Exit Status (리눅스/유닉스)	예상 Exit Status (윈도우, STATUS_CONTROL_C_EXIT)
정상 종료	프로그램이 모든 작업을 성공적으로 마치고 스스로 종료	0	0
Ctrl+C (SIGINT)	사용자가 Ctrl+C를 눌러 인터럽트 시그널 발생	130 (128 + SIGINT 시그널 번호 2)	0xC000013A (STATUS_CONTROL_C_EXIT)
치명적인 오류	세그멘테이션 폴트, 0 으로 나누기 등 예측 불가능한 오류	128 + 시그널 번호 (예: SIGSEGV의 경우 139)	다양한 시스템 오류 코드 (예: STATUS_ACCESS_VIOLATION)
명시적 오류 종료	개발자가 특정 오류 상황에서 exit(1) 등으로 종료	1 (또는 다른 0 이 아닌 값)	1 (또는 다른 0 이 아닌 값)

위 표에서 볼 수 있듯이, Ctrl+C에 의한 종료는 일반적인 성공 종료와는 확연히 다른 특성을 가집니다. 개발자는 이러한 종료 상태들을 면밀히 분석하여 자신의 프로그램이 예상치 못한 방식으로 종료되는 것을 방지하고, 문제가 발생했을 때 신속하게 원인을 파악할 수 있어야 합니다.

저도 이 종료 코드들 덕분에 수많은 버그의 원인을 찾아내곤 했답니다.

현명하게 Ctrl+C 종료를 처리하는 방법

시그널 핸들링 구현하기

Ctrl+C와 같은 인터럽트 시그널을 우아하게 처리하는 가장 좋은 방법은 바로 ‘시그널 핸들링(Signal Handling)’을 구현하는 것입니다. 시그널 핸들링은 프로그램이 특정 시그널을 받았을 때 기본 동작(예: 즉시 종료) 대신 개발자가 정의한 함수를 실행하도록 하는 기술이에요.

C/C++에서는 함수나 함수를 사용하여 시그널 핸들러를 등록할 수 있습니다. 파이썬 같은 언어에서도 모듈을 통해 쉽게 구현할 수 있죠. 저도 프로그램을 만들 때 항상 이 시그널 핸들러를 최우선적으로 고려하는데, 이를 통해 Ctrl+C가 눌러졌을 때 중요한 데이터를 저장하거나, 열려있던 네트워크 연결을 안전하게 끊거나, 임시 파일을 정리하는 등의 작업을 수행할 수 있습니다.

단순히 종료되는 것을 넘어, 사용자에게 “프로그램이 안전하게 종료되었습니다”라는 메시지를 보여주는 것만으로도 서비스의 신뢰도가 훨씬 높아질 수 있어요.

자원 해제 로직의 중요성

프로그램이 실행되는 동안 할당받은 모든 시스템 리소스는 종료 시 반드시 반환되어야 합니다. 이는 마치 우리가 다 쓴 물건을 제자리에 두는 것과 같아요. 시그널 핸들링을 통해 Ctrl+C 종료를 감지했다면, 이 시점에 모든 할당된 리소스, 예를 들어 메모리, 파일 디스크립터, 네트워크 소켓 등을 해제하는 로직을 실행해야 합니다.

만약 이 과정을 소홀히 하면 앞서 언급했듯이 메모리 누수나 파일 핸들 누수와 같은 심각한 문제가 발생할 수 있어요. 저도 과거에 복잡한 멀티쓰레드 애플리케이션을 개발하면서 리소스 해제 순서가 꼬여서 애를 먹은 적이 있습니다. 그때의 경험을 바탕으로 지금은 항상 프로그램 설계 단계부터 리소스 할당과 해제 로직을 명확히 정의하고, 종료 시에는 반드시 모든 리소스가 안전하게 정리될 수 있도록 꼼꼼하게 검토하는 습관을 들이게 되었죠.

안전한 종료 루틴 설계

궁극적으로 우리는 프로그램이 어떤 상황에서든 ‘안전하게 종료(Graceful Shutdown)’되도록 만들어야 합니다. 이는 단순히 시그널 핸들러를 추가하고 리소스를 해제하는 것을 넘어, 프로그램의 전체적인 구조를 종료 친화적으로 설계하는 것을 의미해요. 예를 들어, 백그라운드에서 실행 중인 작업이 있다면 이를 완료될 때까지 기다리거나, 중간에 끊겨도 문제가 없도록 설계해야 합니다.

또한, 중요한 데이터를 다루는 부분에서는 트랜잭션 개념을 도입하여 원자성(Atomicity)을 보장하는 것도 중요합니다. 즉, 작업이 완전히 커밋되거나 아니면 아무것도 변경되지 않도록 하는 것이죠. 저의 경험상, 프로그램 시작 단계에서부터 “이 프로그램은 어떻게 종료될 것인가?”라는 질문을 던지고 설계하는 것이 나중에 발생할 수 있는 수많은 문제를 예방하는 가장 현명한 방법입니다.

실제 개발 사례로 배우는 교훈

내가 겪었던 Ctrl+C 재앙

제가 처음으로 대규모 웹 서비스를 개발할 때였어요. 실시간으로 사용자 데이터를 처리하고 저장하는 중요한 백엔드 프로세스였는데, 개발 단계에서는 Ctrl+C로 종료해도 아무 문제가 없어 보였습니다. 그런데 실제 서비스에 배포하고 얼마 지나지 않아, 운영팀에서 “간헐적으로 데이터가 유실된다”는 보고가 들어왔어요.

밤새도록 로그를 뒤지고 코드를 분석해도 원인을 찾기 어려웠죠. 결국, 문제의 원인은 Ctrl+C였습니다. 운영팀에서 배포 스크립트를 수동으로 종료하거나, 서버를 재시작하는 과정에서 Ctrl+C와 유사한 시그널이 전달되었고, 저희 프로그램은 이에 대한 아무런 대비책 없이 무방비로 종료되었던 것이죠.

중요한 데이터가 메모리에만 남아있던 상태에서 강제 종료되면서 데이터가 디스크에 저장되지 않고 공중분해되었던 겁니다. 그날 이후로 저는 모든 프로그램에 시그널 핸들링과 우아한 종료 루틴을 적용하는 것을 철칙으로 삼게 되었습니다. 정말 아찔하고도 값비싼 교훈이었죠.

특정 프로젝트의 교훈, 왜 중요했을까?

제가 참여했던 어느 특정 프로젝트에서도 STATUS_CONTROL_C_EXIT와 관련한 문제로 인해 큰 어려움을 겪은 적이 있습니다. 이 프로젝트는 수많은 IoT 장치에서 실시간으로 데이터를 수집하고 처리하는 시스템이었는데, 각 장치와의 통신 연결이 매우 중요했어요. 그런데 서버 프로세스가 Ctrl+C로 인해 강제 종료될 때마다, 장치와의 연결이 제대로 끊기지 않고 ‘좀비 커넥션’으로 남아있는 문제가 발생했습니다.

이 좀비 커넥션들이 쌓이고 쌓여 결국 서버의 네트워크 리소스를 고갈시키고, 새로운 장치들이 연결되지 못하는 상황으로 이어졌죠. 이런 문제가 발생하면 서버를 강제로 재부팅해야 했고, 그 과정에서 실시간 데이터 손실은 물론 서비스 중단까지 발생했습니다. 결국 우리는 종료 시 모든 장치와의 연결을 안전하게 해제하고, 현재 처리 중인 데이터는 반드시 저장하는 복잡한 종료 로직을 추가해야만 했습니다.

이 경험을 통해 저는 Ctrl+C라는 작은 신호 하나가 전체 시스템의 안정성에 얼마나 큰 영향을 미칠 수 있는지 다시 한번 깨달았고, ‘종료’라는 것이 단순히 프로그램을 끄는 행위를 넘어선, 또 하나의 중요한 ‘기능’이라는 인식을 갖게 되었습니다.

궁극적으로 안정적인 시스템을 만드는 비결

우아한 종료(Graceful Shutdown)의 중요성

우아한 종료는 STATUS_CONTROL_C_EXIT와 같은 갑작스러운 종료 시그널을 받았을 때, 프로그램이 즉시 멈추지 않고 진행 중이던 작업을 안전하게 마무리하고 모든 리소스를 해제한 후 종료하는 과정을 의미합니다. 이는 마치 비행기가 착륙할 때 곧바로 땅에 내려앉는 것이 아니라, 서서히 고도를 낮추고 바퀴를 내린 다음 활주로에 부드럽게 안착하는 것과 같아요.

프로그램이 우아하게 종료되면 데이터 손실을 막고, 리소스 누수를 방지하며, 시스템의 안정성을 극대화할 수 있습니다. 특히 사용자에게 중요한 데이터를 제공하거나 장시간 실행되는 서비스에서는 이 ‘우아한 종료’가 선택이 아닌 필수입니다. 저도 제 블로그 서버를 직접 운영하면서, 서버 업데이트나 재시작 시 방문자에게 불쾌한 경험을 주지 않기 위해 항상 우아한 종료 로직을 신경 써서 구현하고 있어요.

이 작은 노력이 결국 서비스의 품질을 결정하고 사용자 경험을 향상시킨다고 믿습니다.

개발 문화와 종료 처리의 관계

STATUS_CONTROL_C_EXIT와 같은 종료 상태를 현명하게 처리하는 것은 단순히 기술적인 문제만을 의미하지 않습니다. 이는 사실 팀의 개발 문화와도 깊은 연관이 있어요. 버그가 발생했을 때 급하게 패치하는 것만큼, 프로그램의 종료 처리 로직을 처음부터 신중하게 설계하고 구현하는 것이 중요합니다.

“일단 실행만 되면 된다”는 생각은 결국 서비스 운영 단계에서 큰 문제로 돌아오기 마련입니다. 저는 팀원들과 코드를 리뷰할 때 항상 “이 프로그램은 어떤 상황에서 어떻게 종료될 것인가?”라는 질문을 던지곤 합니다. 이 질문을 통해 예상치 못한 종료 시나리오에 대해 미리 고민하고 대비책을 마련할 수 있죠.

이러한 문화가 정착되면, 개발자들이 자연스럽게 더 견고하고 안정적인 프로그램을 만들게 되고, 결국 서비스의 전반적인 품질이 향상되는 선순환 구조가 만들어집니다. 여러분도 오늘부터 개발하실 때 이 ‘종료’라는 부분에 조금 더 애정을 가지고 접근해보시는 건 어떨까요?

글을 마치며

오늘은 우리가 무심코 사용하는 Ctrl+C라는 간단한 동작 뒤에 숨겨진 복잡하고 중요한 이야기, 즉 STATUS_CONTROL_C_EXIT와 프로세스의 우아한 종료에 대해 깊이 파헤쳐 보았습니다. 어쩌면 개발자에게 이 ‘종료’라는 건 프로그램을 만드는 시작만큼이나 중요한 부분일지 모른다는 생각이 들어요. 저 역시 수많은 시행착오를 겪으며 종료 처리가 얼마나 서비스의 안정성과 신뢰에 지대한 영향을 미치는지 뼈저리게 깨달았답니다. 여러분의 소중한 코드도 언제나 안전하고 우아하게 생애 주기를 마칠 수 있기를 바라며, 오늘 이야기가 작은 도움이 되었으면 좋겠습니다.

알아두면 쓸모 있는 정보

1. 시그널 핸들러는 선택이 아닌 필수! 프로그램을 개발할 때는 항상 Ctrl+C(SIGINT)와 같은 종료 시그널을 처리할 수 있는 시그널 핸들러를 구현하는 것이 좋아요. 이를 통해 급작스러운 종료에도 데이터를 안전하게 저장하고 리소스를 해제할 수 있습니다. 특히 사용자 데이터나 외부 서비스와의 연동이 있는 경우 더욱 중요하죠.

2. 리소스 해제 로직을 꼼꼼히! 프로그램이 실행 중에 할당하는 메모리, 파일 디스크립터, 네트워크 소켓 등의 모든 시스템 리소스는 종료 시 반드시 반환되어야 합니다. 그렇지 않으면 리소스 누수가 발생하여 시스템 성능 저하를 일으킬 수 있으니, 종료 시 해제 루틴을 철저히 검토해야 합니다.

3. 다양한 종료 시나리오를 미리 테스트하세요! 개발 환경에서는 문제가 없어 보이지만, 실제 운영 환경에서는 예기치 않은 종료 상황이 발생할 수 있습니다. Ctrl+C뿐만 아니라 시스템 종료, 전원 차단 등 다양한 시나리오에서 프로그램이 어떻게 반응하고 종료되는지 미리 테스트하여 대비하는 것이 현명합니다.

4. 종료 코드(Exit Status)를 이해하고 활용하세요! 프로그램이 종료될 때 반환하는 종료 코드는 해당 프로그램이 왜 종료되었는지에 대한 중요한 단서를 제공합니다. exit(0)이 성공적인 종료를 의미하고, 0 이 아닌 다른 값들은 오류를 나타낸다는 점을 인지하고, 필요에 따라 특정 오류에 대한 고유한 코드를 정의하여 활용하면 디버깅 시간을 크게 단축할 수 있습니다.

5. 팀원들과 ‘우아한 종료’의 중요성을 공유하세요! 좋은 개발 문화는 개개인의 노력에서 시작됩니다. 동료 개발자들과 함께 우아한 종료(Graceful Shutdown)의 중요성을 공유하고, 이를 설계 단계부터 반영하는 습관을 들이는 것이 장기적으로 안정적인 서비스를 만들어 나가는 데 큰 도움이 될 것입니다.

중요 사항 정리

Ctrl+C는 단순히 프로그램을 끄는 행위를 넘어, 운영체제가 SIGINT 시그널을 전달하여 프로세스를 종료시키는 중요한 과정입니다. 이때 발생하는 STATUS_CONTROL_C_EXIT와 같은 종료 상태는 프로그램이 외부 요청에 의해 강제 종료되었음을 의미하며, 이는 예측치 못한 데이터 손실, 리소스 누수, 나아가 운영 환경에서의 서비스 중단과 같은 치명적인 문제로 이어질 수 있습니다. 따라서 개발자는 프로그램의 시작만큼이나 종료 처리에 각별한 주의를 기울여야 합니다. 시그널 핸들링을 통해 안전하게 데이터를 저장하고, 사용했던 모든 리소스를 깔끔하게 해제하며, 다양한 종료 시나리오에 대비한 우아한 종료(Graceful Shutdown) 로직을 설계하는 것이 필수적입니다. 이러한 노력은 단지 개별 프로그램의 안정성을 넘어, 우리가 만드는 서비스 전체의 신뢰도를 높이고 사용자 경험을 향상시키는 궁극적인 비결이 될 것입니다. 이 글을 통해 여러분의 프로그램이 어떤 상황에서도 안전하게 ‘착륙’할 수 있기를 진심으로 응원합니다.