mopil devlog

2025년 회고

mopil — Wed, 31 Dec 2025 03:30:17 +0900

2024년 회고

https://mopil.tistory.com/entry/2024%EB%85%84-%ED%9A%8C%EA%B3%A0

2024년 회고

2023년도 회고https://mopil.tistory.com/174 2023년 회고# 1월 친구들과 해커톤에 참여했다. https://mopil.tistory.com/132 SPARCS 2023 StartUp Hackathon 참여 후기 https://hackathon.sparcs.org/ SPARCS 2023 StartUp Hackathon 우리의 생

mopil.tistory.com

# 2025년도 목표 달성?

1. 책읽기 (7권) => 책은 몇 권 샀지만 다 읽지 못했다... 실패

2. 해외여행 => 가족, 친구 일본여행 성공

3. 더 프로답게 일하기 => 목표를 너무 추상적으로 설정한 것 같은데 절반정도 잘 준수한 것 같다.

# 일년을 되돌아보며

# 1월~2월

친구랑 일본여행, 스키장
가족 여행

여행 위주로 보냈던 것 같다.

# 3월

어드민 기능 성능개선을 경험

https://mopil.tistory.com/entry/API-%EC%84%B1%EB%8A%A5-50%EB%B0%B0-%EA%B0%9C%EC%84%A0%EA%B8%B0

API 성능 50배 개선기

오늘은 내부 임직원이 사용하는 어드민 제품의 목록조회 기능을 평균 5~8초에서 100ms 미만 응답속도를 가지도록 성능 개선한 이야기를 공유해볼까 한다. 이야기에 앞서, 먼저 해당 제품으로 이

mopil.tistory.com

기술적으로 기억에 남는건 성능개선기 정도

# 4월~8월

갑자기 무슨 바람이 불었는지 장롱면허 탈출하고 차를사고 싶어졌다.

그래서 운전연수 시작하고 렌트하면서... 차까지 계약했다.

그리고 뭔가 운동 취미를 하나 가지고 싶어서 스쿼시 시작했다. 2개월정도 다니다가 테니스도 찍먹했는데 테니스가 더 재밌어서 테니스로 갈아탔다.

# 9월

기존 구의 자취방이 전세 2년 만료되어가서 회사와 가까운 선릉 근처로 이사했다. 구의집은 주차장이 없어서 멀리 월주차권을 사서 이용했었는데 주차가 되는 집으로 가고싶어서 이사했다.

방구하고 이사하느라 한 달 정신없었다.

# 10월

테니스 레슨 시작. 확실히 스쿼시보다 테니스가 재밌는 것 같다.

기술적으론 파편화 되어있는 계좌개설 과정에 필요한 어떤 부분을 모듈화하는 작업을 하게 되었는데, 새로운 상품이 추가될 때 마다 유연하게 대처할 수 있도록 정책+전략 기반 아키텍처를 도입했다.

처음에는 전략의 범위를 어떻게 설정할지가 막막했는데 하다보니 재밌었다. 올해들어 가장 기술적으로 깊이있게 고민했던 부분인듯.

# 11~12월

면접 참관만 들어가다가 인터뷰어 단계로 가는 프로그램을 신청해서 수련(?)을 시작했다.

일단은 서류검토 부터 의견 남기는걸 연습중인데 이게 생각보다 자극도 많이되고 공부도 많이 되는 것 같아서 좋다.

# 회고

1년이 정말 빠르게 지나가는것 같다.

목표를 좀 더 단기-구체적으로 설정하고 이 목표를 달성하기 위한 선행지표나 데일리 루틴을 만들어야겠다는 생각이 들었다.

25년도는 개발자로써 성장보다는 여가생활 위주로 조금 집중했었던 것 같다. 26년도는 다시 역량강화를 목표로 집중해볼려고 한다.

어드민 기능을 여럿 개발하다보니 성능적으로 최적화를 할 수 있는 노하우들이 조금 쌓인 것 같다. 조만간 한 번 정리하면 좋을 것 같다.

# 26년도 목표

1년이라는 시간이 너무 빨리 지나가는 것 같았다. 그래서 매월 내가 무엇을 했는지 기록하고 before, after, TIL 등을 정리해보는 노력을 시작해보려고 한다.

기술적인 의식적 수련또한 꾸준히 하면서 27년에는 새로운 회사를 도전할 수 있는 발판을 만들어보고 싶다.

JVM old gen이 우상향 하는 이슈 트러블슈팅

mopil — Thu, 25 Dec 2025 03:11:40 +0900

어느 날 어드민 서버에서 Major GC가 발생했다는 소식을 접했다.

그라파나를 확인해 보니 JVM old gen 영역이 끊임없이 우상향 하고 있었다.

서버의 max heap size는 2gb였고 rps 4~5정도 나오는 어드민 서버였는데 old gen이 이렇게 우상향 하고 있다는 것은 어딘가 메모리 누수가 있다는 것을 의미했다.

Major GC가 발생해도 힙을 많이 확보하지 못 하고 있어서 바로 힙덤프를 떠봤다.

# 힙덤프

힙덤프를 뜨면 hprof 확장자 바이너리 파일이 만들어지는데 eclipse MAT나 intelliJ로 이를 열어볼 수 있다.

인텔리제이를 사용하고 있어서 그냥 인텔리제이로 열어봤다.

중간에 배포를 해서 많이 차있는 상태에서 관찰하진 못 했지만, hibernate의 QueryPlanCache가 굉장히 많이 메모리를 잡아먹고 있음을 확인할 수 있었다.

# QueryPlanCache

쿼리플랜캐시는 하이버네이트가 한 번 생성한 SQL을 다시 생성하지 않고 재활용할 수 있도록 내부적으로 hash-map에 저장해두는데, 그게 쿼리플랜캐시다.

queryPlanCache는 내부적으로 segments라는 버킷(해시맵)을 두고 그 안에 table이라는 또 다른 해시맵을 둬서 (2중 버킷 구조) table의 key로 어떤 쿼리를 캐싱해 뒀는지 확인 가능하다.

잘려서 잘 안보일 때는 value의 바이트를 열어보면 가로줄로 쭉 나오는데 이걸 보고 대충 추론할 수 있었다.

# 원인

문제가 되는 부분은 query-dsl로 작성된 어드민 벌크 조회 쿼리였는데, where 절에 동적 쿼리로 인해 너무 많은 쿼리플랜캐시가 생성되는 것이었다.

select *
from table
where (a = ? and b = ? and c = ? and d = ?) 
 or (a = ? and b = ? and c = ? and d = ?)
 
 ...
 
 select *
from table
where (a = ? and b = ? and c = ? and d = ?) 
 or (a = ? and b = ? and c = ? and d = ?)
 or (a = ? and b = ? and c = ? and d = ?)
 
...
=> or 동적 조건에 따라서 계속 쿼리가 생성 됨

