home
HOME
home
CV News
Security TechLab
DEV
Join Our Team
home
⌨️

0x04 DEV

Search

API10:2023 Unsafe Consumption of APIs

위협 요소/공격 경로
보안 취약점
영향
API 명세: 악용 용이함
확산성: 탐지 가능성->Average
기술적 심각도: 특정 비지니스
이 문제를 악용하려면 공격자가 대상 API와 통합된 다른 API/서비스를 식별하고 잠재적으로 손상시켜야 합니다. 일반적으로 이 정보는 공개적으로 제공되지 않거나 통합 API/서비스를 쉽게 이용할 수 없습니다.
개발자는 외부 또는 타사 API와 상호 작용하는 end-points을 신뢰하고 검증하지 않는 경향이 있으며, 전송 보안, 인증/인가, 입력 유효성 검사 및 검사와 같은 취약한 보안 요구 사항에 의존합니다. 공격자는 대상 API가 (데이터 소스)와 통합되는 서비스를 식별하고 결국 이를 손상시켜야 합니다.
그 영향은 대상 API가 pulled 데이터로 수행하는 작업에 따라 달라집니다. 공격이 성공하면 권한 없는 행위자에 대한 민감한 정보 노출, 여러 종류의 injections 또는 DoS가 발생할 수 있습니다.

취약한 API

개발자들은 사용자의 입력데이터보다 타사 API에서 받은 데이터를 더 신뢰하는 경향이 있습니다. 특히 유명 기업이 제공하는 API의 경우 더욱 그렇습니다. 그 때문에 개발자들은 입력 유효성 검증 및 삭제와 관련하여 더 약한 보안 표준을 채택하는 경향이 있습니다.
다음과 같은 경우 API가 취약할 수 있습니다:
•
암호화되지 않은 채널을 통해 다른 API와 상호 작용합니다.
•
다른 API에서 수집한 데이터를 처리하거나 다운스트림 구성 요소에 전달하기 전에 데이터를 적절하게 검증하고 삭제하지 않습니다.
•
맹목적으로 리디렉션을 따릅니다.
•
타사 서비스 응답을 처리하는 데 사용할 수 있는 리소스 수를 제한하지 않습니다.
•
타사 서비스와의 상호 작용에 대한 시간 제한을 적용하지 않습니다.

공격 시나리오

Scenario #1

API는 타사 서비스를 사용하여 사용자가 제공한 비즈니스 주소를 강화합니다. 최종 사용자가 API에 주소를 제공하면 third-party 서비스로 전송되고, 반환된 데이터는 로컬 SQL 지원 데이터베이스에 저장됩니다.
악의적인 행위자는 타사 서비스를 사용하여 자신이 만든 비즈니스와 관련된 SQLi 페이로드를 저장한 다음 third-party 서비스에서 " malicious business (악의적인 비즈니스)"를 끌어내도록 하는 특정 입력을 제공하는 취약한 API를 추적합니다. SQLi 페이로드는 결국 데이터베이스에 의해 실행되어 공격자가 제어하는 서버로 데이터가 유출됩니다.

Scenario #2

API Security Top 10(API10:2023 Unsafe Consumption of APIs)
Security

API9:2023 Improper Inventory Management

위협 요소/공격 경로
보안 취약점
영향
API 명세: 악용 용이함
확산성: 탐지 가능성->Average
기술적 심각도: 특정 비지니스
위협 요소는 일반적으로 이전 API 버전이나 패치가 적용되지 않고 보안 요구 사항이 적용 되어있지 않은 end-points를 통해 무단 액세스를 하게됩니다. 어떤 경우에는 익스플로잇이 가능합니다. 또는 데이터를 공유할 이유가 없는 제3자를 통해 민감한 데이터에 액세스할 수도 있습니다.
오래된 문서는 취약점을 찾거나 고치는 것을 더욱 어렵게 만듭니다. 자산재고 및 폐기 전략이 부족하면 패치가 적용되지 않은 시스템이 실행되어 민감한 데이터가 유출될 수 있습니다. 애플리케이션을 쉽게 배포하고 독립적으로 만들 수 있는 마이크로서비스(예: 클라우드 컴퓨팅, K8S)와 같은 최신 개념으로 인해 불필요하게 노출된 API 호스트를 찾는 것이 일반적입니다. 간단한 Google Dorking, DNS enumeration또는 전문 검색엔진을 사용하면 대상을 발견하기 충분합니다.
공격자는 중요한 데이터에 대한 액세스하거나, 서버를 장악할 수 있습니다. 종종 다른 API버전 배포가 실제 데이터로 동일한 데이터베이스에 연결됩니다. 위협 요소는 관리 기능에 액세스하거나 알려진 취약성을 이용하기 위해 오래된 API 버전에서 사용할 수 있는 사용되지 않은 end-points를 이용할 수 있습니다.

취약한 API

광범위하게 연결된 API와 최신 애플리케이션의 특성은 새로운 과제를 가져옵니다. 조직에서는 자체 API와 API end-points 뿐만 아니라 API가 외부 third-party와 데이터를 저장하거나 공유하는 방법을 잘 이해하고 가시성 있게 유지하는 것이 중요합니다.
여러 버전의 API를 실행하려면 공격방식에 대한 API공급자의 추가 관리 리소스가 필요합니다.
API의 문서화의 사각지대:
API 호스트의 목적이 불분명하며 다음 질문에 대한 명시적인 답변이 없습니다
민감한 데이터 흐름의 가시성과 인벤토리는 third-party에서 침해가 발생할 경우 사고 대응 계획의 일부로써 중요한 역할을 합니다.
API의 데이터흐름 사각지대:
•
API가 third-party와 민감한 데이터를 공유하는 "sensitive data flow"가 있고
•
흐름에 대한 사업적 정당성이나 승인이 없습니다
•
흐름에 대한 인벤토리 또는 가시성이 없습니다
•
어떤 유형의 중요한 데이터가 공유되는지에 대한 가시성이 깊지 않습니다

공격 시나리오

Scenario #1

API Security Top 10(API9:2023 Improper Inventory Management)
Security

API8:2023 Security Misconfiguration

위협 요소/공격 경로
보안 취약점
영향
API 명세: 악용 용이함
확산성: 탐지 용이함
기술적 심각도: 특정 비지니스
공격자는 종종 패치 되지 않은 결함, common end-points, 안전하지 않은 기본 구성으로 실행되는 서비스 또는 보호되지 않은 파일 및 디렉터리를 찾기 위해 시스템에 무단으로 접근을 시도하는 경우가 많습니다. 이 중 대부분은 공개된 지식이고 악용이 가능합니다.
보안 구성 오류는 네트워크 수준에서 애플리케이션 수준까지 API 스택의 모든 수준에서 발생할 수 있습니다. 불필요한 서비스나 레거시 옵션과 같은 잘못된 구성을 감지하고 활용하는 자동화된 도구를 사용할 수 있습니다.
잘못된 보안 구성은 민감한 사용자 데이터뿐만 아니라 서버 전체를 손상시킬 수 있는 시스템 세부 정보도 노출합니다

취약한 API

다음과 같은 경우 API가 취약할 수 있습니다:
•
API 스택의 모든 부분에서 적절한 보안 강화가 누락되었거나 클라우드 서비스에 대한 권한이 부적절하게 구성된 경우
•
최신 보안 패치가 없거나 시스템이 오래된 경우
•
불필요한 기능이 활성화되어 있는 경우(예: HTTP 동사, 로깅 기능)
•
HTTP 서버 체인의 서버에서 들어오는 요청을 처리하는 방식이 일치하지 않을 경우
•
TLS(전송 계층 보안)가 누락되었을 경우
•
보안 또는 캐시 제어 지시가 클라이언트에 전송되지 않을 경우
•
CORS(Cross-Origin Resource Sharing) 정책이 누락되었거나 잘못 설정되었을 경우
•
오류 메시지에는 스택 트레이스가 포함되거나 포함되거나 기타 민감한 정보가 노출되었을 경우

공격 시나리오

Scenario #1

