낭만코딩

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

[낭만코딩 @romantic_coding]

https://t.co/dkPsjj5z6r

[낭만코딩 @romantic_coding]

1인 개발하면서 광고 소재 어떻게 만들어야 할지 감이 안 잡히신다면 "메타 광고 라이브러리(Meta Ad Library)" 확인해보세요
https://t.co/F0OsRHgs4T

광고하고 싶은 키워드를 검색하면 지금 메타에서 그 키워드로 돌고 있는 광고가 다 나옵니다.

> 경쟁사들이 어떤 소재로 어떻게 광고하고 있는지 확인 가능
> 해당 키워드로 얼마나 많은 광고가 있는지 확인 가능 (경쟁률)
> 광고 디자인 레퍼런스도 그대로 참고 가능
> 1인 개발자 입장에서 광고 소재 제작 시간을 크게 줄일 수 있음

경쟁사들이 어느 정도 퀄리티로 광고를 만들고 있는지 가늠하기 좋습니다.

업계 1위가 어떻게 하고 있는지 제대로 보고 싶다면, 광고 라이브러리보다 그 회사 인스타 계정을 들여다보는 게 더 낫습니다.

정리하면:
> 경쟁사 광고 퀄리티 파악 → Meta Ad Library
> 업계 1위 트레이싱 → 1위 SNS 계정

[크롱 @Krongggggg]

GitHub가 멀티 에이전트 오케스트레이션과 프로덕션 워크플로우 관리를 검증하는 Agentic AI Developer(GH-600) 자격증을 출시함. 단순히 툴을 쓰는 걸 넘어 에이전트 가드레일 설정과 운영 병목을 통제하는 시니어급 아키텍처 역량을 요구하는 분위기임. 에이전트 기반 파이프라인 설계할 때 커리큘럼 참고용으로 저장해둘 만함.

[낭만코딩 @romantic_coding]

안녕하세요 어제 공유드린 shellscope 후속입니다.

shellscope는 단순한 터미널 앱이 아니라, 하네스 엔지니어링 관점에서 AI 코드 검수에 최적화된 워크스페이스에 가깝습니다.

내부적으로는 tree-sitter 기반 코드 분석, layer/boundary rule과 coding convention 검사, 그리고 SSH 터미널 권한 위에 구현된 GitHub 통합(PR/CI/Actions)으로 동작합니다.

이 룰들은 워크스페이스의 .shellscope 폴더에 md 파일로 정리되어, 하네스 엔지니어링 설계를 돕습니다.

나아가 그 규칙들을 사람이 쉽게 검수할 수 있게 GUI로 제공합니다.

AI에 모든 것을 맡기지 않고, 사람이 끝까지 끈을 쥐고 있어야 한다는 관점에서 설계했습니다.

지원 언어는 다음과 같습니다.

Dart·TypeScript·JavaScript·Java·Kotlin·Swift·C++·C#·Objective-C·Rust·Go·Python

현재 각 언어 분석 정확도 QA 진행 중입니다.

먼저 모바일(iOS/Android) 출시를 시작으로, 이후 Windows / Linux / macOS 데스크탑까지 확장 예정입니다.

가까운 시일 내에 제품으로 인사드리겠습니다.

#buildinpublic #shellscope

[낭만코딩 @romantic_coding]

바이브코딩은 정말 강력합니다.

근데 프로젝트 규모가 커질수록
결국 사람의 검수가 다시 중요해지더라고요.

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

[낭만코딩 @romantic_coding]

@HypedotStudio 주제넘다니요.. 진심어린 조언 감사드립니다. 안그래도 리디자인 후에 추가로 상품 구성이라던지 개선 방안에 대해 고민중에 있었습니다. 피벗을 하더라도 가져갈 기능 이기도 해서요.
말씀해주신내용 참고해서 더 발전시켜보겠습니다 감사합니다

[낭만코딩 @romantic_coding]

개인적으로 OpenAI image2 충격이 좀 큽니다

저희는 컨셉이나 업로드된 사진을 보고 상황에 따라 Image API를 1~3회 정도 호출해 생성합니다.

