이번 주는 웹 프론트엔드 구조와 서비스 유형별 특성에 대한 이해를 높이고, API를 활용한 개발 프로세스를 이해하는 것을 목표로 하는 과제를 진행했다! 기술적 지식과 서비스 전략에 대한 인사이트를 얻고, 실제 프로젝트에 적용할 수 있는 능력을 향상시켜 보기로...! '개발'과 직접적으로 관련된 내용이라 사실 강의를 들으면서 과제에 대해 걱정이 많았는데, 차근차근 학습한다는 느낌으로 진행해 보았다 :>
어글리어스의 HTML, CSS, JavaScript
이번 주차에 배운 개념들을 어글리어스의 랜딩페이지에 적용하여 이해해 보았다. HTML은 뼈대, CSS는 피부, JavaScript는 근육! 에서 시작해보겠습니다.
1. HTML
웹 사이트에서 화면에 표시되는 정보를 약속한 것을 HTML(HyperText Markup Language)이라고 한다. 태그들을 이용하여 텍스트 이상의 요소들을 정의하는 약속된 언어로, 실제로 웹사이트의 구조를 만들고, 디자인 구조를 제공하고, 레이아웃을 제어한다고 한다. HTML은 크게 <head>와 <body>로 나눠진다고 하여 나는 처음에 듣고 이게 상단과 하단을 의미하는 줄 알았는데 아니었다. ^^;
(1) <Head>
<head> 태그는 문서의 머리를 나타내는 태그로, 브라우저 화면에 직접적으로 보이는 것이 아닌 숨은 데이터를 정의하는 태그들이 들어간다고 한다. 어글리어스의 랜딩페이지를 개발자도구를 통해 보며 부분을 살펴보았다.
내가 읽을 줄 아는 걸 찾아보니 트위터, 구글 분석, 채널톡, 페이스북 등이 있다. 랜딩페이지인 만큼 검색을 통한 유입시 데이터를 수집하는 것과 관련이 있는 것 같다.
- <title>태그는 웹 페이지의 제목을 나타내는 태그이다. 마찬가지로 본문에 보이지 않으며, 위의 이미지처럼 브라우저 탭 등에서 확인할 수 있다. 유저에게 문서의 제목을 알리는 용도 뿐만 아니라, 검색 엔진 등에서 가장 크게 보여지는 텍스트이므로 페이지의 특성을 드러내는 제목을 작성하는 것이 중요하다고 한다.
- <meta>태그는 웹 페이지의 보이지 않는 정보를 제공하는데 쓰이는 태그이다. 페이지의 설명 요약, 핵심 키워드, 제작자, 크롤링 정책 등 수많은 정보를 제공할 수 있다고 한다. 해당 태그를 이용하여 description, keywords, author, subject, classification 등의 정보를 표기할 수 있으며, 검색 엔진에서 이런 정보가 적극적으로 활용된다.
(2) <Body>
<body>태그는 문서의 몸통을 나타내는 태그이다. 우선 태그의 종류를 먼저 알아보고 랜딩페이지에서 사용되는 자주 사용되는 태그들을 비교해보았다.
- <br>를 통하여 줄바꿈을 할 수 있다.
- <p>태그는 paragraph, 즉 문단의 약자로, 하나의 문단을 만들 때 쓰인다.
- <b>태그는 글자를 굵게 표시하는 태그로, bold의 약자이다.
- <strong>태는 <b>와 같은 기능을 하며 최신 표준은 <b> 태그 보다는 <strong> 태그를 권고한다.
- <i>태그는 글자를 기울여서 표시하는 태그로, italic의 약자이다.
- <h1>, <h2>, <h3>, <h4>, <h5>, <h6>를 묶어서 <h#> 태그라고 작성하며, 이 태그들은 섹션, 문단의 제목을 나타내며 숫자가 작을수록 글자의 크기가 커진다. 단순히 글자의 크기가 크게 보일뿐만 아니라, 봇(컴퓨터, 검색엔진)이 문서를 파악하기 위해 쓰이므로 상황에 맞게 <h#>를 잘 써주는 것이 중요하다고 한다.
- <a>태그는 하이퍼링크를 걸어주는 태그이다.
- <img> 태그는 이미지를 삽입하는 태그로, src 속성을 통해 이미지 경로를 지정한다.
- <div>태그는 Division의 약자로, 레이아웃을 나누는데 주로 이며, 다른 태그와 다르게 특별한 기능을 갖고 있지는 않고, 가상의 레이아웃을 설계하는데 쓰이며, 주로 CSS와 연동하여 쓰인다고 한다. 해당 태그가 정말 많이 보였다.
- <span> 태그는 <div>태그처럼 특별한 기능을 갖고있지 않고, CSS와 함께 쓰인다. 이 둘의 차이는 <div>는 줄 바꿈이 되지만, <span>은 줄 바꿈이 되지 않다는 점이라고 한다.
- <li> 태그는 list의 약자로, 목록을 만드는 태그이다. 이 태그는 단독으로 쓰이지 않으며 <ul>혹은 <ol>태그 내부에 들어간다.
- <form>태그는 웹 페이지에서의 입력 양식을 의미하며, 로그인 창이나 회원가입 폼 등이 이에 해당된다.
(3) CSS를 제거하고 본 어글리어스의 랜딩페이지
CSS를 제거하고 보면 HTML만 볼 수 있다고 하여서, 크롬 플러그인의 Web Developer를 설치하여 CSS는 보이지 않게 적용해 보았다. 나는 저 보라색 글씨의 밑줄친 부분만 나올줄 알았는데...! 어쩐지 이미지와 몇몇 글씨가 보였다. 다시한번 살펴보니 HTML중에도 <img>를 통해 이미지를 삽입할 수 있고, 어글리어스에 해당 태그가 보였다. 아리송해서 찾아보니 HTML만으로도 웹페이지 개발+디자인이 가능하기는 하나, 수정을 용이하게 하고 심미성을 위해 CSS를 함께 사용하는 것이라 하니, 꼭 HTML이 정보 코드'만'을 담당하는 것은 아니라고 이해하였다. CSS에 대해서 알아보니 더더욱 이해할 수 있었다.
2. CSS
HTML을 웹 사이트에서 화면에 표시되는 정보를 약속이라 한다면, CSS는 구체적으로 어떤 스타일로 요소가 표시 되는지를 정하는 규격이라고 할 수 있다고 한다. 초기의 웹은 HTML 하나로 문서의 뼈대도 만들고 꾸미기도 함께 하였지만, 공통적인 디자인을 갖는 문서가 여럿 존재 할 경우 하나의 디자인이 변경되면 모든 파일을 수정해야 하는 등의 번거로움이 존재했다. CSS는 이런 문제를 해결함과 동시 웹페이지의 내용과 스타일(표현)을 분리해주어, 역할 분담도 되는 효과를 가지고 있다.
CSS 내부적으로 사용되는 문법은 동일하며, 어디에 기술하느냐의 차이가 존재한다고 한다.기술하는 방법은 아래의 3가지에 해당된다.
- HTML 태그의 style 속성을 이용
- <style> 태그를 통해 HTML 문서 내부에 기술 (<style> 태그는 주로 <head>태그 내부에 사용)
- .css 파일로 분리하여 HTML 문서에 연결
CSS를 별도의 파일로 저장하여 HTML 문서로 불러오면, 여러 웹페이지에서 공통적으로 CSS를 참조할 때, 중복 코드를 제거할 수 있어서 유용하다고 한다.
마찬가지로 CSS Viwer라는 크롬 확장 플러그인을 설치하여, 해당 영역을 클릭하면, 관련 HTML과 스타일을 보여준다! (세상 참 좋다) 혹시 Hifi Wirframe을 그릴 때 참고가 가능할지도...(이렇게 밖에 연관이 잘 안된다. ㅠ^ㅠ) HTML 태그인 <div>를 활용해 각각의 블록(공간)을 알맞게 배치하고, CSS요소를 적용한거라는 건 알겠어요!
3. JavaScrpit
위의 HTML과 CSS는 스타일로 표소되는 규격 즉, 정적인 것만 할 수 있는 언어인데 이와 반대로 자바 스크립트는 웹페이지를 동적으로 만들어주는 언어로, 객체 기반의 스크립트 프로그래밍 언어라고 한다. 앞서 두 언어와 달리 변수와 함수 등이 존재하는 프로그래밍, 클라이언트 언어로 엔드유저 단계에서 동작한다.
안타깝게도(참말로 다행스럽게도) 일반 유저가 자바스크립트 코드는 볼 수 없다고 한다. 대신 자바 스크립트 기능을 끄면 어떻게 되는지 확인해 보기 위해 개발자도구의 '자바스크립트 사용 중지'를 체크해보았다.
정말 로그인, 구출하기, 햄버거 메뉴 등의 버튼들이 동작하지 않았다. 너.. 중요한 놈이구나?(?)
서비스 유형 조사
다양한 프로덕트가 제공하는 서비스 유형에 대한 분석에 대해 알아보는 내용이었는데, 마침 토론도 해당 주제로 진행이 되었다! 다른 조가 선택한 프로덕트들도 알 수있고, 내용도 알 수 있으니 1석2조~ 토론했던 자료들을 둘러보며 간략하게 정리해보았다.
다양한 프로덕트의 서비스 유형
[글쓰기 플랫폼] 네이버 블로그
- 네이티브 앱
- 사용자 인터페이스 블로그 사용자를 위한 사람들의 글 작성, 편집 관리 하는데 필요한 인터페이스를 제공 (텍스트편집기, 이미지업로드, 태그 추가 등)
- 알림 및 실시간 업데이트 사용자들에게 댓글, 좋아요, 팔로우, 이웃추가 등의 상호작용과 관련한 업데이트를 실시간으로 알려줄 수 있음
- 모먼트 기능으로 인스타 스토리같은 기능 추가
- 블로그마켓 - 마켓플레이스와의 연동이 편리
- 적응형
- 네이티브 앱으로 서비스 중이던 블로그앱에 플러터 도입 중
- 코드 하나로 안드로이드/아이폰 앱 모두 만들 수 있음
- 2009년에 출시한 오래된 서비스 → 화면/기능 등 유지보수가 필요 → 조직과 업무 측면의 한정된 개발자원과 업무 효율성 증대가 필요하여 플러터 도입중
[이미지, 소셜 플랫폼] 핀터레스트
- 웹 : 이미지 서칭시 접근성을 높일 떄에는 웹이 편리
- 하이브리드 앱 : 이미지 로딩 속도와 편리한 인터페이스 사용
- 웹페이지의 경우 반응형
[동영상 플랫폼] 스포티비 나우
- 웹 출시 이후 → 하이브리드 앱 개발
- TV채널만 운영하다가 수익을 늘리기 위해서, 모바일 기기 요금제와 더불어 앱 출시
- 신규 콘텐츠가 지속적으로 노출되어 하이브리드 앱이 적절 (포털 앱, 쇼핑몰 앱)
- 하이브리드 앱은 네이티브 앱에 비해 저렴하고 기간도 적게 걸림
- 웹페이지의 경우 적응형
[동영상 플랫폼] 쿠팡플레이
- 쿠팡에서 제공하는 동영상 플랫폼
- 2023년 기준, 국내 OTT시장 2위 탈환
- 웹 / 앱 서비스 모두 제공
- 전 세계의 동영상 시청 75% 이상이 모바일 기기에서 발생, 시청시간 또한 매년 50%씩 증가
- 웹 서비스는 다양한 운영체제와 호환되기 때문에, 웹 브라우저만 있다면 접속이 용이
- ⇒ 플랫폼 간의 유연한 이용을 가능하게
- 파이어폭스는 지원하지 않음
- 자원을 많이 소모하는 코덱으로 인코딩된 비디오들을 재생할 시 CPU 점유율이 상당히 높아지고 전력 소모량도 과도하게 증가한다.
- 파이어폭스가 리눅스에서 만들어져서, 리눅스 자체가 하드에어 가속을 지원하지 않는다.
[뱅킹] 카카오뱅크
- 네이티브 앱
- 인터넷 뱅킹이 없기때문에 네이티브 앱으로 시작
- 카카오뱅크 다른 은행앱
| 테크핀 | 핀테크 |
| 인터넷 전문은행 | 기존의 인터넷뱅킹 → 앱 |
| 네이티브 앱 | 하이브리드 앱 |
- 좋은 사용자 경험 : 하이브리드 앱보다 카메라, 마이크 등 기능 사용 용이 (공인인증서 사용 X, 카카오인증, 지문 인증)
- 초기의 빠른 성능
- 웹개발을 하지 않아서 비용절감 가능
- 쉬운 조작법
- 카카오 연동
- 캐릭터 마케팅
[커머스, 소셜 플랫폼] 당근마켓
- 네이티브 앱?이 아니고 → 네이티브 웹뷰+웹기술(하이브리드)
- 속도를 해결하기 위해 로컬파일 웹뷰 방식 사용중
- 중고거래 시 사진등록을 위한 접근권한 위해
- 앱에 집중을 하는 프로덕트이기 때문에, 속도가 빠르고 트러블 슈팅이 빠르게 가능
- 디바이스 전체의 기능을 가지고 올 수 있음
- 웹 의존성 낮음
- 게시물 업로드, 구매하기 등의 메인기능은 앱을 통해서만 할 수 있음
- 채팅하기 등의 핵심 기능을 웹에서 사용하려 하면 앱 다운로드 유도
- GPS 기반
- 도로명 주소를 위한 오픈 API가 존재하지 않아 정부 데이터 중 도로명 주소 DB를 참고하여 직접 만들고 주기적으로 업데이트
[커머스] 올웨이즈
- 네이티브 앱
- 앱서비스로 시작하여 PMB 달성 이후 웹서비스 제공
- 초기 고객을 위한 ‘게임 콘텐츠’를 위한 모바일 환경 필요
- 레퍼런스로 삼은 ‘핀둬둬’와 유사하게 앱으로 시작
- 소셜 기능 강조에 따라 웹보다 더 빠르게 구동 가능한 앱으로 시작
- e커머스 업계에서 소비자의 모바일 기기 선호도 상승
- 모바일 환경에서 더 편리한 결제수단 제공 (올페이, 카카오페이)
[커머스] 컬리
- 네이티브 앱
- 모바일 웹(적응형)
- PC 웹
- 사용자의 접근성을 위해 각각 유입경로에서 전부 사용자에게 최상의 경험을 주기 위하여
- 각각 UI가 전부 다름
- 사용성을 지속적으로 개선중인데, 베이스는 네이티브 앱을 위주로, 서비스는 웹으로
생각보다 강의에서 학습한 장단점대로, 뚜렷하게 구별되지는 않았다. 그러나 '개발기간과 비용'을 고려하는 초기 스타트업 시기나 혹은 아주 예전부터 있던 프로덕트의 경우 웹으로 시작한 사례는 많은 것 같다. 미국 실리콘 밸리에서도 웹으로 시작하는 스타트업이 한창 유행했다는 내용을 들었던 적이 있는데, MVP에 해당하는 기능으로 테스트하기에 가장 좋기 때문이 아닐까 싶다.
어글리어스의 서비스 유형
어글리어스는 현재 '웹'으로만 서비스를 제공하고 있으나, 5월 말에 앱출시를 앞두고 있다! (두근) PMF를 찾을때까지는 웹으로만 서비스를 제공하며 유저들의 니즈를 좀더 뾰족하게 확인해 나간 것이 아닐까 추측한다. 실제로 내가 이용한지 4개월동안, 2주에 한번씩 웹페이지를 방문할때마다 끊임없이 개선점이 눈에 보였다. 웹페이지의 구성과 같이 디자인적 요소부터, 비선호 채소의 갯수 확대까지 제한된 비용과 인력을 기반으로 고객 선호도와 만족도를 확인하기 위한 좋은 선택이었다고 본다. 다만 앱이 없더라도 카카오톡 채널 연동과 적절한 알림톡 발송을 통해 웹페이지 방문이 엄-청 번거롭지는 않도록 고객 입장을 신경쓴 것이 느껴졌다.
그렇다면 곧 출시되는 앱은 어떤 형태로 나올까? 네이티브 앱의 형태로 예상되는데 정확한건 나와보면 알겠지! 그렇다면 앱을 출시하기로 한 이유는 무엇일까? 구독과 관련되어 매주 채소를 확정하는 것과 같은 접근성을 높이는 것도 물론 있겠지만, 사실 기존에 카카오톡 알림을 통해 바로 웹 방문이 가능했기 때문에 1순위는 아니었을 것 같다. (채소 확정 기능만큼은 푸쉬알림을 통해, 앱을 방문하여 진행하는 것보다 카카오톡 알림이 좀 더 편리할 것 같다는 생각도 든다. 물론 확정 이후 무언가를 변경하기 위해서는 앱의 접근성이 더 편리하겠지만요!)
나는 그 이유로 현재 어글리어스 웹페이지 중 '레시피' 관련 기능이 영향이 크지 않을까 추측해본다! 식단일기, 레시피를 업로드 하는 것 모두 사진과 함께 글을 작성해야 하는데, 이 기능은 구독확정보다 더 빈번하게 사용될 수 있는 기능이다. 요리를 할 때 혹은 밥을 먹다가도 쉽고 빠르게 내 식단일기를 업로드하고 싶다면? 네이티브 앱의 카메라 접근 가능과 사용자 경험 최적화 장점이 더욱 두드러질 것 같다! 이런 고객경험을 더욱 편리하게 하여 방문 횟수를 늘리고, 프로덕트에 머무는 시간이 길어진다면....! 앞으로 또 할 수 있는게 얼마나 많겠어요.(두루뭉술)추가로, 앱이 설치된다면 레시피 페이퍼 발송 중지도 고려해볼 수 있을 것 같다! 더더욱 기대되는 어글리어스 앱!
카카오로 로그인하기? Open API 뜯어보기
API란 Application Programming Interface의 줄임말로 '애플리케이션'을 ‘프로그래밍’하는 데 필요한 ‘인터페이스’라고 한다. 말이 어렵지만, 서버와 클라이언트가 서로 어떤방식으로 주고받을지에 대해 정의한 것으로 이해했다. Open API란 하나의 웹 사이트에서 자신의 기능 중 일부를 이용할 수 있도록 공개한 프로그래밍 인터페이스라고 하였다. 특히 네이버, 카카오, 구글 등과 같이 메타 서비스를 제공하는 대기업들이 시장 확대를 목적으로 오픈 API를 운영하거나 공공의 목적으로 비영리기관에서 무료로 API를 제공한다고 한다.
어글리어스의 경우 카카오 로그인 카카오 싱크기능과, 카카오톡 채널 기능을 이용하고 있다. 카카오 로그인인줄 알았는데, 카카오 싱크에 해당되는 API였다. 카카오 싱크는 카카오 소셜 로그인의 확장 스펙으로, 사용자의 개인정보를 추가로 제공받을 수 있고, 서비스 가입시 서비스에서 받아야 하는 서비스 약관을 카카오 동의창에 함께 노출하여 회원가입 절차를 최소화해 사용자가 쉽고 빠르게 서비스에 유입될 수 있도록 하는 것이다.
가입의 단계를 줄여주는 간편가입 부분도 차이가 나지만, 특히 카카오톡 인앱브라우저에서 서비스 페이지에 진입하면 로그인을 하지 않아도 바로 마이페이지의 내용이 노출되었는데 이게 로그인과 다른 싱크의 기능이라니! 이걸 이제 알다니!
- 카카오톡 실행이 불가능한 환경이라도 카카오 계정을 통해 별도 서비스 회원 가입 절차 없이 로그인 가능
- 한 화면에서 회원 가입에 필요한 모든 동의를 맏을 수 있고, 카카오톡 채널 추가도 가능
- 카카오 로그인 사용자 정보제공 요청을 통해 회원가입 시 필요한 사용자 정보들을 카카오로부터 제공 받기 가능
- 카카오 로그인을 통해 서비스에 손쉽게 로그인 가능
- 카카오톡 채널/카카오 비즈보드/챗봇 등 다양한 카카오 마케팅 솔루션을 더욱 효과적으로 사용 가능
그러나 카카오 싱크의 경우에도 카카오 로그인 개발 가이드를 따르므로, 해당 내용을 분석해보기로 하였다.
가장 먼저데이터 요구사항, 기능 요구사항, 개발 및 서비스 환경을 먼저 확인하라고 권장되어 있었다.
강의를 통해 학습했던 REST API를 사용하겠다라는 가정으로 이어서 알아보기로 하였다.
REST API 명령의 종류
- GET : 읽어오기(불러오기)
- POST : 생성하기
- Update(변경) : PUT(전체)/PATCH(일부)
- Delete(삭제) : DELETE
인가 코드 받기
GET /oauth/authorize?client_id=${REST_API_KEY}&redirect_uri=${REDIRECT_URI}&response_type=code HTTP/1.1Host: kauth.kakao.com
카카오 로그인 동의 화면을 호출하고, 사용자 동의를 거쳐 인가 코드를 발급된다고 한다. 동의 화면은 앱에 설정된 동의 항목에 대해 사용자에게 인가(동의)를 구한다고..하는데요.. 이때 동의항목은 설정에 따라 내용이 바뀌고,사용자 동의는 한번만 받으면 이후에는 즉시 인가 코드 드가 발급 된다고 한다. 저는 동의항목 내용에 좀 더 힘써보겠습니다...
토큰 받기
POST /oauth/token HTTP/1.1Host: kauth.kakao.comContent-type: application/x-www-form-urlencoded;charset=utf-8GET/POST /v2/user/me HTTP/1.1Host: kapi.kakao.com Authorization: Bearer ${ACCESS_TOKEN}/KakaoAK ${APP_ADMIN_KEY}Content-type: application/x-www-form-urlencoded;charset=utf-8인가 코드로 토큰 발급을 요청합니다. 인가 코드 받기만으로는 카카오 로그인이 완료되지 않으며, 토큰 받기까지 마쳐야 카카오 로그인을 정상적으로 완료할 수 있습니다. 필수 파라미터를 포함해 POST로 요청합니다. 요청 성공 시 응답은 토큰과 토큰 정보를 포함합니다. OpenID Connect를 사용하는 앱인 경우, 응답에 ID 토큰이 함께 포함됩니다. 각 토큰의 역할과 만료 시간에 대한 자세한 정보는 토큰 정보에서 확인할 수 있습니다.액세스 토큰으로 사용자 정보 가져오기와 같은 카카오 API를 호출할 수 있습니다. 토큰 정보 보기로 액세스 토큰 유효성 검증 후, 사용자 정보 가져오기를 요청해 필요한 사용자 정보를 받아 서비스 회원 가입 및 로그인을 완료합니다.
추가 기능
인가 코드 받기 요청 시 사용할 수 있는 추가 기능은 다음과 같습니다.
- 추가 항목 동의 받기
- 카카오톡에서 자동 로그인하기
- 약관 선택해 동의 받기
- OpenID Connect ID 토큰 발급하기
- 기존 로그인 여부와 상관없이 로그인하기
- 카카오계정 가입 후 로그인하기
추가 항목 동의 받기
추가 항목 동의 받기는 사용자가 동의하지 않은 동의 항목에 대한 추가 동의를 요청하는 추가 기능입니다. 인가 코드 받기 요청 시 scope 파라미터로 추가 동의받을 항목의 ID 목록을 지정합니다. 응답으로 받은 인가 코드로 토큰 받기를 요청해 카카오 로그인을 완료한 뒤, 이후 새로 발급받은 토큰을 사용해야 합니다.
요약이 잘 안되어 그냥 줄글을 복사해왔다. 저 위에 이미지자료로는 조금 이해가 되었는데, 상세 디스크립션을 보기 시작하니 역시 어렵다.. 우선 어떤 종류의 API가 있는지 알아두고, 내가 담당하는 프로덕트에 필요한 API를 떠올리고, 이에 필요한 내용을 정리할 수 있는 것을 목표로..! 해야겠어요. 강의를 들을때도 강연을 들을때도, 개발 용어와 관련하여 어려움을 극복하는 방법에 대한 질문은 항상 나온다. 지금은 나같은 사람을 대상으로 하는 책을 많이 참고하고, 입사하면 정말 개발자분들과 친해져야지...! 맨날 커피 사드려야지(?) ㅠㅠ
참고자료
https://developers.kakao.com/docs/latest/ko/kakaologin/rest-api#req-user-info-info
Kakao Developers
카카오 API를 활용하여 다양한 어플리케이션을 개발해보세요. 카카오 로그인, 메시지 보내기, 친구 API, 인공지능 API 등을 제공합니다.
developers.kakao.com
'PM 여정 > Uglyus' 카테고리의 다른 글
| [PMB 18기] W6 어글리어스 플로우차트, 데이터 분석하기 (0) | 2023.05.15 |
|---|---|
| [PMB 18기] W5 어글리어스 퍼널 및 AARRR 분석, A/B테스트 기획하기 (1) | 2023.05.08 |
| [PMB 18기] W4 어글리어스, 채소레벨 개선을 위한 기획 산출물 작성하기 (0) | 2023.04.25 |
| [PMB 18기] W3 어글리어스는 어떻게 돈을 벌지? (0) | 2023.04.21 |
| [PMB 18기] W2 어글리어스, 종이페이퍼는 필수일까요? (0) | 2023.04.10 |
