Show HN: Struct – 피드 중심의 채팅 플랫폼

 (struct.ai)
1P by GN⁺ | ★ favorite | 댓글 1개

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • “내 주목을 받을 만한 것”을 골라준다는 도구는 많았지만, 본인이나 팀에는 제대로 맞은 적이 없었음. Struct는 뭐가 다른지 궁금함
    Struct 랜딩 페이지 영상을 보며 적은 질문들: 채널이 스레드/피드의 출발점처럼 보이는데 단순히 사용자를 묶는 개념인지, 채널에서 채팅도 가능한지 궁금함. 실시간 피드에 보이는 스레드만 사용자가 보게 되는 구조라면, 활동은 많지만 신호는 낮은 스레드가 공간을 차지해 중요하지만 활동이 적은 스레드를 밀어내는 문제를 어떻게 다루는지도 궁금함. 태그는 필터링에 중요하지만 JIRA 태그처럼 비슷하지만 다른 텍스트 묶음으로 지저분해지기 쉬운데 이를 관리할 방법이 있는지도 궁금함. 서로 다른 사용자가 같은 주제로 독립적으로 만든 스레드는 어떻게 처리하는지, 1:1 비공개 대화도 영상에서는 짧게만 나와 더 알고 싶음. 도구 자체는 확실히 잠재력이 있어 보임

    • Struct에서 채널은 사람들의 그룹일 뿐이고, 사용자에게 말을 걸듯 채널을 언급해 스레드 접근 권한을 정하는 방식임
      채널로 들어가 채팅하는 구조는 아님. 피드에서는 스레드당 높이가 고정돼 있어서 활동 많은 스레드가 무한히 공간을 먹지는 않으며, 스레드를 일정 시간 보관하거나 음소거하는 기능도 추가할 계획임. 태그는 스레드당 개수 제한이 있고 문맥 추가와 맞춤 피드 생성에 쓰이며, 태스크 우선순위 추적에도 활용해 가벼운 작업 관리 시스템처럼 쓰고 있음. 비슷한 태그는 병합할 수 있게 하고, 새 태그 생성을 중재자에게만 허용하는 식의 제어도 가능함. 비슷한 스레드는 병합할 수 있고, 스레드 안의 일부 채팅을 골라 새 스레드로 포크하는 기능도 준비 중이며 스레드 간 링크를 유지할 예정임. 비공개 대화는 원하는 사용자를 언급하면 되고, @struct를 언급하면 봇과의 DM, 자기 자신을 언급하면 TODO나 메모용 “셀프 DM”이 만들어짐. 채팅 플랫폼이 넘치는 시장이라 Struct가 “또 하나의 채팅앱”처럼 느껴질 수 있지만, 다른 플랫폼이 당연히 해야 한다고 생각했던 것을 몇 년 동안 기다려도 하지 않아서 직접 만들게 됨
    • 문제는 모두가 자기 전화는 걸러지지 않길 바라면서 남의 전화는 걸러내고 싶어 한다는 데 있음
      누군가 내 주의를 원하면 새 스레드를 만드는 식으로 계속 주의를 빼앗을 방법을 찾게 됨

  • 처음으로 관심을 끈 Slack 경쟁자 중 하나이고, 방향을 제대로 잡은 것 같음. 영상을 보고 든 느낌은 전반적으로 긍정적이지만, 어딘가 덜 개인적인 도구처럼 보였음
    Slack 방은 디지털 “방”처럼 느껴졌는데, Struct는 사무실 게시판 같은 느낌을 줌. 회사가 Struct에 완전히 올라탄 상태에서 신입으로 들어간다면 동료와 개인적 연결을 만들기가 더 어려울 것 같다는 첫인상이 있음. 이유는 정확히 모르겠지만 데모를 보며 그렇게 느꼈음. 예전에 실리콘밸리 엔지니어링 리더로 일할 때 겪던 커뮤니케이션 혼란을 생각하면, 마지막 회사에서 이런 도구가 있었으면 좋았겠다고 봄

    • 창업자로서 Jason과 이 부분을 많이 고민하고 있음. 왼쪽 패널에 모두의 이름을 늘어놓아 어수선하게 만들 것인지, 아니면 같은 방에 있는 느낌을 줄 것인지의 균형이 어려움
      피드 기반 플랫폼은 대체로 매우 비동기적이고 거의 포럼처럼 되기 쉬움. 그래서 Struct의 실시간 피드 설계는 “지금 이 방에 이 사람들이 있고, 바로 말하고 있다”는 느낌을 강조하려고 했음. 새 스레드가 뜨거나 새 채팅이 피드에 나타나는 순간은 꽤 재미있고 흥미로움. 온라인인 사람 목록을 보여주면 대화를 시작하고 싶은 느낌이 들 수도 있고, 다른 사람들이 참여하는 모습만 보여줘도 도움이 될 수 있음. 대화가 더 잘 시작되도록 최적화할 여지는 분명히 있음
    • 신입 온보딩에 항상 준비돼 있는 유용한 스레드들을 만들 수 있을 것 같음
      그래도 신입이 따뜻하게 환영받는다고 느끼게 하는 건 모든 조직에 중요하고, 원격 근무 비중이 큰 조직에서는 특히 더 그렇다. @random 채널, @club-channels, @annoucements 같은 공간을 만들어 재미있는 링크나 공지성 자료를 공유하고 동료를 알아가는 공간으로 쓸 수 있음. @struct 내부는 꽤 업무 중심이고 만드는 걸 좋아하지만, 재미도 가져와야 함

  • 정말 좋음. 채널은 유지하면서 집중된 스레드를 쓰는 아이디어가 마음에 들고 디자인도 좋음
    다만 장기 계획이 궁금함. 이런 서비스에 많은 데이터를 넣기 전에, 벤처캐피털 자금으로 키운 뒤 팔고 버리는 식이 아니라는 걸 알고 싶음

    • Struct는 계속 운영할 생각임. 백엔드, 디자이너, 프론트엔드 3명으로 만드는 작은 팀이라 자본 집약적인 제품도 아님
      기대하고 있는 로드맵에는 음성/영상 통화와 웨비나, 커뮤니티용 스팸 제어, AI 봇과 회상 기능 개선 및 비용 절감, Struct에 공유된 문서 색인화와 접근 제어를 유지한 AI 답변 등이 있음. Struct가 흥미로운 이유는 팀 채팅과 커뮤니티 채팅, 작업 관리 시스템, ChatGPT, 개인 TODO 목록, 공개 색인 가능한 지식 베이스를 한꺼번에 대체하기 때문임. 시스템이 잊어버리지 않는다고 신뢰할 수 있을 때 가능한 일이 놀라움

  • 유망해 보임. 다만 가격 표시를 다시 다듬어주면 좋겠음
    직접 계산하기엔 복잡하고, 토론이 갑자기 폭발해서 비용도 폭발할까 걱정됨. 예시를 주고 표 형식으로 보여주면 좋겠음. 사용자가 생각하게 만들지 말았으면 함. Struct 이름에 최소 6글자 제한이 있는 것도 의문임. 4글자부터면 충분하지 않나 싶고, 3글자를 넘는 국제 표준도 더는 없지 않나 싶음. 그리고 macOS 앱 아이콘은 다른 앱처럼 단색으로 만들어주면 좋겠음

    • 실제 사용 중인 조직들의 데이터가 있음. 간단히 말하면 Struct는 Slack보다 훨씬 저렴함
      월 기본요금은 9.97달러이고, 사용자 수나 스레드 수나 채팅 수가 아니라 AI 사용량에만 과금함. 기본 가격에는 20만 토큰이 포함돼 있고, 스레드 제목과 요약 생성 정도로만 쓰는 작은 조직에는 충분함. 실제 사용자 중 Typesense의 평균 사용량이 그 정도이고, Apache Druid는 월 40만 토큰 정도를 씀. 1천 토큰은 3센트라서 20만 토큰은 기본요금 위에 6달러가 추가되는 수준임. 둘 다 Struct를 지식 베이스로 쓰고 있음. 과금을 강제하기 시작할 때는 월 지출 한도를 설정할 수 있게 해서 예상 밖 청구가 없도록 할 예정이고, 기본요금 이후 비용은 원하는 만큼 낮게 유지할 수 있음

  • 제품 축하함. 예전 포럼 시절을 기억할 만큼 나이가 있는데, 솔직히 포럼을 다시 발견한 것처럼 보였음
    업데이트가 있으면 위로 올라오는 스레드 구조 말임. 큰 차이는 UI가 더 채팅/페이스북스럽고, 포럼은 관리자가 정적으로 구조화했지만 Struct는 많은 주제가 동시에 돌아가는 큰 조직에서 필요한 폴더 같은 스레드 구조화가 잘 안 보인다는 정도였음. 반면 메일은 어느 정도 “대화”로 묶을 수 있고, 개인 폴더로도 구조화할 수 있음. “AI”가 붙어 있는 점도 요즘은 피곤하게 느껴짐. 스레드의 동적 요약 자체는 의미가 있지만, 스레드가 채팅처럼 단순하면 요약이 필요 없고, 메일/포럼처럼 길다면 실제로 얼마나 잘 작동할지 확신이 안 듦. 그래서 이게 AI 유행어를 붙인 채팅형 마케팅 앱인지, 아니면 포럼 스레드나 이메일 대화와 근본적으로 다른 무언가를 놓친 건지 잘 모르겠음

    • Struct는 Discourse에서 꽤 많은 영감을 받았고, 포럼과 채팅 애플리케이션을 독특하게 섞은 형태임
      이메일을 포함한 모든 포럼에는 스레드와 피드가 있지만, 포럼은 비동기적이고 실시간 채팅을 중심으로 설계되지 않았음. 스레드와 피드 개념을 채팅 플랫폼에 적용할 때의 어려움은 이를 실시간으로 만들어야 한다는 점이고, Struct가 해결하려는 것도 바로 그 부분임. “채팅이면 요약이 필요 없다”는 말에는 조금 동의하기 어렵다. 끝없이 이어지는 대화에 충분히 많이 참여해봤고, 작은 팀에서도 수백 개 메시지가 오가는 스레드가 있음. 요약은 실제로 도움이 많이 되고, 최소한 제목만 있어도 피드가 훨씬 이해하기 쉬워짐. 태그로 스레드를 구조화하고 그 태그 중심으로 피드를 만들 수 있으며, 이것이 폴더에 해당함. Gmail이 나왔을 때 사람들이 라벨을 SMTP 폴더에 대응해 이해해야 했던 때가 떠오름. Struct 스레드와 Discourse 스레드의 차이는, Struct는 짧고 실시간으로 오가는 왕복 커뮤니케이션을 강조하고 Discourse는 길고 숙고된 단발성 게시물을 강조한다는 점임. 전자는 채팅이고 후자는 포럼임. Struct 설계가 어려운 이유도 구조, 지식, 실시간성 사이의 균형 때문임
    • Discord에 잠깐 있던 AI 요약 기능은 꽤 웃겼음
      항상 논의의 핵심을 완전히 놓치고 터무니없는 요약을 만들어서 몇 시간씩 웃을 거리를 줬음

  • “CEO의 스레드로 피드를 만들어 회사의 최신 비전과 목표에 맞춰가세요. 적절한 답으로 대화에 뛰어들고 마땅한 승진을 얻으세요”라는 문구가 씁쓸한 미소를 짓게 했음
    결국 중요한 건 무엇을 하느냐가 아니라 누가 그걸 보느냐라는 걸 다시 깨닫게 됨

    • 스타트업을 만들며 관리를 배운 엔지니어 입장에서 말하면, 일을 하되 그 일이 보이게도 해야 함
      첫 직장이었던 Google에서 계속 만들기만 했고, 내가 만드는 것이 왜 중요한지 전달하는 데 어려움을 겪었음. 첫 매니저는 나만 빼고 팀 전체를 승진시켰고 아직도 아픔. 팀과 매니저를 바꾸자, 내가 있어야 할 레벨보다 2단계 낮게 평가받고 있었다고 들었음. 결론은 그런 대화에 들어가라는 것임. 부담스럽게 굴 필요는 없지만, 존재감은 알려야 함
    • 부하 직원들이 뭘 하는지 최신 상태로 파악하는 것도 매니저의 업무 아닌가 싶음
      직원들이 상사에게 자기 자신을 마케팅하는 데 시간을 쓰도록 장려하는 건 회사에도 이익이 아님. 이런 모습을 자주 보지만, 대부분의 매니저가 이 부분에서 일을 잘 못한다는 신호로 보임

  • runForThread.executeReq.Get.messages: executeReq.client.Do: Get "[https://api.openai.com/v1/threads/thread_*******/messages?li...](<https://api.openai.com/v1/threads/…;)": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
    언젠가는 새 제품들이 OpenAI 의존성 없이도 나올 수 있으면 좋겠음

    • 오류 메시지를 좀 정리해야겠음. OpenAI를 숨기려는 건 아니고, 그냥 더 보기 좋게 만들 필요가 있음
      OpenAI는 마음에 듦. GPT-4는 정말 잘 작동함. 더 저렴한 다른 모델들도 써봤지만 품질이 그만큼 좋지는 않았음
    • 가끔은 이 흐름이 정상으로 돌아올 때까지 라우터에서 .ai 도메인을 막아버릴까 생각함
      진지하게 말하면, 이 제품은 “…그리고 AI”라는 문구를 보기 전까지는 정말 흥미로워 보였음. 아마 내가 목표 고객은 아닌 것 같음

  • 요약은 AI가 정말 잘하는 작업 중 하나라서 이 제품이 훌륭하다고 봄
    어떤 기술을 썼는지 궁금함. 내부에 dgraph나 badger가 쓰였는지, 호스팅은 빅3인지 다른 곳인지, Kubernetes를 쓰는지, Elastic Search를 쓰는지 궁금함. 그리고 Struct가 Slack/Discord를 온라인으로 긁어오는 도구인지, 지금 또는 앞으로 독립형 채팅 앱이 되려는지도 궁금함

    • 기술 스택은 Go, Postgres, OpenAI, React/Next.JS, Loops.so, Imgproxy, Microsoft E5 임베딩, Typesense 검색, Figma, Framer, Hetzner 서버임
      가장 큰 비용은 OpenAI에서 나오고, 임베딩은 OpenAI가 아니라 Microsoft E5를 씀. Typesense는 검색에 쓰며 Struct의 사용자이기도 함. Postgres 대신 Badger를 쓰는 건 맞지 않았지만, 다른 용도로는 Badger를 고려 중임. 내부에서는 ristretto와 roaring bitmaps를 많이 씀. Struct는 Slack과 꽤 좋은 통합이 있어서 Slack 인터페이스처럼 쓸 수 있음. 동료들은 Slack을 쓰고, 나는 Struct에서 답하는 식으로, Gmail용 Superhuman 같은 느낌임. Discord 통합도 잘 되어 있고, 둘 다 오픈소스 회사들이 Slack/Discord 대화에서 공개 지식 베이스를 만들기 위해 사용 중임. [1]: https://github.com/struct-chat/embedding

  • 생산성을 잘못된 방식으로 최적화하려는 건 아닌지 가끔 생각함. 커뮤니케이션의 잡음을 관리하는 도구보다, 애초에 커뮤니케이션을 줄이면서도 필요한 일을 잘 끝내는 쪽에서 더 큰 이득이 나올 수 있음
    예를 들어 회의가 수십 개 있어도 회의록을 잘 추적하도록 최적화하고 싶지는 않음. 더 적지만 더 효과적인 회의를 원함

    • 매우 동의함. 업계는 “마법 버튼” 패러다임에 갇혀 있고, AI는 그 버튼을 눌러야만 멋진 일을 함
      AI가 회의 녹취에서 자동 요약을 만들 수 있다면, 다음 단계나 실행 항목까지 후속 처리하지 못할 이유가 없음. 다음 단계가 Janine이 Carlos와 회의를 잡는 것이라면, AI가 Carlos에게 연락해 일정을 잡게 도와주면 되지 않나 싶음. 지금은 너무 작게 생각하고 있음
    • 회의를 줄여야 한다는 건 타당함. 채팅 플랫폼이나 Loom 같은 도구도 결국 필요한 회의 수를 줄이려는 목적이라고 봄
      다만 메트칼프의 법칙도 피할 수 없음. 현대 업무 대부분은 팀에서 일어나고, 팀 크기가 N이면 O(N^2) 커뮤니케이션 비용을 치러야 함. 전체 커뮤니케이션이 줄어들 것 같지는 않고, 더 효과적으로 처리할 올바른 도구가 필요함

  • 훌륭함. Discord는 정보를 검색하고 스레드를 따라가기에 최악임
    같은 질문에 계속 반복해서 답하고 있는 느낌이 듦

    • Discord도 Slack AI가 발표한 것처럼 결국 대규모 언어 모델 기반 검색을 추가할 테고, 그러면 그 문제는 사라질 것임
    • 이 제품은 Discord보다는 Slack이나 Teams를 겨냥한 것처럼 보임
답변달기