코드 인텔리전스
자동완성, 정의로 이동, 사용처 찾기, 타입 추론, 오류 표시. IDE의 체감 성능은 대부분 여기서 갈립니다.
이 파트에서 다루는 내용
편집기와 IDE의 차이IDE의 구성요소IDE 역사 3단계지금 무엇이 경쟁하고 있는가
01
IDE는 편집기가 아니라 개발 과정 전체를 묶은 작업대입니다
IDE(Integrated Development Environment, 통합개발환경)는 코드를 작성하는 편집기에 빌드, 실행, 디버깅, 형상관리, 검색, 리팩터링을 하나의 화면에서 이어 붙인 도구입니다.
메모장으로도 코드는 쓸 수 있습니다. 그러나 실무에서 오래 걸리는 일은 타이핑이 아니라 '이 함수가 어디서 쓰이는지 찾기', '왜 이 값이 null인지 확인하기', '이름을 바꿔도 안전한지 판단하기'입니다. IDE는 이 확인 비용을 줄이기 위해 존재합니다.
그래서 IDE를 고르는 기준은 '어떤 게 예쁜가'가 아니라 '내가 다루는 언어와 프로젝트에서 코드를 얼마나 정확하게 이해해 주는가'입니다.
빌드와 실행
빌드 도구를 인식해 의존성을 해석하고, 실행 구성을 저장하고, 실패한 위치를 코드로 연결합니다.
디버거
실행 중인 프로세스에 붙어 값을 확인합니다. 로그를 찍고 다시 빌드하는 루프를 줄여 줍니다.
리팩터링
이름 변경, 메서드 추출, 시그니처 변경을 문자열 치환이 아니라 코드 구조 기준으로 처리합니다.
형상관리 연동
변경 목록, diff, 충돌 해결, 브랜치 전환을 편집 화면에서 처리합니다.
확장
언어, 프레임워크, 사내 규칙, 배포 도구를 붙입니다. 확장 생태계가 IDE의 수명을 결정합니다.
02
IDE 시장은 25년 동안 세 번 갈라졌습니다
지금의 Eclipse, IntelliJ IDEA, VS Code, Cursor는 서로 다른 시대의 답입니다. 각 도구가 어떤 문제를 풀려고 태어났는지 알면 장단점이 설명 없이 이해됩니다.
1세대 · 플랫폼 경쟁 (2001~2010)
자바 엔터프라이즈 개발이 커지면서 '무거워도 좋으니 프로젝트 전체를 이해하는 도구'가 필요했습니다. 두 도구 모두 코드를 통째로 파싱해 인덱싱하는 방향을 택했습니다.
- Eclipse는 무료·오픈소스 플러그인 플랫폼으로 표준을 노렸습니다
- IntelliJ IDEA는 유료 대신 코드 분석 품질로 승부했습니다
2세대 · 경량 에디터의 역습 (2015~2022)
웹과 다중 언어 개발이 늘면서 자바 중심 IDE는 과했습니다. VS Code는 가벼운 편집기에 확장을 얹는 방식으로 출발했고, 언어 지원을 별도 서버로 분리한 LSP로 판을 바꿨습니다.
- 언어 지원을 에디터에서 떼어내 재사용 가능하게 만들었습니다
- 원격·컨테이너 개발을 표준 기능으로 끌어왔습니다
3세대 · AI 에이전트 (2023~현재)
코드를 '작성'하는 도구에서 '지시하고 검토'하는 도구로 무게중심이 옮겨갔습니다. Cursor는 이 전제로 처음부터 설계했고, 기존 IDE들은 에이전트를 얹는 방향으로 따라왔습니다.
- 편집 단위가 한 줄에서 여러 파일·여러 작업으로 커졌습니다
- IDE 평가 기준에 모델 품질, 비용, 보안이 추가됐습니다
03
실무에서 IDE를 고르는 기준은 네 가지입니다
- 언어와 프레임워크: 자바·코틀린·스프링 중심이면 IntelliJ, 웹·다중 언어면 VS Code 계열이 유리합니다.
- 프로젝트 제약: 고객사 표준, 폐쇄망, 사내 배포 이미지가 정해져 있으면 개인 취향보다 제약이 먼저입니다.
- 팀 합의: 포맷터, 인코딩, 줄바꿈, 빌드 설정이 IDE마다 다르면 diff가 오염됩니다. 도구보다 설정 통일이 중요합니다.
- AI 사용 가능 범위: 사내 코드가 외부로 나갈 수 있는지에 따라 쓸 수 있는 도구가 먼저 걸러집니다.
현실적인 결론
실무에서는 하나만 쓰지 않습니다. 자바 백엔드는 IntelliJ, 인프라 설정과 스크립트는 VS Code, AI로 크게 손볼 때만 Cursor처럼 병행하는 경우가 많습니다. 중요한 것은 어떤 도구를 쓰든 저장소에 남는 결과물이 동일해야 한다는 점입니다.
체크