블루 엔지니어링 팀과 함께 AI 기반 자동 분류 및 태깅 기능을 구축하는 방법을 설명합니다.


효과적인 프로젝트 및 프로세스 관리는 모든 규모의 조직에 매우 중요합니다.

블루에서는 세계의 일을 조직하는 것을 우리의 사명으로 삼았습니다 최고의 프로젝트 관리 플랫폼을 구축하여—간단하고 강력하며 유연하고 모든 사람에게 저렴하게 제공하는 것입니다.

이는 우리의 플랫폼이 각 팀의 고유한 요구에 맞게 조정되어야 함을 의미합니다. 오늘은 우리의 가장 강력한 기능 중 하나인 맞춤형 권한에 대해 자세히 알아보게 되어 기쁩니다.

프로젝트 관리 도구는 현대 워크플로우의 중추로, 민감한 데이터, 중요한 커뮤니케이션 및 전략적 계획을 담고 있습니다. 따라서 이 정보에 대한 접근을 세밀하게 제어할 수 있는 능력은 단순한 사치가 아니라 필수입니다.

맞춤형 권한은 B2B SaaS 플랫폼에서 중요한 역할을 하며, 특히 프로젝트 관리 도구에서는 협업과 보안 간의 균형이 프로젝트의 성공을 좌우할 수 있습니다.

하지만 블루는 다른 접근 방식을 취합니다: 우리는 엔터프라이즈급 기능이 엔터프라이즈 규모의 예산에만 국한되어서는 안 된다고 믿습니다.

AI가 소규모 팀이 전례 없는 규모로 운영할 수 있도록 하는 시대에, 왜 강력한 보안과 사용자 정의가 손이 닿지 않는 것이어야 할까요?

이번 비하인드 스토리에서는 맞춤형 권한 기능을 개발한 과정을 살펴보며, SaaS 가격 책정 계층의 현상 유지를 도전하고 모든 규모의 기업에 강력하고 유연한 보안 옵션을 제공하는 방법을 설명합니다.

당신이 큰 꿈을 가진 스타트업이든, 프로세스를 최적화하려는 기존 기업이든, 맞춤형 권한은 당신이 몰랐던 새로운 사용 사례를 가능하게 할 수 있습니다.

맞춤형 사용자 권한 이해하기

블루를 위한 맞춤형 권한 개발 여정을 시작하기 전에, 맞춤형 사용자 권한이 무엇인지, 그리고 프로젝트 관리 소프트웨어에서 왜 그렇게 중요한지 잠시 이해해 보겠습니다.

맞춤형 사용자 권한은 소프트웨어 시스템 내에서 개별 사용자 또는 그룹에 대한 접근 권한을 조정할 수 있는 능력을 의미합니다. 고정된 권한 세트를 가진 미리 정의된 역할에 의존하는 대신, 맞춤형 권한은 관리자가 조직의 구조와 워크플로우 요구에 완벽하게 맞는 매우 구체적인 접근 프로필을 생성할 수 있도록 합니다.

블루와 같은 프로젝트 관리 소프트웨어의 맥락에서 맞춤형 권한은 다음을 포함합니다:

  • 세분화된 접근 제어: 특정 유형의 프로젝트 데이터를 누가 보고, 편집하거나 삭제할 수 있는지 결정합니다.
  • 기능 기반 제한: 특정 사용자 또는 팀에 대해 특정 기능을 활성화하거나 비활성화합니다.
  • 데이터 민감도 수준: 프로젝트 내에서 민감한 정보에 대한 다양한 접근 수준을 설정합니다.
  • 워크플로우 특정 권한: 특정 단계 또는 프로젝트 워크플로우의 측면에 맞게 사용자 기능을 조정합니다.

