즐거운인생

본 포스트는 애플 앱 스토어(Apple AppStore)에서 앱을 서비스하기 위해 검수 요청할 때 애플에서 요구하는 Native Apple Map을 지원하기 위한 내용을 다룹니다.

앱 서비스를 하나 만들어서 먼저 구글 플레이스토어에 런칭한 후 아이폰 앱도 만들어서 애플 앱 스토어에 검수를 요청했는데, 대강 아래와 같은 사유로 Reject 메시지가 전달 되었습니다.

Guideline 4.0 - Design
Your app's location feature is not integrated with the built-in mapping functionality, which limits users to a third-party maps app

검수를 요청한 앱에는 특정 판매점을 찾아가기 위한 길찾기 기능이 포함되어 있었고, 길찾기 기능을 선택하면 휴대폰에 설치되어 있는 네이버 맵을 호출하여 길찾기 기능을 제공하는 형태였습니다. (아래 그림 참고)

구글 플레이스토어 심사 당시에는 문제가 되지 않았지만 애플에서는 디자인 가이드 라인에 따라서 위 내용과 같이 third-party 앱이 아닌 이미 built-in 되어 있는 애플 맵을 통해 길찾기 기능을 제공해야 한다는 Review 였습니다. 사실 애플 맵에 길찾기 기능이 있는 것도 확인해보지 않았었고, 대부분 길찾기 기능을 네이버 맵을 사용하기에 수정은 하지 않고 회신 처리했습니다.

회신 내용
한국에서는 대부분 네이버 맵을 사용하여 길찾기 기능을 제공하고, 사용자의 휴대폰에 설치되어 있지 않은 경우 손쉽게 설치할 수 있도록 앱 스토어로 안내합니다. 모든 지도 기능을 애플 맵을 통해 제공하라는 무리가 있습니다.

어느 정도 납득이 될 줄 알았지만 애플에서는 다시 Reject이 왔습니다. 사유는 대강 아래와 같습니다.

Guideline 4.0 - Design
Specifically, your app  limits users to a third-party maps app, but does not give users the option to launch the native Apple Maps app. Apps that use a third-party maps, need to offer native Apple Maps to users as an equivalent option.

다른 앱으로 서비스를 반드시 해야 한다면 사용자가 애플 맵도 선택할 수 있게 동등한 옵션을 주라는 권고강제였습니다. 하여 Apple Map API를 찾아보니 의외로 많은 기능들이 있었습니다. 아래 링크에 상세한 API 가이드가 나와 있습니다.

https://developer.apple.com/library/archive/featuredarticles/iPhoneURLScheme_Reference/MapLinks/MapLinks.html

개발하실 일이 있으면 아래 소스코드를 참고하시면 됩니다.

1. Android 네이버 맵 연계

const mapUrl: string = 'intent://route/walk?appname=testApp&slat=' + slat + '&slng=' + slng + '&sname=현재위치&'
                     + 'dlat=' + store.lat + '&dlng=' + store.lon + '&dname=' + encodeURIComponent(store.storeName)
                     + '#Intent;scheme=nmap;action=android.intent.action.VIEW;category=android.intent.category.BROWSABLE;package=com.nhn.android.nmap;end';
location.href = mapUrl;

2. Web or iOS 앱에서 네이버 맵 연계

const mapUrl: string = 'nmap://route/walk?appname=testApp&slat=' + slat + '&slng=' + slng + '&sname=현재위치&'
                     + 'dlat=' + store.lat + '&dlng=' + store.lon + '&dname=' + encodeURIComponent(store.storeName);
location.href = mapUrl;

3. Apple Map 연계

const mapUrl: string = 'maps://?t=m&saddr=' + slat + ',' + slng + '&daddr=' + store.lat + ',' + store.lon;
location.href = mapUrl;

블로그에 정리한 내용들 중 React와 Express로 애플리케이션을 구성하여 이전 회차들의 당첨번호를 수집하여, 해당 데이터들로 통계를 분석하여 로또 추천(예측/예상) 번호를 생성해주는 애플리케이션을 사이드 프로젝트로 만들어 보았습니다.

아래 URL에서 다운로드 하실 수 있습니다.

https://play.google.com/store/apps/details?id=com.nextact.lottoapp

애플리케이션은 아래 포스트에서 설명한 구조로 구성되어 있습니다.

https://redballs.tistory.com/entry/React-Express-Typescript-애플리케이션-구성