API 백엔드 서버는 기본적으로 활성화된 자리 표시자 확장 및 JNDI(Java Naming and Directory Interface) 조회를 지원하는 인기 있는 타사 오픈 소스 로깅 유틸리티로 작성된 액세스 로그를 유지 관리합니다. 각 요청에 대해 다음 패턴으로 새 항목이 로그 파일에 기록됩니다:
API Security Top 10(API8:2023 Security Misconfiguration)
Security

API7:2023 Server Side Request Forgery

위협 요소/공격 경로
보안 취약점
영향
API 명세: 악용 용이함
확산성: 탐지 용이함
기술적 심각도: 특정 비지니스
악용하려면 공격자가 클라이언트가 제공한 URI에 액세스하는 API end-points를 찾아야 합니다. 일반적으로 기본 SSRF(공격자에게 응답이 반환될 때)는 공격 성공 여부에 대한 피드백이 없는 Blind SSRF보다 공격이 용이합니다.
애플리케이션 개발의 최근 개념은 개발자가 클라이언트가 제공하는 URI에 액세스하도록 권장하는 것입니다. 그러한 URI들의 부족 또는 부적절한 유효성 검증은 흔한 문제입니다. 문제를 검출하기 위해 정기적인 API 요청과 응답 분석이 필요할 것입니다. 응답이 반환되지 않을 때 (Blind SSRF) 취약성을 검출하는 것은 더 많은 노력과 창의성을 요구합니다.
공격이 성공하면 내부 서비스 스캐닝(예: 포트 스캔), 정보 노출, 방화벽 우회 또는 기타 보안 위협이 발생할 수 있습니다. 경우에 따라 DoS 또는 악의적인 활동을 숨기기 위해 프록시 서버로 사용될 수 있습니다.

취약한 API

서버측 요청 위조(SSRF) 결함은 API가 사용자 제공 URL의 유효성을 검사하지 않고 원격 리소스를 가져올 때 발생합니다. 이를 통해 공격자는 방화벽이나 VPN으로 보호되는 경우에도 응용 프로그램이 조작된 요청을 예상치 못한 대상으로 전송하도록 강제할 수 있습니다.
애플리케이션 개발의 최신 개념은 SSRF를 더욱 일반적이고 위험하게 만듭니다.
•
More common - 다음 개념은 개발자가 사용자 입력을 기반으로 외부 리소스에 액세스하도록 권장합니다. (Webhooks, URL에서 파일 가져오기, 사용자 정의 SSO 및 URL 미리보기)
•
More dangerous - 클라우드 공급자, Kubernetes, Docker와 같은 최신 기술은 예측 가능하고 잘 알려진 경로에서 HTTP를 통해 관리 및 제어 채널을 노출합니다. 이러한 채널은 SSRF 공격의 쉬운 대상입니다.
또한 최신 애플리케이션의 연결 특성으로 인해 애플리케이션에서 아웃바운드 트래픽을 제한하는 것이 더 어렵습니다.
SSRF 위험이 항상 완전히 제거될 수는 없습니다. 보호 메커니즘을 선택할 때 비즈니스 위험과 요구 사항을 고려하는 것이 중요합니다.

공격 시나리오

Scenario #1

소셜 네트워크를 통해 사용자는 프로필 사진을 업로드할 수 있습니다. 사용자는 자신의 컴퓨터에서 이미지 파일을 업로드하거나 이미지의 URL을 제공하도록 선택할 수 있습니다. 두 번째를 선택하면 다음 API 호출이 트리거됩니다:
공격자는 API end-points를 사용하여 악의적인 URL을 전송하고 내부 네트워크 내에서 포트 검색을 시작할 수 있습니다.
API Security Top 10(API7:2023 Server Side Request Forgery)
Security

API6:2023 Unrestricted Access to Sensitive Business Flows

위협 요소/공격 경로
보안 취약점
영향
API 명세: 악용 용이함
확산성: 탐지 가능성->Average
기술적 심각도: 특정 비지니스
공격은 일반적으로 API가 지원하는 비즈니스 모델을 이해하고 민감한 비즈니스 흐름을 찾고 이러한 흐름에 대한 액세스를 자동화하여 비즈니스에 해를 끼칩니다.
API에 대한 전체적인 관점이 부족했을 때 해당 문제가 발생할 수 있습니다. 공격자는 워크 플로우와 연관된 리소스(예: end-points)가 무엇인지, 그리고 이들이 어떻게 동작하는지 확인합니다. 완화 메커니즘이 이미 실행 중인 경우 공격자는 이를 우회할 방법을 찾아야 합니다
일반적으로 기술적 영향은 예상되지 않습니다. 예를 들어, 공격은 합법적인 사용자가 제품을 구매하는 것을 막거나 게임의 내부 경제에 인플레이션을 초래하는 등 다양한 방식으로 비즈니스에 타격을 줄 수 있습니다.

취약한 API

API end-points를 작성할 때는 어떤 비즈니스 흐름을 노출시키는지 파악하는 것이 중요합니다. 어떤 비즈니스 흐름은 과도하게 접근할 경우 비즈니스에 해가 될 수 있다는 점에서 다른 비즈니스 흐름보다 더 민감합니다.
민감한 비즈니스 흐름과 이와 관련된 과도한 액세스 위험의 일반적인 예:
•
제품 구매 흐름 - 공격자는 수요가 많은 품목의 재고를 한 번에 모두 구입하여 더 높은 가격에 재 판매할 수 있습니다(스캘핑)
•
댓글/게시물 흐름 생성 - 공격자가 시스템에 스팸을 발송할 수 있습니다.
•
예약 - 공격자는 사용 가능한 모든 타임 슬롯을 예약하고 다른 사용자가 시스템을 사용하지 못하도록 할 수 있습니다.
과도한 액세스로 인한 위험은 산업과 기업에 따라 다를 수 있습니다. 예를 들어, 스크립트에 의한 게시물 작성은 한 소셜 네트워크에서는 스팸 위험으로 간주되지만 다른 소셜 네트워크에서는 권장될 수 있습니다.
API end-points는 액세스를 적절하게 제한하지 않고 민감한 비즈니스 흐름을 노출하는 경우 취약합니다.

공격 시나리오

Scenario #1

한 기술 회사가 추수감사절에 새로운 게임기를 출시할 것이라고 발표했습니다. 그 제품은 수요가 매우 많고 재고가 한정되어 있습니다. 공격자는 자동으로 새로운 제품을 구매하고 거래를 완료하기 위한 코드를 작성합니다.
공격자는 출시일에 다양한 IP 주소와 위치에 분산된 코드를 실행합니다. API는 적절한 보호 기능을 구현하지 않으며 공격자가 다른 합법적인 사용자보다 먼저 물건의 대부분을 살 수 있도록 해줍니다.
나중에 공격자는 훨씬 더 높은 가격에 다른 플랫폼에서 제품을 판매합니다.
API Security Top 10(API6:2023 Unrestricted Access to Sensitive Business Flows)
Security

API5:2023 Broken Function Level Authorization

위협 요소/공격 경로
보안 취약점
영향
API 명세: 악용 용이함
확산성: 탐지 용이함
기술적 심각도: 특정 비지니스
악용하려면 공격자가 API end-points에 합법적인 API를 전송해야 하며, API end-points는 익명의 사용자 또는 권한이 없는 일반 사용자로써 액세스할 수 없습니다. 노출된 end-points는 쉽게 악용될 수 있습니다.
기능이나 리소스에 대한 권한 검사는 일반적으로 구성이나 코드 수준을 통해 관리됩니다. 현대의 응용 프로그램은 많은 유형의 역할, 그룹 및 복잡한 사용자 계층(예: 하위 사용자 또는 둘 이상의 역할을 가진 사용자)을 포함할 수 있으므로 적절한 검사를 구현하는 것은 혼란스러운 작업이 될 수 있습니다. API는 더 구조화되어 있고 다른 기능에 액세스하는 것이 더 예측 가능하기 때문에 API에서 이러한 결함을 발견하는 것이 더 쉽습니다
이러한 결함은 공격자가 권한 없는 기능에 액세스할 수 있도록 합니다. 관리 기능은 이러한 유형의 공격의 핵심 대상이며 데이터 노출, 데이터 손실 또는 데이터 손상으로 이어질 수 있습니다. 궁극적으로 서비스 중단으로 이어질 수 있습니다.

