백엔드 개발 블로그

Google OAuth2 적용하기

베꺼 — Tue, 9 Dec 2025 13:17:28 +0900

* 2025/12/09 기준

Google 공식 가이드: https://developers.google.com/identity/openid-connect/openid-connect?hl=ko

구글 클라우드 프로젝트 생성 및 설정

만약 구글 클라우드 프로젝트가 없다면 클라우드 콘솔에서 신규 생성
프로젝트 생성에 시간이 소요될 수 있음
BETA 프로젝트와 PROD 프로젝트를 각각 생성하였음

데이터 액세스 탭에서 조회하고자 하는 데이터 설정
openid 및 email 추가

클라이언트 탭에서 신규 클라이언트 설정
웹 클라이언트인 경우 도메인과 redirection URI를 입력
- Spring Security의 경우 기본값은 {baseUrl}/login/oauth2/code/google
클라이언트 생성 후 클라이언트 ID와 secret(보안 비밀번호) 확인

Google ID Token 포맷

{
  "iss": "https://accounts.google.com",
  "azp": "1234987819200.apps.googleusercontent.com",
  "aud": "1234987819200.apps.googleusercontent.com",
  "sub": "10769150350006150715113082367",
  "at_hash": "HK6E_P6Dh8Y93mRNtsDB1Q",
  "hd": "example.com",
  "email": "jsmith@example.com",
  "email_verified": "true",
  "iat": 1353601026,
  "exp": 1353604926,
  "nonce": "0394852-3190485-2490358"
}

기본으로 제공되는 데이터는 aud, exp, iat, iss, sub
상세 설명은 문서 참고
email은 고유한 값이 아니며 변동될 수 있으므로 사용자 식별을 위한 고유키는 sub 값을 사용해야 함

Spring Security 설정

해당 내용은 Baeldung에서 잘 설명되어 있음
Spring Security 공식 가이드도 참고

Java Stream 병렬로 실행하기

베꺼 — Mon, 19 May 2025 21:50:55 +0900

기본

List<MyResult> results = inputList.parallelStream()
    .map(this::doSomeProcessing)
    .collect(Collectors.toList());

parallelStream()을 중간에 하나 넣어주기만 하여도 자동으로 병렬 실행된다.
이 때 실제 병렬 처리에 사용되는 pool은 전역으로 공유하는 공유 ForkJoinPool이다.
기본적으로 pool size는 CPU 코어 수 - 1이다.
- 그렇다고 CPU 코어를 다 안쓰는 것은 아니다. 병렬 처리 시에 Main 쓰레드도 거든다. 따라서 전체 코어를 사용한다.
- 참고 Medium 게시글
java.util.concurrent.ForkJoinPool.common.parallelism 환경 변수를 수정하여 기본 common pool의 사이즈를 변경할 수 있다.
- 참고 스택오버플로우

ForkJoinPool을 이용해 pool size 커스터마이징

ForkJoinPool forkJoinPool = new ForkJoinPool(poolSize);
List<MyResult> results = forkJoinPool.submit(() -> inputList.parallelStream()
    .map(this::doSomeProcessing)
    .collect(Collectors.toList())).get();

따로 만든 ForkJoinPool에 병렬 스트림 관련 runnable / function을 submit하여 실행하면 원하는 pool size가 적용된다.
Task를 따로 나누어서 submit한 것도 아니고 통짜 function을 넣었는데도 어떻게 작동하는 건지 궁금했는데
ForkJoinPool의 작동 방식 때문이라고 한다. (ForkJoinPool task 내에서 ForkJoinPool이 사용될 때에는 원래 pool을 그대로 사용한다.)
- 참고 스택오버플로우

[MySQL] utf8mb4_general_ci vs utf8mb4_unicode_ci vs utf8mb4_0900_ai_ci

베꺼 — Fri, 5 Jan 2024 11:26:59 +0900

Character Set

`utf8`는 전체 유니코드를 지원하지 않는다. 한글자에 최대 3바이트를 할당한다.
이모지를 저장하고자 한다면 `utf8mb4`를 사용하자.

Collation

Collation은 어떻게 문자열을 비교하고 정렬할지에 대한 규칙이다.
`utf8mb4_bin` : 바이트 순서대로 정렬
- (ex: 'A' < 'B' < 'a' < 'b' )
`utf8mb4_general_ci` : Case Insensitive, 대소문자 구분 없이 비교 및 정렬
- (ex: 'A' = 'a' < 'B' = 'b')
`utf8mb4_unicode_ci` : general에 더해서 유럽쪽 문자 비교 로직이 추가됨
- (ex: 'ß' = 'ss')
- 유럽쪽 다국어 지원이 필요하지 않다면 굳이?
`utf8mb4_0900_ai_ci` : MySQL 8 디폴트 값.
- 0900: 유니코드 collation algorithm 9.0.0 을 뜻함
- Accent Insensitive : 외국어에서 사용하는 악센트 기호가 있을 때 구분 없이 동일한 글자로 취급
- Case Insensitive : 대소문자 구분 없음
- 큰 문제가 있는데... "가" 와 "ㄱㅏ"를 동일한 문자열로 취급함

결론

한국에서는 웬만하면 utf8mb4, utf8mb4_general_ci를 사용하면 된다.

MySQL 8에서 유니코드가 디폴트가 되었다고 마음 놓지 말고 collation을 챙겨주자.

[Java] Java 가상 스레드 (Virtual Thread)

베꺼 — Sat, 11 Nov 2023 19:25:55 +0900

Java 가상 스레드는 JDK 19부터 Preview, LTS 버전인 JDK 21부터 정식 탑재된 기능으로서

OS가 제공해주는 스레드를 그대로 사용하지 않고 가상의 경량 스레드를 사용하는 기능이다.

개인적으로는 JDK 8 이후로 Java 언어에는 이렇다 할 큰 변화는 없었다고 생각하는데

Project Loom(Java 언어에 경량화된 비동기 기능을 Java에 추가하기 위한 프로젝트)이 추진되면서

오랜만의 큰 혁신이 다가왔다는 생각이다.

기본 컨셉

기존의 코드, 로깅, 디버깅 툴들을 최대한 호환시키면서 경량화된 스레드를 지원한다.
- 개발자는 비즈니스 로직에만 집중하면서 Blocking IO에 대한 성능을 비약적으로 향상시킬 수 있다.
기존 스레드는 스레드 수의 제약이 컸던 반면 가상 스레드는 백만개까지도 큰 문제가 없다고 한다.
- 물론 다소의 오버헤드는 있다.

용어

플랫폼 스레드(Platform Thread): 기존에 사용하던 스레드로서 실제 OS에서 제공하는 스레드를 이용
가상 스레드(Virtual Thread): 신규로 추가된 경량화된 가상 스레드
캐리어 스레드(Carrier Thread): 가상 스레드 작업이 실제로 수행되는 플랫폼 스레드.

그래서 얼마나 좋아졌는데요?

성능 테스트가 잘 정리되어 있는 블로그가 있어 링크를 첨부한다.