Back-end는 살짝 변경해서 NestJS 기반으로 구성했지만 별반 다를 내용은 없습니다. Front-end는 React + Typescript로 구성해 보았습니다. 원리는 수집한 자료를 기반으로 나름의 알고리즘으로 서버에서 분석을 해서 번호를 생성한 후 Front-end에 전달하면 Front-end에서 추천번호를 보여주는 방식입니다.

UX는 아래와 같이 구성되어 있습니다.

로또 번호를 5개까지 생성할 수 있고 (마음에 들지 않는 번호는 재생성할 수 있습니다.) 근처에 있는 1등 당첨 판매점과 일반 로또 판매점을 조회할 수 있습니다. 또한 우리 앱에서 생성한 번호 중 실제로 1등~5등에 당첨된 번호가 있으면 [당첨내역]에서 조회할 수 있습니다. 

그리고 회차 별 당첨번호도 조회할 수 있고, 생성한 번호를 지인에게 선물할 수도 있습니다.

한 번쯤 애플리케이션에 관심이 있으신 분은 다운로드 하셔서 평가 부탁 드립니다.

구글 플레이스토어에서 "lottokit"을 검색하시거나 아래 URL로 바로 다운로드 하실 수 있습니다.

https://play.google.com/store/apps/details?id=com.nextact.lottoapp

이 포스트는 Java 에서 여러 개의 단어 조건을 equals로 비교할 때 equals 대신 Arrays.asList().contains 를 사용하는 방법을 설명합니다.

Java 업무 프로그램을 작성하다 보면 A이거나 B이거나 C일 경우에 어떤 코드를 실행시키는 형태의 조건문을 많이 작성합니다. 이렇게 조건이 몇 개 없을 때는 equals를 사용해도 가독성이 나쁘지 않고, 변경에도 문제가 없지만 조건이 많을 경우에는 프로그램도 길어져 가독성이 떨어질 뿐만 아니라 변경 시에도 좀 헷갈리는 경우가 있습니다.

String cond = request.getParameter("cond");

if ("A".equals(cond) || "B".equals(cond) || "C".equals(cond)) {
    //Do something
}

JavaScript에서 조건을 배열로 만든 후 indexOf나 includes로 조건문을 사용한 것과 동일하게 Java에서도 Arrays.asList를 아래와 같이 사용할 수 있습니다.

String cond = request.getParameter("cond");

List condList = Arrays.asList(new String[] {"A", "B", "C"});
if (condList.contains(cond)) {
    //Do something
}

위와 아래의 조건문은 동일한 코드이지만 가독성이나 변경을 생각하면 아래 쪽이 조금 더 용이해 보입니다.

JavaScript에서 indexOf, includes를 사용하는 방법은 아래 포스트를 참고합니다.

조건문에서 indexOf, includes 활용 :: 즐거운인생 (tistory.com)

웹 페이지의 성능을 측정하고 진단하기 위한 도구로 Google Chrome의 Lighthouse의 권고사항 중 하나인 WebP, AVIF와 같은 차세대 이미지 형식을 사용하는 방법을 알아 보겠습니다.

이번 포스트에서는 기존의 이미지를 WebP 형식으로 변환하여 웹 페이지에서 사용할 수 있는 방법을 설명하겠습니다.

로컬 페이지로 성능 테스트

먼저 로컬에 JPEG 형식의 이미지를 하나 표시하는 페이지를 만든 후 Chrome Lighthouse로  성능을 테스트합니다. 이미지는 그냥 제 이전 포스트를 캡쳐한 이미지를 사용하겠습니다.

위 그림과 같이 크롬 개발자 도구를 열고 Lighthouse 탭으로 이동하여 [Analyze page load] 버튼을 선택하면 아래와 같이 성능을 분석한 결과가 표시됩니다. 물론 로컬에 있는 페이지를 불러온 것이고 달랑 이미지만 하나 넣었으므로 성능 지수는 부족함이 없이 나오지만 권장 사항 중에 아래와 같은 내용이 표시됩니다. (실제 웹 페이지를 분석해 보면 많은 내용들이 나옵니다.)

현재 사용 중인 JPEG 포맷 대신 WebP나 AVIF 포맷을 사용ㅇ하면 126.8 KiB가 발생하는 트래픽을 73.0KiB 까지 줄일 수 있다는 내용입니다. 이번 포스트에서는 이 중 WebP 포맷으로 변환하여 사용해 보겠습니다.

WebP 변환 Command-Line 도구 다운로드

