노코드 6개월 써보고 로우코드로 갈아탄 PM의 솔직 후기

작년 여름, 우리 팀은 Bubble로 신규 기능 프로토타입을 만들었다. 개발 리소스 없이 일주일 만에 작동하는 프로토타입을 만들어냈고, 나는 노코드 전도사가 될 뻔했다.

그런데 3개월 후, 같은 프로토타입을 Retool로 다시 만들고 있었다. 로딩 속도는 4배 빨라졌고, 유지보수 시간은 반으로 줄었다. 노코드에서 로우코드로의 이주. 이건 단순한 도구 교체가 아니라, PM으로서 '실행 가능성'에 대한 관점이 완전히 바뀐 경험이었다.

노코드의 약속과 현실 사이

노코드 플랫폼들은 매력적인 약속을 한다. "코드 없이 48시간 만에 MVP 론칭." 디자이너 출신으로서 드래그 앤 드롭 인터페이스는 친숙했고, 초반 속도는 정말 빨랐다.

Bubble로 만든 첫 프로토타입:

• 제작 시간: 6일
• 투입 인력: PM 1명 (나)
• 초기 피드백: 긍정적

하지만 실제 사용자 테스트를 시작하면서 문제가 보이기 시작했다.

첫 번째 벽: 성능 페이지 로딩 시간이 3-5초. 모바일에서는 더 느렸다. 사용자 50명 동시 접속 테스트에서 응답 시간이 8초까지 늘어났다. Bubble의 워크플로우 구조상 데이터베이스 쿼리 최적화에 한계가 명확했다.

두 번째 벽: 확장성 기능이 추가될수록 워크플로우가 스파게티처럼 엉켰다. 하나의 버튼 클릭에 15개의 워크플로우가 연결된 적도 있었다. 디버깅? 불가능에 가까웠다. 에러 메시지는 "Something went wrong" 뿐.

세 번째 벽: 비용 Bubble 프로페셔널 플랜: 월 $129. 여기에 플러그인, 추가 용량, API 콜 비용까지 더하니 월 $300 근처로 올라갔다. 우리가 만든 건 내부 어드민 툴이었는데, 이 비용이 정당화되지 않았다.

로우코드라는 중간 지대

로우코드는 노코드와 풀스택 개발 사이 어딘가에 있다. Retool, Airplane, Superblocks 같은 도구들. 여전히 드래그 앤 드롭이 가능하지만, 필요할 때 코드를 직접 쓸 수 있다.

PM으로서 내가 발견한 로우코드의 진짜 가치:

1. SQL을 쓸 수 있다는 것 노코드에서는 데이터 조작이 플랫폼의 논리 구조에 갇혀있다. 로우코드에서는 SQL을 직접 쓸 수 있다. 복잡한 조인, 서브쿼리, 집계 함수. PM이 데이터베이스를 직접 다룬다는 게 부담스러울 수 있지만, 기본적인 SQL만 알아도 가능성이 10배는 넓어진다.

sql -- 이런 쿼리를 노코드에서 구현하려면 5-6개 워크플로우 필요 SELECT u.name, COUNT(o.id) as order_count FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.created_at > NOW() - INTERVAL '30 days' GROUP BY u.name

2. API 통합의 자유도 Bubble에서 외부 API 연결은 플러그인에 의존하거나, API Connector로 복잡한 설정을 해야 했다. Retool에서는 JavaScript로 fetch 함수를 바로 쓴다. 인증, 에러 핸들링, 재시도 로직까지 직접 컨트롤.

3. 버전 관리가 가능하다 노코드의 가장 큰 문제 중 하나가 히스토리 관리였다. "어제까지 되던 게 왜 안 되지?"의 연속. 로우코드 도구들은 대부분 Git 통합을 지원한다. 변경 이력 추적, 롤백, 브랜치. 개발자들이 당연하게 쓰는 이 기능이 PM에게도 얼마나 중요한지 뼈저리게 느꼈다.

실패에서 배운 선택 기준

6개월간의 시행착오 끝에 정리한 내 기준:

노코드를 선택하는 경우

• 프로젝트 수명: 2주 이내
  진짜 일회성 이벤트 페이지, 간단한 설문조사, 개념 검증용 목업

• 사용자 수: 50명 미만
  내부 팀 테스트, 소규모 베타 테스트

• 복잡도: 화면 10개 이내, 데이터 테이블 5개 이내
  이걸 넘어가면 관리 불가능 지점이 온다

로우코드를 선택하는 경우

• 프로젝트 수명: 3개월 이상
  지속적으로 개선하고 유지보수할 도구

• 데이터 작업이 핵심
  대시보드, 어드민 패널, 내부 툴

