toss·2026년 8월 11일·6분 읽기큐레이션 요약

토스의 속도와 품질, 상용 도구로 충분한가 — 토션(Tossion)

토션(Tossion)은 흩어진 자동화·수동 테스트 결과와 테스트 케이스를 하나의 플랫폼에서 연결하고, QA 조직이 필요한 기능을 직접 빠르게 확장하기 위해 만든 테스트 관리 플랫폼입니다. 테스트 런에는 당시의 테스트 케이스와 판정 근거를 스냅샷으로 보존해 과거 결과의 신뢰성을 확보하고, AI·PR 분석·실기기 자동화까지 하나의 흐름으로 통합했습니다. 토스는 상용 TCM의 기능을 사용하는 데 그치지 않고, 빠른 개발 속도와 품질 기준에 맞춰 플랫폼 자체를 계속 진화시키는 것을 목표로 합니다. ## 흩어진 테스트 정보를 하나의 기록으로 통합 - 기존에는 자동화 테스트 결과, 매뉴얼 테스트 결과, 테스트 케이스와 판단 근거가 서로 다른 곳에 흩어져 과거 결과를 확인하는 데 시간이 걸렸습니다. - 토션의 기본 구조는 **프로젝트 → 스위트 → 섹션 → 테스트 케이스**이며, 섹션은 트리 구조로 관리됩니다. - 테스트 케이스는 제품 변화에 따라 수정·삭제되지만, 테스트 런은 당시 검증 내용을 보존하기 위해 별도로 축적됩니다. - 테스트 런을 생성할 때 테스트 케이스를 단순 참조하지 않고 다음 정보를 복사해 독립적인 행으로 저장합니다. - Assignee - Test Step - Description - 테스트 런의 각 행에는 상태 변경 이력이 쌓이며, 누가 언제 어떤 Version에서 어떤 판단을 했는지 확인할 수 있습니다. - 섹션을 직접 선택한 테스트 케이스에는 Type·Platform 등의 필터를 적용하지 않습니다. 명시적인 선택이 자동 조건보다 우선하기 때문입니다. ## 테스트 런의 스냅샷과 변경 이력 - 테스트 런은 **Active → Completed → Closed** 상태로 진행됩니다. - Closed 시점에 테스트 케이스, 코멘트, 자동화 결과를 스냅샷으로 저장합니다. - 이후 원본 테스트 케이스가 수정되거나 삭제되어도 종료된 테스트 런의 화면과 리포트는 변하지 않습니다. - 이를 통해 “지난달에는 무엇으로 검증했는가”라는 질문에 당시 상태 그대로 답할 수 있습니다. ## 빠른 피드백을 반영하는 협업 기능 - Assignee별로 전체 테스트 수와 남은 테스트 수를 보여 주는 진척도 차트를 제공합니다. - Status, Type, Assignee, Version, Platform, RNR, History 등 실제로 필요한 필드만 추가·유지합니다. - 여러 사용자가 같은 테스트 런을 동시에 사용할 수 있도록 다음 기능을 제공합니다. - 현재 접속 중인 사용자 아바타 표시 - 사용자별 색상 구분 - 편집 중인 테스트 케이스와 Description 잠금 - 창을 닫거나 연결이 끊기면 잠금 자동 해제 - 다른 사용자의 Status 변경을 새로고침 없이 반영 - 핵심은 기능의 규모보다 사용자 요청을 개발·배포·활용하는 시간이 짧다는 점입니다. ## 상용 TCM 대신 직접 만든 플랫폼 - 토스의 빠른 개발 속도에서는 품질 검증도 같은 속도로 변화해야 하며, 품질이 속도의 희생양이 되어서는 안 됩니다. - 상용 도구는 제공 업체가 정한 기능과 로드맵 안에서만 사용할 수 있습니다. - 토스가 필요로 한 것은 정해진 기능을 제공하는 도구가 아니라, 새로운 요구를 즉시 추가할 수 있는 플랫폼이었습니다. - 이를 기반으로 다음 기능을 직접 추가했습니다. - 릴리즈 PR 분석 - AI 기반 테스트 케이스 생성 - 실기기 회귀 테스트 실행 - 자동화 결과를 수동 테스트 케이스별로 기록 ## 릴리즈 PR 분석과 QA 범위 결정 - RC 빌드나 릴리즈 마일스톤에 포함된 PR을 모두 수집해 QA 라벨이 있는 PR과 없는 PR로 나누어 분석합니다. - QA 라벨이 있는 PR은 검증 관점을 정리하고, 라벨이 없는 PR은 정말 QA 검증이 필요 없는지 다시 확인합니다. - 분석 목적은 기능 요약이 아니라 “이번 릴리즈에서 반드시 확인해야 할 항목”을 찾는 것입니다. - QA 서버의 Agent가 토션에 등록된 작업을 주기적으로 확인하고, 작업을 받으면 서버에 로그인된 AI를 실행합니다. - 수백 개의 PR을 한 번에 처리하지 않고 여러 묶음으로 나누어 병렬 분석합니다. - AI 결과는 다음과 같은 규칙으로 검증합니다. - 화면명이나 구체적인 조건이 없는 모호한 문장 - PR 제목을 그대로 옮긴 요약 - 함수명이 그대로 남은 설명 - 재현 단계·기대 결과·실패 증상·판단 근거가 빠진 테스트 케이스 - 부적합한 결과는 AI가 다시 분석합니다. - 병합된 PR 수와 분석 결과 수를 대조해 누락된 PR이 있으면 해당 항목만 재처리합니다. - 과거 장애가 발생한 파일 목록과 이번 PR의 변경 파일을 비교해 위험도를 조정합니다. - 결과는 묶음 단위로 토션에 저장해 중단 시에도 완료된 분석을 보존하고, 재실행할 때 이미 처리한 PR은 건너뜁니다. - 최종적으로 추려진 항목은 Sprint 테스트 런의 범위와 검증 근거가 됩니다. ## AI 기반 테스트 케이스 생성 - 기능 개발 속도를 사람이 따라가기 어렵기 때문에 AI가 테스트 케이스를 생성해 토션에 등록합니다. - AI는 “자산 > 계좌 연결 > 은행 선택”처럼 경로를 출력하고, 토션이 이를 실제 섹션 트리로 변환합니다. - 기존 섹션이 있으면 재사용하고, 없으면 중간 단계를 포함해 새로 생성합니다. - 결과의 신뢰성을 확보하기 위해 세 겹의 검증을 적용합니다. 1. AI가 누락된 분기·에러 상황·경계값을 스스로 재검토 2. 표기 규칙, 테스트 케이스 번호, 화면 누락, 요구사항 반영 여부를 스크립트로 검증 3. 별도의 AI가 테스트 계획을 작성해 범위와 위험 요소, 적용할 테스트 기법을 정의 - 테스트 계획과 실제 테스트 케이스를 비교해 다음을 확인합니다. - 계획에는 있지만 테스트 케이스에 없는 항목은 누락 - 테스트 케이스에는 있지만 계획에 없는 항목은 범위 이탈 - 화면 중심으로만 테스트하면 상태 전이처럼 화면에 드러나지 않는 테스트 축을 놓칠 수 있습니다. - 따라서 테스트 계획에서 상태 전이, 경계값 등 필요한 테스트 기법을 먼저 지정하고, 테스트 케이스가 이를 모두 포함하는지 확인합니다. - AI의 토션 접근은 화면이 아닌 CLI로 제한하고, 환경 차이로 인한 설치·런타임·경로 문제를 줄이기 위해 단일 실행 파일로 배포합니다. ## 토션에서 실기기 회귀 테스트 실행 - 신규 기능은 사람이 직접 검증하고, 안정화된 테스트 케이스는 회귀 자동화 대상으로 편입합니다. - 토션의 실행 화면에서 다음 항목을 선택해 바로 테스트를 시작합니다. - 대상 기기 - 빌드 - 실행 범위 - 결과를 연결할 테스트 런 - QA 서버의 러너는 Android·iOS 실기기를 관리하며, 스스로 토션에 등록되지만 관리자 승인 전에는 작업을 받지 않습니다. - 러너는 주기적으로 연결된 기기 상태를 보고하므로 실행 가능한 기기를 화면에서 확인할 수 있습니다. - 토션이 발급한 빌드를 설치해 실행함으로써 어떤 빌드에서 나온 결과인지 명확히 유지합니다. - 전체 회귀 또는 특정 섹션만 선택해 실행할 수 있습니다. - 테스트 중에는 시나리오별 통과·실패 여부, 실행 시간, 오류 메시지가 실시간으로 기록됩니다. - 결과는 시나리오가 아니라 **스텝 단위**로 저장됩니다. - 상태 - 소요 시간 - 오류 메시지 - 해당 시점의 스크린샷 - 시나리오 단위 영상 - 실행 결과를 특정 테스트 런에 연결하면 자동화 결과가 수동 테스트 기록의 각 테스트 케이스에 직접 반영됩니다. ## 자동화 결과를 테스트 케이스와 연결 - 별도 자동화 리포트에 “200건 중 3건 실패”라고만 표시하면 어떤 수동 테스트 케이스가 실패했는지 사람이 다시 대조해야 합니다. - 이를 해결하려면 양방향 연동이 필요합니다. - 테스트 케이스를 자동화 코드로 변환 - 자동화 결과를 다시 테스트 케이스별 기록으로 저장 - 토션은 자동화 결과를 테스트 케이스 한 건 단위까지 내려보내 수동 검증 기록과 자동화 실행 결과를 같은 맥락에서 확인할 수 있도록 설계되었습니다. - 제공된 글은 이 자동화 코드 생성 기능의 상세 구현 설명 직전에서 끝납니다. 토션의 핵심은 테스트 관리, AI 분석, 테스트 생성, 실기기 자동화를 각각 분리하지 않고 하나의 테스트 런과 테스트 케이스 흐름으로 연결한 데 있습니다. 유사한 플랫폼을 구축할 때도 먼저 결과의 스냅샷·이력 보존을 설계하고, 이후 AI와 자동화를 기존 기록 구조에 연결하는 방식이 실용적입니다.

