VS Code 안에 AI를 다 넣어놨더니 생긴 일
VS Code를 바꾸면 풀릴 문제였을까요
아니었습니다. VS Code를 다른 편집기로 갈아타는 것만으로는 제 문제가 하나도 해결되지 않았습니다. 저는 코드를 오래 편집하는 사람이 아니라 업무 구조를 설계하고 지시하고 결과를 확인하는 사람입니다. 그런 사람에게 필요한 것은 더 좋은 편집기가 아니라, 지시하는 창과 실제로 일하는 프로세스를 떼어놓는 구조였습니다.
실제로 제가 쓰고 있던 VS Code는 코드 편집기 역할을 거의 하지 않았습니다. 그 안에 AI 대화창과 여러 개의 터미널, 별도 채팅 패널, 프로젝트별 탭이 하나도 빠짐없이 들어가 앉아 있었습니다. 편집기라기보다 AI 작업 운영체제에 가까웠습니다. 닫으면 일이 멈췄습니다.
작업 기록을 근거로 내린 판단은 이렇습니다.
- 편집기를 교체해서 얻을 것은 거의 없습니다. 제 장애는 편집기에서 나온 적이 없습니다. 전부 실행 환경 쪽이었습니다.
- 먼저 할 일은 이미 독립적으로 실행되던 백엔드는 그대로 두고 지시용 화면을 VS Code 밖으로 옮기는 것이었습니다.
- 그다음이 코딩 작업자를 편집기 확장이 아니라 독립 실행 프로그램으로 두는 일이었습니다.
- 여러 작업자를 한 화면에서 관리하는 도구는 병렬 작업이 실제로 늘어난 뒤에 붙여도 늦지 않습니다.
시작은 “더 좋은 IDE가 있을까”였습니다
처음 던진 질문은 단순했습니다. 지금까지 제가 AI 에이전트로 해온 작업 기록을 근거로, 지금 쓰는 VS Code보다 더 맞는 개발 환경이나 조합이 있는지 평가해달라는 것이었습니다. 이런저런 대안 이름을 몇 개 예시로 들면서 물었습니다.
돌아온 답은 대안 목록이 아니었습니다. 제 작업 패턴을 뜯어본 분석이었고, 결과적으로 이쪽이 훨씬 쓸모 있었습니다.
과거 기록에서 확인된 제 작업 방식
첫째, 순수 코딩보다 업무 설계에서 구현, 실행 검증까지의 비중이 컸습니다. 사내 업무용 웹앱 하나를 만들 때도 실제로 처리한 건 코드가 아니었습니다. 여러 법인의 업무 구분과 권한 구조 설계, 요청을 담당별로 나누는 라우팅, 읽기 전용 권한 설정, 승인 게이트, 서버와 대시보드 화면, 윈도우 프로세스 관리, 외부 접속 경로, 그리고 실제 실행이 되는지 확인하는 검증까지였습니다. 이 중 코드 편집기가 실제로 도와주는 구간은 일부입니다.
둘째, 장애의 대부분이 편집기가 아니라 실행 환경에서 나왔습니다. 기록에 반복해서 등장한 문제는 이런 것들이었습니다.
- 서버 프로세스는 살아 있는데 응답하지 않음
- 같은 포트에 프로세스가 세 개 중복 실행됨
- 서로 다른 두 서비스의 포트 번호를 혼동함
- 네트워크는 정상인데 접속 주소가 틀림
- 윈도우 서비스 권한 문제
- 죽었을 때 되살리는 절차와 상태 점검이 없음
이 목록을 쭉 놓고 보면 편집기를 바꿔서 해결될 항목이 하나도 없습니다. 필요한 것은 프로세스 단일 실행 보장, 변경 이력, 최소한의 자동 테스트, 상태 점검, 로그, 재시작 절차의 표준화였습니다.
셋째, 저는 코드를 직접 오래 고치기보다 자연어로 방향을 교정합니다. 실제로 한 프로젝트는 초기 목표 수정, 역할 경량화, 더 가벼운 모델 배치, 계정별 호출에서 묶음 처리 방식으로 변경, 최종 게시는 사람 승인 유지 순서로 발전했습니다. 전부 대화로 방향을 튼 것입니다. 코드를 붙잡고 앉아서 한 게 아닙니다.
스크린샷 한 장으로 판이 뒤집혔습니다
여기까지는 편집기가 보조 도구라는 정리였습니다. 그런데 제 실제 화면을 캡처해 보여주고 나니 이야기가 완전히 달라졌습니다. 왼쪽에 AI 세션 목록, 가운데 AI 작업창, 아래에 에이전트 실행 터미널과 여러 개의 파워셸 터미널이 있었습니다. 오른쪽에는 별도 AI 채팅 패널, 위쪽 탭에는 회사 업무, 블로그, 엑셀, 자동매매 같은 프로젝트별 세션이 전부 VS Code 안에 들어가 있었습니다.
그러니까 VS Code를 닫으면 이렇게 됩니다.
- 그 안의 에이전트 대화창 종료
- 확장으로 붙어 있던 AI 세션 접근 불가
- 다른 AI 채팅 패널 접근 불가
- 통합 터미널에서 돌던 대화형 프로세스 종료 가능성
- 프로젝트별로 배치해둔 터미널 구성 상실
편집기가 아니었습니다. 작업 전체의 단일 장애점이었습니다.
확인해보니 런타임은 이미 독립돼 있었습니다
여기서 실제 상태를 점검한 결과가 중요했습니다. 상시 실행 백엔드는 이미 별도 프로세스로 돌고 있었고, 윈도우 예약 작업으로도 등록돼 있었습니다. 텔레그램 연결도 살아 있었고, 모델 인증은 여섯 곳이 이미 붙어 있었습니다. 데스크톱 앱과 웹 대시보드도 있었습니다.
반면 독립 실행형 코딩 CLI는 하나도 없었습니다. 확인한 다섯 개가 전부 미설치였습니다.
정리하면 이런 상태였습니다.
- 모델 인증과 에이전트 런타임은 이미 편집기와 무관하게 독립
- 사용자 인터페이스만 VS Code 안에 전부 몰려 있음
기술 문제가 아니라 배치 문제였습니다.
데스크톱 앱을 설치해보니 그냥 됐습니다
1차 개선은 단순했습니다. 에이전트를 VS Code 터미널 밖으로 꺼내 독립 윈도우 앱으로 실행하는 것이었습니다. 설치하고 실행하니 기존 세션 목록이 그대로 떴습니다. 텔레그램과 예약 작업 연결 표시도 그대로였고, 기존 메모리와 모델 인증과 스킬이 전부 연동됐습니다. 바탕화면 바로가기까지 만들어졌습니다.
같은 프로그램의 다른 화면이었을 뿐입니다. 그동안 터미널에서만 띄워놓고 쓰다 보니, 저 혼자 이건 터미널 프로그램이라고 규정해두고 있었던 셈입니다.
그런데 이건 의존성을 옮긴 것뿐 아닐까요
설치하자마자 든 의문입니다. VS Code 안에서 AI 도구들을 돌리던 것을 데스크톱 앱 안에서 돌리는 것으로 바꾸면, 결국 VS Code 의존성이 데스크톱 앱 의존성으로 자리만 옮기는 것 아니냐는 이야기입니다.
맞는 지적이었습니다. 앱이 작업자를 소유하는 구조에서는, 앱을 닫는 순간 작업도 같이 끝납니다. 최소한 결과를 받을 창이 사라지고 진행 상태를 다시 찾기 어려워집니다.
그래서 목표 구조는 이렇게 정리됐습니다. 접속 창구는 여러 개여도 되고, 그중 어느 것도 필수가 아니어야 합니다. 데스크톱 앱, 모바일 메신저, 웹 대시보드, 필요할 때 VS Code까지 전부 창구일 뿐입니다. 그 아래에 상시 실행 백엔드가 있고, 다시 그 아래에 작업 큐와 작업 상태 기록과 실제 작업자 프로세스가 있는 형태입니다. 어느 화면을 닫아도 작업은 계속되고, 어디서든 상태를 확인하고 다음 지시를 내릴 수 있는 구조입니다.
모바일에서 확인하는 문제
PC 앞을 떠나 있을 때 진행 상황을 확인하고 추가 지시를 하려면 창구가 하나 더 필요했습니다. 역할을 나눴습니다.
텔레그램은 지시와 승인, 오류 알림, 완료 보고에 씁니다. 웹 대시보드는 세션 목록과 대화 내용, 진행 중인 작업 과정을 눈으로 확인하는 용도입니다. 이 둘로 부족해서 코딩 작업자의 터미널 화면 자체를 실시간으로 봐야 하는 상황이 실제로 생기면, 그때 전용 도구를 검토하기로 했습니다.
텔레그램을 통합 지시창으로 쓸 때 걱정한 것은 알림 폭탄이었습니다. 모든 답변이 복제돼 날아오면 못 씁니다. 확인해보니 기본 동작은 출발한 창구로만 답변이 돌아가는 방식이었고, PC에서 시작한 작업을 모바일에서도 받아보려면 그때마다 따로 요청해야 했습니다. 그래서 지시 말미에 “텔레 보고해”라고 붙이면 최종 결과만 텔레그램으로 보내는 규칙을 만들었습니다. 이 규칙은 지속 메모리에 저장돼서 새 세션에서도 동작합니다.
다만 반대 방향의 함정도 있었습니다. 결과를 봐야 다음 지시를 내릴 수 있으므로, 중간 도구 실행 로그는 안 보내더라도 의사결정에 필요한 최종 결과는 반드시 보내도록 했습니다. 안 그러면 통합 지시창이 아니라 알림창이 됩니다.
여기서 걸린 것들
매끄러웠다고 쓰면 거짓말입니다.
Tailscale 공개 기능이 계정 단위로 잠겨 있었습니다
웹 대시보드를 모바일에 연결하려고 Tailscale의 공개 기능을 쓰려 했습니다. 그런데 그 기능이 계정 단위로 비활성이라, 명령으로는 아예 처리가 안 됐습니다. 관리 콘솔에 브라우저로 로그인해서 승인해야 하는 항목이었습니다. 우회로는 대시보드를 로컬 주소가 아니라 Tailscale 주소에도 바인딩해서 직접 접속하는 방식이었습니다.
방화벽 규칙은 관리자 권한이 필요했습니다
바인딩을 바꾸고 나서도 다른 기기에서는 접속이 안 됐습니다. 해당 포트의 인바운드 허용 규칙이 없었는데, 이건 관리자 권한이 필요한 작업이라 에이전트가 대신 처리하지 못했습니다. 결국 제가 직접 관리자 권한 창을 열어 규칙 한 줄을 추가했습니다. 자동화가 어디까지 가능하고 어디서부터 사람이 손을 대야 하는지, 그 경계가 여기서 갈렸습니다.
원인 진단이 두 번이나 헛다리를 짚었습니다
방화벽까지 열었는데도 모바일에서 화면이 안 떴습니다. 처음 나온 진단은 주소창에 포트 번호가 빠졌다는 것이었습니다. 아니었습니다. 두 번째로는 모델 호출 쪽 사용 한도 초과 메시지를 원인으로 오인했는데, 그건 접속과는 아무 상관 없는 별개 화면이었습니다.
진짜 원인은 다른 곳에 있었습니다. 대시보드 서버를 실행한 터미널이 데스크톱 앱 내부에서 열린 터미널이라 앱 전용 환경변수를 물려받고 있었습니다. 그 탓에 서버가 웹용 화면 파일이 아니라 데스크톱 앱 전용 화면 파일을 그대로 내보내고 있었습니다. 앱 전용 화면은 앱 내부 통신 경로를 전제로 만들어져 있어서, 모바일 브라우저에서는 시작조차 못 하고 오류 화면이 떴습니다. 환경변수를 제거하고 완전히 새 프로세스로 재시작하니 정상적인 로그인 화면이 나왔습니다.
이건 편집기 종류와 아무 상관이 없는 문제였습니다. 앞서 정리한 “제 장애는 실행 환경에서 나온다”는 진단이 이 작업 안에서 그대로 재현된 셈입니다.
웹과 앱이 별개 코드베이스였습니다
이어서 입력창 근처에 5시간 사용량과 1주 사용량을 표시하는 기능을 붙였습니다. 웹 대시보드에 만들어 넣고 반영까지 확인했습니다. 그런데 데스크톱 앱에는 나타나지 않았습니다. 두 화면이 같은 백엔드를 쓰긴 하지만, 화면 코드는 완전히 별개였습니다. 결국 같은 기능을 두 번 만들었습니다.
이런 건 기능 소개 문서에 안 나옵니다. 직접 굴려봐야 나오는 종류의 정보입니다.
실무자 기준으로 다시 정리하면
도구 이름으로 고르지 않고 제가 어떤 작업을 하는 사람인지를 기준으로 고르기 시작하니, 판단이 훨씬 빨라졌습니다. 아래 항목을 스스로에게 물어보고 정리했습니다.
- 하루에 코드를 직접 타이핑하는 시간이 긴 사람인가, 아니면 지시하고 결과를 확인하는 시간이 긴 사람인가
- 지난 몇 달간 실제로 나를 멈춰 세운 문제가 편집 기능 부족이었나, 프로세스와 포트와 권한이었나
- 지금 쓰는 화면을 닫으면 무엇이 같이 죽는가
- 자리에 없을 때 진행 상황을 확인할 경로가 있는가
- 새 도구를 붙이기 전에, 이미 설치돼 있는데 안 쓰고 있는 기능부터 확인했는가
마지막 항목이 이번에 가장 크게 남았습니다. 새 도구를 검토하려고 시작한 작업이었는데, 결국 새로 들인 도구는 하나도 없었습니다. 이미 있던 기능을 원래 있어야 할 자리에 옮겨놓은 게 전부였습니다.
VS Code는 지금도 씁니다. 다만 코드와 변경 내역을 눈으로 확인할 때만 엽니다. 모든 일이 그 안에서 벌어져야 할 이유는 없었습니다. 그게 이번 정리의 전부입니다.
이어서 읽을 기록
