사이드 프로젝트 6개를 만들며 얻고 잃은 것

개요

---

나는 지금 회사에서 개발자로 일하고 있다. 그리고 퇴근 후에는 사이드 프로젝트 여섯 개를 만들고, 운영하고, 고치고 있다.

• 1D1S
• Rutsubo-Plus
• Laiteu
• HIARC-Platform
• DayLane
• Pangea

 물론 여섯 개에 같은 비중으로 매달리고 있다는 뜻은 아니다. 출시해 운영하는 것도 있고, 유지보수만 하는 것도 있고, 잠시 손을 놓은 것도 있으며, 아직 만드는 중인 것도 있다.

 

 솔직히 이 중에서 잘됐다고 말할 만한 것은 딱히 없다. 잘 만들었는지 못 만들었는지를 평가받기 이전에, 일단 세상에 내놓고 굴려봤다는 정도다.

 

 그런데 이름을 한 줄씩 나열해놓고 보니 나도 좀 이상하긴 하다. 하나만 제대로 해도 벅찰 텐데 여섯 개라니. 스몰토크에서 이 이야기가 나오면 퇴근 후에 잠은 자냐는 질문을 종종 받는다.

 

 이 글에서 하고 싶은 이야기는 "이렇게 많이 했다"가 아니다. 많이 하는게 좋은 것도 자랑도 아니다. 좋은 성과가 있어야 자랑이 되고 좋은게 되는거지 '많이'만 하는건 의미가 없다. 이번에 내가 이야기를 하고 싶은건 여섯 개를 만들고 굴리면서 내가 무엇을 얻고, 무엇을 잃었는지에 대한 이야기다. 사이드 프로젝트를 이만큼 했으면 개발 실력이 많이 늘었을 것 같지만, 돌아보면 늘어난 것은 개발 지식보다는 기획이나 PM 쪽 역량에 가까웠다. 반대로 코드를 짜는 감각과 배우는 즐거움은 전보다 흐릿해졌다.

 

 

지금 굴리고 있는 것들

---

 여섯 개가 각각 어떤 상태인지부터 간단히 정리해보면 이렇다. 1D1S, Rutsubo-Plus, Laiteu는 출시한 서비스다. HIARC-Platform은 동아리 내부에서 사용 중이고, DayLane은 내가 쓰기 위해 만들었다가 스토어에 올린 앱이다. Pangea는 지금 만들고 있다.

 

1D1S(1Day 1Streak)

 1D1S는 거의 3년을 붙잡고 있던 서비스다. 2023년에 운영하던 동아리를 서비스로 만들고 싶다는 생각에서 시작했는데, 처음 2년 동안은 사실상 만들어진 것이 없었다. 마지막 1년 동안 몰아치듯 개발했고, 웹으로 먼저 출시한 뒤 앱까지 내놓았다.

 

 출시 과정에서 겪은 시행착오는 1D1S를 출시하며에 길게 적어두었다. 자세한 내용이 궁금한 사람을 위한 참고용이고, 이 글을 이해하는 데 꼭 필요한 내용은 아니다.

 

Rutsubo-Plus

 Rutsubo-Plus는 해외에서 일본 출판만화에 도전하는 지망생을 위한 멘토링 서비스다. 외국인 신분으로 일본에서 먼저 데뷔한 선배 작가들이 멘토가 되어 정보와 트렌드, 일본어 표현, 편집자와의 소통, 작품 피드백 등을 일대일로 다룬다. 나는 만화를 그리는 사람이 아니다. 그래서 이 서비스는 내가 가진 문제를 풀기보다, 다른 사람의 운영 방식을 서비스로 옮기는 작업에 가까웠다.

 

Laiteu

 Laiteu는 웹 콘텐츠 창작자를 위한 서비스다. 이름인 "라이트"에는 빛(LIGHT), 권리(RIGHT), 쓰다(WRITE)라는 뜻이 함께 담겨 있다. 내 아이디어로 시작한 서비스는 아니고, 나는 프론트엔드 개발로 참여했다. 지금은 개발에서 잠시 빠져 있다. 잠깐 쉬어가는 시간 정도다.

 

HIARC-Platform

 예전에 몸담았던 동아리에서 시작한 프로젝트다. 지금은 전면 리팩터링을 거쳐 동아리에서 실제로 사용하고 있다. 기존에 의존하던 백준 연동을 걷어내고 리니어솔브라는 새로운 서비스를 붙이는 작업도 했다. 새로 만드는 것보다 이미 있는 것을 뜯어고치는 쪽이라 다른 프로젝트들과는 성격이 조금 다르다.

 