매 스텝마다 100~300원씩 비용이 들어서, 한 장 만드는 데 비용이 꽤 나가게 되죠

그런데 이젠 ChatGPT에서 '해줘' 한 마디면 비슷한 퀄리티의 사진이 바로 나옵니다.

그것도 무료로요

무서운건 image2 나오는 시점에 인스타에 OpenAI 광고가 깔리고
인플루언서들이 'ChatGPT에서만 되는 프롬프트'라고 하면서 공유하기 시작했어요

인플루언서들이 자기들 혼자 움직였겠냐 싶더라고요

도매업자가 진지하게 소매업까지 끼어들고 마케팅까지 팔 걷어부친 격이죠

자기들은 돈 받아가면서 무료라니, 너무 하단 생각도 들었습니다

아무튼, 이미지 생성 아이템 하나만으로는 이제 답이 없다고 보고 있습니다

이제는 정말 사용자 데이터나 +α가 더해져야 지속 가능한 아이템이 된다고 봅니다.

예를 들면 스노우 같은 케이스가 있어요. OpenCV랑 자체 딥러닝 모델로 실시간 필터·보정 해주고, 영상까지 제작됩니다. AI 컨텐츠가 밈 유행 선도하는 식으로 지속되고, 구독제로 주기적으로 사용하는 비즈니스가 되죠.

또 다른 케이스는 영유아 플랫폼입니다. 아이 데이터가 있으니 락인 효과가 대단하거든요. AI 사진은 제공하지만 주 수익은 아니고, 가족 공유·성장 기록·성장 앨범 구독제가 본진입니다.

저는 이런 상황이 오기전에 최대한 트래픽을 모으고 피봇하자라는 전략이었어요. 개인적으로 이런 상황이 1년 뒤에나 올 줄 알았거든요

이미지 생성은 컴퓨팅 파워가 많이 들어서 무료로 풀진 않을 거라고 봤습니다.

제가 AI 발전속도를 얕잡아 봤던 것 같습니다.

아마 다음 분기에 신규 모델 나오고, 그다음 분기에 또 새로운 게 나오고 하다 보면 정말 의미가 없어질 거라 봅니다.

물론 이런 앱들을 다량으로 찍어내면 당장 돈이 되지 않을까 싶기도합니다

실제로 유나스튜디오도 광고 0인 상태에서 매일 결제가 들어오고 있거든요

하지만 앞서 말했듯 지속가능하지 않다고 판단을 했고, 카테고리만 바꿔 서비스를 복붙해 출시하진 않을 것 같습니다.

이런 상황을 몰랐던것도 아니고 당장 현금 흐름이 중요해 시작한 아이템이고, 결과적으로 성과도 있었습니다.

그러나 좀 더 지속 가능한 아이템을 만들기 위해 서비스 성격을 바꿔 앱으로 전환할 예정입니다

피봇은 AI + α + 리텐션 나오는 구조로 방향을 잡을 계획입니다.

#buildinpublic #유나스튜디오

[낭만코딩 @romantic_coding]

@masan_aje 아 참고로 OpenAI가 밈을 유행시킨다는건, 인플루언서들이 동시다발적으로 움직인것 보고 생각한 제 추측입니다 ㅎㅎ

[낭만코딩 @romantic_coding]

인사이트 감사드립니다.

하네스 잘 깎으면 해자가 될 수도 있다고 보긴 합니다.
저도 그 방향으로 고민을 많이 했었거든요

다만 그 하네스 자체에도 사실 비용이 들고, ChatGPT도 image2 한 번 호출로 끝나는 게 아니라 여러 워크플로우를 거쳐서 생성하는 걸로 보고 있구요.

핵심은 단건 API 호출 비용이 아니라, ChatGPT가 여러 번 API 호출(image2 포함)로 퀄리티 상당한 이미지를 무료로 제공한다는 점인 것 같습니다.

저희가 그런 워크플로우를 똑같이 짜려고 해도 수익 타산이 안 맞아서 경쟁이 쉽지 않더라고요. (무료 vs 유료)

