LLM 보조 소프트웨어 개발 도구 사용기

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

필자는 LLM이 저품질 콘텐츠와 불필요한 AI 기능을 늘린다는 이유로 회의적이었지만, Claude Code와 Cursor를 실제 소프트웨어 개발에 적용하면서 판단을 바꿨습니다. 프로젝트 파일과 업무 기록을 직접 읽고 도구를 호출하는 coding agent는 테스트 작성, 보안 점검, 장시간 조사, 반복적인 rebase와 마이그레이션을 빠르게 처리해 숙련자의 경험을 더 넓게 적용하게 했습니다. 반면 5000줄 pull request, 미묘한 버그, 환각, 서비스 장애, 권한 오남용, 토큰 비용과 모델 변경은 인간 검토와 여러 검증 계층을 필수로 만듭니다. 저자는 완전 자동화보다 LLM을 사용해 품질과 보안, 성능을 높이는 신중한 LLM-first 접근을 계속하되, 로컬 실행 가능한 오픈 웨이트 모델과 오픈소스 도구의 필요성을 강조합니다.

섹션별 상세

필자는 초기에는 LLM이 그럴듯하지만 저품질인 텍스트와 이미지 생산을 늘리고, 소프트웨어 서비스에 불필요한 AI 기능을 덧붙인다고 보아 회의적이었습니다. 그러나 Java, Spring Boot, Svelte, Docker, Linux VM으로 구성된 비교적 예측 가능한 제품과 실험을 허용하는 소규모 팀에서 직접 사용하면서 판단이 바뀌었습니다. 전문 경험과 사고 대응 경험을 가진 개발자가 도구를 통제하면 새로운 코드를 무작정 양산하기보다 어려운 작업을 더 빠르게 처리할 수 있다는 점이 전환의 배경이었습니다.

처음 사용한 ChatGPT와 Copilot에서는 검색어를 프롬프트로 재사용해 빠르게 설명과 예시를 얻는 방식이 유용했지만, IDE 자동완성은 느리고 결과도 실망스러웠습니다. Copilot의 agent 기능은 필요한 맥락을 직접 제공해야 했고 기존 테스트를 참고한 테스트 작성에는 어느 정도 쓸모가 있었지만, 작업 흐름이 매끄럽지는 않았습니다. 이후 동료가 Cursor로 긴급 문제를 약 두 시간 만에 테스트와 검증까지 마친 해결책으로 완성한 사건이 LLM 보조 개발 도구의 실질적 가능성을 확인한 계기가 되었습니다.

Claude Code는 터미널에서 실행되며 디스크의 관련 파일을 스스로 읽고 도구와 스크립트를 호출해 변경을 수행하므로 IntelliJ IDEA를 계속 사용하면서도 프로젝트 맥락을 확보했습니다. 사용자는 이름 변경 같은 작은 작업부터 파일 탐색, diff 확인, 단계별 진행 관찰까지 한 흐름으로 처리했고, Codex보다 빠른 피드백과 반복 개선을 선호하게 되었습니다. 제품과 도메인 지식을 prompt에 담아야 했던 기존 온보딩 과정도 관련 파일과 기록을 찾아 묻는 방식으로 짧아졌으며, 숙련자는 잘못된 답을 빠르게 식별할 수 있었습니다.

마감이 임박한 시기에는 Claude Code와 Cursor가 실험용 장난감에서 핵심 업무 도구로 바뀌었고, 팀은 프로젝트별 지침을 Claude skills에 모았습니다. 파일 시스템 격리를 위한 sandbox container를 직접 만들면서 우회 권한 모드와 여러 병렬 세션을 안전하게 운용했고, 통합 테스트 최적화나 권한 누락 점검처럼 조사와 구현을 연결하는 작업에도 활용했습니다. 대부분의 최적화 제안은 효과가 작았지만 일부 변경으로 통합 테스트가 10% 빨라졌고, 보호되지 않은 endpoint를 테스트로 재현한 뒤 수정하는 작업은 수주에서 수시간으로 단축되었습니다.

생산성이 높아지는 과정에서 검토 부담과 결함 위험도 함께 커졌습니다. 시간 압박 속에서 5000줄 규모의 pull request가 생겼고, vibe-coding으로 만든 흔적과 미묘한 버그, 특히 transactional boundary 관련 문제가 검토를 어렵게 했으며, 도구는 지시의 일정 비율을 계속 무시했습니다. 새 모델 출시 뒤 성능 저하가 체감되거나 메모리 누수와 서비스 장애가 발생하는 등 제품과 모델의 잦은 변경, 비결정성, 확장성 문제가 일상 업무의 불확실성과 피로를 키웠습니다.

LLM만 제공하는 모델보다 채팅 인터페이스와 도구 호출, 외부 업무 시스템 접근을 결합한 구성이 실제 생산성의 중심에 놓였습니다. Claude Code에 Slack, Notion, Jira, Linear, Google Drive, GitHub 등의 권한을 주면 필요한 맥락을 모으고 티켓을 대량 생성하거나 의존성을 연결하는 반복 작업을 수행할 수 있지만, 악성 지시나 오작동으로 회사 자료가 삭제될 위험도 커집니다. 저자는 데이터 보호, 위협 모델링, GDPR, 권한 관리 없이 이런 접근을 확대하는 상황을 통제되지 않은 위험으로 보고, 생산성보다 안전을 우선하는 운영 장치가 필요하다고 봅니다.

