낭만코딩
1.4K posts

낭만코딩
@romantic_coding
남의 서비스 만들다 내 제품 만드는 중 | 1인 개발 · Build in Public · 실경험 공유



GitHub just launched an Agentic AI Developer certification (GH-600) Covers multi-agent orchestration, guardrails & production AI workflows. this is the credential for devs who supervise AI agents, not just use them → learn.github.com/certification/…

바이브코딩은 정말 강력합니다. 근데 프로젝트 규모가 커질수록 결국 사람의 검수가 다시 중요해지더라고요. AI가 코드 대부분을 만들기 시작하면서 오히려 '어디를 검수해야 하는가' 가 더 중요해졌습니다. CLAUDE.md, AGENTS.md, Codex rule 같은 걸 잘 작성해도 프로젝트가 커지면 결국 룰은 조금씩 무너지기 시작합니다. > boundary 깨지고 > 순환참조 생기고 > dead code 쌓이고 > 컨벤션 drift 나고 구조가 서서히 오염됩니다. 프로젝트 규모가 커질수록 AI가 만든 코드를 전부 읽는 건 현실적으로 불가능하더라고요. 그래서 저는 IDE 대신, 빠르게 구조를 분석하고 취약 지점을 찾는 툴을 직접 만들어 쓰고 있습니다. > 터미널에서 바로 작업하고 > 코드베이스 구조/UML 확인하고 > boundary rule, coding convention, dead code, cycle, diff 추적하고 > PR 리뷰와 GitHub 상태까지 한 화면에서 봅니다. AI 코드 검수에 최적화된, 터미널 기반 workspace에 가까운 툴입니다. 특히 새 프로젝트 온보딩이나, 직접 디버깅해야 하는 순간에 코드를 훨씬 빠르게 손에 쥘 수 있더라고요. 특히 아이패드에서 개발하다 보니 기존 터미널 앱들의 한계도 많아서 하드웨어 키보드와 터치 workflow까지 직접 맞춰 만들고 있습니다ㅎㅎ 모바일로 개발하시는 분들에게는 꽤 도움이 되실거라 생각합니다. 아직 정식 공개 전이지만, 정리되면 더 공유해보겠습니다. #buildinpublic #shellscope















This is how I got 1M users in 6 months Finally dropping it! It's 60 pages lol tally.so/r/BzZpA4 If you repost & follow, I'll send you some extra sauce🌶️


이 사업의 지속 가능성에 대한 글을 봤습니다. 처음부터 리텐션 구조로 만들지 않은 이유, 저도 고민을 많이 했었거든요. 근데 결론은 현실적으로 안 맞다는 거였습니다. 1인 창업가에게 생존은 결국 현금이잖아요. 플랫폼은 수익이 나기까지 너무 오래 걸리더라고요. 그 사이에 런웨이가 바닥나면 할 수 있는 게 없어지니까요. 그래서 저는 핵심 기능 하나를 빠르게 만들어서, 1회성이라도 돈을 받고 반응이 오면 그걸 진화시키는 게 더 현실적이라고 판단했습니다. 실제로 토스도 그렇게 시작했던 걸로 알고 있어요. 웹페이지 하나에 무료 송금 기능 하나. 그마저도 사람이 하루 12시간씩 수동으로 송금해주는 방식이었다고 하더라고요. 그래서 저는 제 서비스가 래퍼인지 아닌지는 지금 단계에선 크게 신경 안 쓰고 있습니다. 돈을 쓰는 사람이 있고 트래픽이 몰리면, 피봇할 기회는 만들 수 있거든요. 그리고 그 피봇이 진짜 실력이 되는 거라고 생각해요. #buildinpublic #유나스튜디오