join과 추가 조건으로 실로는 더 복잡했지만 대강 이런 형식이었다.

# 접근

논리적으로 동일한 쿼리에 where 절에 따라 쿼리플랜캐시가 무분별하게 많이 생성되는 게 원인이므로

1. 플랜캐시를 생성 안 하는 방법

2. 플랜캐시를 적당히 생성하는 방법

순으로 접근해 보았다.

0. 쿼리플랜캐시 전역 off?

아무리 rps 낮은 어드민 서버라고 하지만 이건 너무 무식한 방법이라고 생각해서 기각

비슷하게 query-dsl로 이미 잘 짜인 로직을 native-query로 바꾸는 것도 고려하지 않았다.

1. 특정 쿼리만 off 할 수 있나?

쿼리플랜캐시 옵션을 특정 쿼리만 off 할 수 있는지 조사해 보았다. 하이버네이트 6.3부터 지원하는 기능을 활용하면 쿼리별로 off가 가능하다고 한다.

https://github.com/hibernate/hibernate-orm/blob/77a53bb28a4d38a72cdc96788299e4910be1425e/hibernate-core/src/main/java/org/hibernate/jpa/HibernateHints.java#L264

hibernate-orm/hibernate-core/src/main/java/org/hibernate/jpa/HibernateHints.java at 77a53bb28a4d38a72cdc96788299e4910be1425e ·

Idiomatic persistence for Java and relational databases - hibernate/hibernate-orm

github.com

hibernate.query.plan.cacheable

우리가 쓰는 하이버네이트 버전은 6.1이라서 당장 적용은 힘들어 보였다.

3. 로직 바꾸기

해당 쿼리가 복잡하게 join이 되어있고 임시테이블이나 비즈니스 로직으로 해결하는 건 제약이 커 보였다.

4. 그럼 적당히 만들자! - in_clause_parameter_padding 설정 및 in 절로 리팩토링

하이버네이트는 in_cluase_parameter_padding: true/false 옵션을 제공하는데, where in 절에 들어오는 파라미터 수를 2의 제곱수로 고정시켜 쿼리플랜캐시 히트율을 높이는 튜닝 옵션이다.

예시로 해당 옵션이 false일 경우

select *
from table
where a in (?, ?)

이것과

select *
from table
where a in (?, ?, ?)

이것은 서로 다른 쿼리로 취급함. 즉 in 절 파라미터 수에 따라서 n개 쿼리플랜 생성

이렇게 동작하게 된다.

옵션을 true로 설정하면

select *
from table
where a in (?, ?)
혹은
a in (?, ?, ?, ?)
a in (?, ?, ?, ?, ?, ?, ?, ?)

이렇게 2의 제곱수만큼 만든다. 만약 파라미터가 3개인 경우는? 마지막 파라미터를 동일하게 붙여 넣어 4개로 만들어서 교묘히 재사용할 수 있도록 한다.

select *
from table
where a in (1,2,3,3)
=> 사실은 1,2,3 조회

우리 회사는 해당 옵션이 cloud config 서버에 공통으로 true로 적용되어 있음을 확인하였고, in 절로 리팩토링을 진행하였다.

5. 기타 옵션 조정

in_clause_padding_parameter 외에도 튜닝할 수 있는 옵션이 2개 더 있다.

hibernate.query.plan_parameter_metadata_max_size (default: 128) - 해시맵에 들어갈 수 있는 사이즈 수 hibernate.query.plan_cache_max_size (default: 2048) - 해시맵에 들어갈 수 있는 사이즈 수

메타데이터 옵션은 ParameterMetadataImpl 해당 객체의 retianed size가 너무 크면 조정이 필요하고, QueryPlanCache는 hibernate.query.plan_cache_max_size 요 옵션으로 조절 가능하다.

힙덤프 분석 결과 쿼리플랜캐시가 문제였으므로 메타데이터는 조절하지 않고 플랜캐시 max size만 조절했다.

최종적으로 2048 -> 48로 조절했는데, 근거는 다음과 같다.

1. 먼저 1024 절반으로 줄여봤는데 유의미한 효과는 보지 못했다.

2. 트래픽도 적은 어드민 서버고 다른 복잡한 동적 쿼리들도 많아서 플랜 히트율이 생각보다 낮았다. 그래서 더 많이 줄여도 될 것으로 생각했다.

3. p95기준 쿼리플랜캐시 사이즈는 5mb였고 서버 힙사이즈는 2gb이므로 쿼리플랜캐시로 인한 old gen 점유율을 10% 정도 유지하려는 목표를 잡았다.

이 결과 5mb * x = 200mb = 40 (2의 배수 48)로 설정

# 해결?

Major GC도 발생하지 않게 되었고 무지막지하게 우상향 하는 건 해결했으나, 그래도 어느 정도 증가하다가 수렴하는 현상이 다시 관찰 됐다.

힙덤프를 다시 해보니 역시 지난번 쿼리와 쿼리플랜캐시가 문제였고, 상한선은 많이 내려왔지만 그래도 1.25gb 정도라서 뭔가 더 줄여야 할 것 같았다.

# 접근 2

힙덤프를 분석하다 보니 이상하게 쿼리들의 padding 옵션이 적용되지 않음을 발견했다!

로컬에서 재현해 보니 padding 옵션이 true임에도 2의 배수로 생성되고 있지 않았다.

# 또 다른 문제

in 절로 리팩토링을 진행할 때 단일 칼럼 in 절이 아닌, multi-column in 절로 변경했는데, 알고 보니 이 문법은 하이버네이트 padding 옵션이 적용이 되지 않는다고 한다..!

비슷한 in 절처럼 보이지만 내부적으로는 아예 다르게 동작하고, 하이버네이트는 이를 미지원한 다고 한다.

(ansi 정식 명칭은 row value constructor syntax라고 한다고 한다)

# 해결

그래서 기본적으로 하이버네이트가 제공하는 padding기능을 multi-column도 가능하게끔 커스텀으로 구현했다.

조금 차이점은 2의 배수가 아닌 고정된 멀티칼럼(튜플이라고 칭함)으로 반드시 패딩 되도록 로직을 구성했다.

select *
from table
where (a,b,c,d) in (?,?,?,?), (?,?,?,?)... (?,?,?,?) <- 항상 고정

고정 값은 별도 로그를 통해 평균 몇 개의 파라미터가 들어오는지 집계하여 적용했다.

고정 값 보다 적은 파라미터면 항상 고정수치로 패딩 하였고, 그 이상이면 청킹 하여 호출될 수 있도록 구성했다.

이렇게 적용하니 이제 쿼리플랜캐시가 old gen에서 많이 잡아먹는 이슈는 해결할 수 있었다!

# 후기

이후에는 재발방지를 위해 팀원들과 일단은 멀티칼럼 in 절 로직을 구성할 때 잘 리뷰하자는 컨벤션을 싱크 하였고, 나중에 버전업을 하게 되면 그냥 옵션을 끄는 방향으로 일단 정리했다.

