언리얼 C++ IDE 비교 — Visual Studio vs Rider

알고리즘 문제를 풀다가 언리얼 작업으로 넘어가면서, 계속 미뤄 뒀던 질문 하나를 정리했다 — “언리얼 C++은 Visual Studio에서 하면 안 되나?” C++ 클래스를 만들면 자동완성이 안 붙는 경험이 쌓여 Rider를 함께 쓰고 있었는데, 그게 정말 VS의 한계인지 확인해 보고 싶었다. 이 글에서는 두 IDE를 같은 작업으로 비교한 결과를 이야기하려 한다 — 증상이 무엇이었고, 실제 원인은 무엇이었고, 어떤 상황에 무엇을 쓰기로 했는지다.

같은 날 푼 알고리즘 문제 풀이는 백준 9012 괄호·백준 10828 스택·CodeKata 09·CodeKata 10에 각각 정리돼 있다.

언리얼에서 VS vs Rider — IDE 선택과 사용 경험

언리얼에서 C++ 클래스를 생성할 때 VS와 Rider가 구체적으로 어떻게 다른지 직접 비교

증상

언리얼 클래스 마법사로 새 C++ 클래스를 만든 직후, VS에서 자동완성과 오류 표시가 바로 작동하지 않았다. 파일 자체는 프로젝트에 추가되는데 IDE가 완전히 인식하기까지 솔루션 재로드가 필요한 경우가 있었고, 그래서 “VS에서는 안 된다”는 인상이 남아 Rider를 함께 쓰게 됐다.

원인과 확인

VS에서도 클래스 생성 자체는 정상이다. 파일이 솔루션에 추가되고 언리얼에도 반영된다. 다만 생성 직후 인텔리센스(자동완성·오류 표시)가 즉시 따라오지 않을 수 있고, 솔루션을 재로드해야 IDE 기능이 정상화되는 경우가 있다. 대신 디버깅 환경은 확실한 강점이다 — 중단점, 호출 스택, 변수 확인 흐름이 익숙하고 안정적이다.

Rider는 .uproject 기준으로 프로젝트를 관리해서 새 파일 추가 후 반영이 빠르다. 생성 직후에도 자동완성·코드 인식이 자연스럽게 붙어서 “추가하고 바로 이어서 작업”하기 편했다.

공통적으로, 런타임 에러가 나면 처음엔 엔진 내부 파일 경로만 보여 당황할 수 있는데, 호출 스택을 따라가면 내 코드의 정확한 줄 번호를 찾을 수 있다.

결론

상황	추천	이유
새 C++ 클래스 추가 후 바로 작업	Rider	생성 직후 코드 인식·자동완성이 빠르게 붙음
디버깅 / 빌드 흐름	VS	중단점·호출 스택 등 디버그 환경이 손에 익음
자동완성이 안 붙을 때	VS 솔루션 재로드	파일 추가 직후 인텔리센스 반응이 늦을 수 있음

핵심 교훈: “VS에서 클래스 생성이 안 된다”가 아니라, 생성 후 IDE 기능이 붙는 속도의 차이였다. 클래스 추가·즉각 작업은 Rider, 디버깅·빌드는 VS — 상황에 맞게 병행하는 것이 효율적.

핵심 요약 — “VS에서 언리얼 C++ 클래스 생성이 안 된다”는 기능의 문제가 아니라 생성 직후 IDE가 파일을 인식하는 속도의 차이였다. 파일 추가 직후 바로 이어서 작업할 때는 .uproject 기준으로 프로젝트를 관리하는 Rider가, 중단점·호출 스택을 따라가는 디버깅에는 VS가 편했다.