원문 읽기(새 탭에서 열림)

cliAIAndroidiOS+3

cloudflare·2026년 7월 27일·3분 읽기큐레이션 요약

프라이버시 프록시 CLI를 오픈 소스로 공개합니다

Oblivious HTTP(OHTTP)는 여러 주체와 바이너리 인코딩을 거치기 때문에 장애 원인을 추적하기 어렵다. Cloudflare는 실제 운영 경험을 바탕으로 전체 OHTTP 요청 과정을 한 번에 실행하고 각 단계를 확인할 수 있는 오픈소스 CLI 도구 `pvcli(privacy-client)`를 만들었다. 이 도구는 복잡한 수작업과 일회성 스크립트를 줄여 개발·테스트·장애 대응을 단순화한다. ### OHTTP가 제공하는 프라이버시 구조 - OHTTP는 요청을 보낸 사람과 요청 내용을 한 주체가 동시에 알 수 없도록 설계된다. - 서로 충돌하지 않는 두 운영 주체가 필요하다. - **Relay**: 클라이언트의 신원을 gateway에 전달하지 않음 - **Gateway**: 요청을 복호화해 실제 대상 서버로 전달 - 일반적인 요청 흐름은 다음과 같다. - 클라이언트가 gateway의 공개 키를 가져온다. - 클라이언트가 HTTP 요청을 암호화해 relay로 보낸다. - relay가 클라이언트 식별 정보를 제거하고 gateway로 전달한다. - gateway가 요청을 복호화해 target 서버에 전송한다. - target의 응답을 gateway가 다시 암호화한다. - relay가 암호화된 응답을 클라이언트에 전달한다. - 클라이언트가 응답을 복호화한다. - 각 단계가 별도의 장애 지점이므로, 문제가 relay·gateway·target 중 어디에서 발생했는지 확인하기 어렵다. ### 기존 디버깅 방식의 문제 - 고객 환경에서 실제 end-to-end 테스트를 수행하려면 배포별 맞춤 클라이언트를 일회성으로 작성해야 했다. - 장애 발생 시 자체 시스템의 문제인지 고객 시스템의 문제인지 판별하는 데 시간이 많이 걸렸다. - OHTTP는 바이너리 HTTP를 사용하므로 원시 바이트를 직접 분석해야 했다. - 공개 키, 바이너리 HTTP 요청, 암호화된 OHTTP 메시지를 RFC에 따라 수작업으로 해석해야 했다. - 사람이 긴 hexadecimal 문자열을 직접 검증하는 과정은 번거롭고 실수하기 쉽다. ### 공개 키와 바이너리 HTTP의 수동 분석 - gateway에서 받은 공개 키 설정은 긴 hexadecimal 데이터로 반환된다. - RFC 9458에 따라 다음 필드를 직접 해석해야 한다. - `0029`: 공개 키 항목의 길이 - `55`: 공개 키 ID - `0020`: DHKEM(X25519, HKDF-SHA256) 비대칭 암호 방식 - 뒤따르는 32바이트: 실제 공개 키 - `0004`: 대칭 암호 방식 ID 영역의 길이 - `0001`, `0001`: HKDF-SHA256 및 AES-128-GCM 식별자 - 원래의 HTTP 요청도 RFC 9292의 바이너리 HTTP 형식으로 변환해야 한다. - 예를 들어 `POST`, `https`, 호스트명, 경로, 헤더와 본문이 각각 바이너리 필드로 인코딩된다. - 이후 공개 키를 이용해 바이너리 HTTP 요청을 OHTTP 형식으로 암호화하고, 키 ID와 암호 방식 ID를 포함한 헤더를 붙여 relay에 보낼 wrapper HTTP 요청을 만들어야 한다. ### `pvcli`의 역할 - Cloudflare는 이러한 프라이버시 프로토콜 관련 기능을 하나의 CLI에 통합했다. - 익숙한 HTTP 클라이언트 인터페이스를 제공하면서 OHTTP의 각 처리 단계를 순서대로 표시한다. - relay, gateway, origin으로 이어지는 전체 요청을 단일 명령으로 실행할 수 있다. - 예시 명령은 다음 작업을 수행한다. - `--first-hop`: relay 지정 - `--proxy`: gateway 지정 - `-X POST`: HTTP 메서드 지정 - `--header`: 요청 헤더 지정 - `--data`: JSON 요청 본문 지정 - 대상 URL: gateway가 요청을 전달할 origin - 따라서 사용자는 공개 키 조회, 바이너리 HTTP 변환, OHTTP 암호화, relay 전달, 응답 복호화 과정을 각각 수동으로 구현할 필요가 없다. ### 공개와 활용 - 도구 이름은 `privacy-client`, 실행 파일은 `pvcli`다. - Apache-2.0 라이선스로 공개되며 외부 기여를 허용한다. - 새로운 프라이버시 프로토콜이나 다양한 네트워크 아키텍처를 지원할 수 있도록 확장성을 고려했다. - 운영 환경과 유사한 end-to-end 테스트 및 장애 재현에 활용할 수 있다. 복잡한 OHTTP 시스템을 운영하거나 연동한다면, 원시 바이트와 RFC를 직접 해석하는 방식보다 `pvcli`로 전체 경로를 재현하는 것이 효율적이다. 특히 relay·gateway·origin 중 장애 위치를 빠르게 좁혀야 하는 개발 및 incident response 상황에서 유용하다.