DayLane

 상업화하거나 사용자를 모으려고 만든 것은 아니다. 그냥 내가 편하게 쓰려고 만든 투두 앱이다. 기존 투두 앱들을 쓰면서 늘 조금씩 아쉬웠는데, 그 부분을 내 방식대로 채워 넣었다. 만들고 나니 기존 앱들과 약간의 차별점은 있는 것 같아서 스토어에도 올렸다.

 

 나부터 잘 사용하고 있다. 불편하거나 거슬리는 부분이 생기면 적어뒀다가 퇴근 후에 바로바로 고친다. 내 입맛대로 만들다 보니 만족도는 이 앱이 가장 높다. 사실상 애플 생태계와 개발자 계정을 내 편의를 위해 쓰는 느낌이긴 하다. 그래도 1년에 13만 원가량을 내는데 이 정도는 해도 되지 않나 싶다.

 

Pangea

 사이드 프로젝트들을 좀 더 잘 굴려보려고 만들기 시작한 도구다. 레포를 등록해두면 프로젝트의 화면, API, 데이터 흐름, 문서, 이슈를 한곳에서 볼 수 있게 하는 것이 목표다. 사이드 프로젝트를 굴리기 위한 사이드 프로젝트라니 조금 웃기긴 하다. 왜 이런 것을 만들게 됐는지는 뒤에서 이야기하겠다.

 

 

어떻게 6개나 굴릴 수 있었나

---

 여섯 개나 굴리고 있지만 수익은 없다. 현재 신분상 겸업을 할 수 없기 때문이다. 광고도 못 붙이고 구독제도 못 한다. 오히려 서버비를 비롯해 나가는 돈이 더 많다.

 

"그럼 이걸 왜 하는 거야?"

 

 솔직히 거창한 이유는 없다. 프로덕트 만드는 게 재밌다. 자기만족도 있고, 언젠가는 수익으로 이어지지 않을까 하는 기대도 조금 있다. 하지만 가장 큰 원동력은 머릿속에 있던 것이 실제로 굴러가는 모습을 보는 재미다. 이 감각에 관해서는 초등학생 때 노트 게임 만들던 감각으로에 따로 적어두었다.

 

 물론 재미만으로 여섯 개를 굴릴 수는 없다. 예전에는 아이디어가 생기면 사람부터 모았다.

 

"이런 서비스 아이디어가 있는데 같이 할 사람?"

 

 문제는 사람 자체라기보다, 당시의 내가 팀을 꾸리고 운영하는 방법을 잘 몰랐다는 데 있었다. 서로의 실력과 역할, 기대치와 일정을 충분히 맞추기도 전에 프로젝트부터 시작했다. 그러다 보니 개발과 상관없는 문제로 프로젝트가 망가지거나 흐지부지 끝나는 경우가 많았다. 아이디어는 우유 같아서 너무 쉽게 상한다.

 

 AI가 이 구조를 바꿔놓았다. 적어도 내 의지만 있으면 프로젝트는 계속 진행된다. 누군가의 일정을 기다릴 필요도 없고, 기획 의도를 매번 처음부터 설득할 필요도 없다. 구현 속도도 비교가 안 된다.

 

 HIARC-Platform 리팩터링에서는 혼자 했다면 두 달쯤 잡았을 범위의 초벌 작업을 하루 안에 끝냈다. 물론 그 뒤로 검증하고 다듬는 시간이 더 필요했지만, 출발선 자체가 달라졌다. 기본 화면의 완성도도 내가 처음부터 직접 만들었을 때보다 높았다. 자세한 과정은 블랙박스로 굴러가는 서비스를 운영할 수 있을까에 적어두었다.

 

 1D1S도 AI가 없었다면 세상에 나오지 못했을 것이다. 첫 번째이자 가장 큰 고비인 '출시'를 넘기 쉬워지면서, 그 뒤로 더 많은 프로덕트를 만들 수 있게 됐다. 여섯 개라는 숫자는 그렇게 나왔다.

 

 

내가 하는 일이 바뀌었다

---

 AI가 구현을 맡으면서 내가 하는 일도 달라졌다. 돌아보면 여섯 개 중 처음부터 끝까지 코드를 직접 짠 것은 두 개 정도뿐이다. 그마저도 요즘은 코드를 잘 안 본다. 그럼 나머지 시간에는 무엇을 했을까.

 

