2026년을 향한 나의 LLM 코딩 워크플로우

게시일: 2025년 12월 19일 | 원문 작성일: 2025년 12월 19일 | 저자: Addy Osmani | 원문 보기

AI 코딩 어시스턴트가 올해 판도를 바꿔놓았지만, 효과적으로 활용하려면 기술과 체계가 필요해요. 이 도구들은 LLM이 실제 코딩에서 할 수 있는 일을 극적으로 늘렸고, 저를 포함한 많은 개발자들이 적극 수용했어요.

예를 들어 Anthropic에서는 엔지니어들이 Claude Code를 너무 열심히 사용해서 오늘날 Claude Code 코드의 약 90%가 Claude Code 자체로 작성되고 있어요. 하지만 LLM으로 프로그래밍하는 것은 버튼만 누르면 되는 마법 같은 경험이 아니에요 - “어렵고 직관적이지 않으며” 좋은 결과를 얻으려면 새로운 패턴을 배워야 해요. 비판적 사고가 여전히 핵심이에요. 1년간의 프로젝트를 통해 저는 많은 숙련된 개발자들이 발견하고 있는 것과 비슷한 워크플로우에 수렴하게 되었어요: LLM을 강력한 주니어 페어 프로그래머로 대하는 것 - 가이드, 컨텍스트, 감독이 필요한 존재로요.

이 글에서는 2026년을 향해 제가 어떻게 AI와 함께 계획하고, 코딩하고, 협업하는지 공유할게요. 제 경험과 커뮤니티의 집단 학습에서 추출한 팁과 모범 사례를 정리했어요. 더 체계적인 “AI 지원 엔지니어링” 접근법 - AI를 공격적으로 활용하면서도 생산된 소프트웨어에 대해 당당히 책임지는 방식이에요.

제 워크플로우에 대해 더 궁금하시면 “The AI-Native Software Engineer” 영상을 보세요. 아니면 바로 제가 배운 교훈들로 들어가볼게요.

• • •

명확한 계획으로 시작하기 (코드 전에 스펙)

흔한 실수 중 하나는 애매한 프롬프트로 바로 코드 생성에 뛰어드는 거예요. 제 워크플로우에서, 그리고 다른 많은 사람들의 워크플로우에서도, 첫 단계는 AI와 함께 상세한 스펙을 브레인스토밍한 다음 단계별 계획을 세우는 거예요 - 실제 코드를 작성하기 전에. 새 프로젝트의 경우, 아이디어를 설명하고 LLM에게 요구사항과 엣지 케이스가 명확해질 때까지 반복적으로 질문하게 해요. 결국 이 논의 내용을 요구사항, 아키텍처 결정, 데이터 모델, 심지어 테스트 전략까지 포함하는 포괄적인 spec.md로 정리해요. 이 스펙이 개발의 기반이 돼요.

다음으로, 스펙을 추론 가능한 모델에 넣고 프로젝트 계획을 생성하도록 프롬프트해요: 구현을 논리적인 작은 태스크나 마일스톤으로 쪼개는 거예요. AI가 본질적으로 미니 “디자인 문서”나 프로젝트 계획을 작성하도록 돕는 거죠. 저는 종종 이 계획을 반복하며 - AI에게 편집하거나 비평하거나 다듬도록 요청해요 - 일관성 있고 완전해질 때까지. 그때서야 코딩으로 넘어가요. 이 초기 투자가 느리게 느껴질 수 있지만, 엄청난 보상을 줘요. Les Orchard가 말했듯이, 이건 “15분 안에 하는 워터폴” 같은 거예요 - 후속 코딩을 훨씬 매끄럽게 만드는 빠른 구조화된 계획 단계.

명확한 스펙과 계획이 있으면, 코드 생성을 시작할 때 인간과 LLM 모두 정확히 무엇을 왜 만드는지 알게 돼요. 요약하면, 먼저 계획하기가 여러분과 AI를 같은 페이지에 올려놓고 낭비되는 사이클을 방지해요. 많은 사람이 건너뛰고 싶어하는 단계지만, 숙련된 LLM 개발자들은 이제 견고한 스펙/계획을 워크플로우의 초석으로 여겨요.

원문 보기

작은 반복 단위로 작업 쪼개기

제가 배운 중요한 교훈 중 하나는 AI에게 크고 거대한 결과물을 요청하지 않는 거예요. 대신, 프로젝트를 반복적인 단계나 티켓으로 쪼개고 하나씩 처리해요. 이건 좋은 소프트웨어 엔지니어링 관행을 반영하지만, AI가 관여할 때 더욱 중요해요. LLM은 집중된 프롬프트에서 가장 잘 해요: 한 번에 하나의 함수 구현, 하나의 버그 수정, 하나의 기능 추가. 예를 들어, 계획 후에 코드 생성 모델에게 프롬프트해요: “좋아, 계획의 1단계를 구현하자”. 그걸 코딩하고, 테스트하고, 그 다음 2단계로 가고, 계속 그래요. 각 단위는 AI가 컨텍스트 내에서 처리할 수 있고 여러분이 생성된 코드를 이해할 수 있을 만큼 작아요.

