요즘IT는 2025년 12월 ‘클코나잇 3회 - The 비개발자들’ 세미나를 열어, 비개발자들이 클로드 코드를 어떻게 활용하는지 다양한 사례를 공유했습니다. 참가자들에게 “비개발자들의 유쾌한 반란”, “개발자한테도 유용했습니다”, “정말 많은 인사이트를 얻을 수 있었다” 등의 호평을 받았는데요. 아쉽게도 참석하지 못한 분들을 위해 그날의 핵심 내용을 정리해 콘텐츠로 다시 전해드립니다.

이번 글은 The 비개발자들 세미나 세 번째 주제였던 “스크린샷 주석 서비스(AnnotateShot) 개발기: Claude Code가 비개발 PM에게 준 것들”입니다. 발표 자료는 요즘IT 디스코드에서 다운로드 받을 수 있습니다.

안녕하세요, 라인플러스 PM 정덕범입니다. 오늘은 “스크린샷 주석 서비스(AnnotateShot) 개발기: Claude Code가 비개발 PM에게 준 것들”이라는 주제로 발표하게 됐습니다. 먼저 제 소개를 간단히 하자면, 저는 신문방송학을 전공하고 마케터와 서비스 매니저를 거쳐, 현재는 프로덕트 매니저로 일하고 있는 전형적인 문과생 출신 직장인입니다.

10여 년 전 안드로이드 앱 개발에 도전했다가 포기한 적도 있지만, AI를 접한 후 제 삶은 다이나믹하게 바뀌었습니다. 현재는 'AnnotateShot'이라는 이미지 주석 서비스를 직접 개발해 운영 중이며, 업무 방식 역시 AI를 통해 관리하고 있습니다. 이번 글에서는 제가 약 1년 동안 서비스를 기획하고, 6,000라인이 넘는 코드를 다루며 배포와 운영까지 경험한 이야기를 공유하고자 합니다.

불편함에서 시작된 개발의 꿈

제가 일명 ‘바이브 코딩’의 세계에 입문하게 된 건, 바로 업무 현장에서 불편함을 마주했기 때문입니다. 계기는 라인과 야후 재팬의 합병이라는 큰 변화 속에서 찾아왔습니다. 보안 정책 강화로 평소 화면 설계와 주석 달기에 쓰던 외부 피그마 플러그인 사용이 금지됐기 때문이죠.

업무상 기획 내용을 설명하기 위해선 화면 설계 이미지 위에 숫자를 매기고, 상세 정의를 적어야 하는데요. 도구가 사라지니 스크린샷을 찍어 PPT로 옮기고, 일일이 번호를 매겨 사내 위키에 테이블을 만드는 단순 반복 작업이 시작되었습니다.

더 큰 문제는 리뷰가 끝날 때마다 수정 사항이 생겼고, 번호 위치를 바꾸고 숫자를 다시 매기는 과정을 처음부터 반복해야 한다는 점이었습니다. 이 과정에서 생산성이 심각하게 떨어진다고 느꼈죠. 그래서 이 귀찮은 일을 어떻게든 자동화하고 싶다는 간절함이 저를 AI 페어 프로그래밍의 세계로 이끌었습니다.

*2024년의 일이라, 당시에는 '바이브 코딩'이란 용어가 없었습니다. 바이브 코딩은 OpenAI의 공동 창립자이자, 테슬라의 전 AI 책임자였던 안드레 카파시(Andrej Karpathy)가 2025년 2월 3일, 자신의 X에 사용하면서 처음 등장했습니다.

클로드를 만나 현실이 된 첫 번째 도구

이런 고민을 하던 차에 사내 AI 페어 프로그래밍 스터디를 통해 '클로드(Claude)'를 만나게 됐습니다. 처음에는 단순히 스크린샷에 번호를 입력하는 기능만 구현하려 했는데요. 클로드의 아티팩트 기능을 활용하니, 웹 프리뷰를 통해 결과물이 즉각 동작하는 모습이 정말 신기했습니다.

처음 요청했을 때 파이썬으로 작성된 코드를 웹 기반으로 다시 짜달라고 부탁했고, 그렇게 탄생한 것이 바로 주석 서비스인 '어노테이트 샷(AnnotateShot)'입니다. 저는 이 도구를 저 혼자 쓰는 데 그치지 않고, 사놓고 쓰지 않던 도메인을 연결해 사내 게시판과 동료 기획자들에게 공유했습니다. 그리고 피드백을 받아 서비스를 발전시켜 나갔죠.

제가 사내 게시판에 도구를 공유하자마자, 동료 기획자들로부터 뜨거운 반응과 함께 다양한 피드백이 쏟아졌습니다. 조직마다 다른 키 컬러를 고려한 주석 색상 선택 기능부터 모자이크 설정, 실행 취소(Undo/Redo), 주석 번호 크기 조절 등 실질적인 요구 사항들이 많았습니다.