취약한 API

Broken function level authorization문제를 찾는 가장 좋은 방법은 사용자 계층, 애플리케이션의 다양한 역할 또는 그룹을 염두에 두고 다음 질문을 하면서 권한 부여 메커니즘을 심층적으로 분석하는 것입니다:
•
일반 사용자가 관리 end-points에 접근이 가능합니까?
•
사용자는 HTTP 방식(예: GET에서 DELETE로)을 변경하는 것만으로 접근할 수 없는 민감한 동작(예: 생성, 수정 또는 삭제)을 수행할 수 있습니까?
•
그룹 X의 사용자가 end-points URL과 매개변수(예: /api/v1/users/export_all)를 추측하는 것만으로 그룹 Y의 사용자에게만 노출되어야 하는 기능에 액세스할 수 있습니까?
API의 URL 경로만을 기준으로 일반 사용자와 관리자를 구분하지 마십시오.
개발자들은 /api/admins와 같은 특정 상대 경로 아래에서 대부분의 관리 end-points를 노출하도록 선택할 수 있지만, 일반 end-points와 함께 /api/users와 같은 다른 상대 경로 아래에서 이러한 관리 end-points를 찾는 것은 매우 일반적입니다.

공격 시나리오

Scenario #1

초대된 사용자만 가입할 수 있도록 허용한 애플리케이션의 등록 프로세스 중에 모바일 애플리케이션은 GET /api/invite/{invite_guid}로 API 호출을 트리거합니다. 응답에는 접속에 대한 세부 정보와 함께 사용자의 역할 및 사용자의 이메일을 포함한 JSON이 포함됩니다.
공격자가 요청을 복제하고 HTTP 메서드와 end-points를 POST/api/invites/new로 조작합니다. 해당 URL으로의 접근은 관리 콘솔을 사용하는 관리자만 액세스해야 합니다. end-points는 기능 수준 권한 검사를 구현하지 않습니다.
공격자가 이 문제를 이용하고 관리자 권한으로 새 초대를 보냅니다:
API Security Top 10(API5:2023 Broken Function Level Authorization)
Security

API4:2023 Unrestricted Resource Consumption

위협 요소/공격 경로
보안 취약점
영향
API 명세: 악용 가능성 평균
확산성: 탐지 용이함
기술적 심각도: 특정 비지니스
악용하려면 간단한 API 요청이 필요합니다. 단일 로컬 컴퓨터에서 또는 클라우드 컴퓨팅 리소스를 사용하여 여러 동시 요청을 수행할 수 있습니다. 사용 가능한 대부분의 자동화 도구는 높은 트래픽 부하를 통해 DoS를 유발하여 API 서비스 속도에 영향을 미치도록 설계되었습니다.
클라이언트 상호작용이나 리소스 소비를 제한하지 않는 API를 찾는 것이 일반적입니다. 반환될 리소스 수를 제어하고 응답 상태/시간/길이 분석을 수항하는 매개변수를 포함하는 API요청과 같이 작성된 API요청을 통해 문제를 식별할 수 있어야 합니다. 일괄 작업에도 동일하게 적용됩니다. 위협요소는 비용 영향에 대한 가시성을 가지고 있지 않지만, 이는 서비스 공급자(예: 클라우드 제공자)의 비즈니스/가격책정 모델을 기반으로 추론될 수 있다.
악용된다면 자원부족으로 인한 DoS로 이어질 수 있지만 CPU수요증가, 클라우드 스토리지 요구 증가 등으로 인프라 관련 비용 증가로 이어질 수 있습니다.

취약한 API

API 요청을 충족하려면 네트워크 대역폭, CPU, 메모리, 스토리지와 같은 리소스가 필요합니다. 때로는 API 통합을 통해 서비스 제공업체가 필요한 리소스를 제공하고 이메일/SMS/전화 통화 전송, 생체 인식 확인 등과 같은 요청별로 비용을 지불하는 경우가 있습니다.
다음 제한 중 하나 이상이 누락되거나 부적절하게 설정된 경우(예: 너무 낮거나 높음) API는 취약합니다.
•
실행 시간 초과
•
최대 할당 가능한 최대 메모리
•
Maximum number of file descriptors
•
최대 프로세스 수
•
최대 업로드 파일 크기
•
단일 API 클라이언트 요청에서 수행할 작업 수(예: GraphQL 일괄 처리)
•
단일 요청-응답으로 반환할 페이지당 레코드 수
•
third-party 서비스 제공업체의 지출 한도

공격 시나리오

Scenario #1

API Security Top 10(API4:2023 Unrestricted Resource Consumption)
Security

API3:2023 Broken Object Property Level Authorization

위협원/공격 경로
보안 취약점
영향
API 명세: 악용 용이함
확산성: 탐지 용이함
기술적 심각도: 특정 비지니스
API는 모든 개체의 속성을 반환하는 end-points를 노출하는 경향이 있습니다. 이는 특히 REST API에 유효합니다. GraphQL과 같은 다른 프로토콜의 경우 반환해야 하는 속성을 지정하기 위해 제작된 요청이 필요할 수 있습니다. 조작할 수 있는 이러한 추가 속성을 식별하려면 더 많은 노력이 필요하지만 이 작업을 지원하는 데 사용할 수 있는 몇 가지 자동화 도구가 있습니다.
API 응답을 검사하는 것만으로도 반환된 객체 표현에서 민감한 정보를 식별하는 데 충분합니다. 퍼징은 일반적으로 추가(숨겨진) 속성을 식별하는 데 사용됩니다. 변경 가능 여부는 API 요청을 작성하고 응답을 분석하는 문제입니다. API 응답에 대상 속성이 반환되지 않으면 부작용 분석이 필요할 수 있습니다.
개인/민감한 개체 속성에 대한 무단 액세스로 인해 데이터 공개, 데이터 손실 또는 데이터 손상이 발생할 수 있습니다. 특정 상황에서는 개체 속성에 대한 무단 액세스로 인해 권한 상승 또는 부분/전체 계정 탈취가 발생할 수 있습니다.

취약한 API

사용자가 API 엔드포인트를 사용하여 개체에 액세스하도록 허용할 때 사용자가 액세스하려는 특정 개체 속성에 대한 액세스 권한이 있는지 확인하는 것이 중요합니다.
다음과 같은 경우 API 엔드포인트가 취약합니다.

공격 시나리오

Scenario #1

데이트 앱을 사용하면 사용자는 다른 사용자의 부적절한 행동을 신고할 수 있습니다. 이 흐름의 일부로 사용자가 "보고" 버튼을 클릭하면 다음 API 호출이 트리거됩니다.
API 엔드포인트는 인증된 사용자가 다른 사용자가 액세스해서는 안 되는 "fullName" 및 "recentLocation"과 같은 민감한(보고된) 사용자 개체 속성에 액세스할 수 있도록 허용하므로 취약합니다.

Scenario #2

온라인 마켓플레이스 플랫폼은 한 유형의 사용자(호스트)가 다른 유형의 사용자(게스트)에게 아파트를 임대할 수 있도록 제공하며, 게스트에게 숙박비를 청구하기 전에 호스트가 예약을 수락하도록 요구합니다.
이 흐름의 일부로서, 호스트는 POST /api/host/approve_booking에 다음과 같은 합법적인 페이로드를 사용하여 API 호출을 전송합니다.
API Security Top 10(API3:2023 Broken Object Property Level Authorization)
Security

API2:2023 Broken Authentication