이 접근법은 모델이 탈선하는 것을 방지해요. 한 번에 너무 많이 요청하면, 혼란스러워지거나 풀기 어려운 “뒤죽박죽”을 만들 가능성이 높아요. 개발자들이 보고하기를, LLM이 앱의 거대한 부분을 생성하게 했을 때 일관성 없고 중복된 결과물을 얻었다고 해요 - “10명의 개발자가 서로 얘기 안 하고 작업한 것 같다”고. 저도 그 고통을 겪었어요; 해결책은 멈추고, 물러나서, 문제를 더 작은 조각으로 쪼개는 거예요. 매 반복마다 지금까지 만든 것의 컨텍스트를 가져가며 점진적으로 추가해요. 이건 테스트 주도 개발(TDD) 접근법과도 잘 맞아요 - 진행하면서 각 부분에 대한 테스트를 작성하거나 생성할 수 있어요(테스트에 대해서는 곧 더 얘기할게요).

여러 코딩 에이전트 도구들이 이제 이 작게 나눈 워크플로우를 명시적으로 지원해요. 예를 들어, 저는 종종 각 태스크에 대한 프롬프트 시퀀스를 포함하는 구조화된 “프롬프트 플랜” 파일을 생성해서 Cursor 같은 도구가 하나씩 실행할 수 있게 해요. 핵심은 큰 도약을 피하는 거예요. 작은 루프로 반복함으로써, 치명적인 에러 가능성을 크게 줄이고 빠르게 궤도 수정할 수 있어요. LLM은 빠르고 한정된 태스크에서 뛰어나요 - 그걸 여러분의 이점으로 활용하세요.

광범위한 컨텍스트와 가이드 제공하기

코드베이스에서 작업할 때, 여러분이 AI에게 필요한 모든 정보를 주고 있는지 확인해야 해요. 여기에는 수정하거나 참조해야 할 코드, 프로젝트의 기술적 제약, 알려진 함정이나 선호하는 접근법이 포함돼요. 현대 도구들이 이걸 도와줘요: 예를 들어, Anthropic의 Claude는 “Projects” 모드에서 전체 GitHub 저장소를 컨텍스트에 가져올 수 있고, Cursor나 Copilot 같은 IDE 어시스턴트는 열린 파일을 자동으로 프롬프트에 포함해요. 하지만 저는 종종 더 나아가요 - Context7 같은 MCP를 사용하거나 모델이 없을 것 같은 중요한 코드베이스 조각이나 API 문서를 수동으로 대화에 복사해요.

전문 LLM 사용자들은 이 “컨텍스트 패킹” 단계를 강조해요. 예를 들어, 코딩 전에 모델이 알아야 할 모든 것을 쏟아내는 거예요: 고수준 목표와 불변식, 좋은 솔루션의 예시, 피해야 할 접근법에 대한 경고. AI에게 까다로운 솔루션을 구현하도록 요청할 때, 어떤 순진한 솔루션이 너무 느린지 말해주거나, 다른 곳의 참조 구현을 제공할 수 있어요. 틈새 라이브러리나 새 API를 사용한다면, AI가 눈 가리고 비행하지 않도록 공식 문서나 README를 붙여넣어요. 이 모든 초기 컨텍스트가 결과물의 품질을 극적으로 향상시켜요, 모델이 추측할 필요 없이 눈앞에 사실과 제약이 있으니까요.

원문 보기

컨텍스트 패키징을 자동화하는 유틸리티들도 있어요. gitingest나 repo2txt 같은 도구를 실험해봤는데, 본질적으로 코드베이스의 관련 부분을 LLM이 읽을 수 있는 텍스트 파일로 “덤프”해요. 대규모 프로젝트를 다룰 때 구원자가 될 수 있어요 - 핵심 소스 파일의 output.txt 번들을 생성하고 모델이 그걸 소화하게 해요. 원칙은: AI가 부분 정보로 작동하게 하지 마세요. 버그 수정이 네 개의 다른 모듈을 이해해야 한다면, 그 네 모듈을 보여주세요. 네, 토큰 제한을 봐야 하지만, 현재 최신 모델들은 꽤 큰 컨텍스트 윈도우(수만 토큰)를 가지고 있어요. 현명하게 사용하세요. 저는 종종 현재 태스크와 관련된 코드 부분만 선택적으로 포함하고, 범위 밖인 것은 AI에게 명시적으로 집중하지 말라고 말해요(토큰 절약을 위해).