원문 읽기(새 탭에서 열림)

clicryptographyoblivious-httpbinary-http+3

toss·2026년 6월 23일·3분 읽기큐레이션 요약

5. Technical Writer, 사라질 결심

AI 시대에 문서는 조직의 맥락을 AI에 전달하는 핵심 수단이므로, AI가 문서를 잘 만들고 관리하도록 문서화 원칙과 사례를 학습시켜야 한다. 토스는 소수의 Technical Writer(TW)만으로 수천 명의 문서를 관리할 수 없다는 문제를 해결하기 위해, TW의 역할을 AI Skill로 자동화하려 했다. 하지만 Skill을 만들어 공개하는 것만으로는 사용률이 높아지지 않았고, 사용자가 직접 설치·호출하고 자료를 준비해야 하는 불편함이 주요 장애물로 드러났다. ## AI에게 TW의 암묵지 전달하기 - 기존 TW의 리뷰 코멘트를 분석해 문서를 바라보는 관점과 테크니컬 라이팅 원칙을 추출했다. - 기존 가이드를 AI가 기계적으로 적용하지 않도록 각 원칙에 다음을 함께 제공했다. - 잘못된 예시 - 올바른 예시 - 왜 그렇게 작성해야 하는지에 대한 설명 - 자주 작성하는 문서 유형별 템플릿을 만들었다. - ADR 템플릿에는 다음과 같은 필수 섹션을 명시했다. - 개요 - 맥락 - 고려한 선택지와 장단점 - 최종 결정 - 결정 근거 - 반드시 들어가야 하는 섹션에는 `(required)`를 붙여 AI가 핵심 정보를 누락하지 않게 했다. - 문서 유형과 템플릿을 함께 제공해 AI가 구조와 작성 목적을 이해하도록 했다. ## 문서 작성 Skill 구축 TW가 문서 작성을 지원하는 과정을 네 단계로 분해해 AI Skill에 반영했다. - **목적과 배경 확인** - 서비스·프로젝트명 - 문서 목적 - 대상 독자 - 필요한 상세 수준 - 참고 자료 - 예상 문서 구조를 질문한다. - **문서 구조 결정** - 템플릿이 없으면 개요, 핵심 내용, 부가 정보 순서로 기본 구조를 만든다. - 적합한 템플릿이 있으면 온보딩 가이드, 회의록, PRD 등 문서 유형별 템플릿을 참고한다. - **본문 작성** - 테크니컬 라이팅 원칙과 MDX 규칙에 따라 내용을 채운다. - 템플릿은 문서의 목적과 유형에 맞을 때 보조적으로 사용한다. - **점검** - 어색한 표현이나 누락된 정보를 확인한다. - 필수 정보가 부족하면 추측하지 않고 질문이나 주석으로 남긴다. - 선택 항목은 근거 자료가 없을 경우 빈 섹션으로 만들지 않는다. 사용자는 AI가 묻는 질문에 답하기만 하면 되므로, TW와 대화하듯 문서 초안을 완성할 수 있도록 설계했다. ## 문서 리뷰 Skill의 시행착오 처음에는 기존 리뷰 코멘트를 체크리스트로 바꿔 AI가 모든 항목을 점검하게 했다. 그러나 AI가 중요한 문제는 놓치고, 실제로 필요하지 않은 코멘트를 억지로 생성하는 문제가 발생했다. - 잘 작성된 문서의 기준은 어느 정도 정형화할 수 있다. - 반면 잘못된 문서의 문제는 문서마다 다르게 나타난다. - 목적은 명확하지만 논리 흐름이 어색한 경우 - 논리는 자연스럽지만 독자에게 전달할 가치가 빠진 경우 - 따라서 고정된 체크리스트만으로는 다양한 문서 문제를 효과적으로 찾기 어려웠다. 이를 해결하기 위해 AI가 원칙을 참고해 자율적으로 판단하는 리뷰 워크플로를 만들었다. - 테크니컬 라이팅 원칙 파일을 먼저 읽는다. - 문서를 원칙에 비추어 스스로 검토한다. - 문제라고 판단한 이유와 수정 초안을 코멘트로 작성한다. - 마지막에 체크리스트로 누락을 한 번 더 확인한다. 기존 리뷰 코멘트는 단순 점검 목록이 아니라, 원칙이 실제 문서에 어떻게 적용되는지 보여주는 예시로 활용했다. 예를 들어 `date: string`처럼 이름과 타입만 적는 대신, 의미·허용 형식·사용 예시까지 함께 작성하도록 가르쳤다. ## Skill만 공개해서는 충분하지 않았다 두 가지 Skill을 만들어 사내에 공개했지만, 기대만큼 사용되지 않았다. - 사용자가 직접 Skill을 다운로드하고 설치해야 했다. - 비개발자에게 CLI 기반 설치 과정이 낯설고 어려웠다. - Skill을 설치한 뒤에도 문서를 작성할 때마다 사용자가 AI Skill을 떠올리고 직접 호출해야 했다. - 문서 작성에 필요한 코드, 기획서, 기존 문서, Slack 링크 등의 자료도 사용자가 직접 찾아 AI에게 전달해야 했다. - 결국 자동화된 기능이 있어도 실제 업무 흐름과 분리되어 있으면 사용자가 추가로 수행해야 하는 일이 많았다. 따라서 문서 자동화의 핵심은 좋은 프롬프트나 Skill을 만드는 데서 끝나지 않는다. 사용자가 별도로 설치하거나 기억하거나 자료를 수집하지 않아도, 실제 업무 과정에서 자연스럽게 AI가 문서 작성과 리뷰를 지원하도록 연결해야 한다.