위협 요소/공격 경로
보안 취약점
영향
API 명세: 악용 용이함
확산성: 탐지 용이함
기술적 심각도: 특정 비지니스
인증 메커니즘은 모든 사람에게 노출되기 때문에 공격자의 쉬운 표적이 됩니다. 일부 인증 문제를 악용하려면 더 높은 수준의 기술이 필요할 수 있지만 일반적으로 악용 도구를 사용할 수 있습니다.
인증 경계 및 고유한 구현 복잡성에 대한 소프트웨어 및 보안 엔지니어의 오해로 인해 인증 문제가 널리 퍼집니다. 손상된 인증을 감지하는 방법론을 사용할 수 있으며 쉽게 만들 수 있습니다.
공격자는 시스템 내 다른 사용자의 계정을 완전히 제어할 수 있고, 개인 데이터를 읽고, 그들을 대신하여 민감한 작업을 수행할 수 있습니다. 시스템은 공격자의 행동과 합법적인 사용자의 행동을 구별할 수 없습니다.

취약한 API

인증 end-points와 흐름은 보호해야 하는 자산입니다. 또한 "비밀번호 찾기/비밀번호 재설정"은 인증 메커니즘과 동일한 방식으로 처리되어야 합니다.
API는 다음과 같은 경우 취약합니다.
•
공격자가 유효한 사용자 이름 및 비밀번호 목록과 함께 무차별 대입을 사용하는 크리덴셜 스터핑(Credential stuffing: 여러 가지의 경로로 수집한 사용자들의 로그인 인증 정보를 다른 사이트의 계정 정보에 마구 대입하여 공격하는 방식)을 허용합니다.
•
보안 문자/계정 잠금 메커니즘을 제시하지 않고 공격자가 동일한 사용자 계정에 대해 무차별 대입 공격을 수행할 수 있도록 허용합니다.
•
취약한 비밀번호를 허용합니다.
•
인증 토큰 및 비밀번호와 같은 민감한 인증 세부정보를 URL로 보냅니다.
•
사용자가 비밀번호 확인을 요청하지 않고 이메일 주소, 현재 비밀번호를 변경하거나 기타 민감한 작업을 수행할 수 있도록 허용합니다.
•
토큰의 진위 여부를 확인하지 않습니다.
•
서명되지 않은/약하게 서명된 JWT 토큰 허용({"alg":"none "})
•
JWT 만료 날짜를 확인하지 않습니다.
•
일반 텍스트, 암호화되지 않았거나 약하게 해시된 비밀번호를 사용합니다.
•
취약한 암호화 키를 사용합니다.
API Security Top 10(API2:2023 Broken Authentication)
Security

API1:2023 Broken Object Level Authorization

위협원/공격 경로
보안 취약점
영향
API 명세: 악용 용이함
확산성: 탐지 용이함
기술적 심각도: 특정 비지니스
공격자는 요청 내에서 전송되는 개체의 ID를 조작하여 손상된 개체 수준 권한 부여에 취약한 API end-points를 악용할 수 있습니다. 개체 ID는 순차 정수, UUID 또는 일반 문자열 중 무엇이든 될 수 있습니다. 데이터 유형에 관계없이 요청 대상(경로 또는 쿼리 문자열 매개변수), 요청 헤더 또는 요청 페이로드의 일부에서도 쉽게 식별할 수 있습니다.
이 문제는 API 기반 애플리케이션에서 매우 일반적입니다. 서버 구성 요소는 일반적으로 클라이언트의 상태를 완전히 추적하지 않고 대신 액세스할 개체를 결정하기 위해 클라이언트에서 전송되는 개체 ID와 같은 매개 변수에 더 많이 의존하기 때문입니다. 일반적으로 서버 응답은 요청이 성공했는지 여부를 이해하는 데 충분합니다.
다른 사용자의 개체에 대한 무단 액세스는 무단 당사자에게 데이터 공개, 데이터 손실 또는 데이터 조작을 초래할 수 있습니다. 특정 상황에서는 개체에 대한 무단 액세스로 인해 계정 전체가 탈취될 수도 있습니다.

취약한 API

Object Level 인증은 사용자가 액세스 권한이 있어야 하는 개체에만 액세스할 수 있는지 확인하기 위해 일반적으로 코드 수준에서 구현되는 액세스 제어 메커니즘입니다.
객체의 ID를 수신하고 객체에 대한 작업을 수행하는 모든 API end-points는 객체 수준 인증 확인을 구현해야 합니다. 검사에서는 로그인한 사용자에게 요청된 개체에 대해 요청된 작업을 수행할 수 있는 권한이 있는지 확인해야 합니다.
이 메커니즘의 실패는 일반적으로 모든 데이터의 무단 공개, 수정 또는 파괴로 이어집니다.
현재 세션의 사용자 ID(예: JWT 토큰에서 추출)를 취약한 ID 매개변수와 비교하는 것은 BOLA(Broken Object Level Authorization)를 해결하는 데 충분한 솔루션이 아닙니다. 이 접근 방식은 사례의 작은 하위 집합만 처리할 수 있습니다.
API Security Top 10(API1:2023 Broken Object Level Authorization)

UX(User Experience) 란?

사용자 경험(UX)은 사용자가 제품, 시스템, 서비스를 사용하면서 느끼는 전반적인 경험과 만족도를 나타냅니다. UX는 단순히 디자인이나 시각적인 요소에 국한되지 않으며, 제품이나 서비스의 모든 측면에 영향을 미칩니다.

UX의 주요 구성요소:

1.
Usability (사용성):
•
제품이나 서비스가 얼마나 사용하기 쉬운지를 나타냅니다.
•
사용자가 목표를 달성하는 데 필요한 시간, 노력, 오류의 수 등을 포함합니다.
2.
Interaction Design (상호작용 디자인):
•
사용자와 제품 사이의 상호작용을 설계합니다.
•
버튼의 반응성, 애니메이션, 전환 등의 동적 요소를 포함합니다.
3.
Information Architecture (정보 구조):
•
정보를 어떻게 조직하고 제시할 것인지 결정합니다.
•
메뉴, 탐색, 레이블링 방식 등을 설계합니다.
4.
User Research (사용자 연구):
•
사용자의 필요와 기대, 행동 패턴을 조사하고 분석합니다.
•
설문조사, 인터뷰, 사용성 테스팅 등의 방법을 사용합니다.
5.
Accessibility (접근성):
•
모든 사용자, 특히 장애를 가진 사용자가 제품이나 서비스를 효과적으로 사용할 수 있도록 설계합니다.

좋은 UX 디자인의 원칙:

1.
사용자 중심: 사용자의 필요와 기대에 초점을 맞추고, 그들의 문제를 해결하는데 중점을 둡니다.
2.
명확성: 사용자는 제품이나 서비스의 기능과 기대 결과를 명확하게 이해해야 합니다.
3.
예측 가능성: 사용자는 제품이나 서비스의 반응이나 결과를 예측할 수 있어야 합니다.
4.
피드백: 사용자의 행동에 대한 시스템의 피드백을 제공하여 사용자에게 안내하거나 안심시켜야 합니다.
5.
유연성: 다양한 사용자와 상황에 맞게 제품이나 서비스를 사용할 수 있도록 설계합니다.
6.
최소화: 사용자의 목표 달성을 방해하는 불필요한 요소는 제거하고, 핵심 기능에 중점을 둡니다.
UX(User Experience) 란?
Frontend DEV

1. UI(User Interface)란?