Photoshop 플러그인 형태로도 사용할 수 있지만 우리는 Command-Line 도구를 다운로드 하여 기존 이미지를 변환하는 방법으로 진행해 보겠습니다. 아래 URL로 가서 각자가 사용하는 환경에 맞는 버전을 다운로드 합니다.

https://developers.google.com/speed/webp/docs/precompiled

다운로드를 완료하면 각자 사용을 원하는 경로에 압축을 해제합니다. 환경변수 PATH에 등록하면 어느 경로에서든지 사용할 수 있습니다. 저 같은 경우는 C:\tools\libwebp-1.2.3-windows-x64 경로 아래 압축을 해제 했으며, 필요한 명령어들은 C:\tools\libwebp-1.2.3-windows-x64\bin 아래 있습니다.

이미지 변환해보기

이제 로컬 페이지에서 사용한 JPEG 형식의 이미지를 WebP로 변환해 보겠습니다. 연습 과정이니 PATH를 등록하지 않았다면 그냥 bin 디렉토리 아래 해당 이미지를 복사합니다. 변환 전 이미지의 크기를 확인해 보겠습니다.

변환 전 blog_capture.jpg 이미지 파일의 크기는 129,872 Bytes  입니다. 아래 명령어를 입력하여 이미지를 변환해 봅니다.

C:\tools\libwebp-1.2.3-windows-x64\bin>cwebp -q 50 blog_capture.jpg -o blog_capture.webp

위 명령은 이미지 품질을 50%으로 하여 WebP 형식으로 이미지를 변환하겠다는 의미입니다. cwebp 명령어로 WebP 인코딩을 위한 명령에 대한 상세 설명은 아래 페이지를 참고하시면 됩니다.

https://developers.google.com/speed/webp/docs/cwebp

변환을 완료한 후 이미지 크기를 확인해 보면 아래와 같습니다.

40,124 Bytes로 이미지 크기가 감소했습니다. 압축률이 상당히 좋아 보입니다.

변환한 이미지 사용하기

WebP 이미지 사용을 위해서는 WebP를 지원하지 않는 브라우저 지원을 위해 <picture> 태그를 사용해야 합니다. 변환 전에는 아래와 같은 마크업을 사용해서 이미지를 표시했습니다.

<img src="img/blog_capture.jpg">

WebP 이미지를 사용하기 위해서는 아래와 같이 마크업을 변경합니다.

<picture>
    <source type="image/webp" srcset="img/blog_capture.webp">
    <source type="image/jpeg" srcset="img/blog_capture.jpg">
    <img src="img/blog_capture.jpg">
</picture>

위와 같이 마크업을 구성하면 WebP를 지원하지 않는 브라우저에서는 jpeg 형식의 이미지를 사용하고, WebP를 지원하는 브라우저에서는 webp 형식의 이미지를 사용합니다.

변경 확인

Chrome의 [Network] 탭에서 사용한 이미지의 종류를 확인해보면 아래와 같이 WebP 이미지를 로딩했음을 확인할 수 있습니다.

Lighthouse에서 다시 Analyze 해보면 차세대 이미지를 사용하라는 권장 사항이 사라진 것도 확인할 수 있습니다.

본 포스트는 광고 플랫폼인 카카오 애드핏으로 블로그에 광고를 붙였을 때의 수익분석에 대한 글입니다.

'22년 7월 초 정도에 호기심에 블로그에 광고 플랫폼을 연동해 보았습니다. 일단은 티스토리에서 연결을 제공하는 광고 플랫폼 중 구글 애드센스와 카카오 애드핏을 연동해 보았습니다. 구글 애드센스는 7월 중순이 넘어가고 있지만 아직 "준비 중" 상태로 승인이 되지 않고 있습니다. 

하지만 카카오 애드센스는 어느 정도의 게시물이 있다면 바로 승인이 되어 블로그에 광고를 삽입할 수 있습니다. 광고를 삽입하여 블로그를 운영하다 보면 수익에 대해서 궁금해지는데, 이 내용을 분석하기가 정말 쉽지 않습니다.

먼저 7월 1일부터의 티스토리 방문자 추이입니다.

초기에는 적었지만 검색 엔진 등록 등 노력한 결과 일별로 100~200 건의 방문수가 발생하고 있습니다. 그럼 이번에는 카카오 애드핏 수익 그래프를 한 번 보겠습니다. (사실 저도 광고 플랫폼을 사용해 보는 건 처음으로 어느 정도의 수익이 발생하는지에 대한 감은 전혀 없습니다.)

