Share
Sign In
블로그 ✍️
월간 ProductHunt - 2023년 6월
Kidow
👍👍🏼
6
안녕하세요, 오늘은 새로운 플랫폼에서 인사드리게 되었네요.
오늘은 새 플랫폼으로 이사를 오게 된 이야기를 다루어 보려고 합니다.
2월부터 시작한 이 프로젝트가 어느새 500개가 넘는 제품을 사람들에게 전달하게 되었습니다.
처음엔 메일리로 시작을 했다가 개인 웹사이트로 이전을 했는데, 처음으로 슬랙과 노션 API를 통해 외부로 데이터를 전달하는 프로젝트를 하다 보니 엉성한 부분이 있었고 이를 다 바꾸고 새로 시작해야 하나 말아야 하나를 되게 고민을 많이 했습니다. 어떤 문제가 있었고 어떻게 바꾸었는지 얘기해보겠습니다.
신규 유입 및 SEO 문제
첫 번째로 가장 큰 문제는 유입이 없었다는 것이었습니다.
초창기 홍보 당시 사람들이 가입했던 것 이후로는 새로운 유저가 아예 들어오질 않았습니다. 그 이유로 저는 SEO를 들었는데요,
저는 이 프로젝트를 시작할 당시에 긱뉴스의 영향을 많이 받았습니다. 긱뉴스는 오래 운영되었기 때문에 유저가 많은 부분도 있지만 웹사이트 내에 링크가 있기 때문에 검색 엔진에 노출되면서 새로운 유저들이 계속해서 유입이 될 수 있는 구조인데, 저는 슬랙으로만 콘텐츠를 보내기 때문에 새로운 유저들이 들어올 수가 없었던 겁니다.
그래서 저도 콘텐츠 SEO를 하려고 했는데, 저는 보낸 데이터를 따로 데이터베이스에 저장하기 싫어서 노션 데이터베이스에 저장했기 때문에, 노션 API를 이용해서 콘텐츠를 가져오는 방식을 택해야 했습니다.
노션 데이터베이스
노션 데이터베이스로 SEO를 하는 것은 이론상 가능은 합니다. 한 번 저장한 콘텐츠는 변하지 않기 때문에 Next.js의 정적 페이지 증분 생성을 적용하면 계속해서 API를 호출할 필요는 없거든요.
그런데 여기서 문제가 생깁니다. 기존 데이터베이스는 칼럼이 이름과 태그, 생성일 뿐인데, 노션 API로 데이터를 호출하면 아래처럼 가져오게 됩니다.
{ "object": "page", "id": "2f4a8dac-6d53-470b-991c-318e02cffacf", "created_time": "2023-06-22T04:17:00.000Z", "last_edited_time": "2023-06-22T04:17:00.000Z", "created_by": { "object": "user", "id": "dd4638ca-074d-4454-b367-57d73acc5cb4" }, "last_edited_by": { "object": "user", "id": "dd4638ca-074d-4454-b367-57d73acc5cb4" }, "cover": null, "icon": null, "parent": { "type": "database_id", "database_id": "[DATABASE_ID]" }, "archived": false, "properties": { "태그": { "id": "OrwY", "type": "multi_select", "multi_select": [ { "id": "77153172-fdb8-41b5-87c2-cb7ac1d768d4", "name": "Productivity", "color": "brown" }, { "id": "92b186fb-82e0-4e5e-be1e-80b5b29fb249", "name": "Freelance", "color": "green" }, { "id": "d766ea4f-d05e-45c6-99ad-fd9963d2d49e", "name": "SaaS", "color": "red" } ] }, "생성 일시": { "id": "~QPX", "type": "created_time", "created_time": "2023-06-22T04:17:00.000Z" }, "이름": { "id": "title", "type": "title", "title": [ { "type": "text", "text": { "content": "CheckYa - 프리랜서 및 크리에이터를 위한 올인원 도구", "link": null }, "annotations": { "bold": false, "italic": false, "strikethrough": false, "underline": false, "code": false, "color": "default" }, "plain_text": "CheckYa - 프리랜서 및 크리에이터를 위한 올인원 도구", "href": null } ] } }, "url": "https://www.notion.so/CheckYa-2f4a8dac6d53470b991c318e02cffacf", "public_url": "https://kidow.notion.site/CheckYa-2f4a8dac6d53470b991c318e02cffacf" }
위 JSON 응답 값을 보시면, 이름과 태그, 생성 일시의 데이터만 가져올 뿐 페이지 안에 적은 내용을 가져오지 못합니다. 처음 저장 방식을 잘 못 선택한 바람에 SEO를 할 수가 없는 참사가 나버린 것이죠. 따라서 저장한 데이터를 전부 가져올 수 있는 방식으로 완전히 변경해야 했습니다. URL, 한 줄 소개 등의 데이터를 전부 속성값으로 전환하는 방식으로요.
앱 통합 방식 문제
두 번째로 답답했던 문제는 슬랙과 노션 연동 방식이었습니다. 슬랙은 Incoming Webhook 방식, 노션은 템플릿없이 연동하고 있었는데, 둘 다 비효율적입니다. 처음엔 몰랐지만 지금은 이렇게 할 필요가 업었습니다.
슬랙의 Incoming Webhook 방식은 특정 채널이나 개인 DM에 초점을 맞추고 메시지를 보내는 방식인데, 일반 채널과 DM 채널이 가져오는 로직도 다르고, 처음이다 보니 그것도 몰라서 알아내느라고 시간을 무지하게 잡아먹었습니다.
인커밍 방식을 사용하지 않으면 다음과 같이 앱의 메시지 탭에서 메시지를 수신할 수 있습니다. 인커밍 방식과 똑같이 채팅 및 스레드를 달 수 있기 때문에 더 명확하고 간단합니다. (이걸 몰라서 시간 낭비를 했습니다...)
노션의 경우는 위에서 언급했던 것처럼 데이터베이스 칼럼 구조도 변경했지만 연동 과정에서 사전 정의된 템플릿을 제공할 수가 있습니다. (이것도 처음에 몰랐습니다.)
노션 페이지에서 공유 - 게시 - 템플릿 복제 허용을 체크하고 링크를 복사한 뒤
Notion API 통합에서 Notion 템플릿 URL을 넣으면
연동 과정에서 개발자가 제공한 템플릿을 복제할 수 있습니다.
이렇게 하면 유저에게 직접 데이터베이스를 구성하도록 하지 않아도 됩니다.
소통 문제
마지막으로 소통이 불가능한 구조입니다. 이메일을 포함한 개인 정보를 받지 않고 운영하는 방식이 유저의 부담을 덜 수 있어서 좋다고 처음엔 생각했었는데, 이메일까지 받지 않고 운영하다보니 그냥 콘텐츠를 보내기만 하고 돌아오는 호응이 아무 것도 없는 느낌이라 뭔가 잘못되었다는 생각이 들더라구요. 최소한 이메일은 받아야하는구나라는 것을 비로소 느꼈습니다.
이걸 어떻게 바꿔야할까라는 생각을 많이 했습니다. 새로 바꾸는 프로젝트에서는 최소한 오픈된 소통 창구가 필요했거든요.
그러다가 프로덕트헌트에서 발견했던 제품이 바로 이 슬래시페이지였습니다. 채널과 페이지 두 가지로 한 번에 웹사이트를 구성할 수 있는 이 제품은 꽤 창의적이었습니다. 한 마디로 노션과 슬랙이 합쳐진 모습같았죠.
무려 1000개가 넘는 업보트를 받은 화제의 프로젝트
커뮤니티와 블로그를 같이 구성할 수 있는 이 프로젝트를 알게 되고 나서 새롭게 재단장할 필요성을 확실하게 느꼈습니다. 이 프로덕트를 몰랐으면 아마 개고생했을 겁니다. 역시나 프로덕트헌트를 자주 들여다 봐야하는 이유겠죠? 🤗
지금까지 읽어주셔서 감사합니다.
Subscribe to 'daily-producthunt'
Welcome to 'daily-producthunt'!
By subscribing to my site, you'll be the first to receive notifications and emails about the latest updates, including new posts.
Join SlashPage and subscribe to 'daily-producthunt'!
Subscribe
👍👍🏼
6
Other posts in '블로그 ✍️'See all
Kidow
월간 ProductHunt - 2023년 8월
오랜만입니다! 벌써 한 달이 지났군요. 이번 달은 상당히 무더웠습니다. 저는 피부가 많이 타버렸네요. 😂 월간 ProductHunt도 이제 반 년이 지나 6번째를 맞이했습니다. 한 달에 한 번뿐인데도 무슨 주제를 해야할 지 항상 고민이 되네요. ㅎㅎ 이번 달 주제는 반 년간 소개했던 모든 제품들 중에서 제가 실제로 유용하게 사용하고 있는 제품들을 소개해 볼까합니다. 지금까지 소개한 700개 이상의 제품들 중에서 추렸습니다. 1. floo.app floo는 이미지 포맷을 다른 포맷으로 빠르게 변환시켜 주는 무료 웹 서비스입니다. WebAssembly 기반으로 만들어졌다고 하는데요, 무제한, 무료로 사용할 수 있고 광고도 달려있지 않으며, 직관적인 ui 덕분에 필요할 때마다 유용하게 사용하고 있답니다. 😝 svg, heif, heic, avif, webp, jpg, png, pdf를 jpeg, png, webp, avif로 변환할 수 있습니다. 2. Internxt Internxt가 제공하는 무료 임시 이메일 기능은 이메일 가입 관련 테스트를 하거나 익명으로 특정 서비스에 가입이 필요할 때 유용하게 사용될 수 있습니다. 저같은 경우는 일간 ProductHunt에 소개할 제품을 테스트해보기 위해 주로 사용합니다. 3. DevGPT 개발자를 위한 ChatGPT입니다. ChatGPT와 UI는 거의 유사하지만 코드 생성이나 디버깅 등 개발자 친화적인 기능들이 추가되어 있습니다. 저는 초창기 ChatGPT가 트래픽이 몰려 느려졌을 때 대신 유용하게 사용했습니다. 무료로도 ChatGPT처럼 무제한 채팅 가능하기 때문에 관심있으시면 써보시기 바랍니다. 4. Tailkits TailwindCSS로 개발하는 저에게 많은 영감을 주었던 웹 서비스입니다. Tailwind와 연관된 모든 리소스를 모아놓은 곳인데요, 템플릿, 디자인, 컴포넌트 등을 무료 혹은 유료로 제공하는 제품들을 한데 모아 소개하고 있습니다. 5. Storytale 무료로 사용 가능한 이쁜 수천 개의 3D 애셋과 일러스트레이션을 제공해주는 웹 서비스입니다. 6. Recraft AI 프롬프트로 벡터 아트를 생성할 수 있는 웹 서비스입니다. 무료로도 무제한 생성이 가능하고, 생각보다 많은 스타일을 제공하면서 성능도 좋기 때문에 맞춤형 이미지를 생성할 때 가끔씩 사용합니다. 다만 프롬프트를 잘 짤 수 있는 창작 능력이 필요합니다... 그래도 100% 무료는 엄청난 혜택인 것 같습니다. 7. Slashpage 바로 지금 글을 쓰고 있는 이 웹 서비스입니다. 저는 노션과 디스코드를 합쳐 놓은 듯한 느낌을 받았는데요, 운영자 입장에서 사용자들과 소통할 수 있는 채널을 만들 수 있고, 그 외에도 업데이트 사항, 블로그 등을 만들어 외부에 공개할 수 있습니다. 기존에는 이런 것들을 직접 구축했는데 저에게는 정말 반가운 서비스였습니다. 앞으로 어떤 성장을 보여줄 지 많은 기대와 응원을 하고 있습니다. 👍 8. Icon Buddy
👍
2
Kidow
월간 ProductHunt - 2023년 7월
그동안 잘 지내셨나요? 무더위와 장마가 반복되면서 저도 적응하기가 쉽지가 않았습니다. 7월에는 서드파티로 돈을 버는 프로덕트에 대해 이야기를 나눠보려고 합니다. 어떤 서드파티 프로덕트 종류들이 있고 어떤 프로덕트들이 ProductHunt에 올라왔었는지 한 번 알아보는 시간을 가져봅시다. 서드파티(Thrid Party)란 서드파티는 일반적으로 '제 3자'라는 용어를 의미하지만 IT 업계에서는 기존 플랫폼과 호환되는 부분 파생 제품을 의미합니다. 플랫폼이 제공하는 기능을 통해 새로운 제품을 만드는 것이죠. 일반적으로 SaaS에서 통합을 지원하는 제품까지 서드파티라고 하진 않습니다. 왜냐하면 그런 제품들은 자신들만의 메인 기능이 따로 있고, 통합을 지원한다는 것은 편의를 위해 호환성을 제공하는 것이기 때문에 서드파티랑은 다르죠. 서드파티로 프로덕트를 만들면 이미 구축된 플랫폼 위에서 제품을 만들기 때문에 새로 플랫폼을 구축해야 하는 번거로움이 없어지고 플랫폼이 선점한 고객에 대한 우월한 접근성을 가질 수 있다는 장점이 있습니다. 물론 단점도 있습니다. 해당 플랫폼에 종속되기 때문에 그 바운더리를 넘어서 제품을 확장하기가 힘들다는 점이 있는데요, 예를 들어 제품에 신기능을 추가하고 싶은데 해당 플랫폼에서 내가 필요한 기능을 제공하지 않는다면 구현할 수가 없게 되는 겁니다. Slack 앱 협업 메신저로 유명한 슬랙에는 '앱'이라는 이름의 서드파티를 만들 수 있습니다. 대표적으로 지금 제가 운영하는 일간 ProductHunt가 있겠죠? 협업 메신저라는 특징을 이용해 협업과 관련된, 혹은 정기적으로 메시지를 전달하는 등의 제품을 만들 수 있겠죠. 이 외에도 다양한 슬랙 서드파티 앱이 있습니다. 1v1 for Slack ChatGPT를 통해 회의 예약 과정을 단순화할 수 있는 Slack 앱입니다. 슬랙에서는 회의를 예약하는 기능이 없지만, 셀렉트박스를 통해 일정을 선택하게 한 뒤 내부 API를 활용하여 슬랙 안에서 팀원과 회의를 예약할 수 있도록 구현한 겁니다. Felix 슬랙 내부에서 AI를 사용해서 메시지를 다시 쓸 수 있습니다. 톤을 선택하고 맞춤법 및 문법 검사 여부를 체크하면 미리 보기 메시지를 반환하는 형식입니다. Notion 앱
👍🏼
1
Kidow
슬랙 연동 과정에서 생긴 이슈
안녕하세요, 일간 ProductHunt입니다. 프로젝트를 새단장하는 과정에서 슬랙 연동 방식을 새롭게 바꾸었는데요, 테스트 때 잘되서 괜찮은 줄 알았는데, 알고 보니 제가 오해했던 부분이 있어서 일부 유저들 분들이 제대로 작동하지 않았고 해결하느라 시간을 너무 잡아먹어버리고 말았네요. 이 글에서는 어떤 이슈가 있었고 어떻게 해결했는지 다뤄보고자 합니다. 원래 의도했던 것 원래 의도했던 방식은 위처럼 앱의 메시지 탭을 통해 콘텐츠를 전달하는 방식이었습니다. 이 방식을 통하면 유저에게 채널을 선택할 부담을 주지 않기 때문에 더 간편하고 직관적이라고 생각했거든요. 무언가 잘못 됐다는 걸 알기 까지는요... Incoming Webhook 슬랙 API는 Incoming Webhook이라는 기능이 있습니다. 간단하게 말하면 Webhook URL을 생성하는 것인데요, 이 기능은 기본적으로 비활성화되어 있습니다. 이 기능을 활성화하면 기존처럼 유저가 연동 시 특정 채널을 선택해야 하고, 활성화하지 않으면 채널을 선택하지 않고 연동하게 됩니다. 왜 기존에 하던 Incoming Webhook 방식을 버리고 위와 같은 방식을 따라하려고 했느냐, 크게 별다른 이유는 없었습니다. 이런 방식으로 하는 앱도 있는 것을 보고 나니 이 방식이 더 편해 보였거든요. 이 프로젝트로 테스트해보고 싶은 것도 있긴 했습니다. 좀 더 알아보고 했으면 좋았을 텐데 아쉽긴 합니다. 그렇다면 이제 무슨 실수를 했는지 좀 얘기를 해보려고 합니다. 여러분들은 슬랙 연동할 때 이런 실수를 하지 않기를 바랍니다. 슬랙 URL 규칙 슬랙의 URL은 일종의 규칙이 있습니다. URL의 파라미터 앞글자를 따서 각각의 id를 URL에 표현하는 방식이죠. 위의 hay에서도 볼 수 있듯이 슬랙의 워크스페이스에는 채널, 다이렉트 메시지, 그리고 앱이 있습니다. 채널 페이지에는 Channel ID가, 다이렉트 메시지 페이지에는 DM ID가 할당이 되죠. 그럼 여기서 앱은 무엇에 할당이 되느냐, 바로 DM ID에 할당이 됩니다.