저는 신이 나서 피드백을 반영하며 기능을 계속 추가해 나갔지만, 기능이 많아질수록 배포 간격은 점점 커지기 시작했습니다. 초기에는 2~3일 간격으로 빠르게 배포했으나, 코드가 길어지면서 사이드 이펙트를 관리하기가 점점 어려워졌죠. 나중에는 배포 주기가 한 달을 넘기기도 했습니다. 점차 비대해진 코드를 감당하기 힘들어지면서, 한동안 서비스를 제대로 관리하지 못한 채 방치하는 시기를 겪었습니다.

부트캠프에서 만난 클로드 코드

그렇게 정체기에 빠져있던 제게 다시 기회가 찾아온 것은 사내에서 진행한 ‘LINE AI Summer Bootcamp’를 통해서였습니다. 이 부트캠프는 직원들이 원하는 AI를 경험해 볼 수 있도록 선택해, 구독을 지원해 주는 것이었죠. 저는 동료 PM으로부터 클로드 코드(Claude Code)가 정말 좋다는 추천을 받고, 클로드 코드 사용이 가능한 프로 플랜을 선택했습니다.

그다음 클로드 코드로 가장 먼저 해본 일은 사이드 이펙트를 방지하기 위한 ‘테스트 도구’ 구축이었습니다. 로컬 환경에서 핵심 기능들을 검증할 수 있는 유닛 테스트와 자동화 테스트 시스템을 직접 만들었는데요. 50개 이상의 테스트 케이스를 구축하자, 기능을 수정할 때마다 발생하던 버그가 획기적으로 줄어들었습니다. 덕분에 개발의 안정성이 확보되었고, 크롬 익스텐션까지 영역을 확장할 수 있었죠.

팔방미인 클로드 코드와 업무 방식의 혁명

그렇게 사용해 본 클로드 코드는 그야말로 팔방미인이었습니다. 이전까지는 제가 직접 이슈 디스크립션을 작성해야 했지만, 이제는 요구 사항을 말하면 클로드 코드와 몇 번의 핑퐁 끝에 아주 훌륭한 이슈 관리가 가능해졌습니다. 커밋 메시지 역시 수동으로 작성하던 예전과 달리, 수정된 코드 기반으로 제가 놓치는 세세한 내용까지 포함해 작성해 주니 변경 이력 관리가 매우 정확해졌습니다.

4주 동안 업데이트하지 못했던 리드미(README)를 최신화하고, 한 줄에 불과했던 릴리즈 노트를 세세한 부분까지 기록해 줬습니다. 클로드 코드 덕분에 개발 속도는 이전보다 8배나 증가했고, 코드 볼륨도 비약적으로 늘어났습니다.

6,000라인의 코드 폭탄을 해체하다

하지만 8월 무렵, 즐겁게 개발하던 제게 다시 위기가 찾아왔습니다. 많은 기능을 추가했더니 메인 파일 두 개가 각각 3,000라인에 육박하며, 총 6,000라인이 넘는 '코드 폭탄' 상태가 된 것이죠. 파일이 너무 길어지자 클로드 코드조차 전체 내용을 제대로 읽지 못해, 리팩토링에 실패하는 좌절을 겪었습니다. 그렇게 약 3개월간의 공백기를 갖게 됐습니다.

그리고 몇 달 후, "클로드 코드가 그동안 많이 업데이트됐겠지."라는 믿음으로 다시 시도하자, 역시 놀라운 능력을 보여줬습니다. 같은 프롬프트였음에도 클로드 코드는 3,400라인이 넘는 코드를 500라인 이하의 논리적 모듈로 쪼개, 체계적으로 구조화해 주었죠. 이 과정을 통해 저는 AI의 발전 속도가 상상 이상으로 빠르다는 것을 다시 한번 실감했습니다.

클로드 코드로 내가 얻은 것들

우선 비개발자로서 무에서 유를 창조하는 'Zero to One'의 귀중한 경험을 얻었습니다. 이전에는 막연하게만 느껴졌던 깃허브(Github), VS Code, 그리고 터미널 활용법 등이 이제는 손에 익어, 업무 전반에 자연스럽게 녹아들었죠.

현실적인 수익에 대해서도 많은 것을 배웠습니다. 제가 만든 '어노테이트 샷'에 광고를 붙여 약 10일간 운영해 본 결과 수익은 고작 0.09달러였는데요. 이는 1년에 약 2만 원 정도인 도메인 비용조차 충당하기 힘든 수준이었습니다. 결국 지금은 광고를 모두 걷어냈고요.