가장 많은 날이 7월 8일이었는데 3,187원을 기록했습니다. 사실 이날까지는 8일이 방문자가 가장 많았던 터라 방문자를 늘리면 수익이 늘어날 거라고 생각했지만, 이 생각이 7월 13일에 깨졌습니다. 13일은 그 날까지는 방문자가 가장 많은 날이었는데, 수익은 현저하게 감소했습니다. 15일도 마찬가지 입니다. 다시 최대 방문자수를 갱신했지만 수익은 폭- 고꾸라진 것을 확인할 수 있습니다.

하여 카카오 애드핏 사이트를 방문해서 자료를 확인해보았습니다. 애드핏 관리 페이지는 아래 URL로 접속하시면 됩니다.

https://adfit.kakao.com/info

로그인해서 보고서 > 매체별 보고서 화면을 선택합니다.

화면 하단에서 일자별 수익금액을 확인할 수 있습니다.

일자별 예상적립금과 어떤 수치가 관련이 있는지 궁금하여 수치를 확인해 보면 의외로 중요하다고 생각했던 광고노출수, 클릭수 등은 크게 상관이 없어 보입니다. (물론 노출과 클릭이 없으면 수익이 없긴 합니다.) 표에서 눈에 띄는 수치는 CPC입니다 CPC값이 변동됨에 따라 예상적립금도 따라 움직이는 것을 확인할 수 있습니다.

카카오 고객센터의 "보고서" 영역에서 CPC 값에 대한 설명을 아래와 같이 찾을 수 있습니다.

결국 클릭 당 벌어들이는 수익이라는 의미인데, "광고주의 입찰 상황에 따라 변동될 수 있습니다."라고 기재되어 있습니다. 다른 분들도 이 CPC가 변동되는 사유에 대해 궁금했었는지, 해당 내용의 FAQ도 있습니다.

광고주가 입찰하는 가격이 변동되므로 변동된다는 의미는 이해가 되는데, "매체 지면의 효율에 따라"라는 이야기는 아직 정확히 이해가 되지 않습니다. 이런 저런 실험은 해보겠지만 플랫폼에서 가격 변동의 키를 가지고 있는 이상 아마 파악은 거의 불가능하지 않을까 싶습니다 ㅠㅠ

본 포스트는 협업을 위해 Github에 업로드 되어 있는 프로젝트를 비주얼 스튜디오 코드로 체크아웃 하는 방법을 설명합니다.

1. 체크아웃 대상 프로젝트

다른 포스트에서 진행했던 searchNaverApiTs 프로젝트를 체크아웃 해보겠습니다. Github 경로는 아래와 같습니다.

https://github.com/lgcjh0s/searchNaverApiTs 

2. 프로젝트 폴더 생성

Workspace 폴더를 하나 생성합니다.

D:\> mkdir reactWorkspace

3. Repository 복제

VSCode에서 [리포지토리 복제] 버튼을 클릭한 후 위에 입력창이 생기면 복제할 Github Repository 경로를 입력하고 선택합니다.

4. 저장 경로 선택

아까 생성한 프로젝트 루트 경로를 선택하고, [리포지토리 위치 선택] 버튼을 클릭합니다.

5.  프로젝트 열기

복제된 리포지토리를 여시겠습니까? 라는 확인창이 표시되면 [열기] 버튼을 클릭하여 프로젝트를 엽니다.

프로젝트를 열면 아래와 같은 프로젝트 폴더 구조를 확인할 수 있습니다.

6. node_modules 설치

보통 협업을 위해 Github에 공유할 때는 용량 등의 문제로 node_modules는 제외하고 체크인합니다. 아래 명령어를 입력하여 package.json 기준으로 node_modules를 설치합니다.

D:\reactWorkspace\searchNaverApiTs> yarn install

7. 컴파일 및 번들링, 실행

컴파일 및 번들링을 진행하여 오류가 없는지 확인합니다.

D:\reactWorkspace\searchNaverApiTs> tsc
D:\reactWorkspace\searchNaverApiTs> npm run build

8. 실행

프로젝트를 구동하여 결과를 확인합니다.

D:\reactWorkspace\searchNaverApiTs> yarn start

본 포스트는 비주얼 스튜디오 코드로 작성한 프로젝트를 깃헙에 업로드 하는 방법을 설명합니다.

VSCode에서 작성한 프로젝트는 아래 방법으로 Github에 업로드해서 공동 작업을 할 수 있습니다.

