개인 개발에서 코딩 AI에 휘둘리지 않기 위해, 나만의 템플릿을 만든 이야기

2026년 상반기, 저의 개인 개발 방식은 크게 바뀌었습니다.

계기는 나만의 개발 템플릿(Amplify Gen 2 x Kiro)을 만든 것입니다.

다만, 이 기사에서 전하고 싶은 것은 "Amplify x Kiro가 최고였다"라는 이야기뿐만이 아니라,

코딩 AI에 의존할수록, 이쪽에 의지할 수 있는 "형식 (Template)"이 필요해진다

는 점입니다.

저는 본업 프로그래머가 아닙니다.

간단한 업무 효율화를 위해 약간의 코딩을 하는 일은 있지만, 일상적으로 코드를 작성하며 프로덕트 개발을 하는 것은 아닙니다. 그렇기 때문에 개인 개발에서는 이전부터 코딩 AI에 상당히 의존해 왔습니다.

이 기사에서는 2026년 상반기의 AI 활용을 되돌아보며, 나만의 템플릿을 만들어 좋았던 점들을 정리해 보겠습니다.

도구로는 Cursor를 사용하거나, VSCode의 확장 기능으로 Claude Code를 사용하곤 했습니다. MCP 서버 설정만 해두고, 나머지는 대화 내용만으로 버티는 스타일입니다.

AGENTS.md나 CLAUDE.md와 같은 규칙 파일이 존재한다는 것은 알고 있었지만, 솔직히 제대로 활용하지는 못했습니다.

전업 프로그래머가 아닌 저에게 코딩 AI는 매우 강력한 지원 도구입니다.

실제로 AI가 없었다면 개인이 웹 앱을 만드는 허들은 훨씬 더 높았을 것이라고 생각합니다.

하지만 한동안 사용하다 보니 어떤 과제를 느끼게 되었습니다.

그것은 AI에 의존하면 매번 구성이 안정되지 않는다는 점입니다.

코딩 AI는 편리하지만, 전제가 되는 정보가 부족하면 매번 제안되는 구성이 미묘하게 달라집니다. 누구나 겪는 길이라고 생각하면서도, 저 역시 예외 없이 직면한 과제였습니다.

특히 버그나 에러가 발생하여 좀처럼 해결되지 않을 때가 주의해야 할 시점입니다.

이 또한 AI의 답변에 주의력이 산만해진 타이밍에, Allow(허용)를 연발했을 때 발생합니다.

"아, 저기를 바꿔버리는구나..."라고 생각하게 되는 임시방편식 수정이 들어가는 경우도 있었습니다.

저 스스로도 본업 프로그래머가 아니기에, AI의 제안이 타당한지를 매번 판단하는 것은 쉽지 않습니다.

AI가 자신만만하게 제안하면 "아마 이걸로 괜찮겠지"라고 생각하며 진행하게 됩니다.

이러한 것이 축적되어 최종적인 구성이 안정되지 않는 결과로 이어지고 있었습니다.

이 경험을 통해 느낀 것은, 코딩 AI를 잘 사용하려면 단순히 질문만 해서는 부족하다는 것입니다.

필요했던 것은 **AI에 의존하기 위한 "형식 (Template)"**였습니다.

AI는 전제 조건이 없는 상태에서도 답변해 줍니다.

다만 그 경우에는 "그 자리에서 그럴듯한 최적해"가 돌아옵니다.

반면, 제가 원했던 것은 매번 다른 최적해가 아니라, 저에게 다루기 쉽고 매번 같은 토대 위에서 안정적으로 만들 수 있는 구성이었습니다.

즉, 개인 개발에서 중요했던 것은,

"AI에게 무엇을 물을 것인가"뿐만 아니라, "AI에게 무엇을 전제로 전달할 것인가"

였습니다.

그래서 저만의 표준 구성으로서 개발 템플릿을 만들기로 했습니다.

이번에 만든 템플릿의 목적은 단순한 코드의 雛形 (Boilerplate)을 준비하는 것이 아닙니다.

목적은 코딩 AI에 의존할 때의 전제를 고정하는 것이었습니다.

구체적으로 실행한 것은 두 가지입니다.

Kiro의 사양 주도 개발 (Specification-Driven Development)을 도입하여 앱 개발 방식을 안정화
Amplify Gen 2 구성으로 고정하여 AWS 구성의 안정화

그리고 중요한 점은, 템플릿 자체에 Kiro의 Steering (상주 규칙)을 심어두었다는 것입니다.

