이제 개발을 할 때 LLM은 거의 필수 도구가 된 것 같습니다. 작업을 하다 보면 LLM에 여러 작업을 던져놓고, 그 사이에 다른 일을 처리하는 방식이 자연스럽게 익숙해진 것 같아요.
아직까지는 코딩용 AI 도구들이 확실하게 한쪽으로 쏠렸다기보다는.. 서로 계속 경쟁하면서 발전하고 있는 느낌입니다.
그래서 저는 하나에 정착하기보다는 할인이나 제공 정책에 따라 그때그때 옮겨가며 사용하는 편입니다.
2026년 3월 기준으로는 Codex를 주로 사용하고 있고, 그전에는 Claude Code와 Serena 조합을 자주 활용했습니다.
요즘은 LLM들이 전반적으로 기본 이상은 해주는 느낌입니다. 특정 하나를 딱 집어서 더 낫다고 말하기는 어려운 것 같아요. 모델과 서비스도 워낙 빠르게 바뀌고 있고요.
그래서 특정 도구를 비교하기보다는, CLI 기반 LLM 도구를 사용하면서 공통적으로 도움이 되었던 설정이나 사용 방법을 정리해보려고 합니다.
컨텍스트 설정
LLM을 CLI 환경에서 사용할 때 가장 먼저 정리해야 할 것은 프로젝트 컨텍스트입니다.
CLI를 통해 프로젝트를 한 번 연동하면 해당 세션에서 프로젝트가 기본 컨텍스트로 유지되기 때문에, 초기 설정을 잘 해두는 것이 중요합니다.
최근에는 여러 도구에서 AGENTS.md와 같은 규칙 파일을 지원하고 있습니다.
프로젝트 루트에 이 파일을 두고 구조, 빌드 방법, 코드 스타일, 주의사항 등을 정리해두면 도구가 저장소를 보다 안정적으로 이해하고, 일관된 결과를 생성하는 데 도움이 됩니다.
예를 들어, Claude Code는 CLAUDE.md를 사용합니다. 도구마다 파일명은 다르지만, 역할은 동일합니다.
결국 핵심은 프로젝트에서 지켜야 할 규칙을 AI가 읽을 수 있는 형태로 명확하게 정의하는 것입니다.
일반적으로 CLI 도구에서는 /init과 같은 명령을 통해 초기 가이드 파일을 생성할 수 있습니다.
생성된 파일을 그대로 사용하는 것보다, 아래와 같은 항목을 구체적으로 채워두면 실제 사용 시 훨씬 효과적입니다.
- 프로젝트 구조
- 실행 및 빌드 방법
- 테스트 방법
- 코드 스타일
- 금지하거나 주의해야 할 작업
여러 도구를 함께 쓰고 있다면 관리 포인트를 줄이는 것도 중요합니다. 예를 들어 하나의 기준 문서를 만들고 다른 규칙 파일에서 그 문서를 따르도록 적어두면 유지보수가 조금 더 편합니다.
관련 가이드는 아래 문서를 참고하면 좋을 것 같아요.
Claude Code와 Serena 조합
한동안 가장 만족스럽게 사용했던 조합은 Claude Code와 Serena였습니다.
Serena는 공식 GitHub에서 설치 가이드를 확인할 수 있습니다.
Serena는 로컬에서 실행되는 MCP 서버 형태로 동작하고, Claude Code가 이를 호출하여 사용하는 구조입니다.
특히 규모가 큰 프로젝트를 다룰 때 컨텍스트를 효율적으로 관리할 수 있었고, 여러 파일을 오가며 작업할 때의 흐름도 꽤 자연스러웠습니다.
다만 제가 사용하던 시점 기준으로는 Claude Code 자체도 토큰 소모가 빠른 편이었고, Serena를 함께 사용한다고 해서 토큰 사용량이 크게 줄어들지는 않았습니다.
대신 작업의 정확도나 맥락 이해 측면에서는 더 나아졌다는 느낌을 받았습니다.
저는 macOS 환경에서 간단한 스크립트를 만들어 사용했는데, 아래 gist 스크립트를 내려받은 후, 아래 두 개의 명령어를 실행하면 바로 사용할 수 있습니다.
| |
아래의 스크립트는 Serena 저장소에서 최신 코드로 Serena를 설치한 뒤, 두 번째 스크립트로 Claude CLI에 MCP 설정을 자동 등록하는 방식입니다.
이렇게 세팅해두면 이후에는 프로젝트 위치에서 간단한 명령(setup serena)만으로 Serena가 연결된 Claude Code 환경을 빠르게 띄울 수 있습니다.
아래 gist에 설치 과정을 정리해두었습니다.
당연한 이야기지만 이 조합도 시점에 따라 더 좋은 방식이 계속 나옵니다. LLM 도구 생태계는 며칠만 지나도 흐름이 바뀌기 때문에, 설치 전에 공식 문서와 최근 저장소 안내를 한 번 확인하는 편이 안전합니다.
Codex 사용
Codex는 상대적으로 시작이 단순한 편이었습니다.
Node 환경에서 설치한 뒤 터미널에서 실행하면 바로 써볼 수 있고, 종종 알아서 업데이트하고, 초기 진입 장벽도 높지 않았습니다. 기본 명령어와 설정만 조금 익히면 바로 프로젝트 작업에 쓸 수 있습니다.
요즘은 제가 써보기에는 토큰도 넉넉하고, 생각보다 똑똑하고.. 좋습니다.
CLI 환경에서의 AI 사용 장단점 및 팁
CLI 환경에서 AI를 사용할 때 아래와 같은 장점이 있습니다.
- 저장소를 읽고 수정하는 흐름이 자연스러움
- 터미널 중심으로 작업하기 편함
- 비교적 빠르게 결과를 확인할 수 있음
그러나 복잡한 로직에서는 여전히 사람이 방향을 잘 잡아줘야 합니다. 프롬프트를 길게 쓰는 것보다도, 현재 작업 범위와 제약 조건을 명확히 알려주는 것이 더 중요했습니다.
예를 들면 아래 정도만 분명하게 전달해도 결과가 훨씬 안정적이었습니다.
- 어떤 파일을 기준으로 수정할지
- 어디까지 변경해도 되는지
- 테스트가 필요한지
- 기존 스타일을 유지해야 하는지(유지해야 한다면 어떤 코드를 참조해야 하는지 지정)
결국 LLM을 잘 쓰는 방법은 “좋은 질문"보다도 “좋은 작업 맥락"을 주는 것이 현재는 더 좋은 방법이 될 것 같습니다.
커뮤니티를 종종 보면 이제는 코드도 안 보고 배포하는 것도 가능하다고 하는데.. 아직은 전 그 방식까지는 가지 못했네요.
MCP 관련
예전에는 IntelliJ나 VS Code에서 LLM을 쓰려면 IDE 전용 플러그인을 먼저 찾아 설치해야 했습니다.
지금은 MCP를 지원하는 도구가 많아지면서, 예전보다 훨씬 유연하게 연결해서 쓸 수 있게 됐습니다. 같은 모델을 CLI와 IDE 양쪽에서 이어서 활용할 수 있다는 점도 꽤 편합니다.
다만 개인적으로는 MCP를 많이 붙일수록 컨텍스트와 토큰 사용량이 커진다고 느꼈습니다. 그래서 평소에는 CLI 중심으로 작업하고, IDE 연동은 아래처럼 필요한 경우에만 쓰는 편입니다.
- 코드 탐색보다 UI 확인이 중요할 때
- IDE 안에서 바로 수정 흐름을 끝내고 싶을 때
- 특정 도구 연동이 꼭 필요할 때
마치며
LLM 도구는 이제 있으면 좋은 보조 도구를 넘어서, 개발 속도와 작업 방식 자체를 바꾸는 단계로 들어온 것 같아요.
다만 아무 도구나 붙인다고 생산성이 바로 올라가지는 않았습니다. 프로젝트 규칙을 잘 정리하고, 작업 범위를 좁혀서 전달하고, 결과를 검토하는 습관이 같이 있어야 실제로 도움이 됐습니다.
지금도 Codex, Claude Code, Gemini 등 여러 선택지가 계속 바뀌고 있습니다. 그래서 특정 도구 하나를 정답처럼 보기보다는, 현재 작업 방식에 맞는 조합을 찾고 계속 업데이트해나가는 편이 현실적인 것 같습니다.
그런데도 한편으로는 이런 생각이 들 때가 있습니다. LLM이 등장했는데도 회사 업무의 생산성이 왜 기대만큼 크게 늘어나지는 않을까 하는 점입니다. 개인적으로 사용할 때는 확실히 할 수 있는 범위가 넓어졌다고 느끼지만, 조직 단위에서는 그 변화가 그렇게까지 크게 체감되지는 않는 것 같습니다.
아직은 도구보다 일하는 방식이 더 큰 영향을 주는 단계라서 그런 걸까요. 쉽지 않은 것 같네요.