https://findstar.pe.kr/2023/07/02/java-virtual-threads-2/

Virtual Thread란 무엇일까? (2)

Software Developer, I love code.

findstar.pe.kr

서버가 수행하는 로직에 따라서 천차만별이기 때문에 정량적인 수치를 딱 짚기는 어렵지만

외부 API 호출 등 Blocking IO가 많고 그 소요시간이 병목인 로직에서는 시스템 자원을 효율적으로 활용할 수 있기 때문에

별도의 코드 수정 없이도 매우 큰 성능 향상을 얻을 수 있다.

주의점

1. ThreadLocal

기존 플랫폼 스레드(OS 스레드)를 사용할 경우 ThreadLocal에 저장되는 객체의 개수가 스레드 개수만큼 제한되며 자주 재사용되는 반면

가상 스레드의 경우 스레드가 수만개까지 생성이 될 수 있기 떄문에 메모리 사용량이나 객체의 초기화 비용이 매우 커질 수 있다.

따라서 ThreadLocal에 너무 무거운 객체를 담지 않도록 주의해야하며 사용 후에는 반드시 remove()로 정리해서 빠르게 GC될 수 있도록 해주어야 한다.

Jackson이나 Netty와 같은 유명 라이브러리에서도 비용이 큰 버퍼와 캐시 등을 ThreadLocal에 저장해두고 있기 때문에

가상 스레드의 개수가 너무 많아질 경우 애플리케이션에 악영향이 있을 수 있다고 한다.

참고) 이를 보완하기 위해서 'Scoped Values'란 신규 기능이 JDK 21에 Preview로 탑재되었다.

JEP 문두부터 "많은 수의 가상스레드를 사용하는 경우 ThreadLocal 대신 이거 쓰세요"라고 소개하는 기능이다.

가볍게 훑어보았을 때에는 기존 ThreadLocal에서 mutability와 lifetime을 제한함으로써
좀 더 효율적으로 사용하는 컨셉인 것으로 보이는데 나중에 좀 더 공부해봐야겠다.

2. Pinning

1. Thread-safety 를 위해 synchronized block을 사용하는 경우

2. 혹은 native 메서드나 foreign 함수를 실행할 경우

위 두가지 케이스에서 가상 스레드는 캐리어 스레드에 고정(pinned)되어 blocking이 있다고 해도

다른 가상 스레드로의 switching이 불가능하여 잠재적인 성능 이슈가 있다.

JEP-444 에서는 pinning이 너무 길어지지 않도록 synchronized block을 손보고

native 메서드나 foreign 함수의 경우 ReentrantLock을 이용해서 함수 실행 전후에 Guard를 추가하도록 가이드하고 있다.

3. 스레드 독점 현상 (Monopolization)

Blocking 없이 CPU를 오래 점유하는 가상 스레드가 다수 있을 경우

다른 가상 스레드의 처리가 지연될 수 있다.

이는 가상 스레드에 아직 선점 스케줄링(preemptive scheduling)이 구현되지 않았기 떄문이다.

쉽게 말해서 block이 없으면 현재 돌고 있는 가상 스레드가 아무리 오래 실행되었다고 해도 다른 스레드로 강제로 전환시키지 않는다.

4. DB 커넥션 풀 등 외부의 한정된 자원

가상 스레드가 아무리 효율적이라고 해도 DB 커넥션 풀 사이즈가 적다면 오히려 무수한 connection timeout을 맞이할 수 있다.

또 MSA 환경에서는 내 서버가 아무리 빨라도 저쪽 서버가 받아주지 못하면 더 큰 문제를 야기할 수 있으며 합법적 디도스 공격이 될 수 있다.

가상 스레드 이전의 OS 스레드를 사용할 때에는 최대 스레드 개수가 천연 rate limiter의 역할을 했다면
가상 스레드를 사용할 경우 리미터가 해제된 것과 다름이 없기 때문에 이를 유념해야 한다.

5. 가상 스레드 오버헤드

가상 스레드는 플랫폼 스레드에 비해서 다소의 오버헤드가 있기 때문에

Blocking이 없는 로직의 경우 오히려 더 성능이 느릴 수 있다.

따라서 가상 스레드를 도입하기 전 blocking 로직이 병목인 게 맞는지 검토할 필요는 있다.

Reactive Webflux는 이제 한물갔나요??

가상 스레드는 저수준의 OS 스레드를 경량화한 기능으로서 결국 '스레드'일 뿐

Webflux의 정확한 대체재는 아니다.

외부 API 호출 및 DB 요청과 같은 blocking IO가 많지만
복잡한 비동기성까지는 필요 없고 선형적인 로직이 주를 이루면서
단순히 blocking IO에 대한 성능 이점 때문에 Mono.map만 주구장창 연결하는 WebFlux를 사용했다면

-> 가상 스레드가 더 적절한 대안이다.

복잡하고 병렬적으로 실행되어야 하는 로직이 있는 등 높은 수준의 비동기성이 필요하거나
BackPressure 등 Reactive가 제공하는 정교한 기능이 필요하다면

-> WebFlux가 적합할 것이다.

극히 개인적인 의견으로는 예전에 WebFlux를 적용해보면서

MDC는 복잡하고 스택트레이스도 제대로 안나오고 디버깅도 복잡하고 예외 처리도 번거롭고...

여러모로 고통받았던 기억이 있어서 쌍수들고 가상 스레드를 환영하고 싶다.

이와 별개로 Structured Concurrency라는 새로운 Java의 concurrency 기능도 논의가 되고 있으며

JDK 21 현재 Preview 기능으로 도입되고 있다.

가상 스레드 + Structured Concurrency가 합쳐지고 Project Loom이 완성된다면

비로소 Reactive WebFlux, 코틀린 Coroutine과의 싸움이 되지 않을까 싶다.

Oracle의 개발자이자 Project Loom의 주요 개발자인 브라이언 게츠(Brian Goetz)는 2021년 팟캐스트에서 아래와 같이 언급하는데

https://www.youtube.com/watch?v=9si7gK94gLo&t=1156s

Loom이 Reactive Programming을 죽일 것이라고 생각한다.

Reactive Programming은 과도기적 기술이었으며
우리가 가진 문제에 대한 반작용에 불과했다는 것을
머지 않은 미래에 모두가 깨달을 것이라고 생각한다.

만약 그 문제가 사라지게 된다면
Reactive는 우리가 원하던 해결책이 아니라는 것이 분명하게 드러날 거다.

Java가 가진 한계점을 극복하기 위해 라이브러리(Reactive)와 개량 언어(Kotlin Coroutine)가 인기를 끌고 있지만

만약 Java가 이런 문제점을 해결한다면 그들의 위치가 애매해진다는 점에는 공감이 간다.

오라클에서 Reactive를 죽이려는 한편 코틀린 진영에서는 가상 스레드 기능을 코루틴에 포함시켜 확장하는 등

Java로 밥벌어먹는 사람 입장에서는 그 미래가 매우 궁금하긴 하다.

(아직 Reactive도 제대로 못써보긴 했지만)

Spring에서는 언제 사용할 수 있나요?

