모든 글

실제로 검증한 AI 작업 흐름으로 개발 템플릿 바꾸기

반복해서 검증한 AI 작업 흐름에 맞춰 개발 템플릿을 바꾸되, 검증은 명시적으로 남기고 프로젝트별 지침은 공통 기본값과 분리합니다.

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

재사용할 개발 템플릿은 실험보다 앞서가면 안 된다. AI와 몇 달 동안 반복해서 작업한 뒤에야 기존 기본값 중 실제 흐름과 맞지 않는 부분을 내 템플릿에서 바꿨다.

여기서 다루는 것은 개인적인 구성의 기록이다. 모든 기업에 적용할 기본값이 아니며, 현재 사용하는 운영체제와 기술 스택, 작업 방식에 기대는 선택도 들어 있다.

검증을 없애지 말고 위치를 옮긴다

기존 템플릿은 커밋할 때 린트를 실행하고 실패하면 커밋을 막았다. 직접 커밋하던 흐름에는 잘 맞았다. 지금은 에이전트가 커밋을 준비하고 검증까지 실행하도록 지시하는 경우가 많아져, 로컬 커밋 훅이 검사를 책임지는 지점이 아니게 됐다.

훅을 지웠다는 말은 린트를 없애거나 검증하지 않은 결과를 받겠다는 뜻이 아니다. 책임이 실행 지침과 리뷰 흐름으로 이동했다. 팀에서 검증이 어디서 실행되는지 볼 수 없다면 훅 삭제는 안전망 하나를 없애는 일에 불과하다.

이 변경은 2026년에 커밋 훅이 쓸모없어져서가 아니라 개인 템플릿에서 반복 사용한 결과다. 팀원이 직접 커밋하는 조직이라면 반대 결론이 더 잘 맞을 수 있다.

공통 템플릿은 개별 프로젝트보다 작게 둔다

여러 에이전트의 병렬 작업 때문에 예전에는 쓰지 않던 워크트리 지원이 필요해졌다. 로컬 실험 파일이 커밋에 들어가지 않도록 무시 규칙도 추가했다. 이런 작업 공간의 공통 장치는 여러 번 반복됐기 때문에 기본 템플릿에 들어갈 수 있었다.

재사용 가능한 에이전트 스킬은 달랐다. 큰 범용 스킬 묶음이 특정 프로젝트와 팀, 새 동료에게 항상 맞는 것은 아니다. 유행하는 흐름을 전부 기본값에 넣기보다 현재 맥락에 필요한 지침을 고르거나 직접 만드는 편을 선호한다.

두 종류의 지침 파일이 한 원본을 보도록 연결한 것도 개인 환경에서는 편리했다. 그러나 자신의 운영체제 가정에 따른 선택이므로 이식 가능한 기본값으로 볼 수 없다. 공유 템플릿은 실제 사용할 사람들의 환경을 고려해야 한다.

아키텍처 실험도 검증된 뒤 템플릿에 넣는다

AI를 활용한 개발은 모듈 구조도 다시 보게 했다. 싱글 모듈과 더 작은 두 부분 구조를 시험했지만, 현재 생산성과 이후 확장 가능성의 균형을 보고 익숙한 기본 구조로 돌아왔다. 특정 모듈 구성이 어디서나 이긴다는 증명이 아니라 개인 실험의 결과다.

작업 흐름이 바뀌면 기본값도 다시 시험한다

모델이 바뀌면 필요한 보조 지침의 양도 달라질 수 있다. 이전 지침이 계속 필요한지 단정하지 않고 작업 맥락을 초기화한 상태에서 같은 구조를 다시 시험하기도 한다. 일부 보조 장치가 가벼워져도 내가 만들고 싶은 방향은 계속 남는다.

템플릿에는 반복 작업으로 자격을 얻은 것만 담는다. 검증 위치를 보이게 하고, 실제로 쓰는 작업 공간 지원을 넣으며, 새 동료가 이해할 만큼 공통 지침을 작게 유지한다. 프로젝트별 전술은 더 넓은 효용이 확인될 때까지 각 프로젝트에 둘 수 있다.