팀 내 유일한 프론트엔드 개발자가 회사에서 살아남는 법

"프론트엔드 개발자님, 이거 언제 배포되나요?"

저희 회사는 빠르게 성장하고 있는 조직입니다. AI 서비스 특성상 관리자 대시보드, B2C 클라이언트, 파트너사 페이지까지 총 3개의 제품을 운영하고 있죠.

문제는 프론트엔드 개발자가 저 혼자라는 점이었습니다.

기획자, 디자이너, 백엔드 개발자분들이 쏟아내는 요구사항을 혼자 감당해야 하는데, 버전 관리까지 수동으로 하다 보니 병목이 생기기 시작했습니다.

• 높은 컨텍스트 스위칭 비용: 하루에도 몇 번씩 앱을 오가며 작업하다 보니, "어? 이거 패치했나?" 헷갈리는 순간이 잦아졌습니다.
• 배포 리스크: 급하게 핫픽스를 배포하다가 다른 앱에 사이드 이펙트가 발생한 적이 있습니다. 등골이 서늘했죠.
• 문서화의 부재: 바쁘다는 핑계로 CHANGELOG 작성을 미루다 보니, 히스토리 파악이 안 돼서 똑같은 문제를 또 고민하게 되더라고요.

혼자라고 해서 주먹구구식으로 할 순 없었습니다. 오히려 혼자니까 더 시스템이 필요했죠.
제 리소스를 '운영'이 아닌 '기능 개발'에 온전히 쏟기 위해 자동화 시스템을 구축하기로 결심했습니다.

나를 복제할 수 없다면, 시스템을 만들자

그래서 도입한 것이 Simplified Git Flow + Changesets + CI/CD 파이프라인입니다.

도입 후 변화는 명확했습니다.

✅ 릴리스 프로세스 완전 자동화
✅ 의존성 패키지 업데이트 실수가 사라짐
✅ 어떤 기능이 배포되었는지 전사 공유 가능
✅ 나중에 팀원이 충원되어도 바로 적응 가능한 체계 구축

이제부터 어떻게 '혼자서도 잘 돌아가는 시스템'을 만들었는지 공유 해드릴게요

제 프로젝트 구조부터 소개할게요

먼저 제가 뚝딱거리고 있는 모노레포 구조입니다.

ai-client-mono/
├── apps/
│   ├── ai-agent-admin/      # 관리자 대시보드 (포트: 3000)
│   ├── ai-agent-client/     # 클라이언트 앱 (포트: 3333)
│   └── ai-partner-admin/    # 파트너 관리 (포트: 3001)
├── packages/
│   ├── ui/                  # 공유 UI 컴포넌트
│   ├── eslint-config/       # ESLint 설정
│   ├── prettier-config/     # Prettier 설정
│   ├── tailwind-config/     # Tailwind 설정
│   └── typescript-config/   # TypeScript 설정
└── turbo.json               # Turborepo 설정

3개의 앱이 packages/ui 같은 공유 패키지를 함께 쓰고 있어요. 그래서 버전 관리가 더 중요했죠.

1인 개발인데 Git Flow가 필요할까?

처음엔 고민했습니다. "어차피 나 혼자 다 머지할 건데, 그냥 메인 브랜치 하나면 되지 않나?"

하지만 안정적인 서비스 운영을 위해선 타협할 수 없는 기준들이 있었습니다.

1. 프로덕션 배포는 언제나 신뢰할 수 있어야 한다. (Main Branch)
2. 개발 중인 기능이 운영 환경을 오염시키면 안 된다. (Dev Branch)
3. 긴급 버그 픽스는 다른 기능 개발과 격리되어야 한다. (Hotfix)

그래서 복잡한 Git Flow 대신, 실용성에 초점을 맞춘 Simplified Git Flow를 정립했습니다.

브랜치 구조

main (프로덕션)
  ↑
dev (개발 통합)
  ↑