Spring Boot 3.2에서는 spring.threads.virtual.enabled=true 옵션을 통해 정식으로 지원하며
심지어 Spring Boot 2에서도 Embedded Tomcat의 요청을 처리할 executor를 명시적으로 지정해줌으로써 적용이 가능하다.

(Spring Boot 2에서 제대로 최적화가 되었는지는 좀더 확인이 필요)

@Bean
public TomcatProtocolHandlerCustomizer<?> protocolHandlerVirtualThreadExecutorCustomizer() {
    return protocolHandler -> protocolHandler.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
}

총평

가상 스레드는 확실히 Java 생태계의 패러다임을 바꿀 수 있는 기능이라고 생각하지만
흔들기만 하면 성능 좋은 서버가 탄생하는 마법봉은 아니다.

프로덕션에 적용하기 전 위 주의점에서 설명했던 사항들을 점검해보고 테스트와 시행착오를 거쳐야할 것이다.

ThreadLocal에 무거운 객체를 담지 말고 사용 후 remove()로 정리할 것
사용하는 라이브러리가 가상 스레드 환경에서 잘 작동하는지, CPU와 메모리 사용량에 문제가 없는지 확인
Pinning과 스레드 독점 현상이 문제가 되진 않을지 검토
DB 커넥션 풀 사이즈 및 외부 API 등 여러 한정된 자원과의 상호작용을 고려
정말 가상 스레드가 필요한지, Blocking 로직이 병목이 맞는지 검토

프로덕션 코드는 아직 Spring Boot 3, JDK 17로도 전환을 못했는데 21은 언제 할 수 있을지 모르겠다.

참고 문서

JWT의 구조 및 사용 예

베꺼 — Mon, 12 Sep 2022 23:23:17 +0900

JSON Web Token
RFC 7519 표준
흔히 로그인 데이터 등을 주고 받는 데에 사용된다.
JSON 형태의 데이터에 서명 정보를 추가하여 데이터의 위변조 여부를 검사할 수 있다.
- 서명에는 HMAC, RSA 등의 암호화 기법이 사용된다.
- HMAC 참고: https://blog.honeybomb.kr/7

HMAC 이란?

API 통신 등을 할 때, 보안 등의 이유로 통신되는 메시지의 위변조를 막아야 할 경우가 있다. 이 때 어떠한 토큰을 사용하여 메시지가 위변조가 되지 않았는지 검증하는 기법이 주로 사용되는데,

blog.honeybomb.kr

데이터 구조

"헤더.페이로드.서명"의 형태이다.
헤더에는 서명에 사용된 알고리즘과 타입을 담고 있는 JSON이 Base64 URL 형태로 인코딩된다.
페이로드는 실제 전송되는 데이터를 담고 있으며 데이터 JSON이 Base64 URL 형태로 인코딩된다.
서명은 헤더에 명시된 알고리즘을 사용하여 헤더 및 페이로드 데이터를 서명한 문자열이다.

클레임(Claims)

페이로드에 사용되는 JSON은 정해진 데이터 포맷은 없으며 자유롭게 사용할 수 있다.
단, 여러 시스템 간의 호환성을 위하여 미리 정해진 필드명 등이 있는데, "exp", "email", "profile" 등이 있다. 이를 클레임(Claims)이라고 한다.
등록된 클레임과 공개 클레임 목록은 https://www.iana.org/assignments/jwt/jwt.xhtml 링크를 참고한다.

1. 등록된 클레임 (Registered Claims)

필수는 아니지만 JWT 사용 시 흔히 사용되는 필드들로서 여러 시스템 간 호환성을 위해 구현하도록 권장된다.
"iss", "aud", "exp" 등이 이에 해당된다.
하지만 단순 웹서비스 인증 용도를 위해서는 "exp" 정도 외에는 사용할 일이 많이 없을 듯 하다.
- "exp" 필드는 초 단위의 unix timestamp 데이터로서 토큰의 만료기한을 나타낸다.

2. 공개 클레임 (Public Claims)

JWT에서 흔히 쓰이는 데이터를 위해 필드명을 미리 정해둔 것이다.
"email", "profile" 등이 이에 해당된다.
공개 클레임으로 정해진 필드명이 있다면 되도록 규약에 따르는 것이 권장된다.

3. 비공개 클레임 (Private Claims)

등록된 클레임도, 공개 클레임도 아니기 때문에 자유롭게 사용할 수 있는 필드명들이다.

JWT 사용 예

클라이언트는 ID 및 패스워드를 사용해서 최초 인증을 수행한 뒤 권한 정보가 담긴 JWT 토큰을 획득한다.
이후 기타 리소스에 접근하기 위한 API 요청을 보낼 때, "Authorization: Bearer" 헤더 등에 JWT 토큰을 함께 전송한다.
서버는 클라이언트가 함께 전송한 JWT 토큰으로부터 리소스에 대한 접근 권한을 확인한다.
JWT의 서명이 올바르고, 만료되지 않은 토큰이면서 리소스에 대한 접근 권한이 있다고 판단되면 리소스를 클라이언트에게 반환한다.

JWT의 장점 (기존 세션 구조와의 차이)

세션 방식의 인증을 사용할 경우 인증 정보를 별도의 인증 DB에 저장해야 한다. 또, 리소스 요청마다 DB를 조회해야 하는 부담이 있다.
JWT는 무상태(stateless) 토큰으로서 인증 정보를 DB 등에 저장하지 않고 토큰에 포함시키기 때문에, 별도의 저장소가 필요 없다.
따라서 JWT를 사용하면 DB 부하를 줄이고 요청 응답 시간을 빠르게 할 수 있다.
- MSA 구조 등에서 응답 시간을 빠르게 할 수 있고, 수천만 명의 유저가 동시 접속할 때에도 수평적 확장이 용이하다.

JWT 사용 시 주의사항

JWT의 페이로드는 일반적으로 암호화되지 않기 때문에, 페이로드 데이터에 민감한 정보를 포함해서는 안된다. (개인정보, 패스워드 등)
- 평문은 아니어서 사람이 바로 읽을 수는 없지만, Base64 URL 형태로 인코딩된 것이기 때문에 디코딩이 아주 쉽다.
- JWT는 데이터에 서명을 할 뿐, (대부분의 경우) 암호화하는 것이 아니다.
세션을 사용할 경우 서버 측에서 강제로 로그아웃시킬 수 있지만, JWT를 사용할 경우 로그아웃이 힘들다.
JWT는 토큰의 크기가 상대적으로 크기 때문에 트래픽 오버헤드가 생긴다. 따라서 페이로드 데이터는 되도록 간결해야 한다.
토큰 유출의 문제 등으로 인해 Refresh Token과 Access Token을 분리하여 사용하기도 한다. 관련 자료는 나중에 정리할 예정.

참고 자료

HMAC의 구조 및 필요성

베꺼 — Wed, 31 Aug 2022 22:00:09 +0900