무엇을 만들지 정확히 전달하는 일

 가장 많은 시간을 쓴 것은 기획을 전달하는 일이었다. AI와 일하면 무엇을 만들고 싶은지 얼마나 정확하게 전달하느냐가 결과물을 좌우한다. 중의적인 표현을 쓰면 작업 품질이 눈에 띄게 떨어진다.

 

 일부 개발자 커뮤니티에서는 생각 없이 AI에게 지시를 전달하고, 나온 결과물을 다시 옮기기만 하는 사람을 'meat proxy'라고 비꼬기도 한다. 그게 사람이 맡아야 할 역할이냐고 묻는다면 나 역시 아니라고 생각한다. 그래서 최대한 내가 먼저 판단하고, 어떻게 말해야 오해 없이 정확히 전달할 수 있을지를 고민한다.

 

 문제는 일부러 모호하게 말하는 사람은 없다는 것이다. 나도 모르게 중의적이거나 모호한 표현을 쓴다. 어휘가 부족해 원하는 것을 100퍼센트 표현하지 못할 때도 있다.

 

 디자인도 마찬가지였다. AI가 만든 결과물에서 어색한 요소를 하나하나 집어내 없앤 서비스는 반응이 좋았고, 그러지 못한 서비스는 'AI 티가 난다'는 말을 들었다. 결국 무엇이 맞고 무엇이 틀린지 판단하고, 그 판단을 정확한 말로 옮기는 일은 내 몫이었다.

 

 독서를 더 해야겠다고 느낀 것도 이때다. 말을 잘한다는 것은 단지 어휘가 많은 것이 아니라, 내가 원하는 것이 무엇인지 먼저 분명하게 생각하고 구조화할 수 있다는 뜻에 가까웠다.

 

만든 것을 검증하는 일

 다음은 QA였다. 만들어진 결과물이 의도대로 돌아가는지 점검하고, 기획 자체에 빠진 조건은 없는지 계속 확인했다. AI가 만든 결과물은 대부분 그럴듯하다. 그래서 오히려 더 꼼꼼히 봐야 한다.

 

 결과물을 그대로 블랙박스로 받아들이지 않으려면 최소한 어디를 의심해야 하는지는 알고 있어야 했다. 코드 한 줄 한 줄을 직접 쓰지는 않더라도, 잘못된 결과를 알아보고 책임질 수 있는 능력은 여전히 필요했다.

 

여러 개를 동시에 굴리는 일

 마지막은 운영이었다. 만들기가 쉬워지니 운영해야 할 것이 많아졌다. 출시한 서비스가 여러 개가 되니 유저 문의와 버그 대응에만 시간을 꽤 빼앗긴다. 물론 사용자가 많지는 않지만, 하나하나는 작은 문제여도 여러 서비스에서 동시에 들어오면 이야기가 달라진다. 만드는 시간보다 대응하는 시간이 더 긴 날도 생긴다.

 

 수익도 없으면서 회사를 운영한다고 말하는 게 조금 우습기는 하다. 그래도 실제로 하는 일을 보면 아주 작은 회사를 운영하는 것과 크게 다르지 않다. 무엇을 만들지 정하고, 일정을 조율하고, 문의와 장애에 대응하고, 배포 이후까지 책임진다.

 

 그래서 운영 플로우를 만드는 데 시간을 많이 썼다. 이슈를 모으고, 재현하고, 원인을 찾고, 배포하고, 다시 확인하는 과정이 매번 수작업이면 프로젝트 수만큼 시간이 늘어난다. 프로젝트별 일정을 정리하고 반복 작업을 줄일 도구를 계속 만들었다. Pangea도 이 과정에서 나왔다.

 

 다만 완전한 자동화 플로우를 만들지는 않았다. 지금은 HITL, 즉 AI의 작업에 사람이 개입해 확인하고 승인하는 방식이 더 중요하다고 본다. AI가 문제를 분류하고 해결안을 내는 것까지는 괜찮다. 하지만 실제 유저에게 영향을 주는 판단은 사람이 한 번 더 봐야 한다.

 

 정리하면 이렇다. 무엇을 만들지 정하고, 정확히 전달하고, 결과물을 검증하고, 일정을 조율하고, 운영 플로우를 만든다. 이것은 개발자의 일이라기보다 PM이나 기획자의 일에 가깝다.

 

그 대가

---

그 과정에서 개발자로서 잃은 것도 적지 않다.

 

코드를 짜는 감각

 프로덕트를 세상에 내놓는 능력은 늘었다. 하지만 코드를 짜는 감각은 오히려 무뎌졌다는 느낌이 든다. 구체적인 코드와 원리는 잘 기억나지 않고, 해결 방향만 지나치게 추상적인 형태로 남아 있다.

 

"대충 이런 식으로 고치면 되는데…"

 

 딱 이 정도만 떠오른다. 막상 코드를 치려고 하면 손이 멈춘다.

 

 예전에는 문제가 생기면 공식 문서를 보고, 에러 메시지를 읽고, 비슷한 사례를 찾아보고, 이것저것 바꿔보면서 해결했다. 지금은 일단 AI에게 물어본다. 엄청 효율적이다. 그런데 해설지를 너무 빨리 펼쳐보는 느낌이다.

 

 답을 보면 문제는 풀린다. 하지만 다음에 비슷한 문제가 나왔을 때 혼자 풀 수 있느냐는 또 다른 이야기다. AI 없이 코드를 짜라고 해도 아예 못 짜는 것은 아니다. 다만 AI를 쓰기 전의 나보다도 더 오래 걸릴 것 같다.

 

 