코드를 만드는 비용이 낮아져도 사람이 요구사항을 이해하고 변경을 검토하며 실제 고객 환경에서 테스트하는 과정은 사라지지 않아 인간이 병목으로 남습니다. 팀은 구현 전에 높은 수준의 계획을 검토하고 구현자가 최종 결과를 직접 검토하게 하는 방식을 시도했으며, AI가 AI 코드를 다시 검토하는 skill도 보조 수단으로 사용했습니다. 다만 LLM은 함수의 성능 문제를 찾더라도 제품 결정으로 해당 기능 자체를 생략할 수 있다는 판단까지 내리기 어렵기 때문에, linter와 formatter, static analysis, LLM 검토, 인간 판단을 여러 층으로 결합해야 합니다.

LLM 보조 도구를 엄격하게 사용하면 테스트, 보안, 문서화, 성능 개선과 기술 부채 정리가 오히려 일상 업무에 들어옵니다. 실제로 코드 테스트가 개선되고 TODO가 줄었으며, 고객 문의 조사와 일회성 문제 해결이 빨라지고, 보안 개선과 성능 최적화를 미루지 않게 되었으며, 프로젝트 규칙과 인프라 구성이 문서화되었습니다. 이런 효과는 새 코드를 빠르게 생산하는 데서만 나오지 않고, 숙련자가 과거 장애 경험을 prompt와 검증 절차에 반영해 설계, 보안, 성능, 규정 준수에 더 많은 집중력을 쓰는 데서 나옵니다.

항상 켜진 홈 서버의 별도 VM에서 Claude Code를 실행하면 장시간 조사, 테스트, 마이그레이션을 비동기 작업으로 넘길 수 있습니다. 간단한 자동화 loop는 여러 pull request의 rebase와 충돌 해결, CI 대기를 반복하고, 예약된 시간에 Spring Boot 4 업그레이드를 시작하며, SSH 터미널을 통해 저사양 노트북에서도 원격 서버의 작업을 텍스트만으로 조작합니다. 다만 프런트엔드나 디자인 중심 작업에는 적합성이 낮고, 결과는 다음 날 사람이 검토해야 하므로 완전 자동화보다 집중 시간을 절약하는 보조 흐름에 가깝습니다.

저자는 현재 기술 수준에서 coding agent가 인간의 입력만으로 안정적이고 테스트된 아키텍처를 만들며 인간 검토를 완전히 없애는 방식은 신뢰하기 어렵다고 판단합니다. 여러 검증 계층을 갖춘 custom harness를 만들면 결과를 개선할 수 있지만, 제품 개발보다 harness 유지보수에 집중하게 되고 토큰 비용도 커지며 모델 변경 뒤에도 같은 방식이 유지된다는 보장이 없습니다. 따라서 LLM을 활용해 더 많은 코드를 무조건 만드는 대신, 계획과 아키텍처를 유지하면서 반복적으로 개선하고 품질, 보안, 성능을 높이는 방식이 지속 가능한 선택이라는 결론입니다.

용어 해설

에이전트 기반 코딩(Agentic Coding): — LLM이 코드 편집기나 터미널에서 파일을 읽고, 명령어와 도구를 호출하며, 여러 단계의 개발 작업을 수행하는 방식입니다. 단순 자동완성보다 넓은 프로젝트 맥락을 활용하지만, 결과 검증과 권한 통제가 필요합니다.
샌드박스 컨테이너(Sandbox Container): — 프로그램이 호스트 파일 시스템이나 다른 실행 환경에 직접 영향을 주지 못하도록 격리된 컨테이너입니다. 글에서는 Claude Code를 우회 권한 모드로 실행하면서 실수로 홈 디렉터리를 삭제하는 사고를 막고, 여러 세션의 충돌도 줄이는 용도로 활용했습니다.
정적 분석(Static Analysis): — 프로그램을 실행하지 않고 소스 코드의 오류 가능성, 규칙 위반, 보안 문제를 검사하는 기법입니다. LLM의 맥락 기반 검토와 결합하면 코드 품질을 보완할 수 있지만, 제품 요구사항이나 더 나은 설계 선택까지 대신 판단하지는 못합니다.
코드형 인프라(Infrastructure as Code): — 서버와 네트워크 같은 인프라 구성을 사람이 직접 조작하는 대신 코드와 설정 파일로 정의하고 재현하는 방식입니다. 글에서는 LLM 보조 도구가 팀의 인프라 지식을 문서화하고, Ansible 설정과 새로운 역할을 작성하는 진입 장벽을 낮췄다고 설명합니다.
오픈 웨이트 모델(Open Weights Model): — 모델 가중치를 공개해 사용자가 자신의 하드웨어나 통제 가능한 환경에서 실행할 수 있는 모델입니다. 글에서는 중앙 서비스의 가격, 장애, 데이터 보호 문제에 대응할 대안으로 로컬 실행 가능한 오픈 웨이트 모델과 오픈소스 harness를 주목합니다.

기술

LLM
ChatGPT
Copilot
IntelliJ IDEA
Java
Spring Boot
Svelte
Docker
Linux VM
Cursor
Claude Code
Claude skills
Codex
Junie
sandbox container
Linear
Slack
Notion
Jira
Google Drive
GitHub
GitHub CLI
linter
formatter
static analysis
CI/CD
Ansible
infrastructure-as-code
SSH
Spring Boot 4
Fedora
GIMP

활용 사례

기존 코드와 프로젝트 기록을 읽은 뒤 기능 변경안 작성
기존 예시를 바탕으로 테스트 생성
권한 누락을 찾고 재현 테스트와 수정 코드 작성
통합 테스트 최적화 아이디어 도출과 benchmark 계획 수립
Linear 티켓 대량 생성과 의존성 연결
여러 pull request의 rebase와 충돌 해결 자동화
장시간 기술 조사와 Spring Boot 4 마이그레이션 실행
Ansible playbook 검증과 새로운 역할 작성
보안, 성능, 문서화, 기술 부채 개선