API 통신 등을 할 때, 보안 등의 이유로 통신되는 메시지의 위변조를 막아야 할 경우가 있다.
이 때 어떠한 토큰을 사용하여 메시지가 위변조가 되지 않았는지 검증하는 기법이 주로 사용되는데, 이 때 사용되는 토큰을 MAC(Message Authentication Code)라고 한다.
그 중 HMAC(Hash-based MAC)은 SHA256 등의 해시 함수 기반으로 안전하게 MAC을 생성하는 것을 이른다.
HTTPS, JWT 등 다양한 레벨의 보안 통신 프로토콜에서 사용된다.

단순히 해시함수만을 사용할 때의 취약점

패스워드와 같이 원본 데이터는 알 수 없되 그 값의 동일성만 비교하는 경우, H(password || salt || secretKey)와 같이 암호화 후에 DB에 저장하는 것이 보편적이다. (이러한 방식은 패스워드를 탈취하기 위한 Rainbow table 공격을 효과적으로 방어할 수 있다.)
하지만 HMAC으로 사용하기에는 위와 같은 한번의 해싱으로는 부족하다. 공격자가 원본 데이터의 값을 알고 있기 때문이다.
- 먼저, H(secretKey || message)의 경우, 공격자가 비밀키를 몰라도, 원본데이터의 길이와 해시 함수만 안다면 원본 데이터에 악성 데이터를 append하는 동시에 유효한 MAC을 생성할 수 있다고 알려져 있다. 이를 Length extension 공격이라고 한다.
- 반대로, H(message || secretKey)와 같이 비밀키를 뒤에 두어 append를 막는다고 하자. 공격자가 비밀키를 몰라도, 대부분의 해시 함수는 H(m1) = H(m2)라면 H(m1 || key) = H(m2 || key)를 만족하므로 MD5와 같은 약한 해시함수를 사용할 경우 해시함수 conflict를 이용한 공격에 이론적으로 취약해진다.
- 심지어 H(k1 || message || k2) when k1 != k2 또한 취약점이 있다고 알려져 있다.
따라서 해싱 함수가 다소 취약하더라도 복잡한 방법으로 해싱하여 보안성을 높인 것이 HMAC이다.

HMAC 생성 로직

ipad = 0x5c5c5c…5c5c
opad = 0x363636…3636
ikeypad = key XOR ipad
okeypad = key XOR opad
output = H(okeypad || H(ikeypad || message))

위와 같이 두 번 해싱을 수행하면 안전하다고 한다.
ipad와 opad의 값은 ikeypad와 okeypad 사이의 hamming distance를 최대화하기 위한 것이라고 한다.

참고 자료

Hash-based message authentication code, Wikipedia
Bellare, M., Canetti, R., & Krawczyk, H., Keying Hash Functions for Message Authentication, Annual International Cryptology Conference, 1996
Why does HMAC need a fixed length padding?, Stack Overflow

[Kotlin] 코틀린 launch, async 차이점

베꺼 — Tue, 23 Aug 2022 23:30:22 +0900

Kotlin 1.5 기준으로 작성된 글입니다.

코틀린 코루틴에서 새로운 경량 쓰레드에서 작업을 생성하기 위해선 launch 혹은 async를 사용한다.
둘의 자세한 차이점 및 사용시 주의사항에 대해 알아보자.

TL;DR

launch는 작업을 실행만 시키고 그 결과에 관심이 없으며, 각 job 마다의 오류를 처리할 필요가 없을 경우 사용한다.
- launch 내에서 발생한 오류는 join() 메소드 호출 시 catch할 수 없으며, 오류는 부모 job으로 전파된다.
- 만약 supervisorScope 등을 사용하여 부모 job으로 전파되지 않는 경우, 오류는 unhandled exception으로 취급되어 프로그램 실행에 영향을 끼칠 수 있다.
async는 작업 실행의 결과(반환값)를 얻어올 수 있으며 각 job 마다 발생한 오류를 처리할 수 있다.

작업 실행의 결과 포함 여부

`launch`

launch는 Job 객체를 반환한다.
반환된 Job이 완료되기까지 기다려야할 경우 join을 사용하여 기다릴 수 있다.

val job = launch {
    log.info("Launch!")
    delay(1000)
}
job.join()

joinAll()을 사용하여 여러 job의 완료를 기다릴 수 있다.

val job1 = launch {
    log.info("Launch1")
    delay(1000)
}
val job2 = launch {
    log.info("Launch2")
    delay(1000)
}
joinAll(job1, job2)

하지만 launch를 사용하여 반환된 Job에서는 경량 쓰레드에서 수행된 결과를 직접 얻어올 수 없다.

val job = launch {
    doSomething()
}
job.join() // join()의 반환 타입은 Unit 타입이며, doSomething()에서 실행된 결과를 얻어올 수 없다.

`async`

async는 Deferred 객체를 반환한다.
반환된 Deferred가 완료되기까지 기다려야할 경우 await을 사용하여 기다릴 수 있다.

val deferred = async {
    log.info("Async!")
    delay(1000)
}
deferred.await()

awaitAll()을 사용하여 여러 job의 완료를 기다릴 수 있다.

val deferred1 = async {
    log.info("Async1")
    delay(1000)
}
val deferred2 = async {
    log.info("Async2")
    delay(1000)
}
awaitAll(deferred1, deferred2)

async를 사용하여 반환된 Deferred에는 경량 쓰레드에서 수행된 결과가 저장된다.

val deferred = async {
    doSomething()
}
deferred.await() // doSomething()에서 실행된 결과가 반환된다.

Deferred는 Job을 상속하기 때문에, join() 메소드나 joinAll()을 사용할 수 있다.

오류 전파(Exception Propagation) 방식의 차이

`launch`

launch를 사용한 경량 쓰레드에서 발생한 오류는 join() 메소드에서 catch가 불가능하다.

val job = launch {
    log.info("Launch!")
    delay(1000)
    throw RuntimeException("runtime exception")
}

try {
    job.join() // Exception이 발생하지 않아 catch에서 오류를 처리할 수 없다!
} catch (err: Exception) {
    log.error("Error catched from join", err)
}

join()에서 오류를 던지는 대신, 발생한 오류는 부모 job으로 전파되어 외부 scope에서 catch해야만 한다.
- join()에서 오류가 발생하는 경우는 Job이 취소되는 경우 등이 있다.
supervisorScope 등을 사용하여 부모 job으로 전파되지 않는 경우 경량 쓰레드 내에서 발생한 오류는 unhandled exception으로 취급된다.
- 이 경우 안드로이드 애플리케이션이 강제 종료된다거나, 웹 애플리케이션에서는 로깅이 누락되는 등 문제가 있을 수 있으니 주의가 필요하다.

Q: 저는 `join()` 호출할 때 오류 잘 나던데요?

일반적인 코루틴 스코프 내에서 한 경량 쓰레드에서 오류가 발생한 경우, 모든 자식 job은 취소되고 부모 job으로 exception이 전파된다.
이 때 자식 job이 취소가 되면서 join() 호출 시 JobCancellationException가 발생한다.

`async`

async를 사용한 경우 await() 메소드를 실행하면서 오류를 처리할 수 있다.