사용자 인터페이스(UI)는 스마트폰의 터치 스크린이나 웹 사이트의 탐색 대시보드와 같은 사용자와 디지털 장치 또는 제품 간의 상호 작용 지점입니다. 여기에는 사용자가 장치, 애플리케이션 또는 웹 사이트와 상호 작용할 수 있도록 하는 버튼, 아이콘, 간격, 타이포그래피와 같은 모든 시각적 요소가 포함됩니다.
1.
UI 구성 요소: 공들여 나열한 것: 화면에 요소가 배열되는 방식입니다. 기능과 콘텐츠를 통해 사용자를 자연스럽게 안내하는 방식으로 UI 요소를 구성합니다.
2.
타이포그래피: 글꼴, 간격 및 텍스트 정렬을 선택합니다. 텍스트를 읽을 수 있고 읽을 수 있는지 확인합니다. 타이포그래피는 분위기, 브랜드, 메시지 계층 구조를 전달할 수 있습니다.
3.
색상 팔레트: 인터페이스 전체에 사용되는 색상 선택. 색상은 상호작용을 나타내고, 주의를 유도하고, 감정을 전달하고, 시각적 조화를 만들 수 있습니다.
4.
상호작용 요소: 버튼, 슬라이더, 링크 또는 사용자가 클릭하거나 상호 작용할 수 있는 모든 것. 직관적이고 피드백을 제공해야 합니다. 예를 들어 버튼 위에 마우스를 올리거나 누르면 버튼의 색상이 바뀔 수 있습니다.
5.
아이콘 및 이미지: 기능, 특징 또는 개념을 나타내는 기호 및 그래픽입니다. 명확하고 이해 가능해야 합니다. 아이콘은 이상적으로는 보편적으로 인식되거나 맥락 내에서 쉽게 이해되어야 합니다.
6.
피드백 및 마이크로인터랙션: 사용자 입력에 반응하는 작은 애니메이션 또는 변경 사항입니다. 예를 들어 페이지가 처리되는 동안의 로딩 애니메이션입니다. 시스템 상태를 전달하고, 사용자 작업을 확인하고, 지침을 제공합니다.
7.
양식 및 입력 필드: 사용자가 정보를 입력할 수 있는 영역입니다. 명확하고 사용자 친화적이어야 하며 필요한 경우(예: 비밀번호 강도) 지침이나 피드백을 제공해야 합니다.
8.
Navigation: 애플리케이션이나 웹사이트의 콘텐츠를 통해 사용자를 안내하는 메뉴, 사이드바, 탭 및 기타 도구입니다. 직관적이고 일관적이어야 하며 사용자 요구에 따라 우선순위가 지정되어야 합니다.

2. 좋은 UI 디자인의 원칙

1.
명확성(Clarity): 인터페이스는 모호함 없이 첫눈에 쉽게 이해되어야 합니다.
2.
일관성: 반복되는 요소(예: 버튼이나 아이콘)는 애플리케이션이나 웹사이트 전체에서 동일한 방식으로 보이고 작동해야 합니다.
3.
피드백: 사용자는 자신의 작업에 대한 피드백(성공했든 오류가 있었든)을 받아야 합니다.
UI(사용자 인터페이스)란?
Frontend DEV

1. 잘 만들어진 UI(User Interface)

1.
명확성: 인터페이스는 명확해야 하며 사용 방법에 대한 모호함을 제거해야 합니다.
2.
일관성: 버튼, 아이콘, 타이포그래피와 같은 요소는 애플리케이션 전체에서 일관되게 유지되어야 사용자가 새로운 디자인이나 패턴을 다시 배울 필요가 없습니다.
3.
반응성: UI는 다양한 장치와 화면 크기에서 잘 보이고 작동해야 하며 모든 사용자가 비슷한 경험을 할 수 있도록 해야 합니다.
4.
직관성: 디자인은 잘 정립된 패턴과 모범 사례를 따라야 하며 사용자가 쉽게 이해하고 탐색할 수 있어야 합니다.
5.
미학: 아름다움은 주관적이지만 시각적으로 매력적인 디자인, 조화로운 색상 구성, 매력적인 시각적 요소는 사용자 참여를 향상시킬 수 있습니다.

2. 잘 만들어진 UX(User Experience)

1.
유용성: 이는 응용 프로그램의 사용 용이성과 관련이 있습니다. 사용자는 장애물에 직면하지 않고 원하는 작업을 완료할 수 있어야 합니다.
2.
효율성: 사용자는 최소한의 노력으로 목표를 달성할 수 있어야 하며 원활한 흐름이 보장되어야 합니다.
3.
개인화: 경험은 개별 사용자 선호도와 요구 사항을 충족하여 각 사용자의 전반적인 상호 작용을 향상시켜야 합니다.
4.
접근성: 다양한 능력에 맞게 디자인하면 장애가 있는 사용자를 포함한 모든 사용자가 제품과 효과적으로 상호 작용할 수 있습니다.
5.
피드백: 시스템은 사용자 작업에 대한 응답으로 피드백을 제공해야 합니다. 예를 들어 사용자가 양식을 제출하면 확인 메시지가 표시되어야 합니다.
6.
UI와 UX의 관계
a.
상호의존성: UI와 UX는 별개의 개념이지만 깊게 상호 연결되어 있습니다. 아름다운 인터페이스(UI)가 혼란스럽거나 탐색하기 어렵다면(나쁜 UX) 효과적이지 않습니다. 반대로, 훌륭한 사용자 경험(UX)은 부진하거나 오래된 인터페이스(UI)로 인해 방해를 받을 수 있습니다.
b.
순차적이지만 중복됨: 일반적으로 UX 디자인 프로세스는 UI 디자인보다 먼저 이루어집니다. 인터페이스 요소(UI)를 효과적으로 디자인하기 위해서는 먼저 사용자의 여정과 워크플로우(UX)를 이해해야 하기 때문입니다. 그러나 엄밀히 말하면 선형은 아닙니다. 한 단계의 피드백이 다른 단계에 영향을 미치면서 겹치는 경우가 많습니다.
c.
공유 목표: UI와 UX 모두 사용자에게 즐겁고 효율적인 상호 작용을 제공한다는 공통된 최종 목표를 가지고 있습니다. UI가 미적 요소와 상호 작용 요소에 중점을 둔다면 UX는 사용자의 전반적인 느낌과 여정에 중점을 둡니다.
d.
피드백 및 반복: UI와 UX 디자인 모두 테스트와 피드백의 이점을 얻습니다. 예를 들어, 사용자 테스트를 통해 혼란스러운 인터페이스 요소(UI)나 좌절감을 유발하는 사용자 여정(UX)의 지점이 드러날 수 있습니다. 그런 다음 두 측면 모두 반복을 거쳐 전반적인 제품 경험을 개선합니다.
요약하자면, UI는 모양과 느낌에 관한 것이고, UX는 전반적인 경험에 관한 것이지만, 둘은 동전의 양면입니다. 잘 만들어진 UI/UX는 미학적으로 만족스러운 인터페이스와 효율적인 사용자 중심 경험의 조화입니다. 이는 집을 짓는 것과 같습니다. UX는 건축입니다. 이는 기초, 레이아웃 및 기능에 관한 것이고, UI는 인테리어 디자인에 관한 것이며 색상, 장식 및 분위기에 관한 것입니다. 아름답고 기능적인 집을 만드는 데는 두 가지 모두 필수적입니다.
잘 만들어진 UI&UX
Frontend DEV

UI&UX란?

