윤누리
윤누리
Admin
🧙 AI 위자드
🎻 루키 파트너
🌈 지피터스금손
🚀 SNS 챌린지 달성자
☕ 커피챗 오픈

서비스명 대충 지으면 이렇게 됩니다 — 하루 만에 전체 리브랜딩한 이야기

📝 한줄 요약

임시로 지었던 서비스명 "Linear Capture"가 법적 리스크와 확장성 한계에 부딪혀, Claude Code와 함께 하루 만에 앱 이름·도메인·아이콘·랜딩페이지·인프라까지 통째로 "IssueIt"으로 갈아엎었습니다.

🎯 이런 분들께 도움돼요

  • 사이드 프로젝트 서비스명을 "일단 아무거나" 지어놓고 후회하고 있는 분

  • 혼자서 앱 리브랜딩을 해야 하는데 어디부터 손대야 할지 막막한 1인 개발자

  • AI 코딩 도구로 실제 프로덕션 앱을 운영하고 있거나 시작하려는 분

우선 결과부터 보고 가시죠

  • 혹시 리니어를 쓰시는 분들은 지금 바로 설치해서 'IssueIt'을 사용하실 수 있습니다.


  • 이슈로 생성하고 싶은 부분을 단축키로 잡고 캡처만 하면 바로 이슈 생성되고,

  • 관련해서 연동하고 싶은 슬랙/노션/지메일/리니어 이슈까지 집어넣을 수 있습니다 💞

😫 문제 상황 (Before)

"Linear Capture"라는 이름은 개발 초기에 그냥 임의로 붙인 이름이었습니다. Linear API로 이슈를 생성하는 화면 캡처 앱이니까, 직관적이잖아? 하고 대충 지은 거였죠.

그런데 서비스가 점점 완성되면서 두 가지 문제가 보이기 시작했습니다.

첫째, 법적 리스크. "Linear"는 이미 존재하는 회사 이름입니다. 공식 앱도 아닌데 이름에 "Linear"가 들어가면 혼동을 줄 수 있고, 나중에 문제가 될 수 있었습니다.

둘째, 확장성 한계. 앞으로 Jira나 GitHub Issues 같은 다른 이슈 트래커도 지원하고 싶었는데, "Linear Capture"라는 이름에 갇혀 있으면 그게 불가능했습니다.

마침 팀원에게 처음으로 앱을 배포하는 시점이었습니다. 외부에 공개하기 전에 이름을 바꾸자. 지금이 마지막 기회다. 그렇게 하루짜리 리브랜딩 프로젝트가 시작됐습니다.

🛠️ 사용한 도구

  • 도구명: Claude Code (CLI 기반 AI 코딩 어시스턴트)

  • 특이사항: Claude Code의 Team 기능(에이전트 팀)을 활용한 병렬 작업도 진행


🔧 작업 과정

도메인부터 바꾸자 — 그런데 두 번 바꿨습니다

리브랜딩의 첫 단계는 서버(Worker) 도메인 변경이었습니다. 기존에 쓰던 임시 도메인을 깔끔한 커스텀 도메인으로 바꾸려고 했죠.

Worker 도메인을 linear-capture.gpters.org로 바꿔줘

Claude가 앱의 서버 주소 설정, Worker 배포 설정을 한꺼번에 바꾸고 새 버전까지 배포해줬습니다.

그런데 문제는, 이 시점에서 아직 새 서비스명을 "IssueIt"으로 확정하지 않았다는 겁니다. 도메인을 바꾸고 나서야 "아, 서비스명도 바꿀 건데 도메인에 linear-capture가 들어가면 안 되잖아?" 하고 깨달았습니다.

서비스명을 IssueIt으로 바꿀 거라 Worker 도메인도 issue-it.gpters.org로 변경해줘

결국 같은 작업을 두 번 했습니다. 앱 설정 변경, Worker 설정 변경, 버전 올리기, 배포 — 전부 두 번. AI가 빠르게 처리해줘서 시간은 크게 안 걸렸지만, 이름을 먼저 확정하고 시작했으면 한 번에 끝났을 일이었습니다. 이때 뼈저리게 느꼈습니다. 초기 세팅은 대충 하면 안 된다.


이름 바꾸기의 함정 — 건드리면 안 되는 것들

서비스명을 바꾸는 건 단순히 텍스트를 치환하는 게 아닙니다. macOS 앱은 코드 서명(코드사이닝)이라는 게 있어서, 특정 설정값을 바꾸면 앱 자체가 실행이 안 됩니다. 자동 업데이트도 마찬가지로, 파일 이름 규칙이 틀어지면 업데이트가 깨집니다.

그래서 Claude에게 이렇게 요청했습니다.

서비스 이름을 IssueIt으로 바꾸고 싶어. 코드사이닝이나 자동업데이트에 영향 안 주도록 조심해서

이게 핵심이었습니다. "조심해서"라는 한 마디. Claude는 이 요청을 받고 먼저 "변경해야 하는 것"과 "절대 변경하면 안 되는 것"을 분류해서 보여줬습니다.

변경한 것: 사용자에게 보이는 앱 이름, 트레이 아이콘 툴팁, 창 제목, 온보딩 화면 텍스트, 다국어 번역 파일(한국어·독일어·프랑스어·스페인어 자동 번역까지) 등 9곳.

변경하지 않은 것: 앱 식별자(appId), 코드 서명에 쓰이는 제품명(productName), 파일 이름 규칙(artifactName), 공증 스크립트, 권한 관리 번들 ID 등.