val deferred = async {
    log.info("Async!")
    delay(1000)
    throw RuntimeException("runtime exception")
}

try {
    deferred.await() // Exception이 발생하므로 내부 로직 내에서 에러를 처리할 수 있다.
} catch (err: Exception) {
    log.error("Error catched from await", err)
}

앞서 Deferred는 Job을 상속하므로 join() 메소드를 사용할 수 있다고 하였다. await()이 아니라 join()을 호출하는 경우 launch와 마찬가지로 오류가 발생하지 않는다.
- 하지만 launch와 다르게 unhandled exception이 발생하지 않는다.

Q: `await()` 호출 시 try catch 블럭으로 감쌌는데도 오류가 무시되지 않고 부모 job이 실패해요!

일반적인 코루틴 스코프 내에서 한 경량 쓰레드에서 오류가 발생한 경우, 모든 자식 job은 취소되고 부모 job으로 exception이 전파된다.
취소 처리를 막고 자식 job의 오류를 수동으로 처리하고 싶은 경우 supervisorScope를 이용해보자.

[Kotlin] 코틀린의 널 안정성 (Null-Safety)

베꺼 — Sat, 6 Aug 2022 17:47:33 +0900

2022/08 기준이며, Java에 익숙하다는 가정 하에 작성된 자료입니다.

Kotlin의 장점으로는 간결성, JVM 호환성, 코루틴 등이 자주 언급되지만 그 중에서도 흔히 언급되는 것은 널 안정성이다.
Java에서는 프로그래머가 주의 깊게 코드를 작성하지 않으면 NPE(NullPointerException)가 빈번하게 일어난다.
Kotlin은 언어의 정적 타입 시스템에 null 관련 구조를 추가하였기 때문에 변수가 null일지 아닐지 고민하거나 수많은 Optional 등을 타이핑하지 않고도 효과적으로 NPE를 막을 수 있다.
기존 Java와 비교하여 어떤 점이 다른지 알아보자.

기존 Java에서는?

String 객체의 레퍼런스는 실제 값을 가질 수도 있고 null 값을 가질 수도 있다.

String myString = null;

파라미터에 null이 들어올지 아닐지 모르기 때문에 null에 대한 예외 처리가 요구된다.

public void doSomething(String inputString) {
    if (inputString == null) {
        // ...
    }

    int stringLength = inputString.length();
    // ...
}

Spring 등 라이브러리에선 이러한 예외 처리를 줄이기 위해 @NonNull Annotation 등과 같은 방식으로 non-null 강제를 하고자 하였다.
다만 Java 언어 자체에서 제공하는 기능은 아니기 때문에 IDE 등에서 경고는 해줄지 모르지만 주의해서 코드를 작성하지 않으면 여전히 NPE가 발생하기 쉽다.

public void doSomething(@NonNull String inputString) {
    int stringLength = inputString.length();
    // ...
}

Java 8에서는 Optional이 추가되어 null일 가능성이 있는 레퍼런스를 직접 사용하기보단 Wrapper로 한번 감싸서 NPE를 줄이고자 하였다.
하지만 Optional을 사용하고 말고는 언어 단에서 강제되지 않기 때문에 Optional이 붙지 않았다고 해서 non-null이라고는 담보할 수 없었다.
그리고 코드가 비교적 간결하지 못하다는 단점이 있다.

public void doSomething(Optional<String> inputStringOptional) {
    String inputString = inputStringOptional.orElse("default");
    int stringLength = inputString.length();
    // ...
}

위와 같이 Java 진영에서도 NPE를 막기 위한 여러 도구를 사용하고자 했지만 언어 자체에 녹여내기는 어려웠고 NPE는 여전히 골칫거리였다.
Kotlin에서는 다소 다른 정적 타입 구조를 도입함으로써 NPE를 근본적으로 방지하고자 하였다.

Kotlin의 nullable 타입

Kotlin에서 String과 같이 타입을 선언한다면, 해당 타입의 레퍼런스에는 null이 들어갈 수 없다.
NPE를 걱정하지 않고 사용할 수 있다.
물론 글 마지막에서 설명할 예외 케이스가 존재한다.

fun doSomething(inputString: String) {
    val stringLength = inputString.length
    // ...
}

아래와 같이 String?와 같이 타입을 선언한다면, 해당 타입의 레퍼런스에는 null이 들어갈 수 있다.
JDK 8의 Optional과 유사하다고 할 수 있다.
nullable한 타입의 변수에 대해 NPE가 발생할 수 있는 메소드 / 필드에 접근하고자 하면 컴파일 단계에서 오류가 발생한다.

fun doSomething(inputString: String?) {
    // 오류 발생!!
    val stringLength = inputString.length
    // ...
}

Safe calls

nullable한 변수의 메소드나 필드에 접근할 때 변수명에 ?을 붙인 것을 safe call 연산자라고 한다.
아래 코드에서 inputString?.length와 같이 접근했을 때, inputString이 null이 아닌 경우라면 length의 값이 되지만, null이라면 stringLength에도 null 값이 들어가게 된다.
자연스럽게 stringLength의 타입 또한 Int가 아닌 nullable한 Int?가 된다.

fun doSomething(inputString: String?) {
    // stringLength 또한 nullable(Int?) 타입이 된다.
    val stringLength = inputString?.length
    // ...
}

이와 같은 Safe call은 위처럼 여러 겹으로 감싸져있는 필드에 접근할 때 매우 유용하다.
만약 Java 코드에서 아래처럼 접근하려면 몇개의 if 문 혹은 삼항 연산자가 필요했을지 생각해보자.

val memberStatus = response?.member?.status

let 함수를 호출하여 null이 아닐 경우에만 특정 코드를 실행할 수 있다.

fun doSomething(inputString: String?) {
    val stringLength = inputString?.length

    // stringLength가 null이 아닐 경우에만 출력이 된다.
    stringLength?.let { println(it) }

    // ...
}

아래와 같이 좌변에서도 safe call을 사용할 수 있다.
만약 좌변의 chain 중 어떤 값이 null일 경우 assignment는 수행되지 않는다.

request?.member?.status = memberStatus

엘비스 연산자 (Elvis Operator, `?:`)

Java에서 null에 따른 예외 처리 / default 값을 사용하기 위해선 아래와 같이 if 문 혹은 삼항 연산자를 사용하거나...

public void doSomething(String inputString) {
    int stringLength = inputString != null ? inputString.length() : -1;
    // ...
}

Optional 등을 이용하는 방법이 있었다.

public void doSomething(Optional<String> inputStringOptional) {
    int stringLength = inputStringOptional.map(String::length).orElse(-1);
    // ...
}

Kotlin에서는 엘비스 연산자 (Elvis Operator, ?:)를 사용하면 위와 동일한 기능을 구현할 수 있다.
아래 코드에서 stringLength는 Int?가 아닌 Int 타입을 가지게 된다.

fun doSomething(inputString: String?) {
    val stringLength = inputString?.length ?: -1
}

Kotlin에서는 return과 throw 또한 expression이기 때문에 중간에 null을 반환하거나...