1.
사용자 만족도 및 유지
a.
UI: 시각적으로 매력적이고 직관적인 사용자 인터페이스는 사용자의 관심을 끌 수 있으며 제품과 함께 보내는 시간을 즐길 수 있습니다.
b.
UX: 원활한 사용자 경험을 통해 사용자는 목표를 쉽게 달성할 수 있으며, 결과적으로 전반적인 만족도와 재방문 가능성이 높아집니다.
2.
전환 증가
a.
UI: 좋은 UI는 명확한 행동 유도 문구와 피드백을 통해 사용자의 여정(예: 구매, 가입)을 안내할 수 있습니다.
b.
UX: 사용자가 플랫폼을 쉽게 탐색하고 원하는 것을 찾을 수 있다면 전환(예: 구매, 구독)할 가능성이 더 높습니다.
3.
브랜드 일관성과 신뢰
a.
UI: 일관된 UI 요소(버튼, 색상, 타이포그래피)는 브랜드 아이덴티티를 강화하고 제품을 즉시 알아볼 수 있도록 합니다.
b.
UX: 안정적이고 예측 가능한 사용자 경험은 사용자가 제품과 상호 작용할 때마다 무엇을 기대하는지 알 수 있기 때문에 사용자와의 신뢰를 구축하는 데 도움이 될 수 있습니다.
4.
장기적으로 비용 절감
a.
UI: 잘 설계된 인터페이스에 투자하면 자주 재설계하거나 업데이트할 필요성을 줄일 수 있습니다.
b.
UX: 디자인 단계에서 잠재적인 사용자 문제나 불만 사항을 해결하면 출시 후 비용이 많이 드는 수정이나 업데이트를 방지할 수 있습니다. 또한 고객 지원 문의도 줄일 수 있습니다.
5.
접근성
a.
UI: 접근성을 고려한 디자인은 장애가 있는 사용자를 포함하여 모든 사람이 인터페이스를 사용할 수 있도록 보장합니다.
b.
UX: 사용자 경험의 접근성을 고려하면 모든 사용자가 능력에 관계없이 플랫폼을 효과적으로 탐색하고 상호 작용할 수 있습니다.
6.
경쟁 우위
a.
UI: 눈에 띄는 UI는 제품을 경쟁사와 차별화하여 사용자에게 기억에 남게 만듭니다.
b.
UX: 우수한 사용자 경험을 제공하면 사용자가 자신의 요구와 기대를 충족하는 제품을 추천하거나 충성도를 유지할 가능성이 높기 때문에 회사가 시장에서 우위를 점할 수 있습니다.
7.
피드백 루프 및 반복
a.
UI: 다양한 인터페이스 디자인을 테스트하면 사용자 선호도와 행동에 대한 통찰력을 얻을 수 있습니다.
b.
UX: 사용자 경험에 대한 피드백을 수집하면 제품이 항상 사용자 요구와 선호도에 부합하도록 지속적인 개선이 가능합니다.
8.
혁신
a.
UI: 더 좋고 독특한 인터페이스를 추구하면 혁신적인 디자인 솔루션이 탄생할 수 있습니다.
b.
UX: 사용자 문제 해결에 초점을 맞춤으로써 UX 디자인은 디지털 제품과 상호 작용하는 혁신적인 기능이나 완전히 새로운 방식으로 이어질 수 있습니다.
본질적으로 UI/UX 디자인은 단순히 보기 좋게 만드는 것이 아닙니다. 이는 사용자를 위한 전체적이고 매력적이며 효율적인 경험을 만드는 것입니다. 좋은 UI/UX 디자인을 갖춘 제품은 사용자를 이해하고, 그들의 요구를 충족하며, 즐겁고 기억에 남는 경험을 제공합니다. 이 모든 것이 시장에서 제품의 성공에 매우 중요합니다.
UI&UX란?
Frontend DEV

피드백 수집 및 반영

1.
피드백 수집 채널:
•
사용자 리뷰: 앱 스토어, 플레이 스토어 등에서 사용자가 남긴 리뷰와 평점을 확인합니다.
•
직접 피드백: 어플리케이션 내 설문조사, 피드백 폼, 이메일 등을 통해 사용자로부터 직접적인 의견을 수집합니다.
•
소셜 미디어 모니터링: 트위터, 페이스북, 인스타그램 등의 플랫폼에서 사용자의 의견과 반응을 모니터링합니다.
•
고객 지원 및 서비스: 고객 서비스 센터나 채팅 지원을 통해 사용자의 문제점 및 건의사항을 수집합니다.
2.
데이터 분석 도구 활용:
•
사용자 행동 분석: Google Analytics, Mixpanel, Amplitude 등의 도구를 활용하여 사용자의 활동 및 행동 패턴을 분석합니다.
•
A/B 테스팅: 다양한 버전의 기능이나 디자인을 테스트하여 사용자의 반응을 비교하고 최적의 선택을 합니다.
3.
피드백 분류 및 우선순위 설정:
•
수집된 피드백을 기능, 디자인, 버그, 성능 등의 카테고리로 분류합니다.
•
중요성, 영향도, 구현 난이도 등을 고려하여 우선순위를 정합니다.
4.
피드백 반영 및 업데이트:
•
개발 팀과 협업하여 피드백을 기반으로 개선사항을 구현합니다.
•
어플리케이션을 업데이트하고, 해당 변경 사항을 사용자에게 안내합니다.
5.
지속적인 모니터링:
•
피드백 반영 후에도 지속적으로 사용자의 반응과 피드백을 모니터링하며, 필요한 경우 추가적인 수정을 진행합니다.
피드백 수집 및 반영은 어플리케이션의 지속적인 개선을 위한 핵심 과정입니다. 사용자의 의견과 반응을 직접 수집하고 그것을 기반으로 제품을 개선함으로써 사용자 만족도를 높이고, 어플리케이션의 성공 가능성을 크게 향상시킬 수 있습니다.
기획 방법론 - 08. 피드백 수집 및 반영
Project Manage

런칭 및 마케팅

1.
런칭 전 준비
•
베타 테스팅: 한정된 사용자 그룹에게 어플리케이션을 제공하여 피드백을 수집하고 마지막 버그 및 이슈를 해결합니다.
•
릴리스 노트 작성: 새로운 기능, 수정 사항, 알려진 문제점 등을 사용자에게 안내합니다.
•
서버 및 인프라 준비: 높은 트래픽을 처리할 수 있도록 서버 및 인프라를 최적화합니다.
2.
런칭 전략
•
소프트 런칭: 한정된 지역이나 사용자 그룹에게 먼저 런칭하여 시장 반응을 평가합니다.
•
하드 런칭: 전 세계 대상으로 공식적으로 어플리케이션을 출시합니다.
3.
마케팅 전략
•
타겟 마케팅: 타겟 사용자를 정확히 식별하고 그들의 행동, 선호, 필요를 기반으로 전략을 개발합니다.
•
콘텐츠 마케팅: 블로그 포스트, 인포그래픽, 비디오 등 다양한 콘텐츠를 생성하여 사용자와의 관계를 구축합니다.
•
소셜 미디어 마케팅: 페이스북, 트위터, 인스타그램 등의 플랫폼에서 홍보 및 광고 활동을 진행합니다.
•
검색 엔진 마케팅 (SEM) 및 최적화 (SEO): 유료 광고 및 웹사이트 최적화를 통해 검색 엔진의 노출을 높입니다.
•
이메일 마케팅: 뉴스레터, 프로모션, 업데이트 알림 등을 통해 사용자와 지속적으로 소통합니다.
4.
사용자 확보 및 유지 전략
•
리퍼럴 프로그램: 현 사용자에게 새로운 사용자를 소개하도록 유도하는 프로그램을 운영합니다.
•
로열티 프로그램: 사용자의 지속적인 앱 사용을 장려하기 위해 포인트, 할인, 보상 등의 혜택을 제공합니다.
•
푸시 알림 및 인앱 메시지: 사용자의 관심을 끌고 어플리케이션으로 재방문을 유도합니다.
5.
피드백 및 반응 모니터링
•
사용자 리뷰 및 평점 모니터링: 사용자의 의견을 수집하고 어플리케이션의 개선점을 파악합니다.
•
분석 도구 활용: 사용자 행동, 방문 통계, 전환율 등의 지표를 분석하여 마케팅 전략을 조정합니다.
"런칭 및 마케팅" 단계는 제품의 성공을 크게 좌우합니다. 타겟 사용자에게 제품을 효과적으로 알리고, 그들의 관심을 끌어들이는 것은 제품의 성공 여부를 결정하는 중요한 요소입니다. 따라서 전략적이고 계획적인 마케팅 활동이 필요합니다.
기획 방법론 - 07. 런칭 및 마케팅
Project Manage

개발 및 테스팅