원문 읽기(새 탭에서 열림)

cliAI프롬프트 엔지니어링technical-writing+3

cloudflare·2026년 4월 13일원문

클라우드플레어 전체를 위한 CLI 구축하기 (새 탭에서 열림)

Cloudflare는 100개 이상의 제품과 3,000여 개의 API 작업을 아우르는 거대한 생태계를 단일화하기 위해 Wrangler CLI를 전면 재구축하고 있습니다. 특히 AI 에이전트가 주요 사용자로 부상함에 따라, 모든 제품을 CLI, SDK, Terraform 등 다양한 인터페이스에서 일관되게 사용할 수 있도록 하는 것을 목표로 합니다. 이를 위해 새로운 TypeScript 기반 스키마 시스템을 도입하여 코드 생성 파이프라인을 자동화하고 개발 생산성을 높이고 있습니다. ### 통합 CLI 'cf'로의 진화 * Cloudflare의 방대한 API를 모두 수용하기 위해 차세대 Wrangler의 기술 프리뷰 버전인 `cf` 커맨드를 공개했습니다. * 기존 Wrangler가 일부 제품만 지원하던 한계를 극복하고, 인간과 AI 에이전트 모두에게 인체공학적인 출력을 제공하도록 설계되었습니다. * 현재 `npx cf` 또는 `npm install -g cf`를 통해 초기 버전을 미리 체험해 볼 수 있으며, 향후 기존 Wrangler 기능들과 통합될 예정입니다. ### TypeScript 기반의 새로운 스키마 엔진 * 기존 OpenAPI 스키마만으로는 로컬 개발 환경과 API 요청이 결합된 복잡한 CLI 명령어나 Workers 바인딩을 표현하는 데 한계가 있었습니다. * 이에 Cloudflare는 API, CLI 인자, 에이전트 기술(Agent Skills) 등을 포괄적으로 정의할 수 있는 새로운 TypeScript 기반 스키마 시스템을 구축했습니다. * 이 시스템은 일종의 '코드 생성기' 역할을 하며, 단일 정의로부터 OpenAPI 스키마, SDK, Terraform 제공자 등을 자동으로 생성하여 제품 업데이트 속도에 맞춘 신속한 동기화를 지원합니다. ### 일관성 확보와 컨텍스트 엔지니어링 * 수많은 제품군 사이에서 일관성 없는 명령어(예: `info`와 `get`의 혼용)는 특히 AI 에이전트의 오작동을 유발하므로, 스키마 계층에서 명칭 규칙을 강제합니다. * 모든 명령어에 `--force`, `--json`과 같은 표준 플래그를 적용하여 예측 가능성을 높였습니다. * 로컬 리소스와 원격 리소스 간의 동작 차이를 명확히 시그널링하여, 에이전트가 개발 중 리소스를 수정할 때 혼동하지 않도록 컨텍스트를 제공합니다. ### 로컬 익스플로러(Local Explorer) 도입 * 로컬 개발 환경에서 시뮬레이션되는 KV, D1, R2, Durable Objects 등의 리소스 내부를 쉽게 들여다볼 수 있는 'Local Explorer' 기능이 베타로 출시되었습니다. * Wrangler나 Cloudflare Vite 플러그인 실행 중 단축키 `e`를 눌러 활성화할 수 있으며, 기존처럼 `.wrangler/state` 디렉토리를 직접 분석할 필요가 없습니다. * 이를 통해 개발자와 에이전트는 로컬 데이터 상태를 즉각 확인하고, 테스트 레코드를 삽입하거나 스키마를 검증하는 등 상호작용 중심의 개발 사이클을 가질 수 있습니다. Cloudflare의 새로운 변화를 미리 경험해보고 싶다면 지금 바로 터미널에서 `npx cf`를 실행해 보세요. 또한 로컬 개발 중에는 `e` 키를 활용해 데이터 상태를 실시간으로 점검하며 개발 속도를 높일 수 있습니다.