당장은 사용자들이 ChatGPT 활용을 못하니 수요가 남아 있지만 OpenAI는 마케팅도 적극적이고 컨텐츠를 밈으로 유행시키면서 사용 허들을 빠르게 낮추고 있어 보입니다.

[낭만코딩 @romantic_coding]

@appstitcher 네 맞아요 ㅎㅎ기업들에게는 가장 비싼 API로 제공하면서 ChatGPT로 공짜로 풀어버리니 멘붕이 왔었습니다

[낭만코딩 @romantic_coding]

네. 이미지 합성 기술은 더 낫다고 봅니다.

나노바나나는 합성이라기 보다 원본 특징을 최대한 유지하면서 다시 생성하는 방식으로 판단하고 있습니다. 그러다 보니 원본과 다른 사람의 얼굴이 나오곤 해요.

그런데 image2는 원본을 있는 그대로 잘 유지해요. 이 부분이 이전 모델들의 한계였는데, image2에서 극복한거라 보고 있습니다.

[낭만코딩 @romantic_coding]

특히 한글 지원이 제대로 되는 터미널 앱이 없더라구요. 터미널 기능 자체만 보더라도 충분히 편리함을 느끼실 수 있을 것 같습니다.

[낭만코딩 @romantic_coding]

바이브코딩은 정말 강력합니다.

근데 프로젝트 규모가 커질수록
결국 사람의 검수가 다시 중요해지더라고요.

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

[낭만코딩 @romantic_coding]

@dalgom_bami 와 대단한걸 만드셨네요....! 당장 프리랜서 하시는 분들은 굳이 한국시장에 있을 필요가 있나싶네요 ㅎㅎ Upwork 도전해도 좋겠는데요

[낭만코딩 @romantic_coding]

@dalgom_bami 오.. 공유해주셔서 감사합니다. 요청했는데 내용이 기대되네요 ㅎㅎ

[dalgom.bami @dalgom_bami]

와 진짜 이건 인용을 안할 수가 없네요.

AI 뷰티 앱 Glam Up을 6개월 만에 100만 유저 + $150K MRR까지 키운 과정을 케이스 스터디 형식으로 정리한 글인데 그냥 논문 수준이고 실제로 논문 포맷입니다.

광고비, 펀딩, 기존 팔로워 없이 한 성장인 점에서 배울게 정말 많네요. 열심히 파먹어봐야겠습니다.

tally에서 응답하면 바로 pdf 다운로드 됩니다.

[낭만코딩 @romantic_coding]

광고 새 소재 만들면 첫 며칠은 ROAS 잘 나오다가
갑자기 뚝 떨어지는 거, 경험해보신 분 많을 겁니다.

저도 예전엔 그냥 소재 피로도라고 생각했거든요.

그래서 새 소재 또 만들고, 또 만들고…
계속 쳇바퀴 돌리고 있었습니다ㅎㅎ

근데 이번에 광고 전면 중단하고
2주 동안 리디자인해보니까 다른 게 보이더라고요.

광고는 며칠 지나면 알고리즘이 점점 콜드 유저 쪽으로 도달 범위를 넓힙니다.

첫 1~2일은 관심군(웜) 위주라 ROAS가 잘 나오는데,
그 이후부터는 콜드 비중이 커지면서 성과가 떨어지는 거였어요.

근데 진짜 문제는 콜드 유저가 들어왔을 때 UI가 그 사람들을 못 잡고 있었다는 거였습니다.

기존 UI는 스토리텔링 중심이었거든요.

페인포인트 공감 > 우리 서비스 가치 > 결과물 소개 순.
약간 Apple 스타일 narrative 느낌입니다.
웜 유저한테는 끝까지 잘 통했어요.

근데 콜드 유저는 그 과정 들어가기 전에 대부분 이탈하더라고요.

리디자인하면서 시장 1등 앱들 UI를 한참 봤는데, 다들 첫 화면에서 결과물·가격·CTA를 3초 안에 박고 있었습니다.