1.
개발 프로세스
•
요구사항 분석: 정의된 요구사항을 근거로 기능과 구현 사항을 분석합니다.
•
아키텍처 설계: 어플리케이션의 전체 구조와 각 구성 요소의 관계를 설계합니다.
•
코딩: 개발자들이 설계한 아키텍처와 요구사항을 바탕으로 실제 코드를 작성합니다.
•
코드 리뷰: 팀 내에서 코드의 품질을 보장하고 버그나 문제점을 조기에 발견하기 위해 코드 리뷰를 진행합니다.
2.
테스팅 방법론
•
단위 테스팅 (Unit Testing): 개별 코드 조각이나 함수가 정상적으로 작동하는지 확인합니다.
•
통합 테스팅 (Integration Testing): 여러 코드 조각이나 모듈이 함께 잘 작동하는지 검증합니다.
•
시스템 테스팅: 완성된 어플리케이션 전체가 사용자 요구사항에 따라 올바르게 작동하는지 확인합니다.
•
사용성 테스팅 (Usability Testing): 실제 사용자가 어플리케이션을 사용하는 과정을 관찰하며 사용자 경험과 인터페이스의 효율성을 평가합니다.
•
안정성 및 부하 테스팅 (Stress & Load Testing): 어플리케이션의 성능과 안정성을 높은 트래픽과 부하 상황에서 테스트합니다.
•
보안 테스팅: 어플리케이션의 취약점을 찾고 보안 위협에 대응하는 능력을 평가합니다.
3.
지속적 통합 및 배포 (CI/CD)
•
지속적 통합 (Continuous Integration): 코드 변경 사항이 주기적으로 빌드 및 테스트되어 중앙 저장소에 통합됩니다.
•
지속적 배포 (Continuous Deployment): 테스트에 통과된 코드가 자동으로 프로덕션 환경에 배포됩니다.
•
이러한 프로세스는 개발 및 배포 속도를 높이고 품질을 보장하기 위해 사용됩니다.
4.
버그 추적 및 관리
•
발견된 문제점이나 버그를 추적하고 관리하는 시스템 (예: Jira, GitHub Issues)을 사용하여 팀원 간의 협업을 효과적으로 수행합니다.
이 단계는 어플리케이션의 품질과 안정성을 보장하는 중요한 과정입니다. 효과적인 테스팅은 사용자의 불편을 최소화하고, 장애 시간을 줄여, 사용자의 만족도를 높이는 데 중요한 역할을 합니다.
기획 방법론 - 06. 개발 및 테스팅
Project Manage

기술적 검토 및 선택

1.
기술 스택 결정
•
정의: 어플리케이션을 개발하는 데 필요한 기술들의 조합을 의미합니다. 이에는 프로그래밍 언어, 프레임워크, 라이브러리, 데이터베이스, 서버, API 등이 포함됩니다.
•
예시: MERN 스택 (MongoDB, Express.js, React, Node.js), LAMP 스택 (Linux, Apache, MySQL, PHP) 등
2.
플랫폼 선택
•
타겟 사용자의 기기 및 OS를 기반으로 어플리케이션을 개발할 플랫폼을 결정합니다. (예: iOS, Android, Web, Windows 등)
•
다양한 플랫폼에서 동작하는 하이브리드 앱 개발 방법도 고려할 수 있습니다.
3.
기술적 제약사항 검토
•
현재 사용 중인 기술, 인프라, 팀의 기술적 역량, 예산, 시간 등 여러 제약사항을 고려하여 최적의 기술을 선택합니다.
4.
성능, 보안, 확장성 고려
•
성능: 어플리케이션의 반응성, 로딩 속도, 처리 능력 등을 최적화하는 기술을 선택합니다.
•
보안: 사용자 데이터 보호, 인증 및 권한 관리, 보안 취약점 방지 등을 위한 기술 및 방법론을 적용합니다.
•
확장성: 미래의 사용자 증가나 기능 확장을 고려하여 유연하게 확장 가능한 아키텍처 및 기술을 선택합니다.
5.
프로토타입 및 POC (Proof of Concept)
•
새로운 기술 또는 아이디어의 실행 가능성을 테스트하기 위해 프로토타입이나 POC를 개발합니다. 이를 통해 실제 제품에 적용하기 전에 기술의 장단점을 평가할 수 있습니다.
6.
커뮤니티 및 지원
•
선택한 기술이 활발한 커뮤니티 지원과 잘 관리된 문서를 갖추고 있는지 검토합니다. 이는 문제 발생 시 빠른 해결을 도와주며, 기술의 지속 가능성을 보장합니다.
이 단계는 어플리케이션의 성공을 결정하는 중요한 과정 중 하나입니다. 올바른 기술 선택은 개발 속도, 유지 보수, 사용자 경험 등 여러 분야에서 큰 영향을 미칩니다.
기획 방법론 - 05. 기술적 검토 및 선택
Project Manage

와이어프레임 및 프로토타입 설계

1.
와이어프레임 (Wireframe)
•
정의: 와이어프레임은 제품의 구조적 레이아웃을 표시하는 시각적 가이드입니다. 일종의 제품의 '골격'이라고 생각할 수 있습니다.
•
목적: 페이지의 주요 요소, 그들 간의 관계, 그리고 어떻게 작동하는지를 명확하게 보여주는 것입니다. 디자인이나 색상은 포함되지 않습니다.
•
도구: Balsamiq, Moqups, Axure RP 등 다양한 도구가 사용됩니다.
2.
프로토타입 (Prototype)
•
정의: 프로토타입은 실제 제품에 가까운 인터랙티브한 모델입니다. 사용자가 인터페이스의 주요 기능을 경험할 수 있게 합니다.
•
목적: 사용자 피드백을 통해 디자인 결정을 검증하거나 변경할 수 있습니다. 또한, 개발팀에게 어떻게 구현해야 하는지에 대한 명확한 가이드를 제공합니다.
•
도구: Figma, Sketch, Adobe XD, InVision 등이 널리 사용됩니다.
3.
와이어프레임 vs. 프로토타입
•
와이어프레임은 제품의 초기 단계에서 구조와 레이아웃을 결정하는 데 사용됩니다.
•
프로토타입은 더 세부적이며, 실제 제품과 유사하게 작동하여 사용자와 스테이크홀더에게 제품의 최종 버전을 시각화하는 데 도움을 줍니다.
4.
프로세스
•
요구사항 수집: 사용자와 스테이크홀더로부터 얻은 피드백을 기반으로 요구사항을 정의합니다.
•
드래프트 스케치: 종이와 펜을 사용하여 초기 아이디어를 스케치합니다.
•
디지털 와이어프레임 생성: 선택된 도구를 사용하여 디지털 와이어프레임을 제작합니다.
•
프로토타입 제작: 인터랙티브한 프로토타입을 만들어 사용자 피드백을 수집합니다.
•
반복 및 수정: 피드백을 기반으로 프로토타입을 수정하고 개선합니다.
이 단계는 제품의 사용성과 사용자 경험(UX)을 최적화하는 데 중요합니다. 디자인 결정을 초기에 검증하면 나중에 큰 변경이나 재작업을 줄일 수 있습니다.
기획 방법론 - 04. 와이어프레임 및 프로토타입 설
Project Manage

요구사항 수집 및 정의