프로젝트 관리에서 맞춤형 권한의 중요성은 과장할 수 없습니다:

  • 강화된 보안: 사용자에게 필요한 접근만 제공함으로써 데이터 유출이나 무단 변경의 위험을 줄입니다.
  • 개선된 준수: 맞춤형 권한은 데이터 접근을 제어하여 조직이 산업별 규제 요구 사항을 충족하도록 돕습니다.
  • 효율적인 협업: 각 팀원이 불필요한 제한이나 과도한 권한 없이 자신의 역할을 수행할 수 있는 올바른 수준의 접근을 가질 때 팀은 더 효율적으로 작업할 수 있습니다.
  • 복잡한 조직에 대한 유연성: 기업이 성장하고 발전함에 따라 맞춤형 권한은 소프트웨어가 변화하는 조직 구조 및 프로세스에 적응할 수 있도록 합니다.

YES를 얻기 위한 과정

우리는 이전에 썼습니다, 블루의 모든 기능은 우리가 구축하기로 결정하기 전에 확실한 YES가 되어야 한다고. 우리는 수백 명의 엔지니어를 두고 고객이 필요로 하지 않는 것을 만들며 시간과 돈을 낭비할 여유가 없습니다.

그래서 블루에서 맞춤형 권한을 구현하는 과정은 직선적이지 않았습니다. 많은 강력한 기능과 마찬가지로, 이는 사용자로부터의 명확한 필요에서 시작되어 신중한 고려와 계획을 통해 발전했습니다.

수년 동안, 우리의 고객들은 사용자 권한에 대한 더 세분화된 제어를 요청해왔습니다. 모든 규모의 조직이 점점 더 복잡하고 민감한 프로젝트를 처리하기 시작하면서, 우리의 표준 역할 기반 접근 제어의 한계가 분명해졌습니다.

외부 클라이언트와 작업하는 소규모 스타트업, 복잡한 승인 프로세스를 가진 중간 규모 기업, 엄격한 준수 요구 사항을 가진 대기업 모두 같은 필요를 표명했습니다:

사용자 접근 관리의 더 많은 유연성.

명확한 수요에도 불구하고, 우리는 처음에 맞춤형 권한 개발에 뛰어드는 것을 주저했습니다.

왜일까요?

우리는 관련된 복잡성을 이해했습니다!

맞춤형 권한은 프로젝트 관리 시스템의 모든 부분에 영향을 미치며, 사용자 인터페이스에서 데이터베이스 구조까지 모두 포함됩니다. 우리는 이 기능을 구현하는 데 핵심 아키텍처에 상당한 변경이 필요하고 성능에 대한 고려가 필요하다는 것을 알고 있었습니다.

경쟁업체들을 조사하면서, 고객들이 요청하는 강력한 맞춤형 권한 엔진을 구현하려고 시도한 경쟁자가 매우 적다는 것을 알게 되었습니다. 그렇게 한 기업들은 종종 가장 높은 계층의 엔터프라이즈 플랜에만 이를 제한했습니다.

그 이유는 분명해졌습니다: 개발 노력이 상당하고 위험이 큽니다.

맞춤형 권한을 잘못 구현하면 치명적인 버그나 보안 취약점이 발생할 수 있으며, 이는 전체 시스템을 위태롭게 할 수 있습니다. 이 인식은 우리가 고려하고 있는 도전의 규모를 강조했습니다.

현상 유지에 도전하기

그러나 우리가 계속 성장하고 발전하면서, 우리는 중대한 깨달음을 얻었습니다:

강력한 기능을 엔터프라이즈 고객에게만 예약하는 전통적인 SaaS 모델은 오늘날의 비즈니스 환경에서 더 이상 의미가 없습니다.

2024년, AI와 고급 도구의 힘으로 소규모 팀은 훨씬 더 큰 조직과 경쟁할 수 있는 규모와 복잡성으로 운영할 수 있습니다. 스타트업은 여러 국가에서 민감한 클라이언트 데이터를 처리할 수 있습니다. 소규모 마케팅 에이전시는 다양한 기밀 요구 사항을 가진 수십 개의 클라이언트 프로젝트를 동시에 관리할 수 있습니다. 이러한 기업들은 어떤 대기업과 동일한 수준의 보안과 사용자 정의가 필요합니다.