힙덤프 떠가면서 분석해보는게 깊은 레벨까지 가본 것 같아서 즐겁고 신기했다.

[Redis] TTL 동작 원리 살펴보기

mopil — Sat, 29 Nov 2025 01:49:01 +0900

Redis에는 TTL (Time-To-Leave)을 expire 명령어를 통해 설정할 수 있다.

어떤 원리로 이를 가능케 하는지 궁금해서 좀 찾아봤다.

공식 홈페이지 (https://redis.io/docs/latest/commands/expire/#how-redis-expires-keys)에 의하면 Passive way, Active way 2가지 방식으로 동작한다고 한다.

Passive Way

키에 접근하는 순간 체크해서 만료 처리

=> 근데 이러면 접근 안 하면 계속 남아있음. 그래서 추가 보완 방법을 사용

Active Way

주기적으로 스케줄링하면서 만료된 키 제거

=> 키를 full-scan 하면 메모리 부하가 올 수 있으니 그러지 않고 샘플링해서 제거함

즉, 접근 시 체크 후 삭제 (Lazy Deletion) + GC 같은 스케줄링 클린업을 병행하는 구조였다.

샘플링해서 삭제하는 원리가 좀 더 궁금해서 깃허브를 찾아봤다.

https://github.com/redis/redis/blob/f56e0115fbce73b012fe4ccce7368a67017b911c/src/expire.c#L287

redis/src/expire.c at f56e0115fbce73b012fe4ccce7368a67017b911c · redis/redis

For developers, who are building real-time data-driven applications, Redis is the preferred, fastest, and most feature-rich cache, data structure server, and document and vector query engine. - red...

github.com

activeExpireCycle 함수가 TTL 처리를 구현하는 함수이다.

인자로 type을 받는데 이는 LAZY (passive) SLOW (active) 방식을 뜻한다.

C 코드라 읽기 어려워서 ChatGPT로 수도코드로 변경해 봤다.

for each DB in server:
  if DB.expires dict is empty: continue

  loop up to max_cycles:
    sample = randomSample(DB.expires, SAMPLE_LIMIT)
    expired_keys = []
    for key in sample:
      if currentTime > DB.expires[key]:
        expired_keys.append(key)

    for key in expired_keys:
      deleteKey(DB, key)      // internal deletion
      propagateDelete(key)    // AOF / replication

    if ( expired_keys.count / sample.count ) < REDUCTION_THRESHOLD:
      break

레디스는 싱글스레드 기반이라 중간에 active way가 실행되면 gc처럼 stop-the-world가 걸릴 거라, 랜덤 샘플링하고 삭제하는 (즉 대기시간을 최소화하려는) 설계 철학을 엿볼 수 있었다.

redis는 내부적으로 serverCron()이라는 함수를 통해서 주기적으로 수행해야 하는 작업들을 쓱 실행하는데, TTL 만료도 여기에 포함된다.

기본설정은 100ms마다 호출되는 거고 실행되는 작업(함수)마다 최대 수행시간이 정해져 있다. (이 주기는 하드코딩된 값은 아니고 변경할 수 있다고 한다.)

#define ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC 25 /* Max % of CPU to use. */

해당 코드를 보면 25로 하드코딩 되어있는데 이는 serverCron()을 실행하는 시간 동안 25%만 activeExpireCycle()을 사용할 수 있음을 의미한다. 디폴트 설정이면 100ms의 25%인 25ms동안만 최대 동작한다.

싱글스레드 기반에서 가장 최적의 메커니즘 같은데 확률적으로 샘플링해서 청소하기 때문에 정말 정확하게 TTL 만료 처리가 안 될 수도 있다.

API 성능 50배 개선기

mopil — Wed, 19 Mar 2025 23:33:38 +0900

오늘은 내부 임직원이 사용하는 어드민 제품의 목록조회 기능을 평균 5~8초에서 100ms 미만 응답속도를 가지도록 성능 개선한 이야기를 공유해볼까 한다.

이야기에 앞서, 먼저 해당 제품으로 이뤄지는 업무 절차에 대해 간략히 소개해보겠다.

계좌를 만들기 위해서 고객의 정보를 확인해야 하는 절차가 있다.

그 절차 중 일부 고객은 어드민에서 승인을 해야 계좌를 개설할 수 있는 경우가 있다.

이번 개선기는 계좌개설 과정에서 승인이 필요한 대상들을 불러오는 목록 리스트 성능 개선 이야기이다.

이 업무를 앞으로 '검토 업무'라고 부르겠다.

검토업무는 고객의 계좌개설 대기 시간을 최소화하기 위해 빠르게 검토가 이뤄져야 한다.

검토가 필요하게 되면 검토건이 생성되고, 검토건은 검토대기, 검토 중, 검토완료 3가지 상태가 존재한다.

업무의 핵심은 검토대기의 있는 건들을 빠르게 검토완료하는 것이었다.

해당 업무는 비교적 최근에 새롭게 오픈된 기능이었다.

# 문제 파악

기본적으로 1초 이상 소요되는 API들은 slow alert을 보내도록 슬랙 설정을 해둔 상태였다.

어느 날 모니터링 중, 특정 API들에서 지연이 발생하는 걸 감지했고 살펴보니 이 검토 업무 관련 API들이었다.

검토업무는 속도가 중요하기 때문에, 그냥 지나칠 수 없었다.

게다가 오픈한 지 얼마 안 되어서 데이터 수가 그렇게 많지 않았음에도 벌써부터 적신호가 온다는 것은 개선이 필요하다고 직감하였다.

보다 자세한 원인분석을 위해 메트릭을 상세히 수집하기로 결정했다. Spring actuator에서 제공하는 메트릭 어노테이션을 통해 의심 가는 API들에 쉽게 수행시간 메트릭을 심을 수 있었다.

수집한 메트릭은 프로메테우스를 통해 집계되어 그라파나를 통해 시각화하여 확인했다.

3일 정도 수집하며 확인해 본 결과, 가장 중요한 검토대기의 목록조회가 5~8초 정도 소요되고 있음을 파악할 수 있었다.

# 원인 분석

문제가 되는 API들을 찾았으니, 원인 분석에 들어갔다.

먼저 설명에 앞서 이해를 위해 검토건의 테이블 설계를 살펴보자.

고객제출정보 테이블은 모든 계좌개설을 시도하는 고객에 대하여 생성된다.

검토정보는 검토가 필요한 고객에 대해서만 생성되고 검토 중, 검토완료 상태정보를 저장하는 1:1 구조였다.

여기서 검토정보 테이블은 검토를 진행했을 때만 생성이 됐었다.

즉, 검토대기 건들을 불러오기 위해서는 고객제출정보와 검토정보를 left join 해서 불러오고 있었다.

left join을 하다 보니 인덱스를 이용하지 못하고 풀스캔을 하고 있는 걸 발견하였다.

# 1차 성능 개선 시도 - 쿼리튜닝

풀스캔 하는 부분을 CTE랑 서브쿼리로 인덱스를 잘 태우도록 바꿔봤지만... 눈에 띄는 성능 개선효과를 볼 수 없었다.

인덱스를 태워도 비용이 높은 걸 확인할 수 있었다.

설명을 위해 테이블 구조를 간략하게 소개했지만 실제로는 더 많은 테이블들을 조인하고 복잡했다.

그래서 구조적으로 서브쿼리를 사용하지 않을 순 없었다.

(가장 비용이 높은 materialize view를 만드는 부분을 쿼리로 해소하기는 한계가 있었다.)

쿼리튜닝으로는 한계가 있음을 깨닫고 다른 개선 방향을 찾아보았다.

# 2차 개선 시도 - 구조 변경

결국 left join으로 인한 view생성 부분에서 모든 검토정보를 불러오는 게 비용이 크다고 판단했다.

따라서 인덱스를 보다 효율적으로 태울 수 있도록 left join 자체를 없애는 방식으로 구조를 개선해보고자 했다.

left join을 통해 검토대기건을 불러오는 이유는, 검토대기 상태일 때는 검토정보가 존재하지 않았고, 목록을 보여주기 위해선 검토정보 테이블 칼럼 정보들이 필요한 상태였기 때문이다.

따라서 검토대기 상태에서도 검토정보가 생성되도록 구조를 변경하면 큰 개선효과를 가져올 수 있을 것 같았다.

그래서 우선 리스트 조회 쿼리를 inner join으로 바꾸고 실행계획을 확인했다.

눈에 띄게 비용이 줄어든 걸 확인할 수 있었다!

하지만 inner join으로 바꾸는 작업은 기존 설계 구조를 많이 변경해야 하기 때문에, 변경범위가 대고객 부분까지 광범위하게 수정작업이 필요했다.

적은 공수는 아니었지만 드라마틱한 성능 개선 효과가 기대되기에 강행하기로 결정했다.

# 결과

결과적으로 5~8초 걸리던 목록조회가 100ms 이내로 개선되었다!!!

제품을 사용하시는 어드민 분들에게도 좋은 피드백을 받을 수 있었다 ㅎㅎㅎ

제품을 만드는 서버 개발자로서 이상징후를 간과하지 않고 빠르게 캐치, 개선하여 사용자에게 좋은 경험을 줄 수 있었던 보람 있는 경험이었다.

2024년 회고

mopil — Tue, 31 Dec 2024 13:00:36 +0900

2023년도 회고

https://mopil.tistory.com/174

2023년 회고

# 1월 친구들과 해커톤에 참여했다. https://mopil.tistory.com/132 SPARCS 2023 StartUp Hackathon 참여 후기 https://hackathon.sparcs.org/ SPARCS 2023 StartUp Hackathon 우리의 생각이 한계까지 함께하는 곳, SPARCS 2023 StartUp Hack

mopil.tistory.com

# 2023년도 목표 달성

술술 사이드 프로젝트 출시 (3월 목표)
- 7월 출시 완료
새로운 사이드 프로젝트...?
- 청년모아 mini 사이드 프로젝트 합류
컨퍼런스, 해커톤 1회 이상 씩 참여하기
- 여럿 시도했지만 결국 둘 다 미달성
오픈소스 기여 1회 이상 해보기
- 미달성

생각했던 것 보다 시간이 빠르게 흘렀던 한 해였다.

# 기술적 성장

내가 예상했던 성장 흐름은 hope 선 처럼 선형적 성장이었는데, 실제로 돌이켜보면 로그함수처럼 성장했던 것 같다.

아무래도 23년도 처음 회사에 와서 마구마구 흡수했던 시절은 기술적으로 가장 크게 성장했다고 느껴졌고,

업무가 어느정도 익숙해진 24년도는 그 기울기가 원만해졌다고 느낀 것이다.

23년도는 내 기술적 천장을 가늠했고, 24년도는 천장을 찍기위해 살짝 놓쳤던 부분들을 채우는, 그런 과정이라고 느껴졌다.

중요한건 기울기를 유지하면서도 디테일을 챙기는 것이라고 생각한다.

그림으로 표현하자면

2023년도는 매우 빠르게 기술적 경험과 습득, 성장 천장 만들기

2024년도는 천장을 기준으로 중간중간 디테일한 부분을 채우는

약간 요런 느낌?

25년도에는 천장과 디테일을 조금씩 죽순마냥 같이 키워나가보고 싶다.

---

여담

24년도 하반기에는 라인에서 오신 새로운 서버 개발자분이 합류하셨는데, 항상 독특한 아이디어로 문제 해결 방안을 제시하시는게 인상깊다.

덕분에 우리팀 개발문화도 더 활성화 된 것 같고 기술적으로 자극을 받고 있음을 느껴서 굉장히 즐겁다!

역시 배울 사람이 곁에 있는게 성장에 참 많은 도움이 되는 것 같다.

# 기술 이야기 이모저모

## 분산 트랜잭션 관리

MSA 환경에서의 이종간 디비의 트랜잭션을 적절하게 핸들하지 못 해서 오류가나 트러블슈팅했던 경험이 있다.

기존에도 보상 트랜잭션이나 SAGA 패턴에 관심이 있어서 훑어본적이 있지만 실제로 겪어보니 더 주의있게 다뤄야할 부분이란걸 느낄 수 있었다.

## Redis로 이것저것 해보기

업무를 하면서 올해는 특히 redis를 많이 활용했던 것 같다. 캐시나 분산락으로 많이 활용했고, redis 해시 자료구조를 활용한 노션의 같이보는 기능을 만들었던게 기억에 남는다.

요런 비슷한 기능을 어드민에 만들었다

TTL을 설정할 수 있고, 다양한 자료구조를 지원한다는 점이 참 매력적인 저장소인 것 같다.

## 배포전략과 점진적 MIG

새로운 기능을 배포할 때 롤백 전략이나 실패시 대응방안을 고려하는 능력이 많이 길러진 것 같다.

(하도 장애내고 쳐맞아서 생존적으로 배운것일 수도 있다...)

어찌보면 좀 더 보수적이게 된 것일 수도 있는데 안정적인 서비스를 위해서라면 속도보다는 안정성이 더 중요하니까

## 새로운 기술들 찍먹

팀에 새로 합류하신 서버 개발자분이 기술적인 조예가 상당하셔서 많은 인사이트와 영감을 받고 있다.

Spring Cloud 계열 기술들의 분산 추적, 메트릭 컨피그등에 대한 개념을 처음 접해서 적용해보았다.

---

QueryDSL 라이브러리가 유지보수가 되지 않아서 새로운 쿼리빌더 라이브러리를 알아보던 도중 라인에서 만든 kotlin-jdsl이라는 라이브러리를 알게되었다.

https://github.com/line/kotlin-jdsl

GitHub - line/kotlin-jdsl: Kotlin library that makes it easy to build and execute queries without generated metamodel

Kotlin library that makes it easy to build and execute queries without generated metamodel - line/kotlin-jdsl

github.com

QClass를 미리 빌드시점에 만들지 않아서 좋은 점 빼고는 아직 잘 모르겠다. 회사에서도 도입해서 쓰는 팀이 있던데 아직까지 QueryDSL과 차이점을 잘 모르겠다.

3.0버전도 새로나오고 업데이트도 꾸준히 하고 있는 점이 장점아닐까

(QueryDSL은 페이징에 group by을 같이 못 쓰는 버그를 아직도 안 고치는 건지.. 못 고치는건지 방치하고 있다)

여담으로 CTE를 자주 쓸 때가 있는데 이를 JPA나 dsl 라이브러리에서 지원을 안 해줘서 언넝 해줬으면 하는 바람이 있다

보니까 하이버네이트 최신 버전에서는 지원을 시작했다고 하는 것 같더라

---

서버 말고도 프론트도 좀 공부를 해봐야겠다는 생각을 예전부터 갖고있었는데 행동으로 옮기진 못 했다.

올해는 그래도 next로 간단한 퀴즈 앱이랑 어드민 페이지등을 만들어보면서 찍먹해봤다.

역시 css는 어렵다.

# 소프트 스킬과 마인드 셋

회사생활을 하면서 기술적 역량만큼 커뮤니케이션 능력(소프트스킬)이 매우 중요하다고 다시금 느끼고 있다.

1. 요구사항 분석은 매우 꼼꼼하자

알더라도 더블체크 하고, 세부사항을 면밀히 파악해서 일을 2번 안 하기

2. 요구사항이 불명확 할 땐 잠시 기다리기 or 제안하기

개발먼저 와다다 시작하지 말고 잠시 flow 정리나 요건 정리를 먼저하고 하는게 능률이 훨씬 좋았다.

3. 꼭 필요한 일 인지 체크하기

개발자 입장에서의 관점을 제시하거나 커뮤니케이션으로 풀어서 안 해도 될 일이 됐던 적이 꽤 있었다. 먼저 소통해보기

4. 부드럽게 피드백 하기

상대방 기분은 안 나쁘게 하면서, 빙빙돌리지 말고 직설적이게 피드백을 해야하는데 역시 어렵다.

라포를 더 형성하고 사소한 것 부터 상냥하게 피드백을 자주 해보자

5. 항상 겸손하기

업무와 기술에 익숙해지다보면 내가 제일 잘 아는 것 처럼 느껴질 때가 있다. 동료가 어떤 제안을 하더라도 열린 관점에서 경청하고 수용할 수 있는 자세를 잃지 말아야겠다고 생각했다.

아는 것 보다 모르는 것에 더 적극적으로 임하고 "가르치기"보단 "제안하기" 화법으로 대화를 하도록 노력하자고 마음먹었다

6. 조급해하지 않기

cs가 몰려오고 요청도 몰려오고 기한도 촉박할 때 항상 조급함때문에 스트레스를 많이 받았던 것 같다.

사실 한 템포 쉬고 들여다보면 별거 아니였던 것들인데 왜 그렇게 스트레스를 받았는지 모르겠다.

# 사이드 프로젝트에 관하여

나는 꼭 회사일이 여유가 생기면 여가시간에 개발을 하는 이상한 병이 있다(...)

그래서 너무 가볍게 사이드 프로젝트를 시작 했던게 아닐까 싶다.

2023년도에 시작했던 사이드 프로젝트인 '술술'은 결과적으로 실패한 사이드 프로젝트라고 생각한다.

실패라고 생각하는 이유

1. mvp가 너무 컸고, 인원수도 너무 많았다.

직장인들로 구성되다보니 시간투자가 절대적으로 많을 수가 없었고, 여가시간에 하는 '사이드'라는 생각에 취준생 때 하는 그 '사이드'와 절박함(?) 정도도 다들 달랐다.

2. 각 팀원들의 목적이 sync되지 않았다.

어떤 팀원은 출시부터 운영까지, 어떤 팀원은 단순 새로운 기술 경험을, 어떤 팀원은 그냥 협업 경험을... 등등 각각 팀원들이 이 프로젝트로 얻고자하는게 달랐다.

3. 기획과 디자인이 완성되지 않은 상태에서 팀원을 모집했다.

가장 큰 패착사유라고 생각한다. 이것은 100% 나의 실수이다.

너무 들뜬나머지(?) 각 분야 팀원들을 모아놓고 기획을 시작했다.

당연히 기획~디자인까지 시간이 엄청 오래걸렸고, 그 과정에서 지친 팀원들도 많았을 것이다.

결국 일정을 계속 못 지키게 되고 팀원들의 열정도 점점 식어져가면서 서비스의 완성도는 처참했다.

이번 사이드 프로젝트로 깨닫게 된 것들은

1. 기획과 디자인이 명확해지면 개발자를 모으자

2. 순수 개발기간은 맥시멈 1달. (mvp는 진짜 제발 작고작고 제발 작게)

3. 정말 최소 인원으로

정도 이다.

술술 프로젝트를 통해서 단기간에 스프린트 형식으로 맺고끝냄이 명확한 해커톤에 더 관심이 생겼다.

(여담이지만, 한 2~3번정도 해커톤 신청을 하고 팀도 꾸렸었는데 모두 잘 되지 못 했다...)

# 나의 장점과 단점

2년정도 실무 개발을 하면서 나의 개발적 장점과 단점을 어느정도 파악하였는데,

장점

- 개발을 매우 스피디하게 한다.

단점

- 꼼꼼함이 부족하다. (특히 테스트)

이러한 특성 때문에 일을 비효율적으로 했던 적이 종종 있다.

업무 요건을 명확하게 파악하지 않고 빠르게만 개발하여 결국 개발을 다시하게 됨
엣지케이스를 충분히 고려하지 못 해서 장애 발생

생각해보면 마냥 '빠르게 개발하기'가 장점인지도 모르겠다.

충분한 시간과 여유를 가지고 좀 더 꼼꼼하게 개발을 하기 위해 노력하고 있다.

1. cs 인입, 외부 변수를 충분히 고려하여 내가 가능한 일정 * 1.3정도로 개발일정 산정하기

2. 요건확립을 최우선 적으로. 요건이 확립되더라도 2~3일정도 상호피드백을 거치면서 엣지케이스 체크하기. 개발은 천천히 꼼꼼하게

3. 꼭 실제 호출(실행)테스트 해보고 데이터 확인하기!!!

# 금융감독원 종합검사

토스뱅크가 첫 금융감독원 정기 검사를 받았다.

https://it.chosun.com/news/articleView.html?idxno=2023092126302

금감원·한은, 토스뱅크 첫 정기 검사… 4주간 진행

금융감독원과 한국은행이 인터넷전문은행 토스뱅크에 대한 공동검사에 착수한다.4일 금융업계에 따르면 금감원과 한은은 이날부터 4주간 토스뱅크를 대상으로 정기검사를 진행한다. 지난 2021

it.chosun.com

난 AML 파트 개발자로써, 검사역과 인터뷰까지 해보는 경험을 해봤다.

자료추출하느라 하루 15시간씩 근무한 적이 많았다.

정말 힘들었지만 또 언제 이런 경험 해보겠나.. 했다.

이번 검사를 통해 엔지니어링 적 리스크 보다 비즈니스 적 리스크를 더 크게 고려해야하는 경우도 있음을 깨달았고,

사소할 것 같았던 이슈가 큰 비즈니스적 임팩트를 불러올 수 있음도 느꼈다.

그간 너무 겁없이(?) 내재화를 속도감 있게 했던 것은 아닐까 하며 되돌아볼 수 있는 시간이었다.

결론적으로 별탈 없이 잘 마무리 되었다! ~~(다행히 짤리지 않았습니다..)~~

# 독서

도메인 주도 개발 시작하기

https://product.kyobobook.co.kr/detail/S000001810495

도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지 | 최범균 - 교보문고

도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지 | 가장 쉽게 배우는 도메인 주도 설계 입문서!이 책은 도메인 주도 설계(DDD)를 처음 배우는 개발자를 위한 책이다. 실제 업무에 DDD를

product.kyobobook.co.kr

회사 동료 추천으로 읽게된 책인데 DDD에 대한 전반적인 개념을 잡을 수 있어서 좋았다.

재밌어서 되게 금방 읽어버렸는데, 나중에 복습할 때 또 읽어도 좋을 것 같다. 추천

좋은 코드, 나쁜 코드

https://www.yes24.com/Product/Goods/109366833

좋은 코드, 나쁜 코드 - 예스24

구글 엔지니어가 말하는 좋은 코드 작성법 좋은 코드를 작성하기 위한 이론과 실전을 소개한다. 단순히 해야 할 일과 하지 말아야 할 일을 나열하기보다, 여섯 가지 원칙을 바탕으로 각 개념과

www.yes24.com

사내 스터디 1번째로 했던 책이다.

생각보다 당연한 이야기를 조금 장황하게 하고 있는 것 같은 느낌이 들어서 별로였다. 비추천

만들면서 배우는 클린 아키텍처

https://www.yes24.com/Product/Goods/105138479

만들면서 배우는 클린 아키텍처 - 예스24

우리 모두는 낮은 개발 비용으로 유연하고 적응이 쉬운 소프트웨어 아키텍처를 구축하고자 한다. 그러나 불합리한 기한과 쉬워보이는 지름길은 이러한 아키텍처를 구축하는 것을 매우 어렵게

www.yes24.com

사내 스터디로 2번째로 했던 책이다.

책 내용은 헥사고날 아키텍처에 관한 이야기인데 평소 고민하던 것들을 책에서 명시적으로 정리해주는 것들이 종종 있어서 좋았다.

책도 책인데 읽고 토론했던 스터디 방식이 인상깊었어서 더 기억에 남는다.

파이토치 딥 러닝 프로그래밍

https://www.yes24.com/Product/Goods/111704966

차근차근 실습하며 배우는 파이토치 딥러닝 프로그래밍 - 예스24

딥러닝 원리와 파이토치의 구현을 빠르게 이해하자!이 책은 최근에 특히 주목받는 딥러닝 프레임워크인 ‘파이토치(PyTorch)’에 관한 입문 서적이다. 이미지 인식을 주 소재로 삼아 파이토치의

www.yes24.com

술술 프로젝트를 하면서 딥러닝이 궁금해져서 무작정 구매해서 읽어봤다.

수학과 시절에 배웠던 것들이 코드로 구현되어 모델이 어떻게 학습이 되는지 원리를 코드로 알 수 있어서 너무 재밌게 읽었었다.

딥러닝 실습을 찍먹해보고 싶다면 추천

# 2025년에는?

어느덧 토스뱅크에 입사한지 2년이 지났고 곧 3년차 개발자가 되어간다 (시간이 참 빠르다)

새로운 기술을 접목시켜보고 학습하는것도 즐겁지만, '더 프로다운' 모습은 저거에 더불어

- 어떻게 안정성있는 운영을 할 것인지

- 영향도 파악과 위험요소 식별을 어떻게 더 잘할 것인지

- 어떻게 장애를 안 낼 것인지 (사실 장애를 안 내는건 서비스가 살아있으면 불가능하다고 생각한다.. 그치만 은행으로써 갖춰야할 보장된 안정성과 개발자로써 추구해야할 혁신의 중간에서 잘 조율을 하는게 내년 과제로 삼고싶다)

를 고민해보면서 성장해가고 싶다.

1. 책을 더 많이 읽자 (목표 7권)

2. 해외여행 다녀오기

3. 더 프로답게 일하기

리눅스 80 -> 8080 포트포워딩

mopil — Thu, 28 Nov 2024 22:59:27 +0900

80포트로 들어오는 요청을 8080포트로 포워딩 시키는 방법

sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

[Spring Boot] Caffeine 로컬 캐시로 Rate Limiter를 구현해보자

mopil — Sun, 20 Oct 2024 02:03:01 +0900

# Rate Limit이란?

일정 시간 동안 호출될 수 있는 API 횟수를 제한하는 걸 말한다.

예를 들어 파일 업로드는 10분에 최대 3번만 가능 이런 걸 구현할 때 사용하는 개념이다.

자세한 건 아래글 참조

https://gngsn.tistory.com/224

Rate Limiter, 제대로 이해하기

Rate limiter의 역할과 강단점을 살펴보고, 구현 알고리즘 5가지를 이해하는 것이 해당 포스팅의 목표입니다. 본 포스팅의 모든 그림은 필자가 직접 그린 것으로 무단 사용을 금하며, 사용 시 출처

gngsn.tistory.com

이번 글에서는 로컬 캐시 라이브러리로 유명한 Caffeine으로 Rate Limiter 기능을 구현해 볼 것이다.

# 왜 Caffeine인가?

Spring Cloud Gateway나 Bucket4j를 활용해서 손쉽게 구현할 수도 있다.

다만, 이번에는 외부 저장소 (ex. Redis) 없이 로컬 캐시로 라이트하게 구현하기 위해서 Caffeine을 선택했다.

단순 InMemory 저장을 위함이면 Collections를 써도되지 않나 싶었지만, TTL을 설정할 수 없다.

여담으로 당연하겠지만 Caffeine은 thread-safe 하다고 한다.

https://github.com/ben-manes/caffeine/issues/392

Question: Thread safety? · Issue #392 · ben-manes/caffeine

Is caffeine thread safe? Can I use the same instance of the cache from multiple threads/coroutines/futures?

github.com

# 가상 요구 사항

파일 업로드 API에 Rate Limit을 구현해볼 예정이다.

인증된 사용자마다 10초동안 최대 5번만 업로드가 가능하다.

# 구현

build.gradle.kts

    implementation("com.github.ben-manes.caffeine:caffeine:3.1.8")

Rate Limiter

interface RateLimiter {
    fun checkLimit(userId: Long)

    fun increaseCount(userId: Long)

    class CaffeineLocalCacheImpl(
        val limit: Int,
        val duration: Long,
        val timeUnit: TimeUnit,
        val maxSize: Long = 100,
    ) : RateLimiter {
        private val cache =
            Caffeine
                .newBuilder()
                .maximumSize(maxSize)
                .expireAfterWrite(duration, timeUnit)
                .build<String, Any>()

        override fun checkLimit(userId: Long) {
            val uploadCount = cache.getIfPresent(userId.toString()) as Int?
            if (uploadCount != null && uploadCount >= limit) {
                throw RateLimitExceededException()
            }
        }

        override fun increaseCount(userId: Long) {
            val uploadCount = cache.getIfPresent(userId.toString()) as Int?
            if (uploadCount == null) {
                cache.put(userId.toString(), 1)
            } else {
                cache.put(userId.toString(), uploadCount + 1)
            }
        }
    }
}

Rate Limiter 인터페이스를 만들고 각 구현체는 Bean으로 등록하여 필요한 곳에서 Qualifier로 주입받아 사용할 수 있게끔 할 것이다.

Caffeine의 key는 userId: Long이고 value는 현재까지의 카운트이다.

class RateLimitExceededException(
    message: String = ErrorType.TOO_MANY_REQUEST.defaultMessage,
) : RuntimeException(message)

커스텀 예외를 하나 만들어준다. 그리고 이를 핸들 할 ControllerAdvice도 추가한다.

    @ExceptionHandler(RateLimitExceededException::class)
    fun handleRateLimitException(e: RateLimitExceededException): ResponseEntity<ErrorResponse> {
        return ResponseEntity
            .status(HttpStatus.TOO_MANY_REQUESTS)
            .body(
                ErrorResponse.from(ErrorType.TOO_MANY_REQUEST),
            )
    }

ErrorResponse과 ErrorType은 커스텀 객체로 적당히 구현해 준다.

RateLimiterConfig

@Configuration
class RateLimiterConfig() {
    @Bean
    fun fileUploadRateLimiter(): RateLimiter {
        return RateLimiter.CaffeineLocalCacheImpl(
            limit = 5,
            duration = 10,
            timeUnit = TimeUnit.SECONDS,
            maxSize = 100,
        )
    }

	// 추후 다른 기능에 필요하다면 추가할 수 있도록 만들었다
    @Bean
    fun programApplicationRateLimiter(): RateLimiter {
        return RateLimiter.CaffeineLocalCacheImpl(
            limit = 5,
            duration = 24,
            timeUnit = TimeUnit.HOURS,
            maxSize = 100,
        )
    }
}

별도 Config 파일을 만들어서 필요한 리미터를 빈으로 등록한다.

fun <T> rateLimit(rateLimiter: RateLimiter, userId: Long, block: () -> T): T {
    rateLimiter.checkLimit(userId)
    val result = block()
    rateLimiter.increaseCount(userId)
    return result
}

코드를 간결하게 하기 위해서 리미터 호출 부분은 별도의 최상위 함수로, 람다를 통해 수행 블록을 받도록 만들었다.

FileController

@Tag(name = "파일")
@RestController
@RequestMapping("/common/files")
class FileController(
    private val fileManager: FileManager,
    @Qualifier("fileUploadRateLimiter") private val rateLimiter: RateLimiter
) : FileApiSpec {
    @AuthenticationRequired
    @PostMapping(
        "/upload",
        consumes = [MediaType.MULTIPART_FORM_DATA_VALUE],
        produces = [MediaType.APPLICATION_JSON_VALUE],
    )
    override fun uploadFile(
        @RequestPart file: MultipartFile,
    ): FileMetaResponse {
        val loginUser = AuthenticationUtils.getCurrentLoginUser()
        return rateLimit(rateLimiter, loginUser.id) {
            fileManager.uploadFile(loginUser.id, file)
        }
    }
}

컨트롤러에서 앞서 정의한 fileUploadRateLimiter를 주입받는다.

rate limit 체크는 비즈니스 로직과는 거리가 멀다고 생각해서 컨트롤러단 로직으로 분리했다.

앞서 정의한 rateLimit 최상위 함수를 통해 리미터와 userId를 넘겨서 체크한다.

이제 호출해 보면

정상적으로 동작하는 걸 확인할 수 있다.

전체 코드는 해당 커밋을 보면 확인 할 수 있다.

https://github.com/mopil/youth-moa-server/commit/ea49f8edf67cf7401d569ff050768af8fbffd2db

feat: file upload rate limit 추가 · mopil/youth-moa-server@ea49f8e

mopil committed Oct 19, 2024

github.com

# 한계 & 후기

복수 인스턴스의 서버 환경에서는 userId별 5회 제한을 할 수 없는 구조여서 그런 경우는 외부 중앙 저장소 (ex. Redis)가 필요하다.

당연히 로컬 캐시로 관리하기 때문에 트래픽을 많이 받는 환경이면 캐시로 인한 OOM에 신경 써야 한다.

서버를 재기동하면 카운트가 초기화된다.

토큰 버킷처럼 특정 시간이 지날 때마다 초기화가 아닌 토큰을 1개 추가하는 기능 구현이 제약된다.

(사실 스케줄링 같은 거 쓰면 할 순 있을 것 같은데 그냥 라이브러리 쓰는 게 편할 것 같다)

사이드 프로젝트 할 때 혹시 모를 AWS 과금을 방지용으로, 혹은 단순 rate limit 기능을 빠르게 구현하기 위해서라면 해당 방법도 나쁘지 않은 것 같다.

다음에는 더 많은 기능이 있는 Bucket4j로 한 번 만들어봐야겠다.

[JPA] 1차 캐싱을 직접 확인해보자

mopil — Sat, 12 Oct 2024 17:08:13 +0900

JPA 영속성 컨텍스트가 제공하는 기능 중 하나인 '1차 캐싱' 기능을 눈으로 직접 확인해 보자

@Service
class FirstService(
    private val userRepository: UserRepository,
) {

    @Transactional
    fun callFirst() {
        var user = userRepository.findById(1).get()
        println("first call user = $user")
        user = userRepository.findById(1).get()
        println("second call user = $user")
        user = userRepository.findById(1).get()
        println("third call user = $user")
    }
}

리포지토리에서 동일한 User를 총 3번 호출했다.

1차 캐싱 덕에 쿼리는 1번만 나가고 2,3번째 조회는 쿼리를 안 보내고 영속성 컨텍스트에서 바로 가져오는 것을 확인할 수 있다.

이는 다른 트랜잭셔널로 묶인 서비스를 주입받아 호출하는 경우도 적용된다.

즉, 최상위 트랜잭션이 종료될 때까지 유지된다.

@Service
class FirstService(
    private val userRepository: UserRepository,
    private val secondService: SecondService
) {

    @Transactional
    fun callFirst() {
        val user = userRepository.findById(1).get()
        println("first call user = $user")
        secondService.callSecond()
    }
}

@Service
class SecondService(
    private val userRepository: UserRepository
) {

    @Transactional
    fun callSecond() {
        val user = userRepository.findById(1).get()
        println("second call user = $user")
    }
}

FisrtService에서 SecondService를 주입받아 동일한 유저를 2번 리포지토리에서 가져오는 간단한 로직이다.

호출해보면 second call user 이전에는 select 쿼리가 나가지 않는 것을 확인할 수 있다.

유저에게 보이는 에러메시지 워싱은 어디서 하는게 좋을까? 서버 vs 프론트

mopil — Sat, 5 Oct 2024 15:19:35 +0900

서버에서 예외(에러)가 나면 보통 이런 응답이 내려간다.

이 에러메시지 그대로 유저에게 보여주는 건 바람직하지 못하다.

그래서 보통 에러메시지를 유저편의적으로 가공하는데, 이를 '에러메시지 워싱'이라고 표현한다.

# 얼마나 구체적인 에러 메시지를 보여줄까?

워싱 주체에 대해 논하기 전, 먼저 유저에게 어떤 에러메시지를 보여주는 게 적합할지 생각을 해보자.

정답은 아닐 수도 있지만, 필자는 이렇게 생각한다.

1. 유저 스스로가 다른 액션을 통해 해당 에러를 해소할 수 있는 경우는 최대한 구체적으로 알려준다.

ex) 회원가입 시 비밀번호 규칙 중, 특수기호가 포함되어야 하는데 빠진 경우