• 팀에 SQL 가능한 사람 최소 1명
  PM인 내가 그 1명이 됐다. Udemy 강의 20시간 투자의 가치

아예 개발팀에 맡기는 경우

• 외부 고객 대상 제품
  브랜드 경험이 중요하면 노코드/로우코드 둘 다 부적합

• 초당 100+ API 요청
  성능이 비즈니스 크리티컬하면 선택지가 없다

• 복잡한 상태 관리
  실시간 협업, 멀티플레이어 인터랙션 같은 건 아직 한계

PM이 코드를 배워야 하는가?

이 질문을 많이 받는다. 내 대답은 "배워야 한다"가 아니라 "배울 수 있다"다.

SQL을 배운 후 달라진 것:

• 개발자와의 커뮤니케이션 시간 40% 감소
• 데이터 분석 요청 건수 80% 감소 (직접 하니까)
• 기능 스펙 작성 시간 50% 감소 (실제 구현 가능성 이해)

디자이너 출신으로서 처음엔 겁났다. 터미널, SQL, JavaScript. 하지만 로우코드 도구들은 학습 곡선이 완만하다. 복사-붙여넣기로 시작해서, ChatGPT에게 물어보고, 점진적으로 이해의 폭을 넓혀갔다.

지금도 나는 "개발자"가 아니다. 그럴 필요도 없다. 하지만 간단한 쿼리 짜고, API 문서 읽고, 에러 로그 해석할 수 있는 PM. 그게 스타트업에서 내 시장 가치를 2배로 만들었다.

실전 가이드: 로우코드로 첫 프로젝트 시작하기

구체적으로 어떻게 시작할까? 내가 밟은 단계:

1주차: SQL 기초 (하루 1시간)

• Khan Academy SQL 코스 완료
• SELECT, WHERE, JOIN, GROUP BY만 확실히
• 회사 데이터베이스에 읽기 권한 요청해서 직접 쿼리 연습

2주차: 도구 선택과 튜토리얼

• Retool 무료 플랜으로 시작 (내부 툴 무제한 무료)
• 공식 튜토리얼 3개 따라하기
• 샘플 프로젝트 템플릿 뜯어보기

3주차: 진짜 문제 하나 골라서 만들기 나의 첫 프로젝트: "주간 지표 대시보드"

• 이전: 매주 월요일 SQL 쿼리 돌려서 슬랙에 복붙
• 이후: Retool 대시보드에서 실시간 확인
• 제작 시간: 4시간
• 절약 시간: 주당 30분

4주차: 피드백과 개선

• 팀원들에게 공유
• 불편한 점 수집
• 하나씩 개선하며 학습

실패 포인트 주의:

• 첫 프로젝트를 너무 크게 잡지 마라. 나는 CRM 만들려다가 2주 날렸다.
• 완벽주의 버려라. 80% 작동하면 배포하고 개선하라.
• 개발자에게 코드 리뷰 부탁하라. 내 SQL 쿼리의 30%는 비효율적이었다.

2024년, PM의 무기는 무엇인가

노코드냐 로우코드냐는 사실 이분법이 아니다. 중요한 건 문제에 맞는 도구를 선택하는 판단력.

AI 시대에 PM의 역할이 흔들린다는 말이 많다. ChatGPT가 PRD 쓰고, Midjourney가 목업 만들고, Copilot이 코드 짠다. 그래서 더욱 중요해진 건 직접 실행하는 능력이다.

디자이너 출신 PM으로서 내가 가진 강점:

• 사용자 경험을 직관적으로 이해
• 비주얼 도구에 익숙함
• 완벽한 것보다 작동하는 것의 가치를 앎

여기에 로우코드 도구를 더하니, 아이디어에서 프로토타입까지의 거리가 극적으로 줄어들었다. 기획서 10페이지보다 작동하는 프로토타입 1개가 설득력 있다는 걸 몸으로 배웠다.

당신이 PM이라면:
다음 주 월요일, 1시간 투자해서 Retool이나 Airplane 무료 플랜 가입하고 튜토리얼 하나 따라해보라. SQL 기초 강의 하나 결제하라. 실패해도 잃는 건 시간뿐이고, 성공하면 얻는 건 새로운 슈퍼파워다.

당신이 창업자라면:
PM 채용 시 "로우코드 경험"을 우대 조건에 넣어라. 개발 리소스는 제품 코어에 집중시키고, 내부 툴과 프로토타입은 PM이 직접 만들게 하라. 우리 팀은 이렇게 개발 속도를 30% 올렸다.

노코드 vs 로우코드 논쟁은 끝났다. 이제는 둘 다 쓸 줄 아는 PM과 그렇지 않은 PM의 격차가 벌어지는 시대다. 당신은 어느 쪽인가?