에디트플러스에서 AI 에이전트까지 — 개발 도구 20년 연대기

오래된 외장 하드를 정리하다가 editplus라는 폴더를 발견했습니다. 안에는 설치 파일과 함께 제가 만들어둔 문법 강조 설정 파일이 들어 있었습니다. 확장자 목록을 보니 .asp가 있었습니다. 그걸 보고 나서야 시간이 꽤 흘렀다는 게 실감이 났습니다.

21년 동안 손에 쥔 도구를 순서대로 늘어놓으면 그 자체로 업계의 변화가 보입니다. 그런데 도구가 바뀔 때마다 편해지기만 한 것은 아니었습니다. 매번 학습 비용을 냈고, 어떤 전환은 몇 달이 걸렸습니다. 이 글에서는 네 개의 축으로 그 흐름을 정리하고, 각 전환기에 실제로 무엇을 치렀는지, 그리고 20년 동안 바뀌지 않은 것이 무엇인지 적어보려 합니다.

네 개의 축으로 본 20년

에디터: 텍스트 편집기에서 대화 상대로

시작은 에디트플러스와 울트라에디트였습니다. 문법 강조와 FTP 업로드 기능이 붙어 있는 텍스트 편집기였고, 자동 완성 같은 건 없었습니다. 함수 이름을 외우고 있어야 했고, 오타는 실행해봐야 알았습니다.

그다음이 통합 개발 환경입니다. 이클립스와 비주얼 스튜디오를 쓰면서 처음으로 "코드를 아는 도구"를 만났습니다. 정의로 이동하고, 이름을 한 번에 바꾸고, 중단점을 걸어 변수를 들여다볼 수 있게 됐습니다. 대신 무거웠습니다. 프로젝트 하나 여는 데 몇 분씩 걸리는 게 당연했습니다.

VS 코드는 그 중간을 다시 찾은 도구였습니다. 가볍게 뜨면서도 확장으로 필요한 만큼만 붙일 수 있었습니다. 그리고 최근 몇 년 사이에 에디터 안으로 AI 에이전트가 들어왔습니다. 이제는 코드를 작성하는 도구라기보다 무엇을 만들지 설명하고 결과를 검토하는 자리에 가까워졌습니다.

형상관리: 폴더 복사에서 브랜치로

가장 부끄러운 시절 이야기부터 하자면, 처음에는 형상관리가 폴더 복사였습니다. src_20050812, src_최종, src_최종_진짜 같은 이름의 폴더들이 서버에 쌓여 있었습니다. 누가 언제 무엇을 바꿨는지는 아무도 몰랐습니다.

CVS를 거쳐 SVN으로 넘어가면서 이력이 남기 시작했습니다. 중앙 서버에 커밋하고, 충돌이 나면 손으로 합쳤습니다. 그래도 폴더 복사에 비하면 완전히 다른 세상이었습니다. 다만 서버가 죽으면 아무것도 할 수 없었고, 브랜치를 만드는 일이 비용이 큰 작업이라 다들 한 줄기에서만 일했습니다.

깃으로 넘어갈 때가 개인적으로 가장 큰 전환이었습니다. 개념 자체가 달랐기 때문입니다. 로컬에 전체 이력이 있다는 것, 커밋과 푸시가 분리되어 있다는 것, 브랜치가 값싸다는 것을 이해하는 데 시간이 걸렸습니다. 저는 처음 몇 달 동안 깃을 SVN처럼 썼습니다. 명령어는 외웠지만 모델은 이해하지 못한 상태였습니다.

배포: 새벽 FTP에서 컨테이너로

배포는 파일을 올리는 일이었습니다. 새벽에 접속자가 줄면 FTP 클라이언트를 열고 바뀐 파일만 골라 올렸습니다. 어떤 파일이 바뀌었는지는 기억에 의존했고, 하나를 빠뜨리면 그때부터 원인을 찾느라 아침을 맞았습니다.

그다음이 스크립트였습니다. 압축해서 올리고 풀고 서비스를 재시작하는 과정을 셸 스크립트로 묶었습니다. 여기서 한 단계 더 가면 CI/CD입니다. 커밋을 밀면 테스트가 돌고 빌드가 되고 배포까지 이어지는 흐름을 처음 만들었을 때, 배포가 무서운 일에서 평범한 일로 바뀌었습니다.