추상적인 경우: 비밀번호 규칙에 올바르지 않습니다.

구체적인 경우: 특수기호가 빠졌어요. 비밀번호에는 적어도 1개 이상의 특수문자가 필요해요.

유저는 에러메시지를 확인하고 해당 에러를 스스로 해소할 수 있어진다.

2. 반대로, 유저가 어떤 액션을 해도 해당 에러를 해소할 수 없는 경우는 최대한 추상적으로 알려준다.

ex) 회원가입 시 다른 서버 호출을 하는데 해당 서버가 죽은 경우

추상적인 경우: 요청을 처리하지 못하였어요. 잠시 후 다시 시도하거나 고객센터에 문의하세요.

구체적인 경우: XX 서버 호출이 실패하였습니다. 사유: xxxx 에러

이런 경우는 아무리 유저에게 구체적인 정보를 알려줘도 해소할 수 없다. 따라서 최대한 추상적으로 알려준다.

이는 좀 더 포괄적으로 개발자가 비즈니스 로직상으로 의도한 flow가 아닌 경우 발생한 예외의 경우 최대한 자세히 알려주고, 그 외 예상치 못한 에러나 테크니컬 적인 에러는 추상적으로 포장하는 것이 좋다고 생각해도 무방할 것이다.

이제 이 워싱은 프론트에서 하는 게 적합할까? 서버에서 하는게 적합할까? 에 대해서 고민해 보자