마지막으로, 프롬프트 안에 코멘트와 규칙으로 AI를 가이드하세요. 코드 스니펫 앞에: “여기 X의 현재 구현이야. Y를 하도록 확장해야 하는데, Z를 깨뜨리지 않도록 조심해”라고 붙일 수 있어요. 이런 작은 힌트가 큰 효과가 있어요. LLM은 지시를 문자 그대로 따르는 존재예요 - 그러니까 상세하고 맥락적인 지시를 주세요. 컨텍스트와 가이드를 선제적으로 제공함으로써, 환각과 엉뚱한 제안을 최소화하고 프로젝트 필요에 맞는 코드를 얻어요.

올바른 모델 선택하기 (필요시 여러 개 사용)

2025년에 우리는 다양한 유능한 코드 중심 LLM을 누리고 있어요. 제 워크플로우의 일부는 각 태스크에 가장 적합한 모델이나 서비스를 선택하는 거예요. 때로는 두 개 이상의 LLM을 병렬로 시도해서 같은 문제에 어떻게 다르게 접근하는지 교차 확인하는 것도 가치 있어요.

각 모델은 고유한 “성격”이 있어요. 핵심은: 한 모델이 막히거나 평범한 결과물을 내면, 다른 걸 시도하세요. 저는 말 그대로 같은 프롬프트를 한 채팅에서 다른 서비스로 복사해서 더 잘 처리하는지 봤어요. 이 “모델 갈아타기”가 모델의 사각지대에 빠졌을 때 구해줄 수 있어요.

또한, 가능한 최고 버전을 사용하세요. 할 수 있다면, 최신 “프로” 티어 모델을 사용하세요 - 품질이 중요하니까요. 네, 접근 비용을 내야 하는 경우가 많지만, 생산성 향상이 그걸 정당화할 수 있어요. 궁극적으로, “느낌”이 맞는 AI 페어 프로그래머를 선택하세요. 어떤 사람들은 단순히 응답 느낌이 좋아서 한 모델을 선호하는 걸 알아요. 그건 유효해요 - AI와 끊임없이 대화할 때, UX와 톤이 차이를 만드니까요.

개인적으로 요즘 코딩 작업에 Gemini를 많이 사용하는데 상호작용이 더 자연스럽게 느껴지고 종종 첫 시도에 제 요청을 이해하거든요. 하지만 필요하면 다른 모델로 바꾸는 걸 주저하지 않아요; 때때로 다른 모델의 의견이 솔루션을 도출하는 데 도움이 돼요. 요약하면: 작업에 가장 좋은 도구를 사용하고, 여러분 손에 AI 무기고가 있다는 걸 기억하세요.

개발 라이프사이클 전반에 AI 코딩 활용하기

커맨드라인에서, 새로운 AI 에이전트들이 등장했어요. Claude Code, OpenAI의 Codex CLI 그리고 Google의 Gemini CLI는 프로젝트 디렉토리에서 직접 채팅할 수 있는 CLI 도구들이에요 - 파일을 읽고, 테스트를 실행하고, 여러 단계의 이슈도 수정할 수 있어요. 저도 Google의 Jules와 GitHub의 Copilot Agent를 사용해봤어요 - 이건 비동기 코딩 에이전트로 실제로 저장소를 클라우드 VM에 클론해서 백그라운드에서 작업해요(테스트 작성, 버그 수정, 그 다음 여러분을 위해 PR 열기). 목격하면 좀 으스스해요: “결제 모듈을 X에 맞게 리팩터링해”라고 명령하면 잠시 후 코드 변경과 통과하는 테스트가 담긴 풀 리퀘스트를 받아요. 미래가 이미 와있는 거예요. 이에 대해 더 읽고 싶으시면 conductors to orchestrators를 보세요.

원문 보기

AI가 개발자 경험을 향상시킬 수 있는 전체 개요. 디자인, 내부, 제출, 외부 루프를 아우르며 - AI가 의미 있게 수고를 줄일 수 있는 모든 지점을 강조해요.

그렇긴 해도, 이 도구들은 완벽하지 않으며, 여러분은 그 한계를 이해해야 해요. 코딩의 기계적인 부분 - 보일러플레이트 생성, 반복적인 변경 적용, 자동 테스트 실행 - 은 가속하지만, 여전히 여러분의 가이드로 크게 이점을 얻어요. 예를 들어, Claude나 Copilot 같은 에이전트로 무언가를 구현할 때, 저는 종종 이전 단계의 계획이나 할 일 목록을 제공해서 정확한 작업 순서를 알게 해요. 에이전트가 파일 로드를 지원한다면, 실행하라고 말하기 전에 spec.md나 plan.md를 컨텍스트에 먼저 넣어줘요. 이렇게 하면 AI가 궤도를 벗어나지 않아요.

