[Part 1] ConfigDeck 소개와 하네스 도입 배경

시리즈 목차

ConfigDeck이란

ConfigDeck은 개발자가 프로젝트 초기 설정 파일을 쉽게 생성할 수 있는 웹 서비스다.

핵심 기능

지원하는 설정 파일

• .gitignore, .editorconfig, .env.example
• tsconfig.json, eslint.config.mjs, prettier.config.mjs
• vite.config.ts, vitest.config.ts, next.config.js

왜 이 서비스를 만들었나

개발을 하다 보면 ESLint, Prettier, TypeScript 같은 설정 파일을 정말 많이 다루게 된다. 그런데 정확하게 어떤 옵션이 어떻게 동작하는지 모른 채 사용하는 경우가 많다.

맨날 쓰던 것만 쓰게 된다. 더 좋은 옵션이 생겨도 인지하지 못하고, 버전이 올라가며 설정 방식이 바뀌어도 구버전 방식만 계속 사용하게 된다.

그래서 생각했다. 사용자가 직접 UI를 통해 각 옵션을 확인하고, 필요한 것만 골라서 다운로드할 수 있다면 어떨까?

항상 똑같은 것만 먹다가, 대형 마트에서 여러 음식을 골라 담아 장을 보는 것처럼. 입맛에 맞는 건 계속 사게 되고, 맞지 않는 건 더 안 사도 되는 것처럼. ConfigDeck은 설정 파일을 그렇게 고를 수 있게 해주는 서비스다.

1인 개발의 한계

서비스 아이디어는 있었지만, 혼자서 만들기에는 여러 한계가 보였다.

코드 리뷰의 부재

팀 프로젝트라면 PR에 리뷰가 달린다. 놓친 부분을 잡아주고, 더 나은 방향을 제안해준다. 1인 개발에는 이게 없다. 내가 작성한 코드를 내가 검토하면 맹점이 생긴다.

QA 리소스의 부재

별도 QA 팀이 없으니 테스트도 혼자 해야 한다. 기능을 만들고, 테스트 케이스를 작성하고, 엣지 케이스를 검증하는 것까지 전부 한 사람 몫이다. 자연히 검증이 부실해진다.

의사결정의 고립

“이 라이브러리를 쓸까, 저 라이브러리를 쓸까?” 같은 기술적 의사결정을 혼자 내려야 한다. 논의할 상대가 없으니 검토가 얕아지고, 결정의 근거를 기록하지 않으면 나중에 왜 그랬는지 기억나지 않는다.

멀티 롤의 부담

기획, 디자인, 개발, 배포, 운영까지 모든 역할을 혼자 수행해야 한다. 각 영역에서 전문성을 기대하기 어렵고, 어느 한 부분에 집중하면 다른 부분이 소홀해진다.

하네스 도입의 계기

이런 한계를 어떻게 극복할 수 있을까 고민하던 중, gstack이라는 오픈소스를 발견했다.

gstack은 Claude Code의 에이전트와 스킬을 팀처럼 구성해서 사용하는 프로젝트다. 이걸 보고 생각이 바뀌었다.

“AI를 단순한 코딩 도우미가 아니라, 역할을 가진 팀원처럼 구성할 수 있지 않을까?”

• QA 에이전트가 코드 리뷰와 테스트를 담당하면?
• 서비스 분석 에이전트가 경쟁사 조사와 UX 분석을 해주면?
• PR 생성 스킬이 일관된 워크플로우를 보장해주면?

1인 개발의 한계를 AI 팀으로 보완할 수 있겠다는 확신이 들었다. 그래서 ConfigDeck은 처음부터 하네스 시스템을 중심으로 개발하기로 했다.

개발 일정

빈 프로젝트에서 배포까지 약 2주가 걸렸다. 물론 이 기간 동안 풀타임으로 작업한 것은 아니고, 퇴근 후와 주말을 활용한 사이드 프로젝트 시간이었다.

기술 스택