fun doSomething(inputString: String?): String? {
    val stringLength = inputString?.length ?: return null
    // ...
}

오류를 throw할 수 있다.

fun doSomething(inputString: String?): String? {
    val stringLength = inputString?.length ?: throw IllegalArgumentException("input expected")
    // ...
}

`!!` 연산자 (사용 지양)

!! 연산자를 사용하면 nullable한 type을 강제로 non-null로 변환할 수 있다.
아래 코드에서 stringLength는 Int?가 아닌 Int 타입을 가지게 된다.

fun doSomething(inputString: String?) {
    val stringLength = inputString!!.length
    // ...
}

이 때 레퍼런스가 null의 값을 가지고 있다면 NPE가 발생한다.
당신이 NPE 애호가가 아닌 이상 !! 연산자는 지양하고 엘비스 연산자(?:)를 사용하여 별도의 예외처리를 하는 것이 대부분의 경우 적절하다고 생각한다.

Nullable collections

filterNotNull() 메소드를 이용하면 nullable한 collection을 non-null collection으로 안전하게 변경할 수 있다.

val nullableList: List<Int?> = listOf(1, 2, null, 4)
val intList: List<Int> = nullableList.filterNotNull()

정말 NPE가 발생하지 않나요?

이 글에서 Kotlin이 NPE를 근본적으로 방지하고자 했다고 하지만 정말 NPE가 발생하지 않을까? 당연하겠지만 예외는 있다.
- throw NullPointerException()으로 NPE를 직접 던지는 NPE 애호가
- !! 연산자를 굳이 사용하는 NPE 애호가
- 객체 초기화 시 아직 초기화되지 않은 객체에 잘못된 접근을 하는 경우
  - 객체 생성자에서는 객체 초기화가 완료되지 않은 this에 접근할 수 있는데 이 때 외부에서 this의 속성들에 접근할 경우 NPE가 발생할 수 있다.
  - 부모 클래스의 생성자에서 자식 클래스의 아직 초기화되지 않은 open 멤버에 접근할 경우
  - 공식 가이드 참고
- 다른 언어의 코드와 함께 사용할 경우
  - Java 코드에서는 null을 미연에 방지할 수 없기 때문

참고

Kotlin Null Safety 공식 가이드

Git, Git Flow, Github Flow

베꺼 — Tue, 10 May 2022 19:01:40 +0900

Git

버전 관리 시스템(VCS)는 실수 혹은 기타 이유로 인해 코드가 손상되었을 때 손쉽게 복구할 수 있으며, 여러 사람이 협업 시 누가 어떤 부분을 수정하고 이슈를 만들어냈는지 쉽게 파악이 가능하다.

단순히 폴더나 파일을 날짜별로 만드는 것도 일종의 VCS라고 할 수 있지만, 사람이 실수할 여지가 많다. 이를 위해 RCS 등의 로컬 버전 관리 시스템이 개발되었다. 하지만 시스템 외부의 사람들과 함께 협업하기에는 로컬 버전 관리 시스템의 한계가 뚜렷했다.

이러한 기능을 목적으로 Subversion과 같은 VCS가 만들어졌는데, 이는 중앙집중식 버전 관리 시스템(CVCS)로서 버전 데이터베이스는 오직 한 곳의 서버에 저장되고, 협업자들은 각각 코드를 checkout해서 작업이 가능했다.

하지만 CVCS 또한 중앙 서버가 다운되거나, 서버에 오류가 생기면 프로젝트에 차질이 생기는 것은 피할 수가 없었다. 프로젝트의 모든 이력이 한 곳에만 있을 경우 생기는 문제는 자명했다.

DVCS

그리하여 탄생한 것이 Git과 Mercurial과 같은 분산 버전 관리 시스템(DVCS)이다. 사용자가 서버에서 checkout을 한다는 것은 프로젝트의 이력을 로컬로 동기화 및 백업한다는 것이다. 서버가 다운되거나 문제가 생겨도 local의 이력을 복사하면 그만이다. 또 DVCS는 다수의 원격 저장소를 가질 수가 있기 때문에 유연한 프로젝트 관리가 가능하다.

DVCS는 분산 환경이라는 특성상, 변경은 시간축에 따른 선형 구조가 아닌 DAG 그래프와 같은 모양새를 갖는다. 이와 같은 구조는 여러 협업자가 다른 사람의 현재 작업 여부에 관계없이 자유로운 작업 후 손쉬운 병합을 가능케 한다. 다만 이러한 DVCS에 경험이 없는 사람이라면 직관적으로 life cycle을 이해하기 어려울 수 있다.

여기서 mercurial과 git의 차이가 드러나는데, mercurial은 최대한 쉽고 간편하게 쓸 수 있도록 DVCS임에도 기존 Subversion과 유사한 면모를 보인다. 반면에 git은 설계부터 많은 수에 브랜치를 사용하는 데에 중점을 두었으며 n-way merge 등 브랜치를 효과적으로 제어할 수 있다. 당연히 git의 경우 가파른 learning curve를 보인다.

내부 작동 방식에 있어서도 둘 DVCS의 차이가 있다. Git은 각 commit마다 전체 코드 형상을 저장하는 스냅샷 방식인 반면에, Mercurial은 patch 방식, 즉 달라진 부분만 저장하는 방식으로 변경 이력을 저장하기 때문에 일반적으로 git이 disk overhead가 더 크다고 생각할 수 있다. 하지만 git은 어느정도 시간이 흐른 후 garbage collection을 실행하여 최신의 snapshot을 제외한 예전의 이력은 patch 형태로 가공, gzip으로 압축하고 최근의 commit만을 snapshot으로 저장하기 때문에 최신의 commit을 살펴보는 데에는 빠르면서도 저장소의 크기를 줄일 수 있다.

단, Git은 변경 이력을 수많은 파일로 쪼개어 저장하는데, Windows를 사용하는 경우 그러한 파일 액세스가 느려 성능이 매우 떨어진다. Git for Windows와 같은 프로젝트에서는 리눅스와는 별도의 파일 캐시 기능을 이용하여 성능을 빠르게 한다.

Git Flow

http://nvie.com/posts/a-successful-git-branching-model/

Vincent Driessen이 쓴 branching 모델을 알아보자.

기존에 널리 사용되던 git의 브랜치 모델을 정리한 것으로서, git의 효율적인 브랜치 관리와 병합을 이용하여 프로젝트를 손쉽게 관리할 수 있다. Feature 개발과 release 및 버그 수정을 분리하여, 각 개발자는 repo의 release cycle을 기다릴 필요 없이 자신이 맡은 역할에 집중할 수 있다는 것이 장점이다. 각 브랜치의 병합 과정을 통해 프로젝트의 life cycle를 한눈에 볼 수도 있다.

우선 origin에 항상 존재하는 브랜치(main branch)는 origin/master와 origin/develop 두 가지가 있다. master는 항상 production-ready 상태여야 한다. 프로덕션 서버에 훅을 걸어 master에 푸쉬되면 자동으로 실서버에 deploy해도 될 정도를 말한다. develop은 다음 release를 위한 코드가 모이는 곳이다. 혹자는 'integration branch'라고도 하며 nightly build는 항상 develop을 기반으로 한다.