우리는 스스로에게 물었습니다: 회사의 인력이나 예산의 크기가 그들의 데이터를 안전하게 유지하고 프로세스를 효율적으로 운영할 수 있는 능력을 결정해야 하는 이유는 무엇인가요?

모든 사람을 위한 엔터프라이즈급

이 깨달음은 이제 블루의 많은 개발을 이끄는 핵심 철학으로 이어졌습니다: 엔터프라이즈급 기능은 모든 규모의 기업이 접근할 수 있어야 합니다.

우리는 다음과 같이 믿습니다:

  • 보안은 사치가 되어서는 안 됩니다. 모든 회사는 규모에 관계없이 데이터와 프로세스를 보호할 도구를 가질 자격이 있습니다.
  • 유연성이 혁신을 이끕니다. 모든 사용자에게 강력한 도구를 제공함으로써, 우리는 그들이 산업을 발전시키는 워크플로우와 시스템을 만들 수 있도록 합니다.
  • 성장은 플랫폼 변경을 요구하지 않아야 합니다. 고객이 성장함에 따라 그들의 도구도 원활하게 성장해야 합니다.

이러한 사고방식으로 우리는 맞춤형 권한의 도전을 정면으로 해결하기로 결정했습니다. 모든 사용자에게 제공할 수 있도록 노력했습니다, 단지 높은 계층의 플랜에 있는 사용자에게만이 아니라.

이 결정은 신중한 설계, 반복적인 개발, 지속적인 사용자 피드백의 경로를 설정하여 궁극적으로 오늘날 우리가 자랑스럽게 제공하는 맞춤형 권한 기능으로 이어졌습니다.

다음 섹션에서는 이 복잡한 기능을 구현하기 위해 설계 및 개발 프로세스에 어떻게 접근했는지 살펴보겠습니다.

설계 및 개발

우리가 맞춤형 권한을 다루기로 결정했을 때, 우리는 곧 거대한 작업에 직면해 있다는 것을 깨달았습니다.

처음에는 "맞춤형 권한"이 간단하게 들릴 수 있지만, 이는 시스템의 모든 측면에 영향을 미치는 복잡한 기능입니다.

도전은 엄청났습니다: 우리는 계단식 권한을 구현하고, 즉석에서 편집을 허용하며, 데이터베이스 스키마에 중대한 변경을 가하고, 웹, Mac, Windows, iOS 및 Android 앱, API 및 웹훅 전반에 걸쳐 원활한 기능을 보장해야 했습니다.

복잡성은 가장 경험이 많은 개발자조차도 주저하게 만들 만큼 컸습니다.

우리의 접근 방식은 두 가지 핵심 원칙에 중점을 두었습니다:

  1. 기능을 관리 가능한 버전으로 나누기
  2. 점진적인 배포 수용하기

전체 맞춤형 권한의 복잡성에 직면했을 때, 우리는 스스로에게 중요한 질문을 던졌습니다:

이 기능의 가장 간단한 첫 번째 버전은 무엇일까요?

이 접근 방식은 최소 기능 제품(MVP)을 제공하고 피드백에 따라 반복하는 애자일 원칙과 일치합니다.

우리의 대답은 신선하게 간단했습니다:

  1. 프로젝트 활동 탭을 숨기는 토글 추가
  2. 양식 탭을 숨기는 또 다른 토글 추가

그게 전부였습니다.

화려한 장식도 없고, 복잡한 권한 매트릭스도 없었습니다—단지 두 개의 간단한 켜기/끄기 스위치뿐이었습니다.