요새 바이브 코딩 관련 눈팅을 하다보면 개발자분들이 열받을만한 포인트가 많이 보이긴 해서 이 주제에 대한 날선 반응이 이해는 가는 것 같다.(사실 나도 좀 긁힘) 특히 백엔드쪽에서 이런게 많은 것 같은데, 사실 나는 서버 기능이 있는 월구독 등의 SaaS는 백엔드 지식없이 존속 자체가 불가능하다고 생각한다. 추후 AI가 좋아져서 가능해질 수도 있지만 진짜로 단호하게 지금은 아예 배우지 않고는 서비스 자체가 성립이 되지 않는다고 생각한다. 보통 이제 백엔드쪽도 뭐 구현이 잘 되고, mcp로도 잘 연결해서 하면 되고 다 된다 이런식으로 이야기하는 바이브코더들이 있는데 구현이라는 가치에서는 뭐 그럴수도 있다고 생각한다. 하지만 내가 오프라인 기능만 있는 앱 등 서버가 없는 앱이 아닌 이상에야 구현은 서비스의 10% 정도 비중이라고 생각한다. 이 백엔드 인프라를 문제없이 계속 업데이트하면서도 사용자의 데이터 손실이나 장애 없이 운영하는것이 실제로 백엔드쪽의 핵심이라고 생각한다. 그냥 간단하게 월 500만원 정도를 목표로 만들고 싶다고 쳐보면, 한 2만원 정도 월 구독료를 받았을 때 최소 250명의 유료 고객이 있을거고, 아래 문제에 대해서 백엔드 지식 없이 이 문제가 생겼을 때 어떻게 해결할거고 이 상황이 되면 어떨 것 같은지를 생각해보면 좋을 것 같다. (오래 서비스하다보면 이런것들이 한번씩 찾아옴) 1. 디비 데이터가 갑자기 다 날아갔음 2. 업데이트하다가 특정 테이블의 컬럼이 통째로 없어짐 3. 업데이트 하지도 않았는데 서버가 갑자기 접속 안되기 시작함. 재배포해도 똑같음 4. vercel, cloudflare가 갑자기 미안합니다 우리 장애났어요. 빨리 복구할게요라고 메일옴 위 상황들이면 서비스가 전혀 안될테니 문의가 폭주하기 시작하고 구독해지가 폭증하고 있는 상황일 것이다. 이중에서 3번정도는 그래도 내가 로그가 뭔지라도 안다면, 로그 등을 AI에게 주면서 고쳐봐 할 수 있지만 서버 운영을 하다보면 1,2번 같은 내가 미리 조치해놓지 않으면 비가역적인 상황이 정말 많이 발생한다. 이건 opus 4.7이 아니고 opus 99.9가 와도 못돌려준다 인정할건 인정해야하는게 개발 지식 없어도 서버+클라이언트가 갖춰진 서비스를 어찌어찌 만들 수는 있다. 솔직히 비개발자가 여기까지 할 수 있다는 것 자체가 엄청난 일이라고 생각한다. 근데 실제로 live 서비스는 그렇게 호락호락 하지 않다. 애초에 개발자 중에서도 맡은 역할에 따라서 이 실제 운영 서비스 경험이 아예 없는 경우도 많다. live 서비스를 운영하다보면 진짜 세상이 나한테 왜그러나 싶을정도의 어이없는 억까상황이 많이 발생한다. 갑자기 AWS전체장애가 나지 않나, 내가 쓰는 region이 지진,화재,정전 나서 접속이 안되질 않나, 코드 실수로 잘못집어넣어서 데이터가 싹 없어지질 않나 휴먼에러를 포함해 자연재해까지 동반되는게 라이브서비스다. 그리고 이런 것에 대한 대비를 유연하게 미리미리 해두고, 대비한 것에서 벗어나는 상황은 순발력으로 거의 차력쇼에 가깝게 해결해내는게 백엔드 엔지니어링의 큰 가치 중 하나라고 생각한다. 내가 추천하는 방향은 매번 똑같다. 처음부터 백엔드 공부해서 개발자가 되라는건 아니다. 바이브코딩이건 해서 혼자 제품을 만들어보고 시장 검증을 해보되, 만약 서버와 db가 있어야 돌아가는 서비스고 진지하게 이걸로 수익을 낼만한 각이 보이면 (결제가 발생하거나 사용자들의 관심이 폭증하거나) 백엔드 개발을 제대로 배우거나, 백엔드 지식이 있는 사람과 협업하기 시작해야한다. 고용이건 파트타임이건 외주건 ps) 무서운 사실: 개인정보 유출, 보안 공격, API악용 관련은 언급조차 안했음.