우리만 다른 길 가고 있었던 거죠. 그래서 UI를 콜드 유저 기준으로 처음부터 다시 그렸고, 광고는 전부 끊었습니다.

근데 신기하게도, 인스타 릴스 자연 유입만으로 초기 결제 건수에 가까운 수준이 다시 돌아오기 시작하더라고요.

소재를 영원히 갈아끼우는 쳇바퀴보다, UI를 콜드 기준으로 한 번 고치면 광고 수명 자체가 늘어납니다.

#buildinpublic #유나스튜디오

[낭만코딩 @romantic_coding]

한 달 전쯤 𝕏에 이런 글을 썼습니다.

그리고 그 피봇 기회는 생각보다 훨씬 빨리 왔습니다.

ChatGPT image 2가 나온 순간, 유료 API에 100~300원 쓰고, 1,900원에 판매하던 유나스튜디오 같은 서비스는 그냥 끝난 게임이 됐거든요.

기존 1등이던 제미나이는 영유아 사진 생성이 제한적이였고, 사진 합성 방식에 한계가 있어서 원하는 결과물을 만들려면 별도 워크플로우 설계가 필요했습니다.

근데 image2는 그냥 “해줘” 한 마디면 됩니다.

출시 직후에는 영유아·강아지 12표정 스티커가 카톡 프로필을 도배하고, 인플루언서들이 “프롬프트 공유” 글 올리면서 너도나도 프사로 걸기 시작했어요.

진짜 제2의 지브리 사태 느낌이더라고요.

그래서 광고는 전부 끄고, 2주 동안 리디자인하면서 그동안 유나스튜디오와 인스타에 쌓아둔 영유아 트래픽을 그대로 살려 영유아 플랫폼으로 피봇 준비하고 있습니다.

그 사이에 바이브 코딩 개발 도구도 하나 더 깎고 있었고요.

𝕏 잠수 20일 만이네요ㅎㅎ

자세한 건 글로 정리해보겠습니다.

#buildinpublic #유나스튜디오

[낭만코딩 @romantic_coding]

이 사업의 지속 가능성에 대한 글을 봤습니다.

처음부터 리텐션 구조로 만들지 않은 이유, 저도 고민을 많이 했었거든요. 근데 결론은 현실적으로 안 맞다는 거였습니다.

1인 창업가에게 생존은 결국 현금이잖아요. 플랫폼은 수익이 나기까지 너무 오래 걸리더라고요. 그 사이에 런웨이가 바닥나면 할 수 있는 게 없어지니까요.

그래서 저는 핵심 기능 하나를 빠르게 만들어서, 1회성이라도 돈을 받고 반응이 오면 그걸 진화시키는 게 더 현실적이라고 판단했습니다.

실제로 토스도 그렇게 시작했던 걸로 알고 있어요. 웹페이지 하나에 무료 송금 기능 하나. 그마저도 사람이 하루 12시간씩 수동으로 송금해주는 방식이었다고 하더라고요.

그래서 저는 제 서비스가 래퍼인지 아닌지는 지금 단계에선 크게 신경 안 쓰고 있습니다.

돈을 쓰는 사람이 있고 트래픽이 몰리면, 피봇할 기회는 만들 수 있거든요. 그리고 그 피봇이 진짜 실력이 되는 거라고 생각해요.

#buildinpublic #유나스튜디오

[낭만코딩 @romantic_coding]

@supernovajunn 저는 코덱스 쓰고 있습니다 ㅎㅎ

[낭만코딩 @romantic_coding]

요즘 OpenClaw, Hermes 하루 1~2시간씩 벌고 있습니다

단순히 코딩을 대신 시키는 게 아니라, 이슈 모니터링에 반복적으로 쓰이던 시간을 줄이고 있습니다.

지난주에는 회원가입 이슈를 3일 동안 놓치면서 매출과 유입이 모두 0이 되는 구간이 있었거든요ㅎㅎ

그 일을 겪고 나서 프로세스를 바로 손봤습니다.

> dev / prod 서버 분리
> dev QA 추가
> 모니터링 시스템 구축

그리고 그 위에 OpenClaw와 Hermes를 얹었습니다.