처음에는 다소 실망스러워 보일 수 있지만, 이 접근 방식은 몇 가지 중요한 장점을 제공했습니다:

  • 빠른 구현: 이러한 간단한 토글은 신속하게 개발 및 테스트할 수 있어, 사용자에게 맞춤형 권한의 기본 버전을 신속하게 제공할 수 있었습니다.
  • 명확한 사용자 가치: 이 두 가지 옵션만으로도 우리는 실질적인 가치를 제공하고 있었습니다. 일부 팀은 클라이언트로부터 활동 피드를 숨기고 싶어할 수 있으며, 다른 팀은 특정 사용자 그룹에 대해 양식 접근을 제한해야 할 수도 있습니다.
  • 성장을 위한 기반: 이 간단한 시작은 더 복잡한 권한을 위한 기초를 마련했습니다. 처음부터 복잡성에 얽매이지 않고 맞춤형 권한을 위한 기본 인프라를 설정할 수 있었습니다.
  • 사용자 피드백: 이 간단한 버전을 출시함으로써, 우리는 사용자가 맞춤형 권한과 상호작용하는 방식에 대한 실제 피드백을 수집할 수 있었고, 이는 향후 개발에 도움이 되었습니다.
  • 기술적 학습: 이 초기 구현은 개발 팀에게 플랫폼 전반에 걸쳐 권한을 수정하는 실질적인 경험을 제공하여, 더 복잡한 반복을 준비하는 데 도움이 되었습니다.

그리고 사실, 어떤 것에 대한 큰 비전을 가지고 있다가, 그 비전의 아주 작은 비율에 해당하는 것을 출시하는 것은 정말 겸손한 경험입니다.

이 첫 두 개의 토글을 출시한 후, 우리는 좀 더 정교한 것을 다루기로 결정했습니다. 우리는 두 가지 새로운 맞춤형 사용자 역할 권한에 도달했습니다.

첫 번째는 사용자가 자신에게 특별히 할당된 레코드만 볼 수 있도록 제한하는 기능이었습니다. 이는 프로젝트에 클라이언트가 있을 때 매우 유용합니다. 클라이언트가 자신에게 특별히 할당된 레코드만 보고, 당신이 그들을 위해 작업하고 있는 모든 것을 보지 않도록 하고 싶을 때 유용합니다.

두 번째는 프로젝트 관리자가 사용자 그룹이 다른 사용자를 초대할 수 없도록 차단하는 옵션이었습니다. 이는 민감한 프로젝트가 "필요에 따라 보기" 기준을 유지하도록 보장하는 데 좋습니다.

이것을 출시한 후, 우리는 더 많은 자신감을 얻었고 세 번째 버전에서는 열 수준의 권한을 다루었습니다. 이는 특정 사용자 그룹이 어떤 맞춤형 필드를 볼 수 있는지 또는 편집할 수 있는지를 결정하는 것을 의미합니다.

이는 매우 강력합니다. CRM 프로젝트가 있고, 고객이 지불할 금액뿐만 아니라 비용 및 이익 마진과 관련된 데이터가 있다고 상상해 보십시오. 비용 필드와 프로젝트 마진 공식 필드를 주니어 직원에게 보이지 않도록 하고 싶을 수 있으며, 맞춤형 권한을 사용하면 이러한 필드를 잠글 수 있습니다.

다음으로 우리는 목록 기반 권한을 생성하는 작업으로 넘어갔습니다. 여기서 프로젝트 관리자는 사용자 그룹이 특정 목록을 보고, 편집하고, 삭제할 수 있는지 결정할 수 있습니다. 목록을 숨기면 해당 목록 내의 모든 레코드도 숨겨지므로 팀원이나 클라이언트로부터 프로세스의 특정 부분을 숨길 수 있습니다.

이것이 최종 결과입니다:

기술적 고려사항

블루의 기술 아키텍처의 핵심에는 GraphQL이 자리 잡고 있으며, 이는 맞춤형 권한과 같은 복잡한 기능을 구현할 수 있는 능력에 상당한 영향을 미쳤습니다. 그러나 구체적인 사항에 들어가기 전에, GraphQL이 무엇인지, 그리고 그것이 더 전통적인 REST API 접근 방식과 어떻게 다른지 한 걸음 물러서서 이해해 보겠습니다.

GraphQL vs REST API: 접근 가능한 설명