AI 에이전트가 전체 기능을 무감독으로 코딩하고 완벽한 결과를 기대하는 단계가 아니에요. 대신, 저는 이 도구들을 감독하며 사용해요: AI가 코드를 생성하고 심지어 실행하게 하지만, 각 단계를 지켜보면서 뭔가 이상해 보이면 개입할 준비를 해요. Conductor 같은 오케스트레이션 도구도 있어서 여러 에이전트를 병렬로 다른 태스크에 실행할 수 있어요(본질적으로 AI 도움을 스케일업하는 방법) - 어떤 엔지니어들은 3-4개의 에이전트를 동시에 별도 기능에 실행하는 것을 실험하고 있어요. 저도 이 “대규모 병렬” 접근법을 시도해봤어요; 놀랍게도 많은 것을 빠르게 완료하는 데 효과적이지만, 여러 AI 스레드를 모니터링하는 것은 정신적으로 힘들어요! 대부분의 경우, 저는 하나의 메인 에이전트와 리뷰용 보조 에이전트 하나를 사용해요(아래에서 논의).

기억하세요 이건 파워 도구예요 - 여러분이 여전히 트리거를 제어하고 결과를 가이드해요.

• • •

루프에 인간 유지하기 - 모든 것을 검증하고 테스트하고 리뷰하기

제 핵심 규칙 중 하나는 LLM의 결과물을 맹목적으로 신뢰하지 않는 거예요. Simon Willison이 적절하게 말했듯이, LLM 페어 프로그래머를 “과신하고 실수하기 쉬운” 존재로 생각하세요. 완벽한 확신을 가지고 코드를 작성해요 - 버그나 헛소리 포함해서 - 여러분이 잡지 않으면 뭔가 잘못됐다고 말하지 않아요. 그래서 저는 모든 AI 생성 스니펫을 주니어 개발자에게서 온 것처럼 취급해요: 코드를 읽고, 실행하고, 필요하면 테스트해요. 작성한 것을 반드시 테스트해야 해요 - 그 유닛 테스트를 실행하거나, 수동으로 기능을 실행해서, 주장하는 대로 동작하는지 확인하세요. vibe coding is not an excuse for low-quality work에서 더 읽어보세요.

원문 보기

사실, 저는 테스트를 워크플로우 자체에 엮어요. 초기 계획 단계에서 종종 각 단계에 대한 테스트 리스트나 테스트 계획을 생성하는 것을 포함해요. Claude Code 같은 도구를 사용할 때, 태스크 구현 후 테스트 스위트를 실행하도록 지시하고, 실패가 있으면 디버그하게 해요. 이런 종류의 타이트한 피드백 루프(코드 작성 → 테스트 실행 → 수정)는 테스트가 존재하는 한 AI가 잘하는 거예요. 코딩 에이전트에서 가장 많이 얻는 사람들이 강한 테스트 프랙티스를 가진 사람들인 것은 놀랍지 않아요. Claude 같은 에이전트는 좋은 테스트 스위트가 안전망이 되면 프로젝트를 척척 진행할 수 있어요. 테스트 없이는, 에이전트가 실제로는 여러 것을 망가뜨렸는데 모든 게 괜찮다고 태평하게 생각할 수 있어요(“네, 다 좋아요!”). 그러니까, 테스트에 투자하세요 - AI의 유용성과 결과에 대한 자신감을 증폭시켜요.

자동화된 테스트를 넘어서, 코드 리뷰를 하세요 - 수동과 AI 지원 모두. 저는 정기적으로 멈춰서 지금까지 생성된 코드를 한 줄씩 리뷰해요. 때때로 두 번째 AI 세션(또는 다른 모델)을 띄워서 첫 번째 AI가 만든 코드를 비평하거나 리뷰하게 해요. 예를 들어, Claude가 코드를 작성하게 하고 Gemini에게 물어요, “이 함수에 에러나 개선점이 있는지 리뷰해줄래?” 이게 미묘한 문제를 잡을 수 있어요. 핵심은 AI가 코드를 작성했다고 리뷰를 건너뛰지 않는 거예요. 어쨌든, AI 작성 코드는 추가 검토가 필요해요, 왜냐하면 때때로 인간이 즉시 알아차리지 못할 결함을 숨기면서 표면적으로 설득력 있을 수 있거든요.

인간 감독을 건너뛰는 심각한 결과가 문서화되어 있어요. 급한 프로젝트에서 AI 생성에 크게 의존한 한 개발자가 결과물이 어땠는지 공유했어요 - 일관성 없는 엉망진창이었대요. 중복 로직, 불일치하는 메서드 이름, 일관된 아키텍처 없음. AI가 어떤 코드를 만들어놨는지 제대로 보지 않고 “짓고, 짓고, 짓고”만 하고 있었다는 걸 깨달았다고 해요. 해결책은 고통스러운 리팩터링과 다시는 그렇게까지 손 놓지 않겠다는 다짐이었어요. 저는 그걸 마음에 새겼어요. 아무리 많이 AI를 사용해도, 저는 책임지는 엔지니어로 남아요.

