편집기 부가기능을 빌드하기 전에 Apps Script 할당량 및 제한사항을 검토하여 프로젝트 설계가 이러한 가이드라인을 준수하는지 확인하세요. 개발 프로세스 초기에 이러한 제한사항을 숙지하면 나중에 발생할 수 있는 문제를 방지하는 데 도움이 됩니다. Apps Script는 나, 내 팀 또는 내 조직을 위한 경량 부가기능 개발에 이상적입니다. 하지만 많은 사용자를 처리해야 하거나 지연 시간이 짧아야 하며 인프라를 완전히 제어해야 하는 대규모 부가기능을 빌드할 예정이라면 다른 런타임 환경에서 Google Workspace 부가기능을 개발해 보세요.
편집기 부가기능을 빌드할 때는 다음과 같은 일반적인 절차를 따르세요.
Apps Script 프로젝트를 만듭니다.
내장된 Apps Script HTML 서비스를 사용하여 부가기능의 모양과 동작을 정의하는 코드를 작성합니다.
부가기능을 테스트합니다.
부가기능을 게시합니다.
스크립트 프로젝트 만들기
편집기 부가기능은 독립형 Apps Script 프로젝트입니다. 독립형 스크립트 가이드에서는 새 프로젝트를 만드는 방법을 안내합니다.
새 스크립트를 열 수도 있습니다.
이렇게 하면 프로젝트 파일 (처음 이름은 Untitled project)이 루트 Drive 폴더에 배치됩니다.
공동작업
부가기능을 개발할 때 다른 사용자와 공동작업하는 경우 단일 사용자 계정이 부가기능 프로젝트를 소유합니다. 부가기능을 게시하면 단일 사용자 계정이 게시자로 작동합니다. 게시 계정에는 부가기능 스크립트 프로젝트에 대한 수정 액세스 권한이 있어야 하지만 프로젝트 소유자일 필요는 없습니다.
프로젝트 소유자가 조직을 탈퇴하여 부가기능의 코드 또는 설정에 액세스할 수 없는 상황이 발생하지 않도록 하는 것이 매우 중요합니다.
부가기능 코드에 대한 액세스 권한을 잃지 않도록 하려면 부가기능에 공동작업할 때 공유 드라이브를 사용하는 것이 좋습니다. 부가기능 스크립트 파일을 공유 드라이브에 배치하면 단일 계정이 프로젝트의 유일한 소유자가 되지 않습니다.
스크립트 프로젝트를 만든 후에는 부가기능 모양과 동작을 정의하는 코드를 작성할 수 있습니다. Apps Script HtmlService를 사용하여 기존 HTML 및 CSS를 사용하여 부가기능 사용자 인터페이스(대화상자 및 사이드바)를 구성합니다. 편집기 부가기능은 맞춤 메뉴 항목도 정의할 수 있습니다.
코딩할 때 부가기능 사용자 환경을 설계하는 방법에 관한 가이드라인은 편집기 부가기능 스타일 가이드를 참고하세요. 또한 부가기능에서 발생할 수 있는 다양한 승인 수명 주기 상태를 이해하고 이에 맞게 프로그래밍해야 합니다.
부가기능 테스트
편집기 부가기능을 게시하기 전에 테스트하여 예상대로 작동하는지 확인할 수 있습니다. 테스트하려면 테스트 구성을 만들고 테스트 문서, 스프레드시트, 양식 또는 프레젠테이션을 사용해야 합니다.
[null,null,["최종 업데이트: 2025-04-23(UTC)"],[[["\u003cp\u003eEditor add-ons are built using Apps Script, requiring a standalone Apps Script project and code for the add-on's functionality and user interface.\u003c/p\u003e\n"],["\u003cp\u003eThorough testing is crucial before publishing using a dedicated test configuration and sample documents, ensuring the add-on functions as intended.\u003c/p\u003e\n"],["\u003cp\u003eCollaboration involves shared ownership and access, recommending the use of shared drives and adding collaborators to the Cloud Platform project for sustained accessibility.\u003c/p\u003e\n"],["\u003cp\u003ePublishing makes the add-on accessible to others, either publicly or within a domain, involving a review process for public listings on the Google Workspace Marketplace.\u003c/p\u003e\n"],["\u003cp\u003eThe add-on's appearance and behavior are defined using Apps Script's HTML service, allowing for custom menus, dialogs, and sidebars constructed with HTML and CSS.\u003c/p\u003e\n"]]],["Begin by creating a standalone Apps Script project, which can be done via a new script or through specific instructions. Next, code the add-on's appearance and functionality using Apps Script's HTML service for the user interface. Before releasing, test the add-on with a test configuration and document. To make the add-on available to users, publish it on the Google Workspace Marketplace after ensuring the add-on complies with publication guidelines. Utilizing shared drives for code access is encouraged.\n"],null,["# Building Editor add-ons\n\nBefore building your Editor add-on, review the\n[Apps Script quotas and limitations](/apps-script/guides/services/quotas) to\nensure your project design aligns with these guidelines. Familiarizing yourself\nwith these limits early in your development process can help prevent potential\nissues later on. Apps Script is ideal for lightweight\nadd-on development for yourself, your team, or your\norganization. However, if you anticipate building a large-scale\nadd-on that needs to handle many users, requires low\nlatency, or demands full control over your infrastructure, consider developing\na Google Workspace add-on on a\n[different runtime](/workspace/add-ons/guides/alternate-runtimes) environment.\n\nFollow this general procedure when building an Editor add-on:\n\n1. Create an Apps Script project.\n2. Write code to define the add-on's appearance and behavior, using the built-in Apps Script [HTML service](/apps-script/reference/html).\n3. Test the add-on.\n4. Publish the add-on.\n\nCreate a script project\n-----------------------\n\nAn Editor add-on is a [standalone](/apps-script/guides/standalone) Apps Script\nproject. The standalone script guide provides\n[instructions to create new projects](/apps-script/guides/standalone#creating_a_standalone_script).\nYou can also just\n[open a new script](https://script.google.com/create).\nIf you do this, the project file (initially named `Untitled project`) is\nplaced in your root Drive folder.\n| **Note:** If you intend to publish your add-on, you must use a [standard Cloud Platform (GCP) project](/apps-script/guides/cloud-platform-projects#standard_cloud_platform_projects).\n\n### Collaboration\n\nWhen you collaborate with others in developing an add-on, a single user account\nowns the add-on project. When you publish an add-on, a single user account acts\nas the publisher. The publishing account must have edit access to the add-on\nscript project, but it doesn't need to be project owner.\n\n**It's very important to avoid situations where you lose access to an add-on's\ncode or settings because the owner of the project left your organization.**\n\nTo prevent losing access to add-on code, we encourage you to use\n[shared drives](/apps-script/collaborating#collaborating_with_shared_drives)\nwhen you collaborate on an add-on. Placing your add-on script file in a shared\ndrive ensures that no single account is the sole owner of the project.\n\nIt is also recommended that you\n[add collaborators to the script project's Cloud Platform (GCP) project](/apps-script/guides/cloud-platform-projects#adding_additional_owners_to_a_standard_gcp_project).\nThis helps ensure someone on your team always can access the add-on's\nCloud settings.\n| **Warning:** If you don't add collaborators to your add-on project, it is vital that you transfer ownership of the script project prior to the owner's account being shutdown or removed. Otherwise you could lose access to the add-on code and settings entirely.\n\nCode the add-on\n---------------\n\nOnce you have created a script project, you can begin writing\ncode to define the add-on appearance and behavior. You use the Apps Script\n[HtmlService](/apps-script/reference/html) to construct the add-on user\ninterface---[dialogs and sidebars](/workspace/add-ons/concepts/dialogs)---\nusing conventional HTML and CSS. Editor add-ons can define custom\n[menu items](/workspace/add-ons/concepts/menus) as well.\n\nAs you code, refer to the [Editor add-on style guide](/workspace/add-ons/guides/editor-style)\nfor guidelines on how to design your add-on user experience. Also, be sure\nyou understand and program for the different\n[authorization lifecycle states](/workspace/add-ons/concepts/editor-auth-lifecycle)\nyour add-on can encounter.\n\nTest the add-on\n---------------\n\nYou can test Editor add-ons before they are published to ensure they behave\nas expected. Testing requires you to create a\n[test configuration](/workspace/add-ons/how-tos/testing-editor-addons#create_a_test_configuration)\nand use a testing document, spreadsheet, form, or presentation.\n\nSee [Test an Editor add-on](/workspace/add-ons/how-tos/testing-editor-addons)\nfor details.\n\nPublish the add-on\n------------------\n\nPublishing your add-on makes it available to others, either publicly or just\nusers in your domain. Before you start the publishing process, be sure to\nreview the [publication overview](/workspace/add-ons/how-tos/editor-publish-overview).\n\nEditor add-ons are published to the [Google Workspace Marketplace](https://workspace.google.com/marketplace/). Publicly available add-ons\nmust complete [add-on review](/workspace/marketplace/about-app-review) before they are published.\n\nSee [Publishing an Editor add-on](/workspace/add-ons/how-tos/publishing-editor-addons)\nfor more details."]]