Steering에 프로젝트의 방침이나 기술 스택을 적어두면, Kiro는 프로젝트를 여는 시점에 그것을 읽어들입니다. 즉, 대화할 때 "이 템플릿을 따라줘"라고 매번 지시하지 않아도, 처음부터 동일한 전제로 앱 개발을 진행해 줍니다.

이전의 Cursor나 Claude Code에서는 AGENTS.md나 CLAUDE.md를 작성해도 제가 제대로 활용하지 못했던 것에 반해, Kiro의 Steering은 파일을 두는 것만으로 자동으로 규칙으로서 기능하기 때문에 이 차이는 상당히 컸습니다.

결과적으로,

• AI에게 "이번에는 이 구성으로"라고 매번 말할 필요가 없어짐
• 프로젝트를 여는 것만으로 전제가 공유된 상태에서 시작됨
• 사양 정리 → 설계 → 태스크 분해 → 구현의 흐름이 매번 동일해짐

이라는 상태가 되었습니다.

왜 Amplify x Kiro인가 하면, 저는 AWS를 접할 기회가 많고 인증(Authentication)·데이터(Data)·호스팅(Hosting)을 한꺼번에 다루고 싶었기 때문입니다. 사람에 따라서는 Next.js + Supabase나 React + Firebase도 괜찮을 것입니다. 중요한 것은 "매번 돌아갈 수 있는 틀이 있다"는 점입니다.

템플릿의 구성은 대략 다음과 같습니다.

kiro-amplify-template/
├── src/ # Next.js App Router
│ ├── app/ # 페이지·레이아웃
...

이 중에서 특히 중요한 부분은 다음과 같습니다.

Amplify Gen 2의 백엔드(Backend) 정의를 두는 곳입니다.

인증, 데이터, 스토리지 등 앱에 필요한 백엔드 리소스를 여기서 관리합니다.

개인 개발에서는 인증이나 DB를 매번 어떻게 만들지 고민하기 쉽습니다.

처음부터 Amplify Gen 2를 전제로 함으로써 백엔드 구축 방침을 고정했습니다.

AI 에이전트(AI Agent)를 추가할 경우에 이용하는 곳입니다.

반드시 사용할 필요는 없으며, 요구사항에 따라 AI 에이전트를 추가할 경우를 대비해 확장 지점으로 마련해 두었습니다.

프론트엔드(Frontend) 구현을 두는 곳입니다.

화면, 컴포넌트(Component), 기능 단위의 디렉토리 등을 미리 정해둠으로써 구현 중에 길을 잃지 않게 됩니다.

앞서 언급한 Steering이나 Skills를 두는 곳입니다.

프로젝트를 여는 순간 Kiro가 읽어들이기 때문에, 여기에 작성한 규칙이 자동으로 적용됩니다.

설계 메모나 조사 메모를 남기는 곳입니다.

개인 개발에서는 README만으로는 다 쓸 수 없는 판단이나 검토 과정이 생겨납니다.

예를 들어,

• 왜 이 데이터 모델(Data Model)로 했는가
• 왜 이 기능을 뒤로 미뤘는가
• 어디에서 막혔는가
• 다음에 할 일은 무엇인가

이러한 정보를 남겨둠으로써 나중에 다시 보기 쉬워집니다.

또한, Qiita 기사를 쓸 때의 재료도 됩니다.

템플릿을 만들어서 가장 컸던 점은, 개인 개발의 시작 비용이 낮아졌다는 것입니다.

이전에는 무언가 만들고 싶어도 처음에 구성을 코딩 AI에게 전달해야 했습니다.

• 프론트는 어떻게 할 것인가
• 백엔드는 어떻게 할 것인가
• 인증은 어떻게 할 것인가
• 배포(Deploy)는 어떻게 할 것인가

매번 막연하게 이미지를 가지고 시작하지만, 그 전제를 AI에게 전달하는 것이 매우 번거로웠습니다.

이런 부분에서 고민하는 사이에 만들고 싶은 마음이 조금 식어버리는 경우도 있었습니다.

하지만 템플릿이 있음으로써 감각이 바뀌었습니다.

"이 아이디어, 템플릿에 얹으면 시도해 볼 수 있겠어."

이 감각은 상당히 큽니다.

개인 개발에서는 아이디어가 있어도 첫걸음이 무거우면 그대로 흘러가 버립니다.

템플릿화를 통해 그 첫걸음이 가벼워졌습니다.

이번 템플릿은 Kiro의 IDE를 사용하는 것을 전제로 하고 있습니다.

