스프레드시트가 곧 시스템이었습니다.

저는 Row입니다. 2025년에 ManyRows를 시작했고, 투자 없이 자비로 혼자 만들고 운영하고 있습니다.

ManyRows라는 이름은 데이터의 행(row), 즉 표 안에 나열되는 여러 줄을 가리킵니다. 제품이 실제로 다루는 것이 바로 그것이기 때문입니다. 하지만 이 이름이 진짜로 뜻하는 것은 관계형 구조, 즉 하나가 여럿과 맺는 관계입니다: 부모와 그 구성 요소들, 스타일과 그 컬러웨이들, 주문과 그 사이즈들처럼요. 이 일대다 관계는 스프레드시트가 붙들고 있지 못하는 부분이며, 그것을 붙드는 일이 PLM이 존재하는 이유의 대부분입니다. 덧붙이자면 제 이름도 Row이고, 스키마 설계부터 결제 연동, 고객 지원, 지금 이 문장까지 전부 저 혼자 하고 있습니다.

이전에는 몇 년 동안 콘텐츠 플랫폼과 앱 빌더를 만들었습니다. 덕분에 가장 어려운 부분은 이미 갖고 있었습니다: 의류든 배합이든 기계 가공 부품이든, 무너지지 않고 휘어지는 데이터 모델입니다.

그런 엔진이 있으면 당연히 또 다른 범용 앱 빌더를 만들고 싶어질 법합니다. 저는 그러고 싶지 않았습니다. 그런 도구는 이미 많고, 데모는 하나같이 근사하지만, 제가 실제로 지켜본 팀이 겪던 어려움에는 그중 무엇도 도움이 되지 않았을 겁니다. 그 팀의 일은 한 번도 “행 몇 개 저장하기”였던 적이 없고, 언제나 “공장이 어떤 리비전으로 만들었고, 누가 승인했는가”였기 때문입니다. 무엇이든 모델링할 수 있는 도구는 변경 관리와 리비전, BOM을 결국 스스로 발명하게 만들 뿐이고, 그것이 일의 전부입니다.

그래서 이것은 근사한 인터페이스를 가진 데이터베이스가 아니라 PLM입니다. 타입과 필드는 직접 정의하지만, 그 아래에서 동작하는 엔진은 다단계 BOM이 무엇인지, 그레이딩이 있는 사이즈 스펙이 무엇인지, 두 사람이 같은 레코드를 동시에 편집할 때 변경 요청이 무엇을 보장해야 하는지를 이미 알고 있습니다. 하나의 문제를 제대로 푸는 것이, 모든 문제를 얕게 푸는 것보다 값어치가 있었습니다.

이것은 방향을 찾고 있는 사이드 프로젝트가 아니라, 유료 요금제를 가진 실제 제품입니다. 동시에 솔직히 작습니다. 둘 다 사실이며, 두 가지를 함께 놓고 판단해 주시기 바랍니다.