위의 두 main branch를 보조하는 브랜치, supporting branch에는 다음의 3가지가 있다.

Feature Branches

다음 릴리즈 혹은 먼 후의 릴리즈를 위해 특정 기능을 개발하는 브랜치이다. 기능이 완성되기 전까지는 origin에 남아있다가 develop에 merge 되거나 혹은 어떤 사정에 의해 버려질 수 있다. 항상 develop 브랜치를 기반으로 해야하고 마지막엔 develop 브랜치에 merge 되어야 한다.

master, develop, release-*, hotfix-* 를 제외한 그 어떤 이름이라도 좋다. Feature branch는 보통 origin에 없고 개발자의 레포에 존재한다. develop에 병합할 때에는 반드시 git merge --no-ff를 사용하자. Fast forward가 가능하면 merge commit이 남지 않는데, feature branch의 기록을 남기기 위해 fast forward를 막고 항상 commit을 남긴다.

기본 브랜치: develop
병합 브랜치: develop
네이밍 컨벤션: master, develop, release-*, hotfix-* 제외한 그 어떤 이름(feature-* 또한 많이 쓰임)

$ git checkout -b myfeature develop

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

Release Branches

다음 릴리즈를 위해 코드 메타데이터(버전 넘버 등)을 수정하고 마이너 버그를 고칠 수 있는 브랜치이다. 기존의 release candidate이라고 볼 수 있다.

기본 브랜치: develop
병합 브랜치: develop, master
네이밍 컨벤션: release-*

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

릴리즈를 위한 메타 데이터를 수정하고 마이너 버그를 모두 고쳐 릴리즈할 준비가 되었을 때 develop과 master브랜치에 병합한다. master 브랜치를 기반으로 태그를 생성한다.

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

이후 해당 브랜치를 삭제한다.

$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

Hotfix Branches

Hotfix 브랜치는 새로운 프로덕션 릴리즈를 준비하는 브랜치라는 점에서 release 브랜치와 유사하지만, 기존에 계획되지 않는다는 점이 다르다. 프로덕션 시스템이 잘 작동하지 않을 때 즉시 대응하기 위해 만들어진다. 기존 develop 브랜치는 hotfix의 진행상황을 신경쓰지 않고 계속 개발할 수 있다는 것이 장점이다.

기본 브랜치: master
병합 브랜치: develop, master
네이밍 컨벤션: hotfix-*

기본 브랜치가 master branch라는 점을 제외하면, 작업과 병합 과정은 release branch와 동일하다.

Git Flow Extension

위의 git flow를 손쉽게 사용할 수 있도록 구현한 extension이 있다.

https://github.com/petervanderdoes/gitflow-avh

GitHub - petervanderdoes/gitflow-avh: AVH Edition of the git extensions to provide high-level repository operations for Vincent

AVH Edition of the git extensions to provide high-level repository operations for Vincent Driessen's branching model - GitHub - petervanderdoes/gitflow-avh: AVH Edition of the git extensions to...

github.com

Mac OS에서는 homebrew를 이용해 아래와 같이 설치할 수 있다.

$ brew install git-flow-avh

# 기존 git repo에서 git flow에 맞게 브랜치 생성
$ git flow init
# develop에서 새 feature 브랜치를 생성 후 전환
$ git flow feature start MYFEATURE
# MYFEATURE 브랜치를 develop에 병합 후 삭제
$ git flow feature finish MYFEATURE      
# origin에 MYFEATURE를 게시하여 공동 작업자와 공유
$ git flow feature publish MYFEATURE
# origin에서 MYFEATURE를 pull
$ git flow feature pull MYFEATURE
# develop(혹은 BASE commit)에서 새 release 브랜치를 생성 후 전환
$ git flow release start RELEASE [BASE]
# release 공유
$ git flow release publish RELEASE
# release를 master에 병합 뒤 태그 생성. develop에 재병합 뒤 삭제
$ git flow release finish RELEASE
# 태그는 별도로 push해야 함
$ git push --tags
# hotfix start
$ git flow hotfix start VERSION [BASE]
# hotfix finish
$ git flow hotfix finish VERSION

Github Flow

Git Flow가 등장한 시기(2010)에는 유용한 브랜치 모델이고 실제로 많이 쓰이던 전략이었지만,

아래와 같은 현재의 트렌드에서는 적합하지 않은 전략일 수 있다.

Github의 Pull Request를 대중적으로 사용한다.
Web App이 유행하게 되면서 여러 버전을 동시에 관리하는 경우가 거의 없다.
Continuous Delivery를 통해 자동 배포를 수행한다.
복잡한 브랜치 기반의 롤백이 불필요하다.

대신 Github Flow를 많이 사용한다.

master 브랜치 하나만을 고정하여 사용하고 나머지 브랜치는 feature 브랜치와 같이 자유롭게 사용하며,

Github의 PR 기능을 적극 활용하는 방식이다.

https://docs.github.com/en/get-started/quickstart/github-flow

GitHub flow - GitHub Docs

Introduction GitHub flow is a lightweight, branch-based workflow. The GitHub flow is useful for everyone, not just developers. For example, here at GitHub, we use GitHub flow for our site policy, documentation, and roadmap. Prerequisites To follow GitHub f

docs.github.com

Github flow와 유사하지만 production 브랜치를 따로 두는 GitLab flow 또한 있다.

React Hook을 이용하여 카카오 애드핏(Adfit) 연동하기

베꺼 — Sun, 17 Apr 2022 18:10:55 +0900

React 17 버전을 기준으로 작성된 글입니다. (2022/04)

TL;DR

// KakaoAdfit.jsx
import {useEffect, useRef} from "react";

function KakaoAdFit({unit, width, height, disabled}: any) {
    const scriptElementWrapper = useRef(null);

    useEffect(() => {
        if (!disabled) {
            const script = document.createElement("script");
            script.setAttribute("src", "https://t1.daumcdn.net/kas/static/ba.min.js");
            scriptElementWrapper.current.appendChild(script);

            return () => {
                const globalAdfit = window.adfit;
                if (globalAdfit) globalAdfit.destroy(unit);
            }
        }
    }, [])

    return <div ref={scriptElementWrapper}>
        <ins className="kakao_ad_area" style={{display: "none"}}
             data-ad-unit={unit}
             data-ad-width={width}
             data-ad-height={height}></ins>
    </div>
}

export default KakaoAdFit;

// 사용 예
<KakaoAdFit unit={"DAN-MyExampleAdUnit"} width={"320"} height={"100"} disabled={false}/>

Try #1 : Naive HTML

카카오 애드핏에서 광고 단위를 발급 받으면, 가이드에서는 다음과 같은 형태의 HTML을 원하는 광고 위치에 삽입하도록 안내하고 있습니다.

<ins class="kakao_ad_area" style="display:none;"
 data-ad-unit    = "DAN-MyExampleAdUnit" 
 data-ad-width   = "320" 
 data-ad-height  = "100"></ins> 