feature/* (기능 개발)
hotfix/* (긴급 수정)
release/* (릴리스 준비)

각 브랜치의 역할

1. main - 프로덕션 브랜치

• 항상 배포 가능한 상태
• 직접 커밋 금지 (PR을 통해서만 병합)
• 태그를 통한 버전 관리

2. dev - 개발 통합 브랜치

• 다음 릴리스를 위한 개발 브랜치
• feature 브랜치들이 병합되는 곳
• CI/CD를 통한 자동 테스트

3. feature/ - 기능 개발 브랜치

모노레포 특성상 앱별/패키지별로 명확한 네이밍이 필요합니다

# 앱별 기능
feature/agent-admin/user-management
feature/agent-client/chat-interface
feature/partner-admin/dashboard

# 공유 패키지
feature/ui/button-component
feature/config/eslint-rules

# 공통 기능
feature/monorepo/ci-optimization

4. hotfix/ - 긴급 수정

hotfix/agent-admin/login-bug
hotfix/shared/security-patch

5. release/ - 릴리스 준비

release/v1.2.0
release/2025-12-ai-agent-admin

커밋 컨벤션: 히스토리는 회사의 자산이니까요

"나중에 보면 알겠지"라는 생각은 프로답지 못합니다. 제가 퇴사하더라도 코드는 남고, 히스토리는 자산이 됩니다.

특히 모노레포 환경에서는 어떤 앱에 변경사항이 발생했는지 명확해야 합니다.
그래서 Conventional Commits + Scope를 강제하여, 커밋 로그만 봐도 프로젝트 흐름이 보이도록 만들었습니다.

형식

<type>(<scope>): <subject>

예시

feat(agent-admin): 사용자 관리 페이지 추가
fix(agent-client): 채팅 메시지 렌더링 버그 수정
chore(ui): 버튼 컴포넌트 스타일 개선
docs(readme): Git 전략 문서 추가
refactor(partner-admin): 대시보드 코드 리팩토링
perf(shared): Tailwind 설정 최적화

Scope 예시

• 앱: agent-admin, agent-client, partner-admin
• 패키지: ui, config, eslint-config, tailwind-config
• 공통: monorepo, deps, ci

Changesets: 운영 비용을 줄이는 마법

가장 큰 병목은 CHANGELOG 관리와 버전 태깅이었습니다.
기능 개발 후 일일이 문서를 작성하고 버전을 올리는 건, 단순 반복 작업이자 리소스 낭비였죠.

"개발 단계에서 변경사항을 선언하면, 배포는 시스템이 알아서 할 수 없을까?"

이 물음에 대한 답이 Changesets이었습니다. 개발자는 코드와 함께 변경 의도를 남기기만 하면 됩니다. 나머지는 도구가 알아서 하니까요.

install

pnpm add -D -w @changesets/cli

init

Changesets를 초기화합니다.

pnpm changeset init

이렇게 init 작업을 하게 되면 .changeset 디렉터리가 생성되고, config.json 파일이 만들어집니다.

config.json 설정

.changeset/config.json 파일을 프로젝트에 맞게 수정합니다

{
  "$schema": "https://unpkg.com/@changesets/config@3.0.0/schema.json",
  "changelog": "@changesets/cli/changelog",
  "commit": false,
  "fixed": [],
  "linked": [],
  "access": "restricted",
  "baseBranch": "main",
  "updateInternalDependencies": "patch",
  "ignore": []
}

워크플로우: 개발에만 집중하는 환경

이제 Release 프로세스는 이렇게 변했습니다.

1. pnpm changeset으로 변경사항 기록 (10초)
2. PR 생성 및 병합 (코드 리뷰)
3. 나머지는 CI/CD가 처리

더 이상 package.json 버전을 수동으로 수정하거나, 히스토리를 찾아 헤맬 필요가 없습니다.
저는 그 시간에 다음 스프린트의 핵심 기능을 개발합니다.

자동화로 신뢰성 확보하기

혼자 일할 때 가장 위험한 건 "체크해 줄 사람이 없다"는 것입니다.
그래서 CI/CD 파이프라인을 구축해 코드의 품질을 기계가 검증하도록 했습니다.

안정적인 배포 파이프라인

1. Lint/Build 검사: 휴먼 에러가 있는 코드는 절대 병합되지 않습니다.
2. 자동 버전 업: Semantic Versioning 규칙에 따라 정확하게 버전이 올라갑니다.
3. Release Note 생성: 배포 내역이 자동으로 문서화되어 팀에 공유됩니다.

이제 저는 마음 놓고 배포 버튼을 누를 수 있습니다. 시스템이 저를 지켜주니까요.

마치며: 혼자라고 시스템을 포기하지 마세요

"혼자니까 대충 해도 되겠지"라고 타협하는 순간, 기술 부채는 걷잡을 수 없이 커집니다.
특히 빠르게 성장하는 스타트업일수록, 초기 단계의 시스템 구축이 중요하다고 생각합니다.

혼자 고군분투하는 프론트엔드 개발자분들에게 시간과 안정성이라는 두 마리 토끼를 분양드립니다 ㅎㅎ

"나는 혼자여서 시스템이고 코드문화도 즐기지 못해" 라는 생각보다 나중에 올 팀원 (오긴 올까,,)을 위해 시스템을 구축하고, 코드 문화를 정립해보는 경험도 좋을것 같습니다 🎶