솔루션 vs 서비스

사용자에게 제공할 수 있는 아이템들의 목록을 보이고 선택한 아이템을 소유하는 기능. SaaS 비즈니스의 대표적인 UX일 듯. 이런 기능을 쉽게 구현할 수 있는 제품을 준비 중이다. 이런 구현이 어려운 것은 아니므로 고객은 개발자가 아닌 서비스를 구축하려는 사람이 될 것이다.

이 제품이 유용할지를 검증하기 위해 개밥먹기 차원의 서비스를 운영할 생각이다. 서비스가 성공적이라면 솔루션도 쓸만하다고 생각해볼 수 있다. 이 지점에서 떠오르는 질문은 솔루션에 집중할 것인가, 서비스에 집중할 것인가다.

답은 둘 다 중요하다, 다. 솔루션은 나중에 판매도 생각해 볼 수 있지만 우선은 포폴 역할로 시작됐다. 그리고 개밥먹기 차원의 서비스들은 거창한 것이 아니고 초기에 고객이 없으므로 시작된 것이다. 서비스가 솔루션이 유효한지를 증명한다는 점에서 중요하긴 하지만 서비스에 집중하느라 솔루션이라는 목표가 사라지면 안 되겠다.

이에 더하여, 솔루션은 서비스가 발전하는 양상에 따라 재사용 가능한 코드 패키지 형태가 아닌 boilerplate 형태로 남을 수도 있다. 서비스에 적용한 개밥먹기와 마찬가지로 솔루션의 발전도 테스트 드리븐으로 쓸모에 집중할 것이다. 이러니 솔루션은 솔루션이라 부르기 애매한 결과물이 될 수도 있다.

결론은 테스트를 한다는 것이고 반응이 오는 것에 집중하겠다는 것이다.

위 내용을 작성하고 boilerplate code를 판매하는 것이 가능할지 찾아봤는데 인디해커스의 문서가 나온다. 댓글에 Laravel Spark에 대한 내용도 나온다. 내가 자주 이용하는 IH, Laravel이라 조금 깜놀이긴한데, 아무튼,

• Boilerplate를 판매 가능한지 고민하는 사람이 역시 있다는 점
• 스팍을 boilerplate로 보는 관점

두 가지가 흥미롭다.

댓글들을 보니 대충 HTML+CSS 같은 코드는 테마라고 부르는 것처럼 앱 로직을 판매하는 것에 boilerplate라는 이름을 사용한다. 사용자가 코드를 열어서 자기 입맛에 맞게 수정해서 써야하는 경우에 해당한다.

워드프레스 플러그인도 코드를 사는 것처럼 보이지만 사용자가 코드를 읽고 쓰는 것을 가정한 제품이 아니므로 boilerplate가 아니다.

패키지와는 어떻게 다를까 생각을 해봤는데 제공한 코드를 있는 그대로 쓰거나 아니면 간단한 설정만 바꿔서 사용하는 것은 패키지, 반쯤 구현되어 있거나 어떤 예를 가정하여 만들어진 코드를 오버라이드해서 바꿔 쓸 수 있게 제공하는 경우라면 boilerplate가 되는 듯.