실용적으로 그건 이해하지 못한 코드는 머지하거나 배포하지 않는다는 의미예요. AI가 복잡한 것을 생성하면, 설명하는 코멘트를 추가하라고 요청하거나, 더 간단한 용어로 다시 작성해요. 뭔가 맞지 않으면 파고들어요 - 인간 동료가 의심스러운 코드를 기여했을 때 그러듯이.

마인드셋의 문제예요: LLM은 어시스턴트지, 자율적으로 신뢰할 수 있는 코더가 아니에요. 저는 시니어 개발자예요. LLM은 저를 가속하기 위해 있지, 제 판단을 대체하기 위해 있지 않아요. 이 태도를 유지하면 더 나은 코드가 나올 뿐 아니라 개발자로서의 성장도 보호해요. (AI에 너무 의존하면 실력이 무뎌질까 걱정하는 사람들이 있다고 들었어요 - 저는 루프에 머물면서 모든 것을 적극적으로 리뷰하고 이해한다면, 더 높은 속도로 본능을 연마하고 있는 거라고 생각해요.) 요약: 경계를 늦추지 말고, 자주 테스트하고, 항상 리뷰하세요. 결국 여러분의 코드베이스니까요.

자주 커밋하고 버전 관리를 안전망으로 사용하기. 설명할 수 없는 코드는 커밋하지 않기.

많은 코드를 빠르게 생성할 수 있는 AI와 작업할 때, 방향이 틀어지기 쉬워요. 저는 아주 세밀한 버전 관리 습관을 채택해서 이걸 완화해요. 일반 수작업 코딩보다 더 일찍, 더 자주 커밋해요. 각 작은 태스크나 성공적인 자동 편집 후에, 명확한 메시지로 git 커밋을 해요. 이렇게 하면, AI의 다음 제안이 버그나 지저분한 변경을 도입해도, 작업 시간을 잃지 않고 되돌리거나 체리픽할 수 있는 최근 체크포인트가 있어요. 한 실무자가 커밋을 “게임의 세이브 포인트”처럼 취급하라고 비유했어요 - LLM 세션이 잘못되면, 언제든 마지막 안정된 커밋으로 롤백할 수 있어요. 그 조언이 정말 유용하다는 걸 알았어요. 필요하면 git reset으로 취소할 수 있다는 걸 알면 과감한 AI 리팩터링 실험이 훨씬 덜 스트레스받아요.

원문 보기

적절한 버전 관리는 AI와 협업할 때도 도움이 돼요. AI가 한 모든 것을 기억하리라 기대할 수 없으니(컨텍스트 윈도우 제한 등), git 히스토리가 귀중한 로그가 돼요. 저는 종종 최근 커밋을 스캔해서 AI(나 저 자신)에게 뭐가 바뀌었는지 브리핑해요. 사실, 여러분이 제공하면 LLM 자체가 커밋 히스토리를 활용할 수 있어요 - git diff나 커밋 로그를 프롬프트에 붙여넣어서 AI가 어떤 코드가 새 것인지, 이전 상태가 뭐였는지 알게 해요. 재미있게도, LLM은 diff 파싱과 git bisect 같은 도구로 버그가 어디서 도입됐는지 찾는 데 정말 잘해요. 커밋 히스토리를 횡단하는 무한한 인내심이 있어서 디버깅을 보강할 수 있어요. 하지만 이건 애초에 깔끔한 커밋 히스토리가 있어야만 해요.

또 다른 이점: 좋은 메시지가 있는 작은 커밋이 본질적으로 개발 프로세스를 문서화해서, 코드 리뷰(AI나 인간)를 할 때 도움이 돼요. AI 에이전트가 한 번에 다섯 개 변경을 하고 뭔가 망가졌을 때, 그 변경들이 별도 커밋에 있으면 어떤 커밋이 문제를 일으켰는지 파악하기 쉬워요. 모든 게 “AI changes”라는 제목의 거대한 커밋 하나에 있으면, 행운을 빌어요! 그래서 저는 규율을 갖춰요: 태스크 완료, 테스트 실행, 커밋. 이건 작업을 작은 청크로 나누라는 앞의 팁과도 잘 어울려요 - 각 청크가 자체 커밋이나 PR이 되니까요.

