<div id="readability-page-1" class="page"><div><article><img src="https://get6.github.io/blog/external/1d093faea3ec22c5206758925d2cd65a.webp" alt="photo by Robert Lukeman(https://unsplash.com/@robertlukeman?utm_source=templater_proxy&amp;utm_medium=referral) on Unsplash">
혼자 무언가를 만들어보려는 사람에게 2026년은 꽤 좋은 시기예요. 몇 년 전만 해도 앱 하나를 띄우려면 프론트, 백엔드, 인프라를 다 알아야 했는데, 지금은 도구들이 그 빈자리를 많이 메워주거든요.
대신 고민의 결이 달라졌어요. "이걸 어떻게 만들지"보다 "무엇을 먼저 정해두고 시작할지"가 더 중요해졌죠. 도구가 좋아질수록 처음에 잡아둔 뼈대가 결과를 가르거든요. 그래서 혼자 개발을 시작한다면 챙겨두면 좋을 것들을 순서대로 정리해볼게요.
<h2 id="ai가-혼자서도-팀처럼-일하게-해줘요">AI가 혼자서도 팀처럼 일하게 해줘요<a href="#ai가-혼자서도-팀처럼-일하게-해줘요">#</a></h2>
2026년 1인 개발의 가장 큰 변화는 단연 AI 코딩 도구예요. Claude Code, Cursor, GitHub Copilot 같은 도구가 이제 "있으면 좋은 것"이 아니라 기본 작업 환경이 됐어요.
말로 설명하면 코드가 나오는 이른바 "바이브 코딩"이 주류가 됐고, AI는 코드 작성뿐 아니라 개발 흐름 전체에 들어와 있어요.
<ul>
<li>디자인 — v0 같은 도구로 UI 초안을 생성</li>
<li>테스트 — 테스트 케이스와 커버리지 보완</li>
<li>문서화 — README, API 문서 자동 정리</li>
<li>코드 리뷰 — PR 요약과 변경점 설명</li>
</ul>
비용 감각도 알아둘 만해요. AI 도구에 월 100달러 남짓 쓰는 게, 외주 개발자 한 명(월 수천 달러)을 대신하는 효과를 낸다는 이야기가 나올 정도예요. 혼자서도 여러 역할을 메울 수 있게 된 거죠.
다만 마냥 장밋빛은 아니에요. 빠르게 90%를 만들고 나서 나머지를 못 넘기는 "80% 벽"에 부딪히는 사람이 늘었어요. AI 크레딧을 태워가며 디버깅을 반복하거나, 보안 구멍을 뒤늦게 발견하는 식이죠. 그래서 2026년의 화두는 속도에서 지속 가능성으로 옮겨가는 중이에요.
<blockquote><div>AI는 손을 늘려주지 판단을 늘려주진 않아요. 뼈대를 어떻게 잡을지는 여전히 사람이 정해야 해요.</div></blockquote>
<h2 id="프레임워크보다-환경을-먼저-정해요">프레임워크보다 "환경"을 먼저 정해요<a href="#프레임워크보다-환경을-먼저-정해요">#</a></h2>
그 판단의 첫 단추가 "무엇으로, 어떻게 만들지"예요. 저는 Flutter를 중심에 두려고 해요. 한 번 짜서 AOS, iOS, Web, 데스크톱까지 가는 크로스 플랫폼이 1인 개발과 잘 맞거든요.
그런데 정작 중요한 건 프레임워크 선택이 아니라 프로젝트 환경이에요. 회사든 1인이든, 특정 프레임워크를 떠나서 공통으로 챙겨야 하는 것들이 있어요.
<ul>
<li>모노레포 — 앱, 패키지, 공용 코드를 한 저장소에서 관리</li>
<li>국제화(i18n) — 처음부터 문자열을 분리해두면 나중에 언어 추가가 쉬워요</li>
<li>Flavor — dev / staging / prod 환경을 빌드 단위로 분리</li>
<li>디자인 시스템 — 색, 타이포, 컴포넌트를 한곳에 정의</li>
<li>아키텍처 / 협업 방식 / 테스트 — 코드가 자라도 무너지지 않게 하는 토대</li>
</ul>
이 가운데 개발 규칙과 아키텍처는 특히 중요해서 바로 뒤에서 따로 펼쳐볼게요. 혼자라고 이걸 건너뛰면, 나중에 동료가 합류하거나 프로젝트가 커질 때 한꺼번에 빚으로 돌아와요. 미래의 나를 위한 환경이라고 생각하면 돼요.
<h2 id="개발-규칙은-처음에-정해두면-편해요">개발 규칙은 처음에 정해두면 편해요<a href="#개발-규칙은-처음에-정해두면-편해요">#</a></h2>
환경과 짝을 이루는 게 개발 규칙이에요. 개발 외적으로 정해둘 게 생각보다 많아요.
<ul>
<li>코드 검토 — 혼자여도 PR을 열고 셀프 리뷰하는 습관</li>
<li>스타일 규칙 — 네이밍, 폴더 구조, 파일 분리 기준</li>
<li>전처리기(포매터) — 저장하면 자동 정렬되게</li>
<li>린팅 — 실수와 안티패턴을 커밋 전에 잡기</li>
</ul>
이 규칙들은 AI 시대에 오히려 더 중요해졌어요. 규칙이 명확할수록 AI가 그 결을 따라 일관된 코드를 만들어주거든요. 사람과 AI가 같이 보는 약속인 셈이에요.
<h2 id="상태-관리와-아키텍처-어디까지-욕심낼까요">상태 관리와 아키텍처, 어디까지 욕심낼까요<a href="#상태-관리와-아키텍처-어디까지-욕심낼까요">#</a></h2>
여기서부턴 코드를 직접 쥔 다음 단계의 이야기예요. 이제 막 시작한다면 가볍게 훑고 나중에 다시 봐도 괜찮아요.
Flutter에서 아키텍처를 입힌 화면을 만들 때 자주 부딪히는 고민이 있어요. Riverpod의 <code>ref</code>를 어디서 쓸지 하는 문제죠.
처음 떠올린 생각은 이랬어요. 컨트롤러를 호출하는 <code>ref.read</code>와 상태를 구독하는 <code>ref.watch</code>를 화면(screen)에 몰아주면, 나머지 UI는 상태에 의존하지 않는 순수한 형태로 만들 수 있지 않을까. 그러면 하위 위젯은 데이터와 콜백만 주입받으면 되니까요.
문제는 그렇게 하면 prop drilling이 생긴다는 거예요. 화면에서 받은 데이터와 함수를 중간 위젯들을 거쳐 깊숙한 곳까지 계속 넘겨줘야 하죠.
여기서 Riverpod의 설계 철학이 답을 줘요. 공식 문서는 <code>ref.watch</code>를 <code>InheritedWidget</code>과 비슷한 것이라고 설명해요. <code>Theme.of(context)</code>처럼, 트리 어디서든 위젯이 프로바이더를 직접 구독할 수 있다는 뜻이에요.
그래서 정답은 "모든 걸 screen에 몰아주기"가 아니라 균형이에요.
<ol>
<li>화면은 흐름을 조율하는 컨트롤러 호출과 큰 상태 구독을 맡아요</li>
<li>실제로 특정 상태가 필요한 말단 위젯은 굳이 props로 받지 말고, 그 위젯을 <code>ConsumerWidget</code>으로 만들어 프로바이더를 직접 <code>ref.watch</code> 하게 해요</li>
<li>잦은 리빌드가 걱정되면 <code>ref.select</code>로 필요한 조각만 구독하면 돼요</li>
</ol>
이렇게 하면 중간 위젯들을 관통하는 드릴링이 사라져요. 상태가 필요한 위젯이 직접 가져다 쓰니까요. "순수한 UI"는 정말 표현만 하는 작은 컴포넌트(버튼, 카드 등)에만 적용하고, 상태가 필요한 곳은 소비자로 만드는 게 더 깔끔해요.
<h3 id="event-driven-아키텍처는-클린-아키텍처와-다를까요">Event-driven 아키텍처는 클린 아키텍처와 다를까요<a href="#event-driven-아키텍처는-클린-아키텍처와-다를까요">#</a></h3>
결론부터 말하면 다른 층위의 이야기예요. 둘은 경쟁 관계가 아니라 같이 쓸 수 있어요.
<ul>
<li>클린 아키텍처는 구조에 대한 거예요. 엔티티, 유스케이스, UI 같은 계층을 나누고, 의존성이 항상 안쪽(도메인)을 향하게 하죠.</li>
<li>이벤트 드리븐 아키텍처는 흐름에 대한 거예요. 컴포넌트가 서로 직접 호출하는 대신 이벤트(메시지)를 주고받으며 느슨하게 연결되죠.</li>
</ul>
그래서 "이벤트로 소통하는 클린 아키텍처"도 충분히 가능해요. 하나는 코드를 어떻게 쌓을지, 다른 하나는 부분들이 어떻게 대화할지를 정하는 거니까요.
<h2 id="서버와-인프라는-가장-가벼운-것부터">서버와 인프라는 가장 가벼운 것부터<a href="#서버와-인프라는-가장-가벼운-것부터">#</a></h2>
코드 안쪽을 정리했다면, 이제 그 코드가 돌아갈 바깥을 볼 차례예요. 혼자 시작할 때 가장 흔한 실수가 처음부터 거창한 인프라를 까는 것이에요. 필요해지기 전엔 미뤄도 돼요.
서버는 단계적으로 올리면 좋아요.
<ol>
<li>Firebase (BaaS) — 시장 검증 단계엔 이게 제일 빨라요. 인증, DB, 스토리지를 코드 몇 줄로 붙이죠</li>
<li>NestJS — Firebase 비용이 부담될 즈음, 비용과 개발 편의의 균형점으로</li>
<li>Spring + Kotlin — 비용이 더 커지고 MSA가 필요해질 때</li>
</ol>
DB도 비슷해요. 기본은 오픈소스인 PostgreSQL 하나면 충분하고, 스키마 변경 이력은 Liquibase 같은 도구로 관리하면 돼요. Redis나 MongoDB, Elasticsearch 같은 건 정말 필요한 순간에 더해도 늦지 않아요.
한 가지 처음부터 챙기면 좋은 건 컨테이너예요. Docker로 환경을 감싸두면 개발 환경과 상용 환경을 똑같이 맞출 수 있거든요. "내 컴퓨터에선 됐는데" 같은 문제를 크게 줄여줘요.
인프라를 더 키울 때는 <a href="https://landscape.cncf.io/guide" rel="noopener noreferrer" target="_blank">CNCF Landscape 가이드</a>를 나침반으로 삼으면 좋아요. 컨테이너 생태계의 검증된 도구들을 정리해둔 곳이라, 유행어에 휩쓸리지 않고 고를 수 있어요.
<h2 id="코드-밖에도-스택이-있어요">코드 밖에도 스택이 있어요<a href="#코드-밖에도-스택이-있어요">#</a></h2>
혼자 한다는 건 결국 개발자 말고도 여러 역할을 겸한다는 뜻이에요. 돈 관리, 마케팅, 고객 응대까지 다 내 몫이 되죠. 그리고 이 각각이 그 나름의 기술 스택을 갖고 있어요.
회계 업무 하나만 봐도 도구가 이렇게 갈라져요.
<img src="https://get6.github.io/blog/assets/accounting-firm-tech-stack-table.webp" alt="회계 사무소가 업무별로 쓰는 도구들">
같은 스택을 온보딩·재무·프로젝트 관리처럼 직무 묶음으로 보면 이런 모습이고요.
<img src="https://get6.github.io/blog/assets/accounting-firm-tech-stack-diagram.webp" alt="직무 그룹으로 묶은 회계 사무소 스택">
마케팅은 또 결이 달라요. 도구를 나열하기보다 흐름으로 엮여 움직이거든요. 인지에서 출발해 웹사이트, 데이터 관리, 재참여, 상호작용을 거쳐 측정으로 이어지죠.
<img src="https://get6.github.io/blog/assets/marketing-tech-stack-flow.webp" alt="인지부터 측정까지 흐름으로 엮인 마케팅 스택">
여기서 두 가지를 가져가면 돼요. 하나, 이런 지도는 이미 누가 잘 그려놨어요. 직접 만들 필요 없이 빌려 쓰면 되죠. 둘, 그림이 거창해 보여도 처음부터 다 채울 필요는 없어요. 개발 스택과 똑같이, 지금 막힌 일 하나에 맞는 가장 가벼운 도구부터 고르면 돼요.
여러 직무의 스택 예시는 <a href="https://blog.hubspot.com/customers/auditing-your-companys-tech-stack-or-platform-apps" rel="noopener noreferrer" target="_blank">Tech Stack: Definition + 9 Examples</a> 같은 글에 더 정리돼 있어요.
<h2 id="그래서-2026년-혼자라면">그래서 2026년, 혼자라면<a href="#그래서-2026년-혼자라면">#</a></h2>
정리하면 이래요.
<ol>
<li>AI 도구를 기본 환경으로 두되, 판단은 내가 한다</li>
<li>프레임워크보다 환경(모노레포·i18n·Flavor·디자인 시스템·테스트)을 먼저 정한다</li>
<li>개발 규칙을 초반에 약속으로 박아둔다 (사람과 AI가 함께 본다)</li>
<li>아키텍처는 균형 있게 — 상태가 필요한 위젯은 직접 소비하게</li>
<li>서버와 인프라는 가장 가벼운 것부터, 필요할 때 키운다</li>
<li>코드 밖 직무(회계·마케팅 등)도 결국 스택이다 — 직접 그리지 말고 검증된 지도를 빌린다</li>
</ol>
도구가 좋아진 만큼 혼자 만들 수 있는 게 정말 많아졌어요. 그래서 더더욱 무엇을 먼저 정해두고 시작하느냐가 결과를 가르는 시대예요. 거창한 스택을 부러워하기보다, 오늘 만들 화면 하나에 맞는 가장 가벼운 선택부터 해보는 게 좋은 출발이에요.
<hr>
<blockquote><div>If we are not fully ourselves, truly in the present moment, we miss everything.</div>— Thich Nhat Hanh</blockquote></article></div></div>

이때의 나

sunhwang

혼자 무언가를 만들어보려는 사람에게 2026년은 꽤 좋은 시기예요. 몇 년 전만 해도 앱 하나를 띄우려면 프론트, 백엔드, 인프라를 다 알아야 했는데, 지금은 도구들이 그 빈자리를 많이 메워주거든요. 대신 고민의 결이 달라졌어요. "이걸 어떻게 만들지"보다 "무엇을 먼저 정해두고 시작할지"가 더 중요해졌죠. 도구가 좋아질수록 처음에 잡아둔 뼈대가 결과를 가...

2026년, 혼자 개발을 시작한다면 무엇부터 챙길까요

댓글