<script type="text/javascript" src="//t1.daumcdn.net/kas/static/ba.min.js" async></script>

적당히 wrapping만 해주면 되지 않을까? 생각해서 아래와 같이 컴포넌트를 만들어 봅니다.

function KakaoAdFit({unit, width, height}: any) {
    return <>
        <ins className="kakao_ad_area" style={{display: "none"}}
             data-ad-unit={unit}
             data-ad-width={width}
             data-ad-height={height}></ins>
        <script type="text/javascript" src="//t1.daumcdn.net/kas/static/ba.min.js" async></script>
    </>
}

export default KakaoAdFit;

잘 작동했다면 이 글을 쓸 필요가 없었겠죠???
어느정도 예상했지만 광고가 노출되지 않습니다.

Try #2: `createElement`를 사용한 스크립트 동적 생성

JSX 문법에서는 script 태그를 사용할 수 없기 때문에, 위와 같이 script 태그를 추가하여도 HTML에 반영이 되지 않습니다.
HTML로 선언하는 것이 아닌, 동적으로 스크립트를 생성하는 방법으로 우회해봅시다.

Ref를 사용하면 low-level HTML element에 접근할 수 있습니다.
컴포넌트가 mount 된 후 최초 한 번 동적 script element를 생성하여, 감싸고 있는 div에 추가해봅시다.

// KakaoAdfit.jsx
import {useEffect, useRef} from "react";

function KakaoAdFit({unit, width, height}: any) {
    const scriptElementWrapper = useRef(null);

    useEffect(() => {
        const script = document.createElement("script");
        script.setAttribute("src", "https://t1.daumcdn.net/kas/static/ba.min.js");
        scriptElementWrapper.current.appendChild(script);
    }, [])

    return <div ref={scriptElementWrapper}>
        <ins className="kakao_ad_area" style={{display: "none"}}
             data-ad-unit={unit}
             data-ad-width={width}
             data-ad-height={height}></ins>
    </div>
}

export default KakaoAdFit;

결과는... 잘 나오는 것 같은데요.

문제는 광고가 없는 다른 페이지로 갔다가 다시 원래의 페이지로 돌아오면 광고가 표시되지 않습니다.

참고: 위와 같이 동적으로 script를 생성할 때, async attribute는 필요 없는 것으로 보입니다.
Stack Overflow: Add defer or async attribute to dynamically generated script tags via JavaScript

Try #3: destroy 구현

이미 한번 로딩이 된 광고 단위에 대해 스크립트를 다시 로딩한다고 하더라도 광고가 다시 갱신되지 않는 것이 원인으로 보입니다.
리액트에서 페이지가 이동되어도 애드핏에서는 인지할 수 없으니까요.
기존에 노출되었던 광고 단위를 삭제하거나 정리하는 기능이 있으면 좋을텐데요...

애드핏 스크립트를 로딩하면 global에 adfit이라는 인스턴스가 생성됩니다.
디버거를 확인하면 해당 인스턴스에 destroy 메소드가 존재하는 것을 확인할 수 있습니다.

해당 destroy 함수를 호출해서 컴포넌트가 unmount될 때 기존 광고 단위를 정리해주도록 합시다.

// KakaoAdfit.jsx
import {useEffect, useRef} from "react";

function KakaoAdFit({unit, width, height, disabled}: any) {
    const scriptElementWrapper = useRef(null);

    useEffect(() => {
        if (!disabled) {
            const script = document.createElement("script");
            script.setAttribute("src", "https://t1.daumcdn.net/kas/static/ba.min.js");
            scriptElementWrapper.current.appendChild(script);

            return () => {
                const globalAdfit = window.adfit;
                if (globalAdfit) globalAdfit.destroy(unit);
            }
        }
    }, [])

    return <div ref={scriptElementWrapper}>
        <ins className="kakao_ad_area" style={{display: "none"}}
             data-ad-unit={unit}
             data-ad-width={width}
             data-ad-height={height}></ins>
    </div>
}

export default KakaoAdFit;

그러면 이제 페이지를 이동하여도 광고가 잘 갱신되는 걸 확인할 수 있습니다.

백엔드 개발 블로그

Google OAuth2 적용하기

구글 클라우드 프로젝트 생성 및 설정

Google ID Token 포맷

Spring Security 설정

Java Stream 병렬로 실행하기

기본

ForkJoinPool을 이용해 pool size 커스터마이징

[MySQL] utf8mb4_general_ci vs utf8mb4_unicode_ci vs utf8mb4_0900_ai_ci

Character Set

Collation

결론

[Java] Java 가상 스레드 (Virtual Thread)

기본 컨셉

용어

그래서 얼마나 좋아졌는데요?

주의점

1. ThreadLocal

2. Pinning

3. 스레드 독점 현상 (Monopolization)

4. DB 커넥션 풀 등 외부의 한정된 자원

5. 가상 스레드 오버헤드

Reactive Webflux는 이제 한물갔나요??

Spring에서는 언제 사용할 수 있나요?

총평

참고 문서

JWT의 구조 및 사용 예

데이터 구조

클레임(Claims)

1. 등록된 클레임 (Registered Claims)

2. 공개 클레임 (Public Claims)

3. 비공개 클레임 (Private Claims)

JWT 사용 예

JWT의 장점 (기존 세션 구조와의 차이)

JWT 사용 시 주의사항

참고 자료

HMAC의 구조 및 필요성

단순히 해시함수만을 사용할 때의 취약점

HMAC 생성 로직

참고 자료

[Kotlin] 코틀린 launch, async 차이점

TL;DR

작업 실행의 결과 포함 여부

launch

async

오류 전파(Exception Propagation) 방식의 차이

launch

Q: 저는 join() 호출할 때 오류 잘 나던데요?

async

Q: await() 호출 시 try catch 블럭으로 감쌌는데도 오류가 무시되지 않고 부모 job이 실패해요!

[Kotlin] 코틀린의 널 안정성 (Null-Safety)

기존 Java에서는?

Kotlin의 nullable 타입

Safe calls

엘비스 연산자 (Elvis Operator, ?:)

!! 연산자 (사용 지양)

Nullable collections

정말 NPE가 발생하지 않나요?

참고

Git, Git Flow, Github Flow

Git

DVCS

Git Flow

Feature Branches

Release Branches

Hotfix Branches

Git Flow Extension

Github Flow

React Hook을 이용하여 카카오 애드핏(Adfit) 연동하기

TL;DR

Try #1 : Naive HTML

Try #2: createElement를 사용한 스크립트 동적 생성

Try #3: destroy 구현

`launch`

`async`

`launch`

Q: 저는 `join()` 호출할 때 오류 잘 나던데요?

`async`

Q: `await()` 호출 시 try catch 블럭으로 감쌌는데도 오류가 무시되지 않고 부모 job이 실패해요!

엘비스 연산자 (Elvis Operator, `?:`)

`!!` 연산자 (사용 지양)

Try #2: `createElement`를 사용한 스크립트 동적 생성