또한 서비스 매각 가능성을 알아보기 위해 '에콰이어 닷컴(acquire.com)'에서 가치 산정을 받았을 때 5,000달러에서 25,000달러라는 꿈같은 금액이 나오기도 했지만, 클로드에게 비판적 분석을 요청하자 "수익 모델이 명확하지 않고, 큰 기업이 복제하기 쉬운 틈새 도구"라는 냉정한 평가를 받기도 했습니다. 이러한 과정을 통해 저는 이 서비스를 돈이 되는 사업보다는 저의 역량을 증명하는 포트폴리오로 더 큰 가치가 있다고 느꼈고, 지금도 꾸준히 관리하고 있습니다.

일하는 방식을 바꾼 AI, 나의 세컨드 브레인

무엇보다 큰 변화는 AI는 제가 일하는 방식 자체를 바꿔놓은 '세컨드 브레인'이 되었다는 점입니다. 저는 평소 "기억보다 기록"이라는 생각을 가지고 있는데요. 이제는 사내 일정, 지라(Jira) 티켓, 위키, 깃허브를 모두 클로드 코드와 연결해, 업무 로그를 아카이브하고 있습니다.

이슈가 발생했을 때 클로드와 토론하고, 의사결정 과정을 기록으로 남기는 과정은 저의 업무 효율을 극대화해 주었습니다. 다만 AI에 대한 의존도가 높다 보니, 회사 토큰 사용자가 몰릴 땐 제 생산성도 함께 느려지곤 합니다. 하지만 이 또한 AI 시대의 새로운 업무 리듬으로 받아들이고 있고요.

마치며: 새롭게 도전하기

현재 저는 어노테이트 샷을 지속적으로 개선하는 동시에, 외국인들에게 한국 이름을 지어주는 네이티브 앱을 개발해 마켓 심사를 기다리고 있습니다. AI를 통해 스스로 문제를 해결하고, 주변에 도움을 줄 수 있다는 사실이 저를 계속 움직이는 것 같습니다. 혹시 여러분도 마음속에만 담아둔 아이디어가 있다면, AI라는 기회를 통해 지금 바로 시작해 보시길 바랍니다.

Q&A

Q. 바이브 코딩을 진행하는 데 있어, 갖추고 있으면 좋은 개념이나 기본 지식이 있을까요?

저는 특정 지식보다는 호기심이 가장 중요하다고 생각해요. 호기심이 있으면 다른 지식을 쌓는 것보다 직접 행동할 가능성이 높기 때문입니다. 주변에 자극을 주는 동료가 있고 그에 따라 호기심이 발동하면, 어떻게 해결할지 스스로 찾아보게 됩니다. 따라서 사전에 알고 있는 지식보다는 클로드 같은 AI를 대면하고, 직접 해보겠다는 결심과 태도가 가장 중요하죠.

Q. 주변 PM분들도 바이브 코딩을 대부분 하고 있나요?

제 주변에는 유료 앱을 만들어 출시하거나, 직접 개발을 병행하는 동료들이 꽤 있습니다. CTO나 임원분들도 직접 회의용 도구를 만들고, 디자이너분들도 사내 공유회를 열 정도로 AI 도구를 활발히 활용합니다. 다만 기획자들의 경우 지속성 면에서는 차이가 있습니다. 시켜서 하는 게 아니라 본인이 만들고 싶은 것이 확실한 사람들은 계속 이어가지만, 그렇지 않은 경우에는 금방 멈추기도 하는 것 같습니다.

Q. MCP는 주로 어떤 것을 사용하시는지 추천 부탁드립니다.

솔직히 말씀드리면, 아직 MCP의 개념을 완벽히 체득하지 못해서 추천해 드릴 만한 것은 없습니다. 다만 저희 조직 엔지니어분들이 MCP를 사용하면, 제가 일하는 방식이 훨씬 나아질 거라고 계속 조언을 해주고 계시죠. 동료들이 MCP를 활용해 어시스턴트를 만드는 과정을 곁에서 지켜보고 있으니, 조만간 제 작업 방식에도 적용해 볼 수 있을 것 같습니다.

덧붙임)

MCP에 대한 이해가 필요하다고 판단되어, 발표를 마치고 MCP를 Claude Code와 함께 만들어봤습니다. 만들어보니 MCP가 무엇인지 어디에서 도움을 주고, 받을 수 있을지 이해할 수 있게 됐습니다. 지금 답변드린다면, 특정 전문 지식 혹은 사내 지식이 존재하는 곳의 MCP가 유용할 것이라고 판단합니다. 다만 짧은 사용 경험으로 볼 때 저의 경우, 인증이라는 아주 사소한 이유로 사내 지식 Wiki, Jira, Figma의 MCP보다 개별적인 Skill이 더 편리하게 느껴졌습니다. 정말 좋다고 판단되는 MCP를 발견하면 여러 채널을 통해 소개해 보겠습니다.