마지막으로, AI 실험을 격리하기 위해 브랜치나 워크트리 사용을 두려워하지 마세요. 제가 채택한 고급 워크플로우(Jesse Vincent 같은 분들에게서 영감받은) 중 하나는 새 기능이나 서브 프로젝트를 위해 새로운 git 워크트리를 만드는 거예요. 이렇게 하면 같은 저장소에서 여러 AI 코딩 세션을 서로 간섭 없이 병렬로 실행할 수 있고, 나중에 변경을 머지할 수 있어요. 각 AI 태스크가 자체 샌드박스 브랜치에 있는 것과 비슷해요. 한 실험이 실패하면, 그 워크트리를 버리고 메인에서 아무것도 잃지 않아요. 성공하면, 머지해요. 이 접근법은 예를 들어 AI가 기능 A를 구현하게 하면서 저(또는 다른 AI)가 동시에 기능 B를 작업할 때 중요했어요. 버전 관리가 이 조정을 가능하게 해요. 요약: 자주 커밋하고, 브랜치로 작업을 정리하고, git을 받아들이세요 - AI 생성 변경을 관리 가능하고 되돌릴 수 있게 유지하는 제어 메커니즘으로.

규칙과 예시로 AI 행동 커스터마이즈하기

제가 배운 한 가지는 AI의 기본 스타일이나 접근법을 그대로 받아들일 필요 없다는 거예요 - 가이드라인을 줌으로써 크게 영향을 미칠 수 있어요. 예를 들어, 저는 주기적으로 업데이트하는 CLAUDE.md 파일이 있어요. Claude(Anthropic의 모델)가 따라야 할 프로세스 규칙과 선호도가 담겨 있어요(마찬가지로 Gemini CLI를 사용할 때 GEMINI.md). 여기에는 “프로젝트 스타일로 코드 작성, 린트 규칙 준수, 특정 함수 사용 금지, OOP보다 함수형 스타일 선호” 같은 것들이 포함돼요. 세션을 시작할 때, 이 파일을 Claude에게 주입해서 우리 관례에 맞추게 해요. Jesse Vincent가 언급했듯이 이런 규칙 파일이 모델을 “궤도에” 유지하는 데 놀랍게 잘 작동해요 - AI가 탈선하거나 우리가 원치 않는 패턴을 도입하는 경향을 줄여줘요.

멋진 규칙 파일 없이도, 커스텀 지침이나 시스템 프롬프트로 톤을 설정할 수 있어요. GitHub Copilot과 Cursor 둘 다 프로젝트에 대해 AI 행동을 전역적으로 구성할 수 있는 기능을 도입했어요. 저는 그걸 활용해서 코딩 스타일에 대한 짧은 문단을 작성해요, 예를 들어 “4칸 들여쓰기 사용, React에서 화살표 함수 피하기, 설명적 변수명 선호, 코드가 ESLint 통과해야 함”. 그런 지침이 자리잡으면, AI의 제안이 인간 동료가 작성할 것에 훨씬 가깝게 맞아요. Ben Congdon이 언급했듯이, Copilot의 커스텀 지침을 사용하는 사람이 적어서 놀랐다고 해요 - 예시와 선호도를 미리 제공해서 팀의 관용구에 맞는 코드를 출력하도록 AI를 유도할 수 있는데요. 저도 공감해요: 시간을 들여 AI에게 기대를 가르치세요.

또 다른 강력한 기법은 원하는 출력 형식이나 접근법의 인라인 예시를 제공하는 거예요. AI가 아주 특정한 방식으로 함수를 작성하게 하고 싶다면, 먼저 코드베이스에 있는 비슷한 함수를 보여줄 수 있어요: “우리가 X를 이렇게 구현했어, Y에도 비슷한 접근법 사용해.” 특정 코멘트 스타일을 원한다면, 직접 코멘트를 작성하고 AI에게 그 스타일로 계속하라고 요청할 수 있어요. 본질적으로, 따라야 할 패턴으로 모델을 프라이밍하는 거예요. LLM은 모방을 잘해요 - 한두 개 예시를 보여주면 그 방향으로 계속할 거예요.

커뮤니티에서도 LLM 행동을 길들이는 창의적인 규칙 모음을 만들어왔어요. “Big Daddy” 규칙이나 프롬프트에 “환각/기만 금지” 조항을 추가하는 것을 들어봤을 수 있어요. 이건 기본적으로 AI가 진실하고 존재하지 않는 코드를 과도하게 만들어내지 않도록 상기시키는 트릭이에요. 예를 들어, 저는 때때로 프롬프트 앞에 붙여요: “뭔가 확신이 없거나 코드베이스 컨텍스트가 없으면, 답을 지어내지 말고 명확히 해달라고 요청해.” 이게 환각을 줄여요. 제가 사용하는 또 다른 규칙은: “버그를 수정할 때 항상 코멘트로 이유를 간단히 설명해.” 이렇게 하면, AI가 수정을 생성할 때 ”// Fixed: X를 Y로 변경해서 Z 방지 (스펙에 따라)” 같은 코멘트도 남겨요. 나중에 리뷰할 때 정말 유용해요.

