모든 Asana 배포에는 관리 콘솔이 있습니다. 여기에서 IT 관리자는 비밀번호 요구 사항, 역할 및 권한, Dropbox에서 파일을 첨부할 수 있는지 여부, 기본 설정으로 새 프로젝트를 볼 수 있는 사용자 등 회사가 Asana를 사용하는 방식을 설정합니다.
Asana가 성장함에 따라 관리 콘솔에는 수년간의 사용자 지정 로직과 일회성 조각 작업이 축적되어 관리 제어를 구축하고 유지하는 데 드는 비용이 점점 더 많이 들게 되었습니다. 관리 설정 중 하나인 새 프로젝트의 기본 공개 범위를 예로 들어보겠습니다. 관리자는 새 프로젝트가 조직 전체에 표시되도록 할지, 팀에 표시되도록 할지, 아니면 초대된 멤버에게만 비공개로 설정할지 선택합니다. 설명하기는 간단하지만, 그 안에는 많은 복잡성이 숨어 있습니다.
이 기능이 고객의 플랜에 포함되어 있나요?
고객이 이전에 해당 기능에 대해 비용을 지불하다가 중단한 후 더 이상 변경할 수 없는 설정에 갇혀 있나요?
고객이 HIPAA 또는 FedRAMP 고객인가요? 그렇다면 상위 역할만 편집할 수 있습니다.
다른 설정으로 인해 한 가지 선택을 사용할 수 없게 되었나요?
현재 제한 사항을 설명하기 위해 정보 배너를 표시해야 할까요?
관리 제어를 추가하려는 모든 팀은 이 모든 것을 올바르게 설정해야 했습니다. 대부분의 팀은 그럴 가치가 없다고 판단했고, 시간이 지남에 따라 Asana가 할 수 있는 것과 관리자가 관리할 수 있는 것 사이의 격차가 커졌습니다. 이는 일부 제어 기능이 회사 전체 수준에서만 구성될 수 있다는 점에서 잘 드러납니다. 따라서 IT 관리자가 사용자 중 일부에게만 제어 기능을 적용하기가 어렵습니다.
다음은 프로젝트 개인 정보 보호 설정 대화 상자의 스니펫으로, 해당 설정을 비활성화해야 하는지 여부와 배너를 표시해야 하는지 여부를 판단하는 데 사용됩니다.
여기에는 기능 라이선싱, 거버넌스, 배포 구조로 인한 재정의, 사용자 역할(특히 검토자) 등 분석해야 할 논리가 많습니다. 꼼꼼하게 확인하려면 테스트 매트릭스를 머릿속에서 다시 구성하여 올바른지 판단해야 합니다.
그리고 이것은 단지 대화 상자일 뿐입니다. 행이 설정 페이지에 표시되는지 여부는 다른 곳에서 결정되었으며, 또한 일관성이 없습니다.
세 개의 행, 세 개의 메커니즘, 그리고 게이팅이 항상 동일한 파일에 있는 것은 아닙니다. 따라서 "이 고객이 실제로 어떤 설정을 볼 수 있나요?"라는 질문에 답하려면 모든 행을 읽어야 할 뿐만 아니라 모든 구성 요소를 훑어봐야 했습니다. 이러한 질문은 꽤 자주 제기됩니다. 고객 지원팀은 고객에게 설정이 사라진 이유를 설명하려고 하고, PM은 새로운 제어 기능이 신속하게 변경되는 것인지 아니면 2주가 소요되는 것인지에 대한 명확한 답변을 원하며, 신규 입사자는 특정 사용자가 무엇을 볼 수 있는지 결정하는 단일 지점을 찾으려고 합니다.
전체적으로 보면, 관리 콘솔에서 작업하는 데 비용이 많이 드는 네 가지 이유가 있었습니다.
검토에 많은 비용이 듭니다. 로직은 작성자가 배치한 곳에 존재했기 때문에 PR이 검토자에게 명확하지 않은 상태에서 특수한 동작을 도입할 수 있었고, 단순히 읽기만 해서는 정확성을 쉽게 확인할 수 없었습니다.
표준화가 부족하여 버그가 가려졌습니다. 오랫동안 지속되어 온 버그가 있었는데, 이를 포착하기가 어려웠습니다. 많은 부분이 맞춤형 구현이 여기저기 촘촘하게 적용되면서 제품 사양과 구현 간의 괴리로 인해 발생했습니다. 팀이 임의로 결정을 내렸기 때문에 모든 컨트롤에 고유한 특성이 있었습니다.
변경 비용이 많이 듭니다. 최종 사용자를 위해 한 가지 변경 사항을 적용하려면 규칙이 코딩된 모든 위치를 찾아야 했으며, 정의가 한 곳에만 있는 경우는 거의 없었습니다.
테스트 비용이 많이 듭니다. 테스트를 설정하려면 백엔드 상태에 대한 심층적인 지식이 필요했으며, 상호 작용하는 차원의 수가 많아 최종 배포에 대한 포괄적인 수동 테스트는 불가능했습니다.
프레임워크 소개
저희는 코드베이스에서 단일 정보 소스의 역할을 할 수 있도록 관리 제어를 위한 선언적 프레임워크를 만들었습니다. 이제 제어는 다음과 같이 정의됩니다.
여기에 있는 모든 필드는 위의 대화 상자의 브랜치에 매핑됩니다. requiredAdminRole은 HIPAA/슈퍼 관리자 확인이고, upsellBehavior는 두 개의 상향 판매 브랜치이며, churnBehavior는 이탈 고객 케이스로, 이탈 고객이 기본 설정을 복원할 수 있도록 하고 다른 것은 허용하지 않습니다.
이러한 과정의 일환으로, 프레임워크는 엔지니어가 컨트롤의 계산된 상태를 도출하는 데 사용하는 훅을 노출합니다. 이제 동일한 프로젝트 개인 정보 보호 대화 상자가 어떻게 표시되는지 살펴보겠습니다.
배너 if-체인은 중앙 집중식 훅에 의해 구동되는 하나의 공유 컴포넌트로 축소되었습니다. 프레임워크는 다양한 모든 시나리오의 조합 논리를 처리하며, 관리 제품을 깊이 이해하고 이를 유지 관리할 책임이 있는 SME는 자신 있게 대대적인 변경을 할 수 있습니다. 이제 우리는 엄격한 타이핑을 사용하여 구현자들이 모든 가능한 시나리오에서 설정을 올바르게 렌더링하는 데 필요한 필수 정보를 입력하도록 안내합니다. 가장 중요한 것은, 구현자들이 이러한 시나리오의 복잡성이나 상호 작용 방식을 이해할 필요가 없다는 점입니다.
이러한 설정은 관리 콘솔 UI의 행을 통해 액세스할 수 있습니다. 이러한 행의 가시성에도 동일한 처리가 적용되었으며, 바로 여기서 두 번째 프레임워크가 등장합니다. 설정 레지스트리의 행은 자체 표시 규칙을 설명하지 않고 대신 이를 나타내는 제어 기능에 연결합니다.
컨트롤 배열은 부가 가치입니다. 이 배열은 대화 상자가 useAdminConsoleControl에 전달하는 것과 동일한 ProjectDefaultPrivacy 객체를 보유하며, 레지스트리는 이를 동일한 정보 소스를 통해 실행하므로 페이지와 대화 상자가 서로 다를 수 없습니다. 이전에는 별도로 계산되었기 때문에 불일치가 두 가지 실패 모드로 이어질 수 있었습니다. 즉, 행은 표시되지만 사용할 수 없는 대화 상자를 열거나, 고객이 비용을 지불하는 설정인데도 해당 설정에 도달할 수 있는 행이 없는 경우가 발생할 수 있었습니다. 이를 중앙 집중화함으로써 이러한 유형의 버그가 사라졌습니다.
중앙 집중식 프레임워크를 채택한 테스트는 PR 검토자 경험을 크게 향상시켰습니다. 예를 들어, 행 가시성 테스트를 통해 앞서 언급한 "이 고객이 실제로 어떤 설정을 볼 수 있나요?"라는 질문에 답할 수 앞서 언급한 질문에 답합니다. 테스트 코드 대신 시나리오는 단순히 데이터입니다. 즉, 페르소나, 도메인 상태, 그리고 시나리오가 렌더링되는 페이지입니다.
그리고 행은 해당 행이 표시되어야 하는 명명된 시나리오를 단순히 나열합니다.
작성할 렌더링 호출이나 어설션이 없습니다. 동적 테스트 도구 모음은 카탈로그를 읽고 각 행을 이름이 지정된 모든 시나리오와 비교하여 확인합니다. 이제 카탈로그는 고객이 보는 내용을 한 곳에서 확인할 수 있는 곳이며, 기계에 의해 검사됩니다. 더 이상 성실한 코드 검토자나 작성자가 자신의 테스트 케이스를 올바르게 식별하고 작성하도록 의존할 필요가 없습니다.
AI의 세계에서
당사는 SME가 아닌 엔지니어가 관리 콘솔에서 자신 있게 구축할 수 있도록 지원할 필요가 있을 것으로 예상했기 때문에 2025년 말에 이 작업을 시작했습니다. 당시 목표는 LLM 성능을 최적화하는 것이 아니었지만, 엔지니어의 경험을 표준화하고 간소화하는 것이 AI 에이전트에게도 동일한 효과를 발휘하는 것으로 나타났습니다.
이러한 프레임워크를 구축하기 전에, 저희는 이 마이그레이션 문제에 AI를 적용해 보았고, 기술적으로는 효과가 있었습니다. 문제는 에이전트와 검토자 모두 테스트가 실제로 올바른지 여부를 알 수 없다는 것이었습니다. 이는 잘못된 자신감과 눈에 띄지 않는 격차를 의미했습니다. AI는 구조의 부족을 해결하지 못합니다. 단순히 기존 구조 위에 더 많은 코드를 더 빠르게 생성할 뿐입니다. Google은 AI 지원 개발에서 Go의 타입 시스템에 대해 비슷한 주장을 펼쳤습니다. LLM은 속성을 환각하고 파일 간에 타입이 일치하지 않는 경향이 있으므로 정적 타입은 자동화된 안전망 역할을 합니다. TypeScript는 Go만큼 정적으로 엄격하지 않지만, 프레임워크는 이를 기반으로 동일한 보장을 구축할 수 있습니다. 프레임워크 수준에서 컨트롤의 타입을 한 번 정의하면 모든 구현이 사용 지점에서 해당 타입에 맞아야 합니다.
프레임워크가 준비되자, 우리는 위임과 병렬화를 준비하기 시작했습니다. 저는 처음부터 끝까지 작업을 수행하는 스킬을 구축하기 위해 새로운 사양 기반 개발 도구 [링크 자리 표시자: 사양 기반 개발에 대한 영어 블로그 게시글: Asana 엔지니어링 블로그 - 사양 기반 개발: 장점]를 사용했습니다. 이 도구는 전체 변환을 인코딩합니다. 즉, 컨트롤을 정의하고, 후크를 호출하고, 배너를 교체하고, 프래그먼트를 업데이트하고, 새로운 선언적 테스트를 추가하며, 여기에 더해 이전 변환에서 발생한 예외 사례에 대한 자체 업데이트 체크리스트와 로그를 추가합니다. 약 150건의 모든 마이그레이션에서 91%가 검토 후 수정이 필요하지 않았습니다.
에이전트를 시작하여 PR을 작성하는 데 많은 작업량이 소요되지 않으며, 해당 PR을 검토하는 데도 많은 작업량이 소요되지 않습니다. 모든 것이 예측 가능한 방식으로 선언되므로, 검토자가 구현이 제품 사양과 일치하는지 확인하기 위해 관리 분야의 SME일 필요가 없습니다. 무엇보다도, 이를 통해 적격한 검토자 풀이 훨씬 더 많은 엔지니어 그룹으로 확대되어 PR을 생성하는 상위 단계의 유입 경로를 넓히는 것보다 속도를 더 높일 수 있습니다. 이 시대에 리뷰를 재고하는 것은 저희뿐만이 아닙니다. GitHub는 인간 리뷰어가 더 빠르게 올바른 질문에 도달할 수 있도록 구조화된 PR 증거를 중심으로 Copilot의 자체 리뷰 에이전트를 재구성하여 리뷰 비용을 약 20% 절감했습니다.
여러 프레임워크에 걸친 약 150개의 항목에 대한 기존 마이그레이션은 처음부터 끝까지 수동적이고 일회성인 엔지니어링 작업으로 범위가 정해졌습니다. 먼저 프레임워크를 구축한 다음, 나중에 에이전트를 모니터링하는 엔지니어에게 마이그레이션을 위임함으로써 전체 작업량을 원래 계획보다 한 달 이상 앞당겨 완료할 수 있었습니다.
다음 단계는 무엇인가요?
이러한 프레임워크를 구축하는 것은 그 자체로 프로젝트가 아니었습니다. 이는 병렬화 및 확장이 필요한 로드맵에서 비롯된 필요성에서 비롯되었으며, 그 과정에서 인력이 제한적이고 변화했으며, 모든 기여자가 먼저 해당 분야의 전문가가 될 필요가 없었습니다. 우리는 이미 이를 구축한 팀을 넘어 그 효과를 확인할 수 있었습니다. 오늘날 프레임워크에 있는 66개의 제어 중 18개는 8개 팀의 엔지니어들이 작성한 것입니다.
이제 우리는 이러한 종류의 투자를 할 다음 영역을 찾고 있습니다. 오히려 지금은 우리가 시작하기 전보다 더 강력한 근거가 있습니다. 잘 설계된 선언적 프레임워크는 검토를 더 쉽게 할 뿐만 아니라 에이전트가 신뢰할 수 있는 결과물을 내놓을지, 아니면 그저 빠른 결과물만 내놓을지를 결정합니다. 또한 이는 자율적인 검토를 가능하게 할 수 있는 요소이기도 합니다. Cloudflare는 AI 검토자가 깨끗한 코드를 승인하고 실제 문제를 스스로 차단하는 시스템을 구축했으며, 이는 입력 데이터가 검토자가 신뢰할 수 있을 만큼 체계적으로 구성되어 있기 때문에 가능한 일입니다. 우리의 것이 동일한 작업을 시도할 만큼 충분히 체계적인지 여부는 다음으로 다룰 만한 좋은 질문입니다.
작성자 소개
Leo Zhang은 IT 관리자가 조직을 관리할 수 있도록 지원하는 관리자 기반 팀의 소프트웨어 엔지니어입니다. 현재 그는 당사 제품을 뒷받침하는 기술적 프레임워크에 투자하여 관리 콘솔에서 다른 제품 엔지니어의 개발 경험을 개선하고 있습니다.
팀에 대한 감사 인사
이러한 변경 사항을 설계, 구현, 테스트하고 공유하는 데는 팀의 엄청난 작업량이 필요했습니다. 이는 관리자 기반 팀의 다른 엔지니어인 Yunus Rahbar, Maryam Booshehrian, Saverio Castelli, Bronwyn Damm, Cindy Yu, Calvin Norton, Jaxsun McCarthy Huggan의 기여로 가능했습니다. 에이전트 성공 타이거 팀의 Walter Li 님은 이러한 마이그레이션에 적합한 AI 도구를 설정하는 데 큰 도움을 주었습니다.
참조
Lan Cheng, Emerson Murphy-Hill, Mark Canning, Ciera Jaspan, Collin Green, Andrea Knight, Nan Zhang, Elizabeth Kammer, "Google에서 개발자 생산성을 향상시키는 요소는 무엇인가? 코드 품질," ESEC/FSE '22, 2022년 11월. https://doi.org/10.1145/3540250.3558940
"Orchestrating AI Code Review at Scale," Cloudflare 블로그, 2026년 4월. https://blog.cloudflare.com/ai-code-review/
Napalys Klicius, "더 나은 툴이 Copilot 코드 리뷰를 더 악화시켰습니다. 다음은 실제로 이를 개선한 방법입니다." The GitHub Blog, 2026년 7월. https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/
"Go가 AI 지원 소프트웨어 엔지니어링에 이상적인 언어인 이유," Google Developers Blog, 2026년 8월. https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/