컨테이너는 "내 컴퓨터에서는 되는데"라는 말을 줄여줬습니다. 실행 환경까지 코드로 적어두는 방식이라, 서버를 새로 만들 때 겪던 설정 지옥이 크게 줄었습니다. 대신 새로 배울 것이 늘었습니다. 이미지, 레이어, 네트워크, 볼륨 같은 개념을 익히는 데 또 시간이 들었습니다.

학습: 책과 잡지에서 대화형 도구로

막히면 책을 봤습니다. 서점에 가서 목차를 훑고 사 왔고, 잡지 부록 CD에 든 예제 소스를 뜯어봤습니다. 번역서가 늦게 나와서 원서를 읽는 사람과 아닌 사람의 속도 차이가 컸습니다.

검색 엔진과 개발자 질의응답 사이트가 자리 잡으면서 이 구도가 완전히 바뀌었습니다. 오류 메시지를 그대로 붙여넣으면 같은 문제를 겪은 사람의 글이 나왔습니다. 문제 해결 시간이 시간 단위에서 분 단위로 줄었습니다.

지금은 LLM에게 상황을 설명하면 맥락에 맞춘 설명이 돌아옵니다. 다만 답이 항상 맞지는 않습니다. 그래서 필요한 능력이 검색어를 잘 만드는 것에서 답을 검증하는 것으로 옮겨갔습니다.

한눈에 보는 네 축

축1단계2단계3단계치른 학습 비용

에디터	에디트플러스, 울트라에디트	이클립스, 비주얼 스튜디오	VS 코드, AI 에이전트 내장	단축키와 설정 재학습, 무거운 IDE 적응
형상관리	폴더 복사	CVS, SVN	깃과 브랜치 전략	분산 저장소 개념 자체를 다시 익힘
배포	수동 FTP 업로드	스크립트, CI/CD	컨테이너와 오케스트레이션	파이프라인 문법, 인프라 개념 추가
학습	책, 잡지 부록	검색, 질의응답 사이트	LLM과 에이전트	정보 판별에서 답 검증으로 기준 이동

바뀌지 않은 것

네 축 모두 바뀌었지만, 그 아래에서 그대로인 것이 하나 있습니다. 문제를 정의하는 능력입니다.

도구가 좋아질수록 이 부분이 오히려 더 드러납니다. 에디트플러스 시절에는 요구사항이 흐릿해도 구현 속도가 느려서 중간에 알아차릴 시간이 있었습니다. 지금은 지시가 흐릿해도 결과물이 몇 분 만에 나옵니다. 잘못된 방향으로 아주 빠르게 가는 일이 가능해진 겁니다.

메리톡톡을 만들면서도 같은 걸 느낍니다. 기능을 구현하는 시간보다 "이 화면에서 사용자가 진짜 하고 싶은 게 뭔가"를 정하는 시간이 훨씬 깁니다. 그리고 그 시간을 줄여주는 도구는 20년 동안 나오지 않았습니다.

도구가 바뀔 때마다 반복된 또 하나의 패턴이 있습니다. 새 도구가 나오면 처음에는 그것을 이전 도구처럼 쓴다는 점입니다. IDE를 텍스트 편집기처럼 쓰고, 깃을 SVN처럼 쓰고, 컨테이너를 가상 머신처럼 쓰고, AI 에이전트를 자동 완성처럼 씁니다. 도구를 제대로 쓰게 되는 시점은 설치한 날이 아니라 그 도구가 전제하는 모델을 이해한 날이었습니다.

마치며

에디터는 대화 상대가 됐고, 형상관리는 분산됐고, 배포는 자동화됐고, 학습은 대화형으로 바뀌었습니다. 각 전환마다 학습 비용을 냈지만 되돌아가고 싶은 단계는 없습니다.

지금 할 수 있는 한 가지는, 현재 쓰는 도구 중 "이해하지 못한 채 명령어만 외워 쓰는 것"이 있는지 하나 찾아보는 일입니다. 제가 깃을 SVN처럼 쓰던 시기가 그랬습니다. 그 하나를 제대로 이해하는 데 드는 며칠이, 다음 몇 년을 편하게 만들어줍니다.