# 다른 개발자들 의견

필자 회사는 보통 서버에서 다 워싱해서 내려주는데, 다른 사람들은(조직) 어떻게 하는지, 생각하는지 궁금했다.

프론트 개발자

서버 개발자1

서버 개발자2

서버다, 프론트다 좁혀지지 않고 다양한 의견이 나왔다. 정리하자면,

서버에서 하는 게 맞다

- 프론트에서까지 해버리면 관리포인트가 늘어난다

프론트에서 하는게 맞다

- 여럿 플랫폼 지원을 (확장성) 고려했을 때 더 유연하다

- 정의된 에러에 대한 더 유저친화적인 에러 메시지

# 필자의 결론

여러 개발자들의 의견을 들어보면서 내린 결론은 다음과 같다.

1. API가 UI에서만 사용되는 경우(다른 플랫폼 지원 가능성이 없는 경우)는 서버에서 에러메시지를 워싱해서 내려준다.

이는 서버, 프론트 둘 다 메시지를 워싱하면 관리포인트가 2개가 생기기 때문에 비효율적이라고 판단했다.

2. 여럿 플랫폼을 지원하는 경우 프론트에서 워싱한다.

이 경우 서버-프론트간 에러 케이스와 규칙을 명확하게 확립해야 할 필요가 있다.