당신이 레스토랑에 있다고 상상해 보십시오. REST API를 사용하면 고정된 메뉴에서 주문하는 것과 같습니다. 특정 요리(엔드포인트)를 요청하면, 원하든 원하지 않든 모든 것이 함께 제공됩니다. 식사를 사용자 정의하고 싶다면 여러 번 주문(API 호출)을 하거나 특별히 준비된 요리(맞춤 엔드포인트)를 요청해야 할 수 있습니다.

반면, GraphQL은 무엇이든 준비할 수 있는 요리사와 대화하는 것과 같습니다. 당신은 요리사에게 원하는 재료(데이터 필드)와 그 양을 정확히 말합니다. 요리사는 당신이 요청한 대로 정확히 요리를 준비합니다 - 더도 말고 덜도 말고. 이것이 바로 GraphQL이 하는 일입니다 - 클라이언트가 필요한 데이터를 정확히 요청할 수 있도록 하고, 서버는 그에 맞는 데이터만 제공합니다.

중요한 점심

블루의 초기 개발이 시작된 지 약 6주 후, 우리의 수석 엔지니어와 CEO는 점심을 먹으러 나갔습니다.

논의의 주제는?

REST API에서 GraphQL로 전환할지 여부였습니다. 이는 가볍게 결정할 문제가 아니었습니다 - GraphQL을 채택한다는 것은 초기 작업 6주를 버리는 것을 의미했습니다.

사무실로 돌아가는 길에 CEO는 수석 엔지니어에게 중요한 질문을 던졌습니다: "5년 후에 이를 하지 않은 것을 후회하게 될까요?"

답은 분명해졌습니다: GraphQL이 앞으로 나아갈 길이었습니다.

우리는 이 기술의 잠재력을 일찍이 인식했으며, 유연하고 강력한 프로젝트 관리 플랫폼을 지원할 수 있는 방법을 보았습니다.

GraphQL을 채택한 우리의 예측은 맞춤형 권한을 구현하는 데 큰 도움이 되었습니다. REST API를 사용했다면, 맞춤형 권한의 가능한 모든 구성에 대해 다른 엔드포인트가 필요했을 것입니다 - 이는 빠르게 관리하기 어려워지는 접근 방식이었습니다.

그러나 GraphQL은 맞춤형 권한을 동적으로 처리할 수 있게 해줍니다. 작동 방식은 다음과 같습니다:

  • 즉석 권한 확인: 클라이언트가 요청을 할 때, 우리의 GraphQL 서버는 데이터베이스에서 사용자의 권한을 확인할 수 있습니다.
  • 정확한 데이터 검색: 이러한 권한에 따라 GraphQL은 사용자의 접근 권한 내에서 요청된 데이터만 반환합니다.
  • 유연한 쿼리: 권한이 변경될 때, 우리는 새로운 엔드포인트를 만들거나 기존 엔드포인트를 변경할 필요가 없습니다. 동일한 GraphQL 쿼리는 다양한 권한 설정에 적응할 수 있습니다.
  • 효율적인 데이터 가져오기: GraphQL은 클라이언트가 필요한 데이터를 정확히 요청할 수 있게 해줍니다. 이는 우리가 데이터를 과도하게 가져오지 않도록 하여, 사용자가 접근해서는 안 되는 정보를 노출할 위험을 줄입니다.

이 유연성은 맞춤형 권한과 같은 복잡한 기능에 매우 중요합니다. 이는 성능이나 유지 관리성을 희생하지 않고 세밀한 제어를 제공할 수 있게 해줍니다.

도전 과제

블루에서 맞춤형 권한을 구현하는 데는 여러 가지 도전 과제가 있었으며, 각 도전은 우리를 혁신하고 접근 방식을 다듬도록 이끌었습니다. 성능 최적화는 빠르게 중요한 문제로 떠올랐습니다. 더 세분화된 권한 확인을 추가하면서, 우리는 시스템 속도가 느려질 위험에 직면했습니다. 특히 많은 사용자와 복잡한 권한 설정을 가진 대규모 프로젝트에서는 더욱 그렇습니다. 이를 해결하기 위해 우리는 다단계 캐싱 전략을 구현하고, 데이터베이스 쿼리를 최적화하며, GraphQL의 능력을 활용하여 필요한 데이터만 요청하도록 했습니다. 이 접근 방식은 프로젝트가 확장되고 권한 복잡성이 증가하더라도 빠른 응답 시간을 유지할 수 있게 해주었습니다.