배우는 즐거움

 더 아쉬운 것은 배움의 즐거움이다.

 

 42서울을 할 때는 배우고, 만들고, 시연하는 과정 자체가 즐거웠다. 세 번째 디펜스에서 떨어져 처음부터 다시 해야 했을 때는 정말 고역이었다. 그래도 배우고 있다는 감각만은 분명했다. 그곳에서 겪은 고통은 성장 과정에서 치르는 통증처럼 느껴졌다.

 

 앱 개발자로 일할 때도 그랬다. 디자인 시스템과 아키텍처를 고민하고, 재사용성을 끌어올리고, 성능을 최적화할 때 보람을 느꼈다. 정교하게 만든 구조 위에서 피처와 모듈이 손쉽게 붙는 모습을 볼 때는 정말 뿌듯했다.

 

 최근에는 AI의 도움 없이 일주일째 풀리지 않던 문제의 원인을 직접 찾아낸 적이 있다. 오랜만에 “내가 직접 해결했다”는 감각이 들었다. 신기한 것은 그 기쁨이 AI와 함께 기능 하나를 빠르게 완성했을 때보다 훨씬 컸다는 점이다.

 

 내가 좋아했던 개발의 재미는 결과물을 보는 재미만이 아니었던 것 같다. 모르던 것을 이해하고, 막힌 원인을 찾아내고, 내 손으로 해결하는 과정이 꽤 큰 비중을 차지하고 있었다.

 

 그런데 그런 순간은 이제 거의 없다. 큰 작업을 끝내도 내가 한 것이 아니라 AI가 한 것 같다는 생각이 든다. 가끔은 PM이 내 자리에 앉아 AI에게 직접 명령해도 똑같은 결과가 나오지 않을까 싶다.

 

 아직은 코드를 볼 줄 아는 능력 덕분에 잘못된 결과를 판단하고, 배포를 결정하고, 그 결과를 책임질 수 있다. 하지만 AI가 조금 더 발전해 코드를 딱히 보지 않고도 배포할 수 있는 경지에 이르면 나는 무엇을 하는 사람이 될까. 더 빠르게 명령하고 더 빠르게 책임지는 것만으로 충분한가. 솔직히 잘 모르겠다.

 

 이 지점에서 만드는 재미와 배우는 재미가 서로 다르다는 것을 깨달았다. 만드는 재미는 결과 중심이다. 화면이 나오고, 기능이 붙고, 배포가 된다. 반응이 빠르고 눈에 보인다.

 

 반면 배우는 재미는 느리다. 개념을 붙잡고, 실패하고, 다시 읽고, 직접 부딪혀야 겨우 찾아온다. AI 덕분에 만드는 재미는 커졌지만 배우는 재미는 많이 줄었다. 개발뿐만 아니라 전반적인 학습 습관도 무너졌다. 꾸준히 무언가를 하고는 있지만, 그것이 개발자로서의 나를 성장시키는 일은 아니었다.

 

 

마치며

---

 사이드 프로젝트 여섯 개를 만들고 굴리면서 늘어난 것은 개발 지식이 아니었다. 무엇을 만들지 정하고, 그것을 정확히 전달하고, 결과물을 판단하고, 여러 프로젝트가 계속 굴러가게 만드는 능력이었다. 개발자보다는 PM에 가까운 역량이다. 그리고 그것을 얻는 동안 코드를 짜는 감각과 배우는 즐거움을 조금씩 내줬다.

 

 이게 좋은 거래였는지는 아직 잘 모르겠다. 개발자로 성장하고 싶었던 입장에서는 씁쓸하다. 반대로 혼자서 서비스를 끝까지 끌고 가는 데 필요한 능력이 무엇인지 배웠다고 보면 꽤 값진 시간이기도 하다.

 

 그래도 당분간은 계속 만들 것 같다. 머릿속에 있던 것이 세상에 나오는 재미는 여전히 크다. 다만 이제는 개수를 늘리기보다, 내준 것을 조금은 되찾는 데 시간을 쓰려고 한다.

 

 가끔은 AI에게 넘기지 않고 직접 디버깅하고, 직접 문서를 읽는 시간을 일부러 남겨둘 생각이다. 그렇지 않으면 어느 순간 나는 문제를 해결하는 사람이 아니라 답을 전달받는 사람이 되어 있을지도 모른다.