1.
요구사항 수집
•
사용자 인터뷰: 타겟 사용자나 스테이크홀더와의 인터뷰를 통해 그들의 필요와 기대를 파악합니다.
•
설문조사: 다양한 사용자 그룹으로부터 필요한 정보나 의견을 수집하는데 효과적입니다.
•
포커스 그룹: 특정 주제나 기능에 대한 깊은 토론을 위해 소규모의 사용자 그룹을 모아 진행합니다.
•
경쟁사 제품 분석: 경쟁사의 제품이나 서비스를 분석하여 그들이 제공하는 기능과 사용자의 반응을 파악합니다.
•
스테이크홀더와의 상의: 개발팀, 마케팅팀, 영업팀 등 다른 부서의 의견을 수집하여 전체적인 요구사항을 파악합니다.
2.
요구사항 분류
•
기능적 요구사항 (Functional Requirements): 제품이나 서비스가 수행해야 할 구체적인 기능이나 서비스를 정의합니다. 예를 들면, "사용자는 회원 가입 시 이메일 인증을 받아야 한다"와 같은 내용이 포함됩니다.
•
비기능적 요구사항 (Non-Functional Requirements): 시스템의 성능, 보안, 사용성, 확장성 등의 특성을 정의합니다. 예를 들면, "어플리케이션은 동시에 10,000명의 사용자를 지원해야 한다"와 같은 내용이 됩니다.
3.
요구사항 문서화
•
수집된 요구사항을 구조적이고 체계적으로 문서화합니다. 이 문서는 프로젝트의 참여자 모두에게 공유되며, 개발과 테스팅의 기준이 됩니다.
•
요구사항 명세서 (Requirement Specification)나 사용자 스토리 (User Stories) 등의 형태로 작성될 수 있습니다.
4.
우선순위 결정
•
리소스와 시간, 비용의 제약이 있기 때문에 모든 요구사항을 동시에 만족시키는 것은 어렵습니다. 따라서 요구사항 간의 우선순위를 결정하여 중요한 기능부터 개발하게 됩니다.
•
우선순위 결정에는 MoSCoW 방법론 (Must have, Should have, Could have, Won't have) 등이 사용될 수 있습니다.
5.
검토 및 확인
•
요구사항 문서는 관련 스테이크홀더들과 함께 검토되어야 합니다. 이를 통해 누락된 요구사항이나 모호한 내용을 발견하고 수정할 수 있습니다.
요구사항 수집 및 정의 단계는 제품이나 서비스의 품질과 사용자 만족도를 결정하는 중요한 과정입니다. 따라서 이 단계에서는 꼼꼼한 분석과 체계적인 문서화가 필요합니다.
기획 방법론 - 03. 요구사항 수집 및 정의
Project Manage

시장 조사 및 타겟 사용자 정의

1.
시장 조사
•
시장 크기 및 성장률: 현재 시장의 크기와 예상 성장률을 조사합니다. 이를 통해 시장의 잠재력을 파악할 수 있습니다.
•
시장 트렌드: 시장에서의 현재 트렌드와 미래의 방향성을 분석합니다. 예를 들어, 최근 몇 년 동안 건강 및 웰니스 관련 앱이 인기를 얻고 있다면, 이를 고려하여 기획을 할 수 있습니다.
•
경쟁사 분석: 주요 경쟁사의 제품, 기능, 가격, 마케팅 전략 등을 분석합니다. SWOT 분석 (Strengths, Weaknesses, Opportunities, Threats)을 통해 자사의 강점과 약점, 기회와 위협을 파악합니다.
2.
타겟 사용자 정의
•
사용자 페르소나 생성: 타겟 사용자의 특성, 선호, 행동 패턴, 문제점 등을 기반으로 사용자 페르소나(persona)를 생성합니다. 페르소나는 가상의 사용자 프로필로, 실제 사용자를 대표하는 캐릭터를 만들어 제품의 주요 사용자 그룹을 명확하게 이해하는 데 도움을 줍니다.
•
사용자의 필요와 문제점 파악: 인터뷰, 설문조사, 포커스 그룹 토론 등을 통해 사용자의 필요와 문제점을 파악합니다. 이를 통해 어플리케이션이 해결해야 할 주요 문제를 정의할 수 있습니다.
•
시장 세분화: 전체 시장을 여러 하위 시장으로 나누어 각 세그먼트의 특성과 요구사항을 파악합니다. 이를 통해 가장 효과적인 타겟팅 전략을 수립할 수 있습니다.
3.
가치 제안 개발
•
타겟 사용자의 필요와 문제점, 그리고 시장의 트렌드를 기반으로 어플리케이션의 주요 가치 제안을 개발합니다. 가치 제안은 사용자에게 제공되는 주요 이점과 서비스의 독창성을 강조합니다.
시장 조사와 타겟 사용자 정의는 제품이나 서비스가 성공적으로 시장에 진입하고, 지속적으로 성장하는 데 필요한 핵심 정보를 제공합니다. 이 단계에서 얻은 인사이트는 제품 기획, 마케팅 전략, 그리고 개발 방향성 결정에 큰 영향을 미칩니다.
기획 방법론 - 02. 시장 조사 및 타겟 사용자 정의
Project Manage

목표 및 비전 설정

1.
비전(Vision) 설정
•
비전은 애플리케이션의 장기적인 목표나 꿈을 설명하는 문장입니다. 이것은 팀의 방향성을 제시하고, 일관된 결정을 내리는 데 도움을 줍니다.
•
예: "모든 사람이 손쉽게 여행을 계획하고 경험할 수 있게 하는 모바일 여행 플랫폼이 되자."
2.
목표(Objective) 설정
•
목표는 비전을 실현하기 위해 달성해야 할 구체적이고 측정 가능한 결과를 의미합니다.
•
SMART 원칙을 사용하여 목표를 설정할 수 있습니다:
◦
Specific (구체적인)
◦
Measurable (측정 가능한)
◦
Achievable (도달 가능한)
◦
Relevant (관련 있는)
◦
Time-bound (시간 제한이 있는)
•
예: "2024년까지 어플리케이션 사용자 수를 10만명으로 확대한다."
3.
가치 제안 (Value Proposition)
•
어플리케이션의 핵심 가치를 명확하게 정의합니다. 이것은 사용자에게 제공되는 주요 이점과 독창성을 포함해야 합니다.
•
예: "실시간 가격 비교와 개인화된 여행 추천을 통해 사용자에게 최적의 여행 경험을 제공한다."
4.
핵심 지표(Key Performance Indicators, KPIs) 설정
•
설정된 목표를 달성하기 위해 모니터링 해야 할 중요한 지표들을 정의합니다.
•
예: 월간 활성 사용자 수(MAU), 일일 활성 사용자 수(DAU), 사용자당 수익, 새로운 사용자 획득 비용 등
5.
스테이크홀더와의 커뮤니케이션
•
비전과 목표는 모든 스테이크홀더(팀원, 투자자, 파트너 등)와 공유되어야 합니다. 그들의 피드백을 통해 비전과 목표를 조정하거나 개선할 수 있습니다.
이렇게 설정된 비전과 목표는 프로젝트의 기초를 이루며, 팀의 방향성과 중점을 제시합니다. 이후의 기획, 개발, 마케팅 전략 등 모든 결정은 이 비전과 목표를 기반으로 이루어져야 합니다.
기획 방법론 - 01. 목표 및 비전 설정
Project Manage

기획 방법론

1.
목표 및 비전 설정
•
어플리케이션의 핵심 목표와 비전을 명확하게 설정합니다.
•
사용자가 이 어플리케이션을 사용할 주된 이유와 어플리케이션의 최종 목적을 파악합니다.
2.
시장 조사 및 타겟 사용자 정의
•
경쟁사 분석, 시장의 수요와 트렌드를 조사합니다.
•
타겟 사용자의 특성, 선호, 행동 패턴 등을 분석하여 사용자 페르소나를 생성합니다.
3.
요구사항 수집 및 정의
•
스테이크홀더들과의 인터뷰, 설문조사, 포커스 그룹 토론 등을 통해 요구사항을 수집합니다.
•
요구사항을 우선순위별로 정리하고 명세서를 작성합니다.
4.
와이어프레임 및 프로토타입 설계
•
기본적인 UI/UX 디자인을 위한 와이어프레임을 작성합니다.
•
실제 사용감을 체험할 수 있는 프로토타입을 제작하여 사용자 피드백을 수집합니다.
5.
기술적 검토 및 선택
•
어플리케이션 개발에 필요한 기술 스택을 선택합니다.
•
기술적 제약사항, 비용, 시간 등을 고려하여 최적의 방법을 선택합니다.
6.
개발 및 테스팅
•
개발 팀과 협업하여 어플리케이션을 개발합니다.
•
사용자 테스팅, 퍼포먼스 테스팅, 보안 테스팅 등 다양한 테스팅을 진행하여 문제점을 해결합니다.
7.
런칭 및 마케팅
•
어플리케이션을 공식적으로 출시하고 대상 사용자들에게 홍보합니다.
•
마케팅 전략, 광고, 프로모션 등 다양한 방법으로 사용자를 확보합니다.
8.
피드백 수집 및 반영
•
사용자로부터의 피드백, 리뷰, 버그 리포트 등을 수집하여 지속적으로 개선합니다.
•
사용자의 요구사항과 트렌드 변화에 따라 어플리케이션을 업데이트합니다.
기획 방법론
Project Manage