맞춤형 권한의 사용자 인터페이스는 또 다른 중요한 장애물로 나타났습니다. 우리는 관리자가 인터페이스를 직관적이고 관리하기 쉽게 만들어야 했습니다. 옵션을 추가하고 시스템의 복잡성을 증가시키면서도 말이죠.

우리의 해결책은 여러 차례의 사용자 테스트와 반복적인 디자인을 포함했습니다.

우리는 관리자가 다양한 역할과 프로젝트 영역에서 권한을 빠르게 보고 수정할 수 있도록 시각적 권한 매트릭스를 도입했습니다.

크로스 플랫폼 일관성을 보장하는 것도 자체적인 도전 과제를 제시했습니다. 우리는 웹, 데스크톱 및 모바일 애플리케이션 전반에 걸쳐 맞춤형 권한을 균일하게 구현해야 했습니다. 각 플랫폼은 고유한 인터페이스와 사용자 경험 고려 사항이 있었습니다. 이는 특히 사용자의 권한에 따라 기능을 동적으로 숨기고 표시해야 했던 모바일 앱에서 까다로웠습니다. 우리는 API 레이어에서 권한 논리를 중앙 집중화하여 모든 플랫폼이 일관된 권한 데이터를 받을 수 있도록 했습니다.

그런 다음, 우리는 이러한 권한 변경에 실시간으로 적응할 수 있는 유연한 UI 프레임워크를 개발하여 사용되는 플랫폼에 관계없이 원활한 경험을 제공했습니다.

사용자 교육 및 채택은 맞춤형 권한 여정의 마지막 장애물이었습니다. 이렇게 강력한 기능을 도입하는 것은 사용자가 맞춤형 권한을 이해하고 효과적으로 활용할 수 있도록 도와야 한다는 것을 의미했습니다.

우리는 처음에 맞춤형 권한을 사용자 기반의 일부에게 출시하고, 그들의 경험을 면밀히 모니터링하며 통찰을 수집했습니다. 이 접근 방식은 실제 사용을 기반으로 기능과 교육 자료를 다듬을 수 있게 해주었습니다.

단계적 출시 방식은 매우 유용했으며, 우리가 예상하지 못했던 작은 문제와 사용자 혼란 포인트를 식별하고 해결하는 데 도움이 되었습니다. 궁극적으로 모든 사용자에게 더 세련되고 사용자 친화적인 기능으로 이어졌습니다.

이러한 사용자 기반의 하위 집합에 출시하는 접근 방식과 일반적으로 2-3주간의 "베타" 기간은 우리의 마음을 편안하게 해줍니다. :)

미래를 바라보며

모든 기능과 마찬가지로, 아무것도 *"완료"*되지 않았습니다.

맞춤형 권한 기능에 대한 우리의 장기 비전은 태그, 맞춤형 필드 필터, 사용자 정의 가능한 프로젝트 탐색 및 댓글 제어에 걸쳐 있습니다.

각 측면을 살펴보겠습니다.

태그 권한

우리는 레코드에 하나 이상의 태그가 있는지에 따라 권한을 생성할 수 있다면 놀라울 것이라고 생각합니다. 가장 명백한 사용 사례는 "고객"이라는 맞춤형 사용자 역할을 만들고, 해당 역할의 사용자만 "고객" 태그가 있는 레코드를 볼 수 있도록 허용하는 것입니다.

이것은 레코드가 고객에게 보일 수 있는지 여부를 한눈에 볼 수 있게 해줍니다.