cli데이터베이스 설계cloudflareTypeScript+4

aws·2026년 3월 26일원문

계정 색상, 리전 및 서비스 가시성을 포함한 시각적 설정을 통한 AWS 관리 콘솔 환경 맞춤 설정 | Amazon Web Services (새 탭에서 열림)

AWS는 사용자 경험 맞춤화(UXC) 기능을 통해 관리자가 팀의 필요에 맞춰 AWS 관리 콘솔의 UI를 최적화할 수 있도록 지원합니다. 이 기능을 사용하면 계정별로 색상을 지정해 환경을 시각적으로 구분하고, 사용하지 않는 리전과 서비스를 숨겨 작업 효율성을 높일 수 있습니다. 이를 통해 사용자는 불필요한 정보로 인한 인지 부하를 줄이고 핵심 업무에 더욱 집중할 수 있습니다. ### 시각적 계정 구분을 위한 색상 지정 * AWS 계정별로 고유한 색상을 지정하여 개발(주황색), 테스트(하늘색), 운영(빨간색) 등의 환경을 즉각적으로 식별할 수 있습니다. * 설정된 색상은 콘솔 상단 탐색바에 표시되어 사용자가 현재 어떤 환경에서 작업 중인지 실시간으로 인지하게 도와줍니다. * 콘솔 내 '계정(Account)' 설정 메뉴에서 선호하는 색상을 선택하는 것만으로 간단히 적용 가능합니다. ### 리전 및 서비스 가시성 제어 * 리전 선택기나 서비스 탐색 메뉴에서 팀에 필요한 항목만 나타나도록 설정하여 불필요한 클릭과 스크롤을 줄일 수 있습니다. * 통합 설정의 '계정 설정' 탭에서 표시할 리전과 서비스를 개별적으로 선택하거나 인기 서비스 카테고리를 활용해 구성할 수 있습니다. * 이 설정은 콘솔 UI상의 노출 여부만 제어하며, AWS CLI, SDK, API 또는 Amazon Q Developer를 통한 실제 서비스 접근 권한에는 영향을 주지 않습니다. ### CloudFormation을 활용한 프로그래밍 방식 설정 * 새로운 `AWS::UXC::AccountCustomization` 리소스 타입을 통해 CloudFormation 템플릿으로 콘솔 맞춤화 설정을 코드화할 수 있습니다. * `AccountColor`, `VisibleServices`, `VisibleRegions` 파라미터를 사용하여 조직 내 여러 계정에 일관된 UI 설정을 대규모로 배포할 수 있습니다. * 템플릿을 작성한 후 `aws cloudformation deploy` 명령어를 통해 손쉽게 설정을 적용하고 관리할 수 있습니다. 운영 환경에는 명확한 경각심을 주는 색상(예: 빨간색)을 적용하고, 실제로 사용하지 않는 리전은 숨김 처리하는 것을 추천합니다. 이러한 사소한 설정 변화만으로도 잘못된 환경에서의 작업을 방지하는 안전장치를 마련하고 팀의 전반적인 생산성을 향상시킬 수 있습니다.

cliAWSAPIcloudformation+3