만약 이걸 수동으로 했다면? 하나하나 찾아서 바꾸다가 실수로 코드사이닝 설정을 건드려서 앱이 안 열리는 사고가 났을 겁니다. AI한테 "이거 조심해"라고 맥락을 알려주면, 알아서 위험 요소를 피해간다는 걸 이때 확실히 느꼈습니다.


트레이 아이콘이 너무 못생겼다

리브랜딩 김에 트레이 아이콘도 바꾸고 싶었습니다. 기존에는 "II"라는 글자를 아이콘으로 쓰고 있었는데, 솔직히 너무 못생겼거든요.

지금 트레이 아이콘이 II인데 진짜 너무 못생겼다. 무료 아이콘 패키지 같은게 없을까?

Claude가 Lucide라는 오픈소스 아이콘 라이브러리에서 "ticket-check"라는 아이콘을 찾아줬습니다. 티켓 모양에 체크 표시가 있어서 "이슈 생성 완료"라는 앱의 핵심 기능과 딱 맞았죠. SVG 파일을 macOS 트레이에 맞는 형식으로 변환하고, 빌드해서 확인하는 것까지 한 번에 처리됐습니다.

나... 나름 귀엽죠? 30초만에 적용한거 생각하면 만족


랜딩페이지까지 한 번에

앱 리브랜딩이 끝나니 랜딩페이지도 바꿔야 했습니다.

랜딩페이지도 IssueIt으로 바꾸고 로고 옆에 아이콘 넣어줘. 파비콘이랑 OG 이미지도 필요해

캡처 배송 완료라는 단어가 포함된 웹사이트

브랜드명 변경, 네비게이션 바에 아이콘 추가, SEO 메타태그, 파비콘, 소셜 미디어 공유용 OG 이미지 생성, 그리고 배포까지. 한 번의 요청으로 랜딩페이지의 모든 브랜딩 요소가 교체됐습니다.


"팀 꾸려서 정리해줘" — 에이전트 3명이 80MB를 찾아냈다

리브랜딩과 별개로, 프로젝트에 불필요한 파일이 쌓여 있다는 걸 알고 있었습니다. 개발하면서 남은 화면 녹화 파일, 백업 아카이브, 더 이상 안 쓰는 코드 등등. 그런데 어디에 뭐가 있는지 일일이 찾기는 귀찮았습니다.

Claude Code에는 "Team" 기능이 있습니다. 여러 AI 에이전트를 팀으로 구성해서 동시에 작업시킬 수 있죠.

CTO 팀 꾸려서 에이전트들이랑 같이 불필요한 파일들 있으면 싹 정리해줘

이 한 마디에 3개의 에이전트가 만들어졌습니다.

  • build-scanner: 빌드 결과물, 대용량 파일 스캔 담당

  • code-scanner: 안 쓰는 소스 코드, 설정 파일 조사 담당

  • docs-scanner: 문서, 마케팅 자료 정리 담당

세 에이전트가 동시에 프로젝트 전체를 스캔했고, 총 83.6MB의 불필요한 파일을 찾아냈습니다. 68MB짜리 원본 화면 녹화 영상, 10MB짜리 데모 GIF, 쓰지 않는 외부 라이브러리, 죽은 코드 파일까지. 혼자서 했으면 "이거 지워도 되나?" 하면서 한참 고민했을 텐데, 에이전트들이 각 파일의 사용 여부를 분석해서 안전하게 제거할 수 있는 것만 골라냈습니다.



✅ 결과 (After)

Before vs After

항목

Before

After

서비스명

Linear Capture (임시)

IssueIt (확정)

Worker 도메인

kangjun-f0f.workers.dev

issue-it.gpters.org

트레이 아이콘

"II" 글자

Lucide ticket-check 아이콘

랜딩페이지

Linear Capture 브랜딩

IssueIt + 파비콘 + OG 이미지

레포 용량

+83.6MB 불필요 파일

정리 완료

작업 항목

12개 (도메인 2회 + 리브랜딩 + 인프라 + 이슈 대응)

하루 만에 전부 완료

커밋

14개

하루 치고는... 많다

결과물

  • 앱 이름, 아이콘, 랜딩페이지, 서버 도메인, 다국어 번역까지 "IssueIt"으로 완전 통일

  • 팀원 배포 후 발생한 3건의 이슈 모두 당일 해결

  • 레포에서 83.6MB 불필요 파일 제거

이렇게 하면 안 돼요

  1. 이름(도메인, 서비스명)을 확정하지 않고 작업 시작하기 — AI가 아무리 빨라도, 같은 작업을 두 번 하면 두 배 걸립니다. 도메인을 두 번 바꾸면서 뼈저리게 느꼈습니다. 초기 세팅은 AI를 쓰기 전에 사람이 먼저 확정해야 합니다.

  2. 구버전 빌드로 테스트하기 — 첫 배포 때 팀원이 옛날 앱을 쓰고 있어서 온갖 이슈가 터졌습니다. 배포할 때는 완전 삭제 후 클린 설치를 기본으로.

🚀 앞으로의 계획

Reddit 등 해외 커뮤니티에 IssueIt을 올려보고 반응을 확인할 예정입니다. 특히 Jira와 GitHub Issues 연동을 추가하면 사용자층이 크게 넓어질 것 같은데, 솔직히 Linear보다 이 둘을 쓰는 사람이 훨씬 많아서 빨리 해보고 싶은 마음입니다.

2
3개의 답글
지피터스 뉴스레터

이번 주 AI, 딱 쓸 것만

매주 월요일 오후,
읽고 바로 써먹을 AI 소식만