AND/OR 조합기를 사용하면 더욱 강력해질 수 있습니다. 예를 들어, "고객"과 "공개" 두 태그가 모두 달린 레코드에 대한 접근을 허용하는 규칙을 설정하거나, "내부" 또는 "기밀" 태그가 달린 레코드에 대한 접근을 허용하는 규칙을 설정할 수 있습니다. 이러한 수준의 유연성은 매우 복잡한 조직 구조와 워크플로우에 맞춘 권한 설정을 가능하게 합니다.

잠재적인 응용 프로그램은 방대합니다. 프로젝트 관리자는 민감한 정보를 쉽게 분리할 수 있고, 영업 팀은 관련 클라이언트 데이터에 자동으로 접근할 수 있으며, 외부 협력자는 민감한 내부 정보에 노출될 위험 없이 프로젝트의 특정 부분에 원활하게 통합될 수 있습니다.

맞춤형 필드 필터

맞춤형 필드 필터에 대한 우리의 비전은 세분화된 접근 제어에서 중요한 도약을 나타냅니다. 이 기능은 프로젝트 관리자가 특정 사용자 그룹이 볼 수 있는 레코드를 맞춤형 필드의 값에 따라 정의할 수 있도록 합니다. 이는 정보 접근을 위한 동적이고 데이터 기반의 경계를 만드는 것입니다.

다음과 같은 권한을 설정할 수 있다고 상상해 보십시오:

  • "프로젝트 상태" 드롭다운이 "공개"로 설정된 레코드만 표시
  • "부서" 다중 선택 필드에 "마케팅"이 포함된 항목의 가시성 제한
  • "우선 순위" 체크박스가 선택된 작업에 대한 접근 허용
  • "예산" 숫자 필드가 특정 임계값 이상인 프로젝트 표시

사용자 정의 가능한 프로젝트 탐색

이는 우리가 이미 가지고 있는 토글의 확장일 뿐입니다. "활동"과 "양식"에 대한 토글만 있는 것이 아니라, 프로젝트 탐색의 모든 부분에 대해 이를 확장하고자 합니다. 이렇게 하면 프로젝트 관리자는 집중된 인터페이스를 만들고 필요 없는 도구를 제거할 수 있습니다.

댓글 제어

미래에는 고객이 댓글을 볼 수 있는 사람과 볼 수 없는 사람을 결정하는 방식에서 창의력을 발휘하고자 합니다. 우리는 하나의 레코드 아래 여러 개의 탭형 댓글 영역을 허용할 수 있으며, 각 영역은 서로 다른 사용자 그룹에 대해 보이거나 보이지 않을 수 있습니다.

또한, 사용자가 특정하게 언급된 댓글만 보이도록 하고, 그 외의 댓글은 보이지 않도록 하는 기능도 허용할 수 있습니다. 이는 프로젝트에 클라이언트가 있는 팀이 클라이언트가 보고 싶어하는 댓글만 보이도록 보장할 수 있게 해줍니다.

결론

이제 우리는 가장 흥미롭고 강력한 기능 중 하나를 구축하는 데 접근한 방법을 살펴보았습니다! 우리의 프로젝트 관리 비교 도구에서 볼 수 있듯이, 매우 적은 수의 프로젝트 관리 시스템이 이렇게 강력한 권한 매트릭스 설정을 가지고 있으며, 그런 시스템은 대부분 가장 비싼 엔터프라이즈 플랜에만 이를 예약하여 일반적인 소규모 또는 중간 규모 기업이 접근할 수 없게 만듭니다.

블루와 함께라면, 당신은 우리의 플랜으로 모든 기능을 이용할 수 있습니다 — 우리는 엔터프라이즈 수준의 기능이 엔터프라이즈 고객에게만 예약되어서는 안 된다고 믿습니다!

AI 어시스턴트

응답은 AI를 사용하여 생성되며 오류가 포함될 수 있습니다.

어떻게 도와드릴까요?

Blue 또는 이 문서에 대해 궁금한 점이 있으면 무엇이든 물어보세요.

전송하려면 Enter • 새 줄을 추가하려면 Shift+Enter • ⌘I를 눌러 열기