편집기에서 보내는 시간이 너무 길었다
개발자는 하루 대부분을 브라우저보다 편집기에서 보낸다. 나도 비슷했다. PHP 코드 몇 줄 고치는 일보다, 어디서 깨졌는지 찾고 관련 파일을 왔다 갔다 하는 시간이 더 길었다. 문제는 기능이 없어서가 아니라, 작업이 자꾸 끊긴다는 점이었다.
예를 들어 Laravel 프로젝트 하나를 열면 routes, app, resources, config 폴더를 계속 오가게 된다. 여기에 Blade 템플릿, JavaScript, .env, SQL 확인까지 붙으면 화면 전환만 수십 번이다. 파일 수가 2,000개를 넘는 프로젝트에서는 단순 검색만으로도 맥락을 유지하기가 쉽지 않았다.
처음에는 가벼운 편집기로 버텼다. 빨리 켜지고 인터페이스도 단순하니 부담이 적었다. 하지만 함수 정의로 이동했다가 다시 돌아오고, 타입 추론이 어긋나고, 리팩터링할 때 문자열 검색에 의존하는 순간부터 속도가 아니라 피로가 쌓였다. 코드 작성보다 확인 작업이 더 길어지는 날이 잦아지면, 편집기를 바꿔야 할 때다.
먼저 해본 방식과 왜 오래 못 갔는지
처음 시도한 건 VS Code 조합이었다. 확장 프로그램으로 PHP Intelephense, ESLint, Prettier, GitLens, Docker, REST Client까지 붙이면 얼추 필요한 틀은 갖춰진다. 작은 프로젝트에서는 이 구성이 나쁘지 않았다. 켜지는 속도도 빠르고, 단발성 수정에는 부담이 없었다.
문제는 프로젝트가 커질수록 설정이 쌓인다는 점이다. PHP 버전이 8.1인지 8.2인지에 따라 경고가 달라지고, Xdebug 연결이 꼬이면 launch.json부터 다시 봐야 한다. 라라벨용 헬퍼 패키지와 확장 간 충돌이 나면, 무엇이 원인인지 바로 드러나지 않는다. 기능은 많지만 서로 다른 조각을 억지로 묶어 쓰는 느낌이 강했다.
한동안은 가벼운 편집기와 터미널을 병행하는 방식도 써봤다. 검색은 rg, 테스트는 터미널, DB는 별도 클라이언트, Git은 GUI 툴로 나누는 식이다. 이 방법은 익숙해지면 제법 빠르다. 다만 실수 한 번 나면 흐름이 끊긴다. 예를 들어 메서드 이름을 바꿀 때 문자열 치환으로는 주석, 테스트 더블, 템플릿 내부 참조까지 안전하게 따라가지 못했다.
결국 바꾼 계기는 디버깅이었다. 브라우저에서 값이 비어 있는데, 컨트롤러에서는 멀쩡해 보이고, 실제 원인은 서비스 클래스의 반환 타입 어긋남인 경우가 있었다. 이걸 로그와 var_dump()만으로 쫓아가려니 시간이 너무 오래 걸렸다. 딱 한 번, 30분이면 끝날 버그를 2시간 넘게 잡고 나서 생각이 바뀌었다. 편집기가 단순 입력창이면 안 되는 작업이라는 걸 체감했다.
PhpStorm을 고른 이유는 기능 수보다 연결감 때문이었다
PhpStorm을 처음 볼 때는 솔직히 무겁다는 인상이 먼저 든다. 실행 속도만 놓고 보면 더 가벼운 대안이 분명 있다. 그런데 며칠 써보면 판단 기준이 달라진다. 개별 기능이 화려해서가 아니라, 작성, 탐색, 리팩터링, 디버깅이 한 흐름으로 붙어 있다는 점이 크다.
가장 먼저 체감한 건 코드 이동 정확도였다. 컨트롤러에서 서비스로, 인터페이스에서 구현체로, 라우트 이름에서 실제 액션으로 넘어가는 과정이 덜 불안하다. Ctrl+B나 Navigate > Declaration or Usages 같은 기본 동작이 단단해서, 검색 결과를 눈으로 다시 검증하는 시간이 줄었다. 편집기에서 확신을 주는 순간이 꽤 중요하다.
두 번째는 자동 분석의 밀도다. 단순 문법 오류뿐 아니라, 도달하지 않는 조건문, 사용하지 않는 import, null 가능성, 잘못된 타입 힌트 같은 신호를 초반에 보여준다. 과하게 간섭하는 느낌이 들 때도 있지만, 적어도 배포 전에 놓치기 쉬운 실수를 먼저 걸러준다. 특히 PHP와 JavaScript가 같이 섞인 화면에서 이런 점검이 생각보다 유용했다.
세 번째는 한 프로젝트 안의 작업을 한 자리에서 처리하기 쉽다는 점이다. Git diff 확인, DB 쿼리 테스트, HTTP 요청 점검, Docker 컨테이너 연결, 테스트 실행까지 분리되지 않는다. 기능이 많다는 말보다, 창을 덜 바꾸게 만든다고 하는 편이 더 맞다. 하루 업무에서 저장과 전환이 반복되면 이 차이가 꽤 크게 남는다.
실제로 어떻게 쓰게 되는지 단계별로 보면 감이 온다
처음 세팅은 생각보다 단순했다. 프로젝트를 열고 File > Settings > PHP에서 인터프리터를 맞춘다. 로컬 PHP를 쓸지, Docker Compose 안의 PHP 컨테이너를 연결할지 먼저 정하면 된다. 여기서 버전을 정확히 잡아야 경고가 엉뚱하게 뜨지 않는다.
그다음은 디버깅 연결이다. Settings > PHP > Debug에서 Xdebug 포트를 확인하고, 서버 매핑은 Settings > PHP > Servers에서 맞춘다. 경로 매핑이 틀리면 브레이크포인트가 회색으로 남는데, 이때는 대부분 컨테이너 내부 경로와 로컬 경로가 어긋난 경우다. 예를 들어 컨테이너는 /var/www/html, 로컬은 D:\Source\project 식으로 잡혀 있으면 정확히 대응시켜야 한다.
업무 흐름은 대체로 이렇다. 라우트 파일에서 시작해 컨트롤러로 이동하고, 서비스 메서드로 들어간 뒤, 해당 메서드에서 참조하는 DTO나 모델 정의를 바로 확인한다. 중간에 SQL이 의심되면 Database 창에서 쿼리를 한번 날려보고, API 응답이 이상하면 내장 HTTP Client로 요청을 재현한다. 입력과 확인이 같은 화면에 머무르니, 어디까지 봤는지 기억하느라 에너지를 쓰지 않게 된다.
리팩터링도 이런 식으로 차이가 난다. 예전에는 메서드 이름을 바꿀 때 전체 검색 후 눈으로 걸러가며 수정했다. PhpStorm에서는 Refactor > Rename으로 바꾸면 PHP 코드, 테스트, 일부 템플릿 참조까지 함께 따라간다. 40개 파일 안팎에서 호출되는 메서드를 바꿀 때, 수동 수정은 보통 15분 이상 걸렸는데 이 작업은 몇 분 안에 끝나는 편이었다. 물론 결과 검토는 해야 하지만, 실수 가능성 자체가 줄어든다.
파일이 많고 작업이 섞일수록 결과 차이가 보였다
체감이 가장 컸던 건 중간 규모 이상 프로젝트였다. PHP 파일만 800개가 넘고 Blade, JS, CSS, 설정 파일이 같이 있는 저장소에서, 전역 검색과 참조 추적 속도가 꽤 안정적이었다. 첫 인덱싱에는 시간이 걸린다. 내 경우에는 SSD 기준으로 약 3~5분 정도 걸렸고, 메모리도 1GB 이상 잡아먹는 날이 있었다. 그 대신 인덱싱이 끝난 뒤부터는 탐색과 자동완성의 일관성이 유지됐다.
구체적인 차이는 수정 후 검증 단계에서 나왔다. 예전에는 라우트 수정, 서비스 수정, 프런트 응답 포맷 확인, 테스트 실행을 서로 다른 프로그램에서 했다. 지금은 코드 수정 후 바로 우측 상단에서 테스트를 돌리고, 실패한 케이스를 클릭해 해당 코드로 점프한 뒤, 필요하면 DB 값을 확인하는 식으로 이어진다. 단계 수로 치면 6~7번 창 전환하던 흐름이 2~3번 수준으로 줄었다.
작은 반복 작업에도 이점이 있다. 예를 들어 CSV 업로드 처리에서 UTF-8 인코딩 문제로 한글이 깨질 때, 관련 서비스와 업로드 검증 규칙, 예외 처리 위치를 한 번에 따라가며 확인할 수 있다. 업로드 대상이 CSV, 결과 저장은 ZIP 백업, 화면 출력은 JSON 응답처럼 포맷이 섞일수록 한 군데서 확인 가능한 편이 낫다. 단순한 기능 설명보다 이런 잡다한 업무에서 차이가 난다.
Git 작업도 의외로 자주 쓰게 된다. 커밋 전에 변경 라인을 바로 보고, 메서드 단위로 히스토리를 확인하고, 충돌 난 부분에서 이전 버전과 현재 버전을 나란히 보는 식이다. CLI Git이 더 빠를 때도 있지만, 리뷰 전에 빠르게 훑는 용도로는 꽤 쓸 만했다. 실무에서는 완벽한 한 방보다, 자주 보는 작업을 덜 번거롭게 만드는 쪽이 더 오래 간다.
누구에게 맞고, 어떤 대안이 더 나은 경우가 있는가
PhpStorm이 항상 정답은 아니다. 단일 PHP 파일 몇 개만 만지거나, 워드프레스 스니펫을 급하게 고치는 수준이면 VS Code가 더 가볍고 부담이 적다. 반대로 PHP 중심의 백엔드와 프런트 파일, 테스트, DB, Docker까지 한 저장소에 얽혀 있다면 PhpStorm 쪽이 낫다. 프로젝트 구조를 이해하고 안전하게 고치는 데 초점이 맞춰져 있기 때문이다.
대안으로 비교하면 VS Code는 시작 비용이 낮다. 무료이고, 필요한 기능만 골라 붙일 수 있어 작은 팀이나 개인 작업에 잘 맞는다. 다만 설정과 확장 의존이 커질수록 환경 편차가 생긴다. 같은 저장소를 열어도 사람마다 경고가 다르게 보이거나, 디버깅 세팅이 제각각인 경우가 생긴다. 팀 온보딩을 자주 해야 한다면 이 지점이 꽤 귀찮다.
또 다른 선택지는 가벼운 편집기와 터미널 조합이다. 숙련자에게는 여전히 강력하다. vim이나 neovim에 LSP를 얹고, 테스트와 Git, 검색을 모두 키보드 중심으로 처리하면 속도는 아주 빠를 수 있다. 대신 이 방식은 본인이 세팅과 유지보수를 감당해야 한다. 회사 노트북 교체 한 번만 있어도 환경 복구에 시간이 들고, 다른 사람이 같은 흐름을 재현하기 어렵다.
아쉬운 점도 분명하다. 무겁다. 인덱싱 중에는 팬이 도는 게 느껴지고, 오래 켜두면 메모리 사용량이 신경 쓰일 때가 있다. 라이선스 비용도 무시하기 어렵다. 그래서 PHP를 가끔만 건드리거나, 서버 접속해서 짧게 수정하는 업무가 대부분이라면 굳이 추천하지 않는다. 반대로 하루 대부분을 코드베이스 탐색, 수정, 디버깅에 쓰는 사람이라면 한번쯤 써볼 가치는 있다. 내 기준에서는 ‘기능이 많아서’가 아니라 ‘삽질 시간을 줄여서’ 남는 편이었다. 다만 노트북 사양이 낮고 프로젝트가 작다면, 예전 방식이 더 현실적일 수도 있다.