Kiro라고 하면 **사양 주도 개발(Specification-Driven Development)**입니다. 작은 개인 개발이라도 사양 작성부터 시작하는 것을 철저히 함으로써 품질의 안정화를 기대할 수 있습니다.

개인 개발이라 해도 만들다 보면 사양 변경이 조금씩 발생합니다.

그럴 때도 유연하게 대응할 수 있도록, 갑자기 코드를 쓰는 것이 아니라 사양서나 설계서를 정리한 뒤 개발을 진행하는 것이 중요합니다.

특히 코딩 AI의 동작 환경에 크게 구애받지 않는 분들에게는, 어느 정도 패키징되어 있는 Kiro IDE는 추천할 만한 선택지입니다.

이번 템플릿에서는 백엔드의 토대로 Amplify Gen 2를 사용하고 있습니다.

개인 개발에서 정말 만들고 싶은 것은 앱의 기능이나 경험입니다.

하지만 실제로는 다음과 같은 주변 구축 작업에서 손이 멈추기 쉽습니다.

• 인증을 어떻게 할 것인가
• DB를 어떻게 할 것인가
• 프론트엔드와 어떻게 연결할 것인가
• 배포를 어떻게 할 것인가

이것들을 매번 제로 베이스에서 생각하는 것은 상당히 무겁습니다.

Amplify Gen 2를 템플릿에 포함함으로써,

• 인증은 Cognito
• 데이터는 AppSync + DynamoDB
• 호스팅은 Amplify Hosting
• CI/CD 파이프라인은 GitHub 연동

과 같이 큰 틀의 구성을 고정할 수 있습니다.

이를 통해 개인 개발의 관심을 "인프라나 주변 구축"에서 "무엇을 만들 것인가", "어떻게 사용하기 편하게 할 것인가"로 돌릴 수 있게 되었습니다.

이 템플릿의 활용을 통해 다음과 같은 앱을 만들었습니다.

• 고배당주 포트폴리오 관리 앱
• 일본 주식 분석 에이전트
• 북마크 관리 도구

나아가 이러한 앱 제작을 통해 기능을 심화 탐구 및 검증하며 새로운 지견을 얻고 있습니다.

템플릿을 정비한다
↓
만들고 싶은 것에 적용한다
...

이러한 사이클이 형성되면서 개인 개발과 학습이 연결되기 시작했습니다.

템플릿을 사용하여 시도한 테마 중 하나가 고배당주 포트폴리오 관리 앱입니다.

저는 일본 주식의 배당 정보나 포트폴리오 관리에 관심이 있어, 이전부터 스프레드시트나 무료 앱을 사용하여 주가 및 배당 정보의 수집·관리를 시도해 왔습니다.

이 테마는 저에게 실용성이 있습니다.

그렇기 때문에 단순한 샘플 앱이 아니라, "내가 정말로 원하는 것"으로서 개인 개발을 하기 쉬운 소재였습니다.

이 앱에서는 예를 들어 다음과 같은 기능을 구상했습니다.

• 보유 종목 등록
• 종목별 배당 수익률 확인
• 포트폴리오 전체의 배당 상황 확인
• 데이터를 축적하여 추이를 볼 수 있도록 구현

이러한 앱을 만들 때, 이전이었다면 우선 구성을 어떻게 할지 고민했을 것입니다.

하지만 자신만의 템플릿이 있음으로써 앱 아이디어 자체에 집중하기 쉬워졌습니다. 추가 기능을 포함할 때도 기존 구성에 무리 없이 통합할 수 있었습니다.

최근 몇 달간 매주 Qiita 포스팅을 이어오고 있습니다.

다만, 이것은 "글을 쓰는 것" 자체가 목적이라기보다, 개인 개발과 학습의 사이클을 돌리기 위한 메커니즘으로 작동하고 있습니다.

템플릿을 만들고, Kiro나 Amplify Gen 2를 다루며 개인 개발을 진행하다 보면 자연스럽게 글의 소재가 나옵니다.

예를 들어,

• 자신이 막혔던 부분
• 이해가 모호했던 부분
• 실제로 만들어 보며 알게 된 점
• 초보자의 관점에서 다시 정리한 내용
• 나중에 다시 보고 싶은 설계 메모

이러한 것들은 그대로 Qiita 기사의 재료가 됩니다.

AI는 이러한 포스팅 사이클에서도 도움이 되었습니다. 다만, 기사를 AI에 통째로 맡기는 것은 아닙니다.