요약하면, AI를 블랙박스로 취급하지 마세요 - 튜닝하세요. 시스템 지침을 구성하고, 프로젝트 문서를 공유하고, 명시적 규칙을 작성함으로써, AI를 팀의 더 전문화된 개발자로 변신시켜요. 신입 사원을 온보딩하는 것과 비슷해요: 스타일 가이드와 시작 팁을 주잖아요? AI 페어 프로그래머에게도 똑같이 해요. 투자 대비 수익이 거대해요: 덜 다듬어야 하고 코드베이스에 더 매끄럽게 통합되는 결과물을 얻어요.

테스트와 자동화를 역량 증폭기로 활용하기

이건 루프에 머물고 컨텍스트를 제공하는 것의 따름정리예요: 잘 정비된 개발 파이프라인이 AI 생산성을 향상시켜요. 무거운 AI 코딩을 사용하는 모든 저장소에 견고한 지속적 통합 설정이 있는지 확인해요. 그건 자동화된 테스트가 모든 커밋이나 PR에서 실행되고, 코드 스타일 체크(ESLint, Prettier 등)가 적용되고, 이상적으로는 모든 새 브랜치에 스테이징 배포가 가능하다는 의미예요. 왜냐고요? AI가 이것들을 트리거하고 결과를 평가할 수 있기 때문이에요. 예를 들어, AI가 Jules나 GitHub Copilot Agent 같은 도구로 풀 리퀘스트를 열면, 우리 CI가 테스트를 실행하고 실패를 보고해요. 그 실패 로그를 AI에게 돌려줄 수 있어요: “통합 테스트가 XYZ로 실패했어, 이것 좀 디버그하자.” 버그 수정이 빠른 피드백을 가진 협업 루프가 되는데, AI가 꽤 잘 처리해요(수정을 제안하고, CI를 다시 실행하고, 반복).

원문 보기

자동화된 코드 품질 체크(린터, 타입 체커)도 AI를 가이드해요. 저는 때때로 린터 출력을 프롬프트에 포함해요. AI가 작성한 코드가 린터를 통과하지 못하면, 린터 에러를 채팅에 복사하고 “이 문제들을 해결해줘”라고 말해요. 그러면 모델이 정확히 뭘 해야 하는지 알아요. 엄격한 선생님이 AI 어깨 너머로 보고 있는 것 같아요. 제 경험상, AI가 도구의 출력(실패하는 테스트나 린트 경고 같은)을 인식하면, 그걸 수정하려고 아주 열심히 해요 - 결국 올바른 답을 내고 “싶어”하니까요. 이건 컨텍스트 제공과 연결돼요: AI에게 환경에서의 행동 결과(테스트 실패 등)를 주면 그것들에서 배울 거예요.

AI 코딩 에이전트 자체도 점점 더 자동화 훅을 통합하고 있어요. 어떤 에이전트는 모든 테스트가 통과할 때까지 코드 태스크가 “완료됐다”고 말하기를 거부해요 - 바로 그 성실함이 여러분이 원하는 거예요. 코드 리뷰 봇(AI든 아니든)이 또 다른 필터 역할을 해요 - 저는 그들의 피드백을 개선을 위한 추가 프롬프트로 취급해요. 예를 들어, CodeRabbit이나 다른 리뷰어가 “이 함수가 X를 하는데 이상적이지 않아”라고 코멘트하면 AI에게 물어봐요, “이 피드백을 기반으로 리팩터링할 수 있어?”

AI와 자동화를 결합하면, 선순환이 시작돼요. AI가 코드를 작성하고, 자동화 도구가 문제를 잡고, AI가 수정하고, 계속 그래요 - 여러분은 고수준 방향을 감독하면서. 아주 빠른 주니어 개발자의 작업이 지치지 않는 QA 엔지니어에 의해 즉시 체크되는 것 같은 느낌이에요. 하지만 기억하세요, 여러분이 그 환경을 구축한 거예요. 프로젝트에 테스트나 자동화 체크가 없으면, AI의 작업이 미묘한 버그나 낮은 품질로 훨씬 나중까지 그냥 통과될 수 있어요.

그래서 2026년을 향해, 제 목표 중 하나는 AI 코드 기여 주변의 품질 게이트를 강화하는 거예요: 더 많은 테스트, 더 많은 모니터링, 아마도 AI가 AI를 코드 리뷰하는 것까지. 역설적으로 들릴 수 있지만(AI가 AI를 리뷰), 한 모델이 놓친 것을 잡는 걸 봤어요. 결론: AI 친화적인 워크플로우는 강한 자동화가 있는 것이에요 - 그 도구들로 AI를 정직하게 유지하세요.

지속적으로 배우고 적응하기 (AI가 여러분의 스킬을 증폭)

원문 보기

개발에 LLM을 사용하면서 가장 흥미로운 점 중 하나는 그 과정에서 제가 얼마나 많이 배웠는지예요. AI가 제 지식을 대체한 게 아니라, 오히려 혼자서는 시도하지 않았을 새로운 언어, 프레임워크, 기법을 배우게 해줬어요.