1. 프로젝트 생성

일단 여기서는 간단하게 React 라이브러리만 하나 설치해서 업로드 해보겠습니다. 먼저 프로젝트 폴더를 하나 만듭니다.

D:\workspace> mkdir testPrj

2.  프로젝트 초기화 및 React 모듈 설치

yarn init -y 명령으로 프로젝트를 초기화하고 React 모듈만 하나 설치합니다.

D:\workspace> cd testPrj
D:\workspace\testPrj> yarn init -y
yarn init v1.22.17
warning The yes flag has been set. This will automatically answer yes to all questions, which may have security implications.
success Saved package.json
Done in 0.04s.

D:\workspace\testPrj> yarn add react
yarn add v1.22.17
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
success Saved lockfile.
warning Your current version of Yarn is out of date. The latest version is "1.22.19", while you're on "1.22.17".
info To upgrade, run the following command:
$ curl --compressed -o- -L https://yarnpkg.com/install.sh | bash
success Saved 3 new dependencies.
info Direct dependencies
└─ react@18.2.0
info All dependencies
├─ js-tokens@4.0.0
├─ loose-envify@1.4.0
└─ react@18.2.0
Done in 1.12s.

3. VSCode로 프로젝트 반입

생성한 프로젝트를 VSCode로 반입합니다.

위의 과정을 거치면 아래와 같이 프로젝트가 반입됩니다.

4. Github에 Repository 생성

Github에 로그인하여 [New] 버튼을 선택하여 Repository를 생성합니다.

Repository 생성 화면은 아래와 같습니다. Repository 명은 현재 계정에서 유니크해야 하며, 체크해서 정상이면 초록색으로 체크가 표시됩니다.

Anonymous 접근을 허용하려면 Public, 아니면 Private을 선택합니다. 일단 여기서는 Public으로 생성해 보겠습니다. 입력을 완료하면 [Create Repository] 버튼을 선택합니다.

Repository 생성을 완료하면 아래와 같은 화면이 표시됩니다.

5. gitignore 파일 생성

다시 VSCode로 돌아와서 프로젝트 루트에 .gitignore 파일을 생성합니다. 없어도 되지만 대표적으로 node_modules 같은 경로는 굳이 Github을 통해서 공유할 필요도 없고, 파일 전송에 오랜 시간이 소요됩니다. 이렇게 Github에 공유할 필요가 없는 경로를 구분하기 위해 .gitignore 파일을 사용합니다.

대강 샘플 양식은 아래와 같습니다. node_modules 하위나 dist 하위, vscode 설정 파일 등을 제외합니다.

# Created by https://www.toptal.com/developers/gitignore/api/visualstudiocode
# Edit at https://www.toptal.com/developers/gitignore?templates=visualstudiocode

### VisualStudioCode ###
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json
*.code-workspace

# Local History for Visual Studio Code
.history/

### VisualStudioCode Patch ###
# Ignore all local history of files
.history
.ionide

# Support for Project snippet scope
!.vscode/*.code-snippets

# nodejs
node_modules
dist/*
build/*
*.log
.DS_Store

여기서는 다 필요는 없지만 위의 내용을 .gitignore 파일로 저장하겠습니다. 저장하면 현재 폴더 구조는 아래와 같습니다.

6. Repository 초기화 및 원격 저장소 전송

되도록 UI를 기준으로 설명하겠습니다. 먼저 VSCode의 소스 제어 탭으로 이동하여 [리포지토리 초기화]를 선택합니다.

모든 파일을 스테이징에 반영하고, commit 합니다.

터미널 > 새 터미널 을 선택하여 터미널을 하나 엽니다.

아까 Repository를 생성할 때 나왔던 원격 저장소 추가 명령어를 Copy & Paste 합니다.

D:\workspace\testPrj> git remote add origin https://github.com/lgcjh0s/testPrj.git

이제 원격 저장소로 파일을 전송하면 아래와 같은 형식의 메시지가 표시됩니다.

D:\workspace\testPrj> git push origin master
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 12 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 1.25 KiB | 1.25 MiB/s, done.
Total 5 (delta 0), reused 0 (delta 0), pack-reused 0     
To https://github.com/lgcjh0s/testPrj.git
 * [new branch]      master -> master

이제 Github으로 가서 원격 저장소에 파일이 적용되었는지 확인해 보면, 아래와 같은 Repository를 확인할 수 있습니다.