기본 시스템이 슬랙으로 오류를 리포트하면,
에이전트가 주기적으로 이를 읽고 GitHub 이슈를 생성합니다.

또 다른 에이전트는 보고된 단순 버그를 기준으로 수정 작업을 진행한 뒤, 제게 코드리뷰를 요청하는 흐름입니다.

아직 AI에게 복잡한 개발을 100% 맡기기는 어렵다고 생각합니다.

대신 반복적이고 범위가 비교적 명확한 버그 수정은 곧 잘합니다.

결국 중요한건 모든 문제를 직접 처리하는 게 아니라, 저만 할 수 있는 판단과 우선순위에 더 많은 시간을 쓰도록 시스템을 고쳐 나가는게 중요하다 생각합니다.

#buildinpublic #유나스튜디오

[낭만코딩 @romantic_coding]

개인적으로 많이 공감됩니다.

저도 바이브 코딩으로 뭘 만들었다는 글들을 자주 보는데, 그게 실제로 돈이 돌고 운영까지 이어지는 서비스인지에 따라 이야기의 무게가 꽤 다르게 느껴질 때가 많습니다.

저도 새 기능이나 확장 방향에 대한 생각은 늘 많이 합니다

근데 막상 돈이 움직이고 서비스를 실제로 운영해야 하는 단계로 가면, 결국 먼저 붙잡게 되는 건 새 기능보다 인프라와 안정화더라고요ㅎㅎ

기술이 곧바로 돈이 되는 게 아니라는 것도 저는 MVP 이후에 더 크게 느꼈습니다.

생각보다 기능은 거의 못 늘렸는데도 서비스는 소소하게나마 계속 돈을 벌고 있거든요.

결국 차이는 기능보다 광고 소재, 전환, ROAS를 집요하게 개선하는 과정에서 나왔습니다.

돈을 버는 건 기능 하나를 더 만드는 일보다,
누가 왜 결제하는지 끝까지 붙잡고 개선하는 일에 더 가깝더라고요.

[dalgom.bami @dalgom_bami]

요새 바이브 코딩 관련 눈팅을 하다보면 개발자분들이 열받을만한 포인트가 많이 보이긴 해서 이 주제에 대한 날선 반응이 이해는 가는 것 같다.(사실 나도 좀 긁힘)

특히 백엔드쪽에서 이런게 많은 것 같은데, 사실 나는 서버 기능이 있는 월구독 등의 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악용 관련은 언급조차 안했음.

[낭만코딩 @romantic_coding]

@HypedotStudio 감사합니다 ㅎㅎ 말씀하신 상황은 글로만봐도 아찔하네요,,,, 저도 생각보다 DAU가 빠르게 올라와서.. 기능이나 서비스 확장은 미루고 안정화에 집중하게 되더라구요

[낭만코딩 @romantic_coding]

지난주 3일간 장애를 놓치면서 대략 50만원 정도의 손실을 본 것 같습니다

이제 서비스 장애는 그냥 에러가 아니라 곧바로 금전적인 손실로 이어지더라고요.

그러다 보니 요즘 더 자주 드는 생각이 있습니다.

AI를 써서 빨라지는 건 분명한데, 그 결과에 대한 책임은 결국 아무도 대신 져주지 않는다는 것이요 ㅎㅎ

그동안은 IDE 없이 CLI만으로 바이브 코딩을 많이 해왔습니다.

속도는 정말 잘 나왔거든요.

근데 최근엔 다시 IDE를 켰습니다. 코드 리뷰도 다시 넣기 시작했고요.

근데 예전처럼 라인 바이 라인으로 보는 게 아니라,

시스템의 병목이 어디인지,
흐름에 모순은 없는지,
아키텍처가 향후 발목을 잡진 않을지,

그런 쪽을 더 보게 됩니다.

AI가 생산성을 많이 올려주는 건 맞는데, 최소한의 끈은 사람 손에 쥐고 있어야겠더라고요.

특히 돈이 돌기 시작한 서비스라면 더더욱이요 ㅠㅠ