백엔드 개발자들 대부분 IntelliJ IDEA를 기준으로 정보 공유가 오고 간다. 필요한 게 있다면, 직접 만들어 사용하는 편이지만, 다음과 같은 이유들로 전환을 결정했다.
1. 문맥 전환
당연하게도 VS Code와 IntelliJ은 서로 다르다. 그래서 무언가를 공유한다고 하더라도, 반드시 추상화 과정을 거쳐야 한다. 이러한 문맥 전환에 따른 불필요한 비용을 줄이기 위한 시도이다.
2. 코드 포맷팅
문맥 전환 비용에 대한 일례로 코드 포맷팅이 있다. IntelliJ와 Ecllipse 기반 규칙은 서로 호환되지 않는데, VS Code에서는 Ecllipse 기반으로 형식을 지정해야 하기 때문에 별도의 변환 과정이 필요하다.
물론 IntelliJ에서 Ecllipse 스타일로 규칙을 export 할 수 있다. 그러나 IntelliJ 엔진에서만 동작하는 기능을 포기해야 한다. 그래서 팀원 간 서로 동일한 규칙을 사용하자는 합의를 한다면, Ecllipse에서 지원하는 기능 중심으로 제한할 수 밖에 없다.
3. Spring 지원
IntelliJ IDEA Ultimate은 유료이나 스프링에 대한 전폭적인 지원을 제공한다. 한참 사용하지 않아서 몰랐지만, Spring Debugger와 같이 실행 문맥을 UI로 보여주는 플러그인도 제공한다. (사실 여기서 혹했다)
4. 커스텀 가능
여러모로 다소 낯설어지긴 했지만, 결국 내 입맛대로 바꿀 수 있으니 괜찮겠다고 판단했다. 1주차 비교적 시간의 여유가 있을 때, 최대한 빨리 허들을 넘어야겠다는 생각이 들어 시작하게 되었다.
다음과 같이 IDE의 모든 설정을 초기화했다.
- 파일 > IDE 설정 관리 > 디폴트 설정 복원
- 설정 > 모양 및 동작 > 시스템 설정 > 언어 및 지역 > 언어 > Korean 한국어
자, 그럼 무엇부터 시작해볼까?
설정 활용도 순으로 AI에게 추천을 받아보았다.
| 단계 | 목표 | 주요 설정 |
|---|---|---|
| 1 | 스타일 통일 | 포맷팅, 린팅, 커밋 컨벤션 |
| 2 | 키맵 적응 | VS Code → IntelliJ gradual 전환 |
| 3 | 탐색·리팩터링 숙달 | Navigate, Refactor, Structure View |
| 4 | 런/디버그 Context 구축 | Run Config, Spring Dashboard |
| 5 | 플러그인 정비 | Save Actions, GitToolBox 등 |
| 6 | Context 전환 체계화 | Inspection Profile, Template |
| 7 | 설정 백업/적용 자동화 | Settings Repository / Export |
** 각각의 단계는 이후 링크를 추가할 예정이다.