# 좀 더 고민해 보기

- 역할과 관심사의 분리의 관점에서 보면 프론트에서 워싱하는 게 더 맞지 않을까?

다른 분들의 의견은 어떠신가요?

인덱스 꼼수 부리기

mopil — Wed, 4 Sep 2024 01:00:40 +0900

# != 연산에 인덱스 태우기

where 절의 not equal(!=) 연산은 인덱스를 걸어놔도 효과를 볼 수 없다.

이런 경우 해당 칼럼이 순차적인 코드값으로 되어있는 경우는 인덱스를 태우도록 꼼수(?)를 부릴 수 있다.

* 디비는 오라클 기준

예를 들어, my_table이 존재하고 my_column이 이런 분포를 가진다고 해보자.

1000 : 32만 rows

2000 : 10만 rows

3000 : 5만 rows

4000 : 22만 rows

5000 : 1만 rows

6000 : 43만 rows

그리고 my_column이 1000이 아닌 rows를 select 한다고 가정해보자. 인덱스를 걸어놔도,

select * from my_table where my_column != '1000' 으로 하면 full scan을 한다.

이 때

select * from my_table where my_column > '1000' 이렇게 쿼리를 짜면 index scan을 하도록 할 수 있다.

물론 이 경우 유니크한 값들이 아니고 카디널리티가 그리 높지 않기 때문에 인덱스 효용성이 그렇게 높지는 않은 상황이긴 하다.

# 카디널리티가 높지 않은 칼럼에 인덱스 효과 누리기

예를 들어, my_table이 존재하고 nationality이 이런 분포를 가진다고 해보자.

대한민국 : 950만 rows

일본 : 3만 rows

가나 : 323 rows

태국 : 3 rows

...

이 테이블에서 국적이 대한민국인 row를 쿼링하는건 당연히 인덱스 효과를 볼 수 없다. (풀스캔과 동일)

단, 다른 국가들인 경우 인덱스 효과를 볼 수 있어 대한민국이 아닌 다른 국가들을 조회하는 쿼리가 많을 경우 인덱스를 적용해주는 것이 좋다.