이 패턴은 일반적으로 적용돼요: 탄탄한 소프트웨어 엔지니어링 기초를 가지고 오면, AI가 여러분의 생산성을 몇 배로 증폭해요. 그 기반이 없으면, AI가 혼란만 증폭할 수 있어요. 시니어 개발자들이 발견한 건 LLM이 “기존의 좋은 관행에 보상을 준다”는 거예요 - 명확한 스펙 작성, 좋은 테스트 보유, 코드 리뷰 하기 같은 것들은 AI가 관여할 때 더욱 강력해져요. 제 경험상, AI가 저를 더 높은 수준의 추상화(디자인, 인터페이스, 아키텍처에 집중)에서 운영하게 해주고 보일러플레이트는 대신 쳐내지만, 저는 먼저 그 고수준 스킬을 가지고 있어야 해요. Simon Willison이 말했듯이, 시니어 엔지니어를 만드는 거의 모든 것(시스템 설계, 복잡성 관리, 무엇을 자동화하고 무엇을 직접 코딩할지 아는 것)이 이제 AI와 함께 가장 좋은 결과를 낳아요. 그래서 AI를 사용하는 것이 실제로 제 엔지니어링 역량을 높이도록 밀어붙였어요 - 계획에 더 엄격하고 아키텍처에 더 의식적이에요, 왜냐하면 사실상 아주 빠르지만 다소 순진한 코더(AI)를 “관리”하고 있으니까요.

AI를 사용하면 능력이 저하될까 걱정하는 분들께: 저는 제대로 하면 오히려 반대라고 주장할게요. AI 코드를 리뷰하면서 새로운 관용구와 솔루션에 노출됐어요. AI 실수를 디버깅하면서 언어와 문제 도메인에 대한 이해가 깊어졌어요. 저는 종종 AI에게 코드나 수정의 이유를 설명해달라고 해요 - 후보자에게 코드에 대해 끊임없이 인터뷰하는 것처럼 - 답변에서 통찰을 얻어요. AI를 연구 어시스턴트로도 사용해요: 라이브러리나 접근법에 대해 확신이 없으면, 옵션을 나열하거나 트레이드오프를 비교해달라고 해요. 백과사전적 멘토가 대기 중인 것 같아요. 이 모든 게 저를 더 지식 있는 프로그래머로 만들었어요.

큰 그림은 AI 도구가 여러분의 전문성을 증폭한다는 거예요. 2026년을 향해, “일자리를 빼앗길까” 두렵지 않아요 - 잡무에서 해방되어 소프트웨어 엔지니어링의 창의적이고 복잡한 측면에 더 많은 시간을 쓸 수 있게 해줘서 신나요. 하지만 탄탄한 기반 없이는 AI가 더닝-크루거 효과를 극대화할 수 있다는 것도 알아요(무너질 때까지 뭔가 대단한 걸 만든 것처럼 보일 수 있어요). 그래서 제 조언: 기술 연마를 계속하고, AI로 그 과정을 가속하세요. 의도적으로 가끔 AI 없이 코딩해서 원시 스킬을 날카롭게 유지하세요. 결국, 개발자 + AI 듀오가 둘 중 하나만보다 훨씬 강력하고, 개발자 쪽이 자기 몫을 해내야 해요.

• • •

결론

2026년을 맞아, 저는 개발 워크플로우에 AI를 완전히 받아들였어요 - 하지만 신중하고 전문성이 주도하는 방식으로. 제 접근법은 본질적으로 AI-자동화 소프트웨어 엔지니어링이 아닌 “AI-증강 소프트웨어 엔지니어링”이에요.

배운 것: 최고의 결과는 AI 협업에 고전적인 소프트웨어 엔지니어링 규율을 적용할 때 나와요. 우리의 힘들게 얻은 관행들 - 코딩 전 설계, 테스트 작성, 버전 관리 사용, 표준 유지 - 은 여전히 적용될 뿐 아니라, AI가 코드 절반을 작성할 때 더욱 중요해져요.

앞으로가 기대돼요. 도구들은 계속 발전하고 제 워크플로우도 함께 진화할 거예요. 아마도 완전 자율적인 “AI 개발 인턴”이 우리가 고수준 태스크에 집중하는 동안 더 많은 잡무를 처리할 거예요. 아마도 디버깅과 코드 탐색의 새로운 패러다임이 등장할 거예요. 무엇이든, 저는 루프에 머물 계획이에요 - AI를 가이드하고, 그들에게서 배우고, 책임감 있게 생산성을 증폭하면서.

저에게 결론: AI 코딩 어시스턴트는 놀라운 역량 증폭기지만, 인간 엔지니어가 여전히 주인공이에요.

그럼…2026년 빌딩 즐겁게 하세요! 🚀

O’Reilly와 함께 새로운 AI 지원 엔지니어링 책을 출간했어요. 관심 있으시면 책 사이트에 무료 팁들이 있어요.