먼저 지정된 액세스 수준으로 전체 캘린더를 공유할 수 있습니다.
예를 들어 팀 캘린더를 만든 후 다음과 같은 작업을 할 수 있습니다.
팀의 모든 구성원에게 캘린더에서 일정을 추가하고 수정할 수 있는 권한을 부여합니다.
상사에게 내 캘린더의 일정을 볼 수 있는 권한 부여
고객에게 한가함/바쁨 여부만 확인할 수 있고 일정 세부정보는 확인할 수 없는 권한을 부여합니다.
공유 캘린더에서 개별 일정에 대한 액세스 권한을 조정할 수도 있습니다.
또는 캘린더의 개별 일정에 다른 사용자를 초대할 수 있습니다.
다른 사용자를 일정에 초대하면 해당 사용자의 캘린더에 일정 사본이 표시됩니다. 참석자의 캘린더에 있는 사본은 참석자의 공유 구성에 따라 다른 사용자에게 표시됩니다.
그러면 초대받은 사용자가 초대를 수락하거나 거부할 수 있으며, 어느 정도는 일정 사본을 수정할 수도 있습니다(예: 캘린더의 색상을 변경하고 알림을 추가). 일정에 사용자를 초대하는 방법 자세히 알아보기
캘린더 공유
캘린더 소유자는 다른 사용자에게 액세스 권한을 부여하여 캘린더를 공유할 수 있습니다. 특정 캘린더의 공유 설정은 해당 캘린더의 ACL 컬렉션(액세스 제어 목록)으로 표시됩니다. ACL 컬렉션의 각 리소스는 지정된 수혜자에게 특정 액세스 역할을 부여합니다. 액세스 역할은 다음 표에 나열된 역할 중 하나입니다.
역할
역할에 의해 부여된 액세스 권한
none
액세스 권한을 제공하지 않습니다.
freeBusyReader
수신자가 특정 시간에 캘린더가 한가한지 바쁜지 확인할 수 있지만 일정 세부정보에 액세스할 수는 없습니다. freeBusy.query 작업을 사용하여 일정 정보(무료/바쁨)를 가져올 수 있습니다.
reader
수신자가 캘린더의 일정을 읽을 수 있도록 허용합니다.
writer
수신자가 캘린더에서 일정을 읽고 쓸 수 있도록 허용합니다. 이 역할은 ACL도 볼 수 있습니다.
owner
캘린더의 소유권을 제공합니다. 이 역할에는 작성자 역할의 모든 권한과 ACL을 조작할 수 있는 추가 기능이 있습니다.
가능한 수혜자는 다음과 같습니다.
다른 개별 사용자
사용자 그룹
도메인
공개 (모든 사용자에게 액세스 권한 부여)
기본적으로 각 사용자는 기본 캘린더에 대한 소유자 액세스 권한을 가지며 이 액세스 권한은 포기할 수 없습니다. 캘린더당 최대 6,000개의 ACL을 추가할 수 있습니다.
Google Workspace 사용자의 경우 허용되는 최대 액세스를 제한할 수 있는 도메인 설정도 있습니다. 예를 들어 도메인에 한가함/바쁨 캘린더 공유만 허용하는 설정이 있다고 가정해 보겠습니다. 이 경우 공개 액세스 권한을 부여하더라도 도메인 외부 사용자는 한가함/바쁨 세부정보만 볼 수 있습니다.
이벤트 공개 상태
캘린더가 공유되면 일정의 공개 상태 속성을 변경하여 캘린더의 개별 일정에 대한 액세스 권한을 조정할 수 있습니다.
이 속성은 공유되지 않은 캘린더에는 의미가 없습니다. 다음 표에는 visibility 속성의 가능한 값이 나와 있습니다.
공개 상태
의미
default
일정의 공개 상태는 캘린더의 ACL에 따라 결정됩니다. 동일한 일정의 참석자마다 ACL과 공유가 다를 수 있습니다. private 캘린더를 사용하는 사용자가 default 공개 상태를 사용하여 공개 캘린더를 사용하는 다른 사용자에게 일정 초대를 보내면 해당 참석자의 캘린더에 일정이 완전히 표시됩니다.
public
이 일정의 세부정보는 캘린더에 freeBusyReader 이상의 액세스 권한이 있는 모든 사용자에게 표시됩니다.
private
이 일정의 세부정보는 캘린더에 대한 액세스 권한이 writer 이상인 사용자에게만 표시됩니다.
[null,null,["최종 업데이트: 2025-08-29(UTC)"],[],[],null,["# Calendar sharing\n\nThere are two different ways to share calendar and event data with others.\n\nFirstly, you can *share* an entire calendar, with a specified level of access.\nFor example, you can create a team calendar, and then do things like:\n\n- Grant all members of your team the right to add and modify events in the calendar\n- Grant your boss the right to see the events on your calendar\n- Grant your customers the right to only see when you are free or busy, but not the details of the events\n\nYou can also adjust the access to individual events on the shared calendar.\n\nAlternatively, you can invite others to individual events on your calendar.\nInviting someone to an event puts a copy of that event on their calendar. The\ncopy on the attendee's calendar is visible to others according to the\nattendee's sharing configuration.\nThe invitee can then accept or reject the invitation, and to some extent also\nmodify their copy of the event --- for example, change the color it has in\ntheir calendar, and add a reminder. [Learn more about inviting users to an\nevent](/workspace/calendar/api/concepts/inviting-attendees-to-events).\n\nSharing calendars\n-----------------\n\nThe owners of a calendar can share the calendar by giving access to other\nusers. The sharing settings of a given calendar are represented by the [ACL\ncollection](/workspace/calendar/v3/reference/acl)\n(access control list) of that calendar. Each resource in the ACL\ncollection grants a specified *grantee* a certain access *role*, which is\none of those listed in the following table:\n\n| Role | Access privilege granted by the role |\n|------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `none` | Provides no access. |\n| `freeBusyReader` | Lets the grantee see whether the calendar is free or busy at a given time, but does not allow access to event details. Free/busy information can be retrieved using the [freeBusy.query](/workspace/calendar/v3/reference/freebusy/query) operation. |\n| `reader` | Lets the grantee read events on the calendar. |\n| `writer` | Lets the grantee read and write events on the calendar. This role can also see ACLs. |\n| `owner` | Provides ownership of the calendar. This role has all of the permissions of the writer role with the additional ability to manipulate ACLs. |\n\nThe possible grantees are:\n\n- another individual user\n- a user group\n- a domain\n- public (grants access to everyone).\n\nBy default, each user has owner access to their primary calendar, and this\naccess cannot be relinquished. Up to 6,000 ACLs can be added per calendar.\n\nFor Google Workspace users, there are also domain\nsettings that might restrict the\nmaximum allowed access. For example, suppose your domain has a setting that\nonly allows free-busy calendar sharing. In this case, even if you grant writer\naccess to the public, users outside the domain will only see the free-busy\ndetails.\n| **Note:** Sharing a calendar with a user no longer automatically inserts the calendar into their `CalendarList`. If you want the user to see and interact with the shared calendar, you need to call the [`CalendarList: insert()`](/workspace/calendar/v3/reference/calendarList/insert) method.\n\nEvent visibility\n----------------\n\nOnce the calendar is shared, you can adjust the access to individual\nevents on a calendar by changing the [visibility\nproperty](/workspace/calendar/v3/reference/events#visibility) of the event.\nThis property has no meaning for non-shared calendars. The following table\nlists the possible values of the visibility property:\n\n| Visibility | Meaning |\n|------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `default` | The visibility of the event is determined by the ACLs of the calendar. Different attendees of the same event can have different ACLs and sharing. If a user with a `private` calendar sends an invite to an event using `default` visibility to another user with a publicly visible calendar, the event is fully visible on that attendee's calendar. |\n| `public` | The details of this event are visible to everyone with at least `freeBusyReader` access to the calendar. |\n| `private` | The details of this event are only visible to users with at least `writer` access to the calendar. |"]]