AI는 어디까지나 아웃풋을 위한 '벽치기(대화 상대)'입니다.

자신의 경험을 기사로 만들기 위한 편집자와 같은 존재라고 느끼고 있습니다. (이 표현은 AI가 말한 방식입니다 ㅎㅎ)

기술적인 면에서는 '자신의 이해를 넘어서는 내용은 게재하지 않는다', '자신의 언어로 치환한다'라는 마음가짐이 무엇보다 중요해집니다.

한편으로는 자신의 이해가 부족하다는 것을 인식할 수 있거나, AI가 잡은 뼈대를 계기로 기능의 심화 탐구가 가능해지며, 자신에게 없는 관점을 더할 수 있습니다.

물론 자신만의 템플릿을 만든다고 해서 모든 것이 해결되는 것은 아닙니다.

실제로 사용해 보면서 몇 가지 주의점도 느꼈습니다.

편리하게 만들려고 처음부터 너무 많은 기능을 다 집어넣으면 템플릿 자체가 무거워집니다.

개인 개발의 초속(시작 속도)을 높이기 위한 템플릿인데, 템플릿을 이해하고 유지보수하는 데 시간이 걸린다면 본말전도입니다.

처음에는 최소한으로 시작하는 것이 좋다고 생각합니다. 필요한 것을 나중에 추가할 수 있는 여백을 남겨두는 편이 오래 사용하기 쉽습니다.

AI는 그럴듯한 제안을 해줍니다.

하지만 반드시 최신 사양이나 베스트 프랙티스(Best Practice)를 따르고 있다고는 할 수 없습니다.

특히 AI 에이전트 주변의 기능은 업데이트가 빠르기 때문에 AI의 답변만 믿는 것은 위험합니다.

실제로 구동하며 확인할 것. 공식 문서를 볼 것. 에러가 발생하면 원인을 분리할 것. 이 부분은 AI에 의존하더라도 의식적으로 지시할 필요가 있습니다.

한 번 템플릿을 만들었다고 끝이 아닙니다.

실제로 개인 개발에 사용해 보면 다음과 같은 개선점이 나타납니다.

• 이 디렉토리는 사용하기 불편하다
• AI에 전달할 전제를 좀 더 명확히 하고 싶다
• 자주 사용하는 프롬프트를 남겨두고 싶다
• CI/CD 설정을 좀 더 정비하고 싶다

템플릿은 완성품이라기보다 개인 개발을 통해 키워나가는 것이라고 느낍니다.

실제로 저의 템플릿도 v1을 만든 후, AI 에이전트 주변의 쇄신(AG-UI, AgentCore CLI 대응 등)을 통해 v2로 개정했습니다.

2026년 상반기, 저의 개인 개발은 상당히 변했습니다.

자신만의 템플릿을 만든 덕분에 매번 처음부터 구성을 고민할 필요가 없어졌고, 아이디어를 시험해 보기까지의 허들이 상당히 낮아졌습니다.

• 템플릿을 통해 개인 개발의 시작 비용이 낮아졌다
• Kiro를 통해 사양이나 태스크를 정리하기 쉬워졌다
• Amplify Gen 2를 통해 백엔드 구축의 허들이 낮아졌다
• AI를 통해 구현뿐만 아니라 기사화 및 회고까지 진행하기 쉬워졌다
• Qiita 포스팅을 통해 배움을 남기는 사이클이 생겼다

이번에 가장 강하게 느낀 점은, AI 활용에서 중요한 것은 "AI에게 맡기는 것"만이 아니라는 사실입니다.

오히려 AI에 의존할수록, 이쪽(사용자) 측으로 되돌아와야 할 틀(型)이나 전제가 필요해집니다.

저의 경우, 그 틀은 Amplify x Kiro 템플릿이었습니다.

다만, 그것은 어디까지나 하나의 예시일 뿐입니다.

중요한 것은 Amplify x Kiro를 사용하는 것 그 자체가 아니라, 자신이 AI에 휘둘리지 않기 위한 표준 구성(Standard Configuration)을 갖는 것이라고 생각합니다.

개인 개발에서 가장 변한 점은 코드를 작성하는 속도가 아닙니다.

2026년 후반에도 이 템플릿을 발전시키면서 개인 개발과 아웃풋(Output)을 계속해 나가고 싶습니다.

• 템플릿의 기술 상세

• 템플릿 v2 (AG-UI / AgentCore CLI 대응)

• 고배당주 포트폴리오 관리 앱