꾸준하게

인턴 생활 한 달 후기

changha. — Sun, 12 Jul 2026 14:15:28 +0900

6월 초에 입사했으니 이제 한 달 하고 일주일 정도 지났다.

초반 1~2주는 도메인 익히는데 문서 읽는 것에 대부분 보냈다.

DB 조회해보고, 백오피스 기능들 보고, 직접 사용자 입장에서 작동시켜보고.

2주정도 됐을 때 백오피스 추가 기능들을 만들기 시작했다.

지라에서 티켓을 발급해서 FE/BE 나누어서 만들었다.

사실 개발 자체는 클로드가 만드니 어려울게 없다.

그래서 어떻게 하면 효율적으로 빠르고, 정확하게 만들 수 있을지를 고민을 많이 했다.

특히 좋았던점이 팀원들이 리뷰를 해주는 것이었는데 클로드의 코드가 난무하는 상황에서 직접 내 코드를 확인하고 코멘트를 달아주니까 더 신경을 쓰게 되었다.

ide에도 관심이 많았는데 팀원들은 대부분 cmux를 사용하시는 것 같다.

병렬 세션으로 통신이 가능하다는 이점이 있기에 여기로 넘어오신분이 많다고 들었다. (이번 주말에 Orca를 써보고 있는데 cmux의 상위버전이라는 느낌이 들었다. 특히 git 결합과 수정 파일을 클로드 앱처럼 보면서 코멘트로 달 수 있다는 것이 유용하다.)

입사하면서 한 달 동안 성장한 부분이 협업 플로우인 것 같다.

워크 트리, 태그 개념, 브랜치 전략.. 등등

사이드 플젝 할 때는 나 혼자서 거의 해서 신경 쓸 것이 없었고 예전에 팀프로젝트해도
큰 어려움이 없었던 것 같다. 왜냐면 hotfix, rebase, sqaush and merge, cherry pick 이런 개념을 내가 잘 모른채로 했기 때문에..ㅋㅋ

이런 상황이 잘 일어나지도 않았고..

그래서 깃 협업 관련해서 많이 알게되었다.

그리고 문서화 또한 중요하다고 생각이 들었다.

내가 추출한 결과물을 어떻게 사람들에게 잘 전달할 건지가 중요했다.

노션을 회사에서 사용하는데 그냥 mcp연결해서 보고서 만들라고 너무 장황하고

간결하게 할 수 있는데도 너무 풀어서 설명하니까 글자의 파도에 먹혀 피로감이 누적되었다.

그래서 이거를 개선하고자 토스의 테크니컬라이팅을 참고하여 skill 을 만들어놓으니 훨씬 깔끔했다. (같은 인턴도 써보고 괜찮다고 해서 뿌듯..)

또 백오피스 새로운 기능이 추가되었을 때 제품팀에서 이해하기 어려운 부분이 있었다.

이거를 스크린샷 포함해서 문서화하고 싶었는데 Playwright를 사용하면 가능할 것 같아 적용하니 알잘딱깔센으로 위의 스킬과 결합하여 잘 만들어 주었다. 필요할 때 유용히 쓸 것 같다.

정리하면 이번 한 달은 단순히 개발을 하는 것이 중요한게 아니라 팀원들에게 어떻게 전달할지, 업무능력을 키울 수 있을지 고민하는 시간이 되었던 것 같다.

내 자리

7월 말에 봉천역 근처로 이사도 하게 됐다.

공릉을 이제 벗어나게 되는데, 오래 살기도 했다.

거의 안가본 카페가 없고, 근처 맛집도 많이 갔으니...

이제 직장 다니니 새로운 곳으로 떠나고 싶다.

이번 한 달은 와딩 프로젝트 앱스토어에 배포되면 유저들 모으고 피드백 받으면서 더 발전시키려고 한다.

그리고 k8s 공부도 회사 다니다보니 이해가 필요하다고 느껴서 틈틈이 하려고 한다.

무더운 7월도 화이팅!!

DDIA 5주차

changha. — Fri, 3 Jul 2026 23:47:12 +0900

이번주차는 7장이다.

트랜잭션 부분.. 정합성 측면에서 정말 중요하다고 느낀다.

최근 회사에서도 트랜잭션 관련하여 오류 하나가 있었는데 더욱 중요하다고 느껴졌다.

이 장을 통해 다양한 트랜잭션이 막을 수 있는 문제들이 무엇이 있고 어떻게 해결하는지 알게되었다.

완화된 격리 수준

1. Read Committed

가장 기본적인 트랜잭션 격리 수준. 두 가지를 보장한다.

커밋된 데이터만 읽을 수 있다 (더티 읽기 방지)
- 커밋 전 값과 커밋 안 된 값 둘 다 유지한다. 읽기 요청 오면 old 값 반환. 커밋 후에야 새로운 값이 보인다. -> 이게 undo log 버전 체인의 목적이다.
커밋된 데이터만 덮어쓸 수 있다 (더티 쓰기 방지)
- Update 시 해당 행에 X Lock 잡고 커밋/롤백까지 유지한다.
- 뒤에 온 쓰기는 락 해제까지 대기 -> 커밋된 값 위에만 쓰게 된다.

더티쓰기 예제

언두로그 조심해야 할 점

트랜잭션이 오랜 시간 실행될 수록 언두 로그의 양은 급격히 증가할 수 있음

- 공간적인 측면 안좋음

- 스캔하는 시간 측면 안좋음

INSERST / UPDATE(DELETE 포함) 문장 언두 로그 각각 분리

- 전자 : MVCC에 사용 안되므로 (이전 버전에는 존재하지 않으니)

- 후자 : MVCC에 사용됨

언두 로그가 저장되는 공간 : 언두 테이블스페이스

하나의 언두 테이블 스페이스 : 1개 이상 128개 이하의 롤백 세그먼트

롤백 세그먼트 : 1개 이상의 언두 슬롯을 가짐

- InnoDB 페이지 크기를 16바이트로 나눈 값의 개수만큼의 언두 슬롯을 가짐

- 트랜잭션당 언두 슬롯 최대 4개

언두 로그 슬롯이 꽉

차면?

-> 트랜잭션을 시작할 수 없음.

2. Snapshot Isolation(MVCC)

MySQL 은 MVCC를 격리 수준마다 어떻게 사용하는지

- 각 행에 숨은 컬럼: DB_TRX_ID(이 행 마지막 수정한 txid), DB_ROLL_PTR(undo log 포인터 = 옛 버전 체인).

- 수정 시 옛 버전을 undo log에 쌓음 → 버전 체인.
- Read View(스냅샷): "지금 어떤 txid까지 커밋된 걸로 볼지" 스냅샷. 이게 가시성 판단 기준.
- 규칙: Read View보다 나중 txid가 만든 버전은 안 보이고, undo 체인 따라 보이는 옛 버전으로 내려감.

- RC: 문장 하나 끝나고 다른 트랜잭션이 커밋하면, 다음 SELECT는 그 값 봄 → 같은 걸 두 번 읽어도 값 바뀔 수 있음.
- RR: 첫 SELECT 순간 스냅샷 박제 → 트랜잭션 동안 남이 뭘 커밋하든 안 흔들림.

SI로도 못막는 것

1. Lost Update

Lost Update는 무엇인가?

- 두 트랜잭션이 같은 행을 읽고 -> 계산 -> 쓰기 하는데, 한 쪽 수정이 덮여 사라지는 것. 스냅샷 격리로도 안 먹힌다.

Lost Update는 어떻게 막을까?

2. 쓰기 스큐 & 팬텀

쓰기 스큐란

- 읽어서 조건 검사 -> 그 결과 믿고 씀. 근데 검사~쓰기 사이 다른 트랜잭션이 전제를 깸.

- 스냅샷 격리로도 못 막음.

스냅샷 격리로도 막지 못하는 이유

스냅샷 격리로는 서로 다른 행에 대한 동시 쓰기는 막지 못함.

- 쓰기 스큐는 Alice→Alice행, Bob→Bob행. 쓰는 행이 겹치지 않음 → SI 입장에선 "충돌 없음" → 둘 다 정상 커밋.

갱신 손실 vs 쓰기 스큐

- 갱신 손실: 두 트랜잭션이 같은 행 수정 -> DB가 충돌 감지 기능.

- 쓰기 스큐: 같은 조건 읽고 다른 행에 씀 -> 충돌 없음.

의사 당직 vs 회의실 예약 - 같은 쓰기 스큐지만 차이가 있음

둘 다 쓰기 스큐지만 막는 방법이 다르다.

팬텀개념이 들어감.

- 팬텀: 한 트랜잭션 쓰기가 다른 트랜잭션 WHERE 결과를 바꿈

1. 의사 당직 — (잠글 행이 있다)
- 검사하는 대상: on_call = true인 행들 = Alice, Bob. 이미 테이블에 존재함.
- 그래서 잠글 게 있다.

SELECT * FROM doctors WHERE on_call = true FOR UPDATE;

- Alice가 먼저 이 락을 잡으면, Bob은 같은 행을 잠그려다 대기한다.
- Alice 커밋 후 Bob이 다시 조회 → 이제 당직 1명 → "빠지면 안 되겠다" 판단.
- 즉, 읽는 순간 존재하는 행을 잠가버리니 다른 트랜잭션이 끼어들 틈이 없다. FOR UPDATE 한 줄로 해결.

2. 회의실 예약 — (잠글 행이 없다)
- 검사하는 대상: "그 시간대에 예약이 없는지". 즉 행의 부재를 확인한다.

SELECT count(*) FROM bookings
WHERE room_id = 5 AND time_range OVERLAPS ('12:00','13:00');  -- 0
-- "비었네" → INSERT

- 검사 결과가 0개. 없는 행은 잠글 수 없다. FOR UPDATE를 걸어도 잠글 대상 자체가 없음.
- 두 트랜잭션이 동시에 "비었네"를 확인 → 각자 INSERT → 이중 예약.
- 여기가 락으로 못 막는 순수 팬텀 지점이다.

해결책

- 충돌 구체화

- 잠글 행이 없기에 미리 만들어둔다.

- 방x시간 슬롯 조합을 time_slots 테이블에 전부 insert 해놓고, 예약 시 그 슬롯 행을 FOR UPDATRE로 잠금.

SELECT * FROM time_slots
WHERE room_id=5 AND slot='12:00' FOR UPDATE;  -- 이제 잠글 실재 행 있음

- 단점 : 슬롯 조합 미리 다 생성해야 됨. 동시성 제어가 데이터 모델로 새어나옴.

직렬성 - SSI

SSI(Serializable Snapshot Isolation) - 직렬성 스냅샷 격리

- 스냅샷 격리 성능은 그대로 두고, 직렬성까지 보장하는 방법.

- 낙관적 동시성 제어. Postgres SERIALIZABLE이 이걸 씀.

배경 — 기존 직렬성 구현의 문제

직렬성 보장 방법은 원래 셋:
- 실제 직렬 실행 — 싱글 스레드로 하나씩. 단순하지만 처리량 한계.
- 2단계 잠금(2PL) — 읽고 쓰는 것마다 락. 확실하지만 느림. 락 대기·데드락 많음.
- SSI — 위 둘의 단점 극복하려고 나옴.

비관 vs 낙관 (2PL vs SSI)

- 2PL(비관적): "충돌 날지 모르니 미리 잠그고 기다린다." 충돌 안 나도 락 비용 냄. 느림.

- SSI(낙관적): "일단 다 진행시킨다. 커밋할 때 진짜 충돌났는지 검사해서, 났으면 그 트랜잭션 취소하고 재시도."
- 충돌이 드문 워크로드면 SSI가 훨씬 빠름. 충돌 잦으면 재시도 폭증해서 손해.

어떻게 동작하나 (핵심 아이디어)

- 스냅샷 격리 위에서 돎 → 각 트랜잭션은 자기 시점 스냅샷을 봄 (읽기 락 없음, 빠름).
- 문제는 쓰기 스큐: "내가 읽은 전제가 커밋 시점엔 이미 낡았을 수 있다."
- SSI는 이걸 감지함:
  - 트랜잭션이 읽은 데이터를 다른 트랜잭션이 나중에 바꿨는지 추적.
  - 커밋 시점에 "내 판단 근거가 된 읽기가 무효화됐나?" 검사.
  - 무효화됐으면 = 직렬 실행이었다면 불가능한 결과 → abort.
- 즉 "낡은 전제 위에서 커밋하려는 트랜잭션"을 잡아 죽인다.

장단점

- 장점: 읽기에 락 안 검(스냅샷 격리 속도) + 직렬성 보장. 한 트랜잭션이 다른 걸 블록 안 함.
- 단점: 커밋 실패(abort) → 재시도 로직 필요. 충돌 잦으면 abort 비율↑ 성능↓.

회사에서 생긴 일

이슈 - @Modifying(clearAutomatically=true) 영속성 컨텍스트 유실

문제 상황

// 1. 엔티티 저장 (영속성 컨텍스트에 올라감)
val classAttend = buildAttend(command, course, nowDate, isWaiting, 0)
classAttendProvider.save(classAttend)

// 2. 쿠폰 컬럼 set 후 2차 save (아직 DB 반영 전, 컨텍스트에만 dirty 상태)
if (command.couponSeq != null) {
    classAttend.couponSeq = command.couponSeq
    ...
    classAttendProvider.save(classAttend)
}

// 3. 벌크 UPDATE
@Modifying(clearAutomatically = true)
@Query("update LivePaymentJpaEntity e set e.attendSeq = :attendSeq where e.merchantUid = :orderId")
fun updateAttendSeqByMerchantUid(...)
→ 3번 실행 시 앞서 변경한 영속성 컨텍스트 내용이 날아감.

해결

@Modifying(clearAutomatically = true, flushAutomatically = true)
- flushAutomatically = true → 벌크 실행 전에 대기 중인 변경을 DB로 flush.
- 순서 바뀜: flush(dirty→DB) → 벌크 UPDATE → clear. 유실 없음.

직접적으로 이번 장과 연관 있는 격리 문제는 아니지만

데이터가 지금 어느 계층에서 어떤 상태인지 파악하는 것이 비슷해서 가져왔다.

이번 장은 트랜잭션으로 막을 수 있는 어떤 문제들이 있는지 파악했고 특히 회의실 예약 예제에서 충돌 구체화는 평소 생각하지 못했던 거라 알게 되어 좋았다.

DDIA 4주차

changha. — Fri, 26 Jun 2026 23:31:40 +0900

이번주차는 6장과 7장이었다.

7장은 추가 문서로 나중에 다시 쓰겠다.(6장만 이번주 하는 줄 착각했다..ㅎ)

6장 - 파티셔닝

왜 파티셔닝하나

복제가 같은 데이터를 여러 노드에 복사하는 것이라면, 파티셔닝은 데이터를 쪼개서 노드마다 다른 조각을 두는 것.

목적은 확장성. 실제 시스템에서는 복제와 파티셔닝을 결합해서 쓴다. (각 파티션을 다시 여러 노드에 복재해 장애 내성까지 확보한다.)

핵심 목표: 부하를 고르게 분산하는 것. 이게 깨지면 skew(쏠림) 이며, 부하가 몰린 파티션은 hot spot.

기본키 기준 파티셔닝 (키-값 데이터를 나누는 방식)

해시 방식의 절충안이 복합 키

ex) 카산드라는 키의 앞부분으로 해시 분산, 뒷부분으로 파티션 안에서 정렬을 유지한다. (한 사용자의 이벤트를 시간순으로 하면 범위 스캔으로 풀림)

해시로도 못 막는 것 - 단일 hot key.

ex) 특정 유명인의 게시글에 팔로워가 몰리는 상황.

해시를 해도 그 키는 한 파티션에 묶이게 된다.

이는 애플리케이션이 키에 랜덤 prefix/suffix를 붙여 인위적으로 쪼개는 식으로 대응해야한다.

(tradeoff <-> 읽을 때 여러 키를 합쳐야 한다.)

보조 인덱스 파티셔닝

보조 인덱스는 PK가 아닌 값으로 검색을 위한 것이다. 이 인덱스도 파티셔닝되면 나눠지게 된다.

로컬 인덱스는 쓰기를 한 곳에 모아 쓰기 증폭을 줄이는 대신 읽기를 분산해서 가져와야된다.

글로벌 인덱스는 읽기를 모으는 대신 쓰기를 증폭시킨다.

점선은 쓰기 흐름. 문서 893 저장할 때 따라가는 경로 (파티션 0으로도 가야됨)

리밸런싱

데이터,노드가 변하면 파티션을 재배치해야 한다.

1. 부하가 다시 고르게 분산된다.

2. 옮기는 데이터가 최소이다.

3. 리밸런싱 중에도 서비스가 계속되는 것.

특징

해시 mod N은 쓰면 안된다.
- N이 바뀌면 모든 키의 소속이 바뀌어 이동 비용이 크다.
고정 개수 파티션
- 노드 수보다 훨씬 많은 파티션을 미리 만들어 노드당 여러 개를 할당
- 장점
  - 이동 최소: 노드 추가/제거 시 파티션 통째로 이사. 키 재해싱 x
  - 운영 단순: 키 -> 파티션 매핑 불변.
  - 이종 노드 대응: 성능 좋은 서버엔 파티션 많이, 약한 서버엔 적게 할당 가능.

고정 개수 파티션 이미지

동적 파티셔닝
- 파티션이 너무 커지면 split, 작아지면 merge.
- 초기 빈 DB의 단일 파티션 쏠림을 막으려면 pre-splitting(사전 분할)을 씀.
  - pre-splitting: 첫 데이터 들어오기 전에 파티션 경계를 미리 그어두는 것.
노드 수 비례
- 노드 당 고정 개수의 파티션.
- 노드를 추가하면 기존 파티션을 무작위로 쪼개 가져간다.
- 장점
  - 파티션 크기 안정: 노드 늘면 파티션도 늘어 -> 파티션당 데이터량 일정 유지
  - 데이터 양 예측 불필요: 고정 개수는 처음에 파티션 몇 개 할 건지 잘 정해야 함. 이거는 노드 수에 자동 연동
  - 확장 자연스러움: 노드 추가 = 새 노드가 기존 파티션 몇 개를 무작위로 쪼개 가져감.

요청 라우팅

이 키는 어디에 있나를 클라이언트가 알아야된다.

세가지 접근

1. 아무 노드에나 보내면 그 노드가 적절한 노드로 포워딩

2. 라우팅 계층을 둔다.

3. 클라이언트가 직접 파티션 배치를 앎.

보통 배치 정보 합의를 위해 Zookeeper같은 코디네이션 서비스를 쓰거나,

gossip 프로토콜로 노드끼리 상태를 퍼트린다.(카산드라)

gossip 프로토콜: 노드끼리 소문내서 클러스터 매핑 공유, 중앙 조정자 없이 라우팅 함.

느낀점

핫스팟 키 부분이 흥미로웠다.

DB단이 아니더라도 서버단에서도 충분히 일어날 수 있는 일인데
랜덤으로 prefix/suffix 로 추가하는 것이 간단하고 이해가 바로 됐다.

또한 복합키를 통해 분산과 정렬 이점을 챙기는 방법도 처음 알게 되었다.

이번 장은 아는 DB 지식을 조합하여 해결할 수 있다는 것을 느끼게 한 장이었다.

DDIA 3주차

changha. — Fri, 19 Jun 2026 23:27:03 +0900

이번 주차는 꽤 재밌는 5장, 복제이다.

여기부터 본격적인 분산환경에서 발생하는 문제들을 다루고 해결책을 설명한다.

복제가 필요한 이유

지연 시간 감소 - 데이터를 사용자와 지리적으로 가깝게 둔다.
내결함성 - 일부 노드가 고장 나도 시스템이 계속 동작하도록 한다.
확장성 - 읽기 질의를 처리하는 장비 수를 늘려 확장한다.

데이터가 안 변하면 복제는 그냥 한 번 복사하면 끝이다.

복제가 어려운 건 변경을 어떻게 전파하느냐의 문제가 있기 때문이다.

문제와 해결

오래된 값일 때 어떻게 해야될까?

문제는 리더의 변경이 팔로워에 즉시 도달하지 않는다는 데 있다. 리더에 쓴 내용이 팔로워에 반영되기까지의 시간차를 복제 지연이라 한다.

이 시스템이 보장하는 것은 최종적 일관성 뿐이다. 쓰기를 멈추면 팔로워들은 언젠가는 리더를 따라잡지만, 그 갭이 생각보다 클 수도 있다.

아래 세 가지 문제는 모두 이 복제 지연 하나에서 갈라져 나온다. 각각이 깨뜨리는 보장이 다르고, 그래서 해결책도 다르다.

문제 1 - 내가 방금 쓴 글이 새로고침하니까 사라졌다.

상황: 사용자가 자신의 프로필을 수정(리더에 쓰기)하고 즉시 새로고침(팔로워에서 읽기)을 한다. 하지만 팔로워에 아직 변경사항이 반영되지 않아 사용자는 수정전의 옛날 정보를 본다.

해결책: 쓰기 후 읽기 일관성

방법 1 - 사용자가 수정한 내용을 읽을 때는 리더에서 읽는다.

보통 마이페이지나 프로필 정보는 소유자만 읽는다.

항상 사용자 프로필은 리더에서 읽고 다른 사용자의 프로필은 팔로워에서 읽는 방식.

방법 2 - 마지막 갱신 시각을 찾아서 마지막 갱신 후 1분 동안은 리더에서 모든 읽기 수행.

팔로워에서는 복제 지연을 모니터링해서 리더보다 1분 이상 늦은 모든 팔로워에 대한 질의를 금지한다.

방법 3 - 복제 서버가 아직 최신이 아니면 다른 복제 서버가 읽기를 처리한다. 또는 복제 서버가 따라잡을 때까지 질의 대기.

클라이언트는 가장 최근 타임스탬프 기억 가능하다. 시스템은 사용자 읽기를 위한 복제 서버가 최소한 해당 타임스탬프까지 갱신을 반영하게 할 수 있다.

문제 2 - 시간이 거꾸로 흘러간다.

상황: 사용자가 페이지를 여러 번 새로고침한다. 첫 읽기는 빠른 팔로워 A에 도달해 최신 글을 봤는데, 두 번째 읽기는 느린 팔로워 B에 도달해 다시 옛날 상태로 돌아간다. 사용자 눈에는 시간이 거꾸로 가는 것처럼 보인다.

문제 1과 달리, 여기서 깨지는 건 "내가 쓴 것"이 아니라 읽기들 사이의 시간 순서다.

해결책: 단조 읽기

한 번 최신 데이터를 본 사용자는, 그 뒤로 더 오래된 데이터를 보지 않도록 보장한다. (시간이 뒤로 가지 않게)

방법 - 각 사용자의 읽기가 항상 동일한 복제 서버에서 수행되게 한다.

사용자 ID의 해시를 기반으로 복제 서버를 고정한다.

문제 3 - 답변이 질문보다 먼저 올라왔다.

상황: 데이터가 여러 샤드에 나뉘어 저장돼 있다. A가 질문을 쓰고, B가 그에 답변을 단다. 그런데 관찰자에게는 B의 답변이 담긴 샤드가 먼저 복제되고 A의 질문이 담긴 샤드가 나중에 복제되어, 답변이 질문보다 먼저 보인다.

질문과 답변 사이에 인과성이 있는데, 그 인과 순서가 뒤집힌 것이다. (샤드별로 복제 지연이 달라 생기는 문제)

해결책: 일관된 순서로 쓰기

인과성이 있는 쓰기들은 항상 쓰여진 순서대로 읽히도록 보장한다.

방법 - 서로 인과관계가 있는 쓰기는 동일한 샤드에 기록되게 한다.

이렇게 하면 한 샤드 안에서는 순서가 보존되므로 역전이 일어나지 않는다.

한 샤드로 들어온다는 것 : 단일 리더 + 순서 로그 + 순차 적용

정리

느낀점

회사에서도 단일 DB로 이루어진것이 아니라 read/write DB로 이루어져있다.

과거 단일 DB로 했던 적이 있는데, 이 때 SPOF문제로 DDos로 DB CPU가 치솟았을 때 웹서버까지 장애가 전파됐었다.

read/write의 구분은 readOnly 트랜잭션은 조회 전용 DB로 보내서 구분하고 있다.

그러면 동기 or 비동기 중에 무엇을 택했나 하면 비동기 방식을 택했다. (유저 알람 배치 복제 지연 개선)

다만 비동기는 복제 지연이 생기게 되는데, 실제로 지연이 7~8초로 터졌었다.

이를 해결하기 위해 쓰기 배치 단위를 작게 쪼개고, Insert/Update를 별도 Kafka 토픽으로 비동기 2단계 분리 하였다.

복제 지연 목표는 1~2초 이내였다.

현재 문제가 없냐 하면 아니다.

비동기 2단계 분리를 하였다고했는데 Insert(알림 저장), Update(뱃지 카운트) 부분에서 새로운 정합성 문제를 만들게 된다.

뱃지 숫자와 실제 알림이 안 맞는 구간이 생길 수 있다.

예를 들어, 알림 목록엔 떴는데 뱃지는 아직 0, 또는 반대. 이 부분이 위에서 기술한 인과성 문제랑 일치하는 것 같다. (알림 생성 -> 뱃지 증가)

다만 이정도는 허용가능한 불일치라서 진행했을 것 같다.

DDIA 2주차

changha. — Fri, 12 Jun 2026 23:39:40 +0900

이번 주차는 4장 부호화와 발전에 대해 알아보았다.

애플리케이션은 필연적으로 시간에 따라 변한다.

첫 문장으로 시작한다.

입사한지 일주일정도 돼서 먼저 기존 소스코드를 파악하는 데 대부분의 시간을 보내고 있다.

이렇게 다시 소스코드나 ERD 구조를 하나하나 깊게 보는 것은 정말 오랜만이었다.

보면서 느낀게 위 첫문장과 일치하였다.

필드가 추가되기도 하고 어떤 테이블은 이제 사용하지 않기도 한다.

이 장에서는 이 변화에 대응하기 위해 어떻게 할 수 있을지 해결책을 알려주었다.

먼저 호환성 개념을 알아야 됐다.

하위 호환성: 새로운 코드는 예전 코드가 기록한 데이터를 읽을 수 있어야 한다.

상위 호환성: 예전 코드는 새로운 코드가 기록한 데이터를 읽을 수 있어야 한다. (이게 더 어렵다)

크게 1부와 2부로 나눌 수 있었다.

1부는 부호화 형식들에 대해 비교하였고 2부는 데이터 플로, 즉 프로세스간 데이터를 전달하는 어떤 방법이 있는지 소개하였다.

나는 회사 문서에서 ProtoBuf나 Avro에 대해 언급한 적이 있어서 이 쪽에 대해 좀 더 알아보았다.

1부: 부호화 형식 비교

메모리 속 객체를 바이트열로 바꾸는 방법들을 호환성 관점에서 바라보았다. (이를 부호화라고 한다.)

- 언어 내장 직렬화

언어 종속적인 문제, 보안 문제, 버전 관리의 부재

- 텍스트 형식

사람이 읽기 좋고 널리 쓰이지만, 숫자 정밀도 문제(json의 큰 정수), 이진 데이터 미지원, 스키마가 선택적이라는 약점

숫자 정밀도 문제

- XML과 CSV는 숫자 123과 문자열 "123"을 구분할 수 없다. (외부 스키마 없이는)

- JSON에서는 2^53보다 큰 정수부터는 정확히 표현이 안됨(JavaScript에서 파싱하는 순간 값이 미세하게 변함)

그래서

이진 데이터 미지원

- 텍스트 형식이라, 이미지나 암호화된 바이트 같은 이진 데이터는 담을 수 없음

Base64로 인코딩해서 문자열로 넣는 건 가능 (다만 데이터 크기 33% 증가)

스키마 선택적

- XML Schema, JSON Schema 존재하긴 하지만 실제로는 잘 안쓰는 곳이 많다고 함

- 이진 스키마 기반 형식

스키마를 명시적으로 정의하고, 필드 태그 번호(Thrift/Protocol Buffers)나 읽기•쓰기 스키마 분리(Avro)를 통해 스키마를 안전하게 발전 시킬 수 있다. (스키마 발전이란: 스키마는 필연적으로 시간이 지남에 따라 변한다)

여기서 각 프레임워크의 차이점과 언제 써야되는지 궁금했다.

1. Thirft / Protocol Buffers

스키마에 각 필드마다 태그 번호를 명시한다.

이 태그 번호는 절대 바꾸면 안된다. (이유: 부호화된 바이트열에는 필드 이름이 없고 태그 번호만 있어서, 태그 번호가 필드의 정체성)

# thrift
struct Person {
  1: required string userName,
  2: optional i64 favoriteNumber,
  3: optional list<string> interests
}

# protocol buffers
message Person {
  required string user_name = 1; // 정확히 1번
  optional int64 favorite_number = 2; // 0번 또는 1번
  repeated string interests = 3; // 0번 이상 몇 번이든
}

부호화된 바이트열에는 필드 이름이 아니라 태그 번호가 들어간다.

두 프레임워크 큰 차이는 없고 Protocol Buffers는 리스트 전용 타입이 없고 repeated표시자를 쓴다는 것 정도이다.

1. 필드 이름 변경: 자유

2. 새 필드 추가:

- 새 코드 -> (읽기) 옛 데이터 : 뒤를 돌아봄 = 하위 호환(required 금지)

- 옛 코드 -> (읽기) 새 데이터 : 앞을 내다봄 = 상위 호환(모르는 태그 건너뛰기로 자동)

3. 필드 삭제: optional 필드만 삭제 가능하고, 그 태그 번호는 영원히 재사용 금지

2. Avro (하둡 생태계에서 출발)

특이점: 태그 번호가 없음

record Person {
  string userName;
  union { null, long } favoriteNumber = null;
  array<string> interests;
}

부호화된 바이트열에는 태그, 필드 이름, 타입 정보 없음

단지 값들만 스키마에 정의된 순서대로 붙어 있음

유니온 타입이란: "이 필드는 이 타입들 중 하나일 수 있다."고 선언하는 방식.

union { null, long } favoriteNumber = null;
해석 -> favoriteNumber는 null이거나 long이다.

왜 필요한가?

Thirft나 Protobuf는 optional/required 표시자가 있지만, Avro는 없음

대신 더 엄격한 원칙이 있음 -> null도 하나의 타입이다.

Protobuf/Thrift 에서는 어떤 필드든 그냥 비워둘 수 있음(optional이면)
Avro에서는 필드 타입이 long이라고 선언했으면 무조건 long 이어야 함
- null을 포함하고 싶으면 유니온에 null을 명시적으로 포함시켜야 함
  - Thirft/Protobuf optional: 필드가 바이트열에서 빠질 수 있음 -> 결과적으로 null 처럼 보임
  - Avro union with null: 필드는 항상 있지만 그 값이 null일 수 있음

그래서

유니온 타입은 optional을 표현하는 수단이자, 한 필드에 여러 타입을 허용하는 장치.

읽기 스키마와 쓰기 스키마

쓰기 스키마: 그 바이트열을 만들 당시 부호화에 사용된 스키마. 데이터와 함께 과거에 박제된 것이라, 지금 와서 바꿀 수 없습니다. "이 바이트열이 어떤 구조로 쓰였는가"의 답.
읽기 스키마: 지금 읽으려는 애플리케이션 코드가 기대하는 스키마. 코드에 컴파일되어 있는 것. "내 코드가 어떤 모양의 객체를 원하는가"의 답.

Avro는 바이트열에 아무것도 없이 값만 나열되어 있어서, 쓰기 스키마를 정확히 알아야 어디서 바이트들을 끊어 읽을지 알 수 있다.

그래서

1. 쓰기 스키마로 바이트열을 해석하고

2. 읽기 스키마로 비교해서 변환한다.

문제점

쓰기 스키마를 어떻게 전달하느냐는 문제가 생긴다.

해결책1

상황: 많은 레코드가 있는 대용량 파일일 때

모든 레코드가 같은 스키마인 경우여서 파일 맨 앞에 쓰기 스키마를 딱 한 번만 넣으면 된다.

Avro가 이를 위해 표준화한 파일 형식이 객체 컨테이너 파일이다.

해결책2

상황: 개별적으로 기록된 레코드를 가진 데이터베이스

각각 레코드들이 서로 다른 시점에 서로 다른 버전으로 쓰였을 때는 해결책1번이 유효하지 않음

이때는 아래처럼 해결

이런식으로 레지스트리에 스키마를 등록해서 컨슈머 쪽에서 조회해서 사용하도록 하면 된다.

동일한 스키마는 캐싱해서 사용할 수 있으니 I/O 비용은 첫 조회때만 발생한다.

해결책3

상황: 두 프로세스가 지속적인 양방향 연결로 통신하는 경우

연결을 맺는 시점에 "우리 이 스키마 버전으로 대화하자"고 합의, 연결이 살아있는 동안 그 스키마를 쓰면 된다.

Avro RPC가 이렇게 동작함

DDIA 1주차

changha. — Fri, 5 Jun 2026 20:55:58 +0900

데이터 중심 애플리케이션 설계 1,2,3장

내용이 꽤 많아 개인적으로 인상적인 부분들 위주로 작성하였다.

1장 - 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션

기억에 남는 문구

단일 도구로는 더 이상 데이터 처리와 저장 모두를 만족시킬 수 없는 과도하고 광범위한 요구사항을 가지고 있다.
이를 해결하기 위해 작업은 단일 도구에서 효율적으로 수행할 수 있는 테스크로 나누고 다양한 도구들을 애플리케이션 코드를 이용해서 서로 연결한다.

예시)

비동기 테스크 - Message Queue

검색 요청 - Elastic Search

읽기 요청 - Cache

느낀점:

하나의 도구로 모든 상황을 해결하려고 하는 것이 아니라 각각의 용도에 맞는 도구를 선택하고 서로 연결해서 사용해야된다고 느꼈다.

나 또한 사이드 프로젝트에서 캐시를 활용한 경험이 있다. 별도로 Redis같은 외부 저장소를 사용한 건 아니고 로컬 메모리를 사용했다.

똑같은 자원을 어떻게 사용하는지에 따라 최적화를 할 수 있다는 것을 느꼈다.

신뢰성 - 무언가 잘못되더라도 시스템이 올바르게 동작해야 함

기억에 남는 문구

결함: 일부 컴포넌트가 잘못됨

장애: 시스템 전체가 멈춤

-> 서로 같지 않음

결함이 생겨도 장애로 이어지지 않게 하는 것이 핵심이다.

느낀점:

결국 운영을 하다보면 결함이 발생하기 마련이다. 그 결함을 미리 어떻게 대처하는지에 따라 큰 장애로 이어지는지 여부를 결정하는 것 같다.

예를 들어 벌크 헤드 패턴을 들 수 있겠다.

외부 io연결 작업에서 공용 스레드 풀을 사용하면 급작스러운 io작업에 모든 스레드가 소진되어 전체 시스템이 마비될 수도 있다.

사전에 독립적인 스레드풀을 만들어 놓았다면 이정도의 장애는 발생하지 않았을 것이다.

2장 - 데이터 모델과 질의 언어

데이터 모델 종류

- 관계형 모델

- 문서 모델

- 그래프 기반 데이터 모델

관계형 모델과 문서 모델

관계형의 경쟁자는 많았지만 결국은 관계형이 대세가 되었다.

2010년대에 NoSQL 등장하면서 관계형에 비해 더 나은 지역성을 가졌다.

여기서 지역성이란?

관련 정보를 한 곳에 모을 수 있는 건데

관계형은 각 흩어진 위치에 I/O 작업을 통해 합치는 반면

NoSQL은 JSON 표현으로 한 번에 볼 수 있음

여기서 I/O작업은 결국 시간이 더 걸리게 되는 요인이 된다.

ID필드와 텍스트 필드 비교

왜 텍스트 대신 ID를 쓰나?

텍스트 직접 저장 시 문제:

"San Francisco" → "SF" 로 이름 변경 시
→ 3개 행 전부 수정해야 함
→ 하나라도 빠뜨리면 불일치 발생

해결:

ID로 저장 시 테이블 값이 있는 1곳만 수정하면 된다. 그 이외에 참조된 곳은 의미없는 아이디만 참조하기에 신경쓰지 않아도 된다.

이것이 곧 DB 정규화의 핵심이다!

여기서 정규화란
중복을 제거하고 데이터를 한 곳에서만 관리하는 것 (다만 join 은 DB I/O를 유발하니 트레이드오프가 있다.)

선언형과 명령형의 차이점

선언형

목표를 달성하기 위한 방법이 아니라 알고자 하는 데이터의 패턴
- 결과가 충족해야 하는 조건과 데이터를 어떻게 변환(정렬, 그룹화, 집계)할지를 저장하기만 하면 됨

명령형

특정 순서, 특정 연산을 수행하게끔 컴퓨터에게 지시함

선언형 장점

자동 최적화: DB 엔진(옵티마이저)이 내부적으로 스스로 최적화함
병렬 실행: 결과의 패턴만 정의하였으니 과정은 병렬화 가능

선언형 예시 - CSS

명령형의 단점

코드 복잡성: 한 눈에 봐도 가독성이 좋지 않다. 순차적으로 depth들어가면서 이해를 하기에
상태 관리 어려움: selected 클래스 삭제되어도 파란색 배경은 자동 삭제되지 않고 삭제 코드를 또 작성해야된다.
유지보수 및 확장성: 새로운 api 사용하려면 코드를 처음부터 다시 작성해야 되는 번거로움

명령형 예시 - JavaScript

3장 - 저장소와 검색

LSM 트리가 무엇이고 어떻게 동작하는지 중점적으로 알아보았다.

1. 로그 구조화와 SS 테이블

로그 구조화: 모든 쓰기를 순차적으로 추가(append-only)하는 방식으로 데이터를 저장

[전통적 방식 - 제자리 수정 (in-place update)]
디스크: [A=1] [B=2] [C=3]
↓ B를 5로 수정
디스크: [A=1] [B=5] [C=3] ← 해당 위치를 직접 덮어씀

[로그 구조화 방식 - append-only]
디스크: [A=1] [B=2] [C=3] [B=5] ← 끝에 추가만 함
↑ 최신값

SS 테이블: 정렬된 키-값 쌍을 디스크에 저장하는 불변 파일 형식

인메모리 색인을 가진 SS테이블

인메모리 색인이 필요한 이유

색인이 없으면 특정 키를 찾을 때 O(N)으로 동작함

키와 디스크 위치를 모르기 때문에 몇 번째 바이트에 뭐가 있는지 계산이 불가하다.

해결

인메모리에 key와 offset(key의 바이트 단위)을 저장한다.

다만, 전체를 안하고 일부 키만 저장해도 된다.

메모리 색인 (Sparse)
apple → offset 0
dog → offset 200
monkey → offset 500

"cat" 검색
→ apple(0) < cat < dog(200)
→ offset 0부터 200까지만 스캔하면 됨
→ 전체 파일이 아닌 아주 작은 범위만 탐색

이렇게 전체가 아니라 그 사이만 스캔하면 되니까 효율적이게 된다.
그러면 메모리 비용 <-> 색인 범위간의 트레이드 오프인 것 같다.

유입되는 쓰기는 임의 순서로 발생한다. 데이터를 키로 정렬하려면 어떻게 해야될까?

실제 쓰기 요청이 들어오는 순서 (임의 순서)

1번째 쓰기: zebra = 100
2번째 쓰기: apple = 200
3번째 쓰기: mango = 300
4번째 쓰기: banana = 400

그런데 SSTable은 정렬이 필요하다.

문제

들어오는 쓰기: zebra → apple → mango → banana (뒤죽박죽)
↓
SSTable 저장: apple → banana → mango → zebra (정렬 필요)

디스크에 바로 쓰면서 동시에 정렬을 유지하는 것은 어렵다.

중간에 넣으려면 뒤의 데이터를 전부 밀어야 함...

해결

MemTable (메모리의 Red-Black Tree 활용)

: 임의 순서로 들어오는 쓰기를 메모리에서 정렬한 뒤, 정렬된 채로 디스크에 한 번에 쓴다.

그렇다면 문제는 없나?

아니다. 만약 DB가 고장나면 아직 디스크로 기록되지 않고 멤테이블에 있는 가장 최신 쓰기는 손실된다.

이 문제를 해결하기 위해서는 이전 절과 같이 매번 쓰기를 즉시 추가할 수 있는 분리된 로그를 디스크 상에 유지해야 한다.

2. LSM 트리

정렬된 파일 병합과 컴팩션 원리를 기반으로 하는 저장소 엔진을 LSM 저장소 엔진이라고 한다.

핵심 구성 요소

1. MemTable(메모리)

: 쓰기 요청을 가장 먼저 받는 곳

2. WAL(Write-Ahead Log)

: MemTable이 날아가도 복구를 위한 보험

3. SSTable(디스크)

: 키가 정렬된 불변 파일

쓰기 흐름

쓰기 요청
↓
① WAL에 append (디스크, 순서 무관)
↓
② MemTable에 삽입 (메모리, 자동 정렬)
↓ 가득 차면
③ SSTable로 Flush (디스크, 정렬된 상태)
↓ L0가 쌓이면
④ Compaction (병합·정렬·중복제거)

읽기 흐름

읽기 요청
↓
① MemTable 확인 (가장 최신)
↓ 없으면
② L0 SSTable 확인
↓ 없으면
③ L1 → L2 → ... 순서로 탐색

성능 최적화 - 1

기존 LSM 트리의 문제점

: DB에 존재하지 않는 키를 찾는 경우에 느릴 수 있다.

이유

: 존재하지 않는 걸 확인하기 위해 가장 오래된 세그먼트까지 거슬어 올라가야 하기에

해결책

블룸필터: 선택한 키가 존재하지 않는다는 것을 매우 빠르게 판별하는 자료구조

준비물: 비트 배열 + 해시 함수

결론

비트 중 하나라도 0

-> 확실히 없음

모두 1

-> 있을 수도 있음

-> 실제로 SSTable 탐색 필요

성능 최적화 - 2

Compaction 전략: 두 가지로 나뉜다.

목적

시간이 지나면 옛날 값들이 쌓이게 된다.(새 값으로 추가되거나, 삭제됐지만 아직 파일에 존재하는 경우)

1. 크기계층 컴팩션

: 작은 SSTable -> 큰 SSTable에 병합

처음
[1MB] [1MB] [1MB] [1MB] ← 작은 것 4개 쌓임
↓ 병합
[4MB] ← 하나로 합침

또 쌓임
[4MB] [4MB] [4MB] [4MB] ← 중간 것 4개 쌓임
↓ 병합
[16MB] ← 또 하나로 합침

계속 반복
[16MB] [16MB] [16MB] [16MB]
↓
[64MB]

장점:

쓰기 속도가 빠르다.

-> 그냥 새 파일 만들고 나중에 합치면 된다.

단점:

같은 키가 여러 파일에 존재 가능하다.

-> 읽을 때 여러 파일 확인 필요

병합 직전에 디스크 공간 일시적으로 2배 필요하다는 단점이 있다.

불변이기에 동일한 데이터를 변경하고 싶을 때 수정할 수 없고 써야 된다.

이는 SSTable A, B로 나뉠 수 있다.

2. 레벨 컴팩션

: 키 범위를 더 작은 SSTable로 나누고 오래된 데이터는 개별 레벨로 이동

L0 (키 범위 겹쳐도 됨, Flush된 파일들)
[a,z,m,b...] [c,k,g,p...]

↓ L0가 일정 개수 차면

L1으로 내려보내면서 키 범위 재정렬
[a-g] [h-n] [o-t] [u-z]
→ 겹치는 파일만 골라서 부분 병합

↓ L1이 차면

L2로 내려보냄 (L1보다 10배 큰 용량)
[a-c][d-f][g-i]...(더 잘게 쪼개짐)

장점:

읽기 빠름 (분리된 구역만 확인하면 되니까)

단점:

쓰기 느림 (Compaction할 때마다 같은 데이터를 반복해서 새로 써야 되기 때문에)

LSM 트리의 장단점

장점

1. 쓰기 처리량이 높다.

B 트리:
데이터 수정 시 해당 페이지를
디스크에서 찾아서 → 덮어씀
→ 랜덤 쓰기 발생 (느림)

LSM 트리:
항상 순차적으로 SSTable 파일을 씀, 즉 여러 페이지를 덮어 쓰는 것이 아님
→ 순차 쓰기 (빠름)

순차 쓰기가 왜 빠를까?

HDD의 매커니즘과 관련있다.

SSD은 물리적 헤드가 없어서 랜덤/순차 차이가 분명하진 않다.

그래도 낮은 쓰기 증폭과 파편화 감소는 SSD의 경우 훨씬 유리하다.

2. 쓰기 증폭이 더 낮다.

B 트리:
데이터 쓰기 전 로그 한 번
+ 트리에 실제 쓰기 한 번
+ 페이지 분리 시 또 쓰기
→ 최소 두 번 이상 기록

LSM 트리:
Compaction이 있지만
순차적으로 한번에 씀
→ 상대적으로 쓰기 증폭 낮음

LSM 트리에서 쓰기 증폭이 있다고 했는데 왜 B트리보다는 낮을까?

3. 압축률이 좋다.

B 트리:
페이지 단위로 저장
→ 페이지가 꽉 안 차면
남는 공간 낭비 (파편화)

LSM 트리:
SSTable을 꽉꽉 채워서 씀
+ Compaction 시 불필요한 데이터 제거
→ 디스크 공간 효율적
→ B 트리보다 더 적은 파일 생성

단점

1. Compaction이 읽기/쓰기 성능에 영향

Compaction 진행 중:
디스크 자원을 Compaction이 점유
↓
새로운 읽기/쓰기 요청이
디스크 쓰려고 대기해야 함
↓
응답 시간이 길어짐

반면 Btree는
데이터 요청 -> 해당 페이지 찾아서 -> 바로 덮어씀 -> 끝
이 과정에서 백그라운드 작업이 없고 항상 일정한 속도임

2. Compaction이 유입 쓰기 속도를 못 따라갈 수 있다.

쓰기가 매우 빠르게 들어오면:
Compaction이 처리하는 속도 < 쓰기 유입 속도
↓
SSTable 파일이 계속 쌓임
↓
디스크 공간 부족 위험
읽기 시 확인할 파일 증가 → 읽기도 느려짐

→ 명시적 모니터링 필요!

3. 같은 키의 다중 복사본 존재

B 트리:
각 키가 색인의 한 곳에만 정확히 존재
→ 트랜잭션 처리 쉬움

LSM 트리:
Compaction 전까지
여러 SSTable에 같은 키 존재 가능
→ 트랜잭션 처리 복잡
→ 강력한 트랜잭션이 필요하면
B 트리가 훨씬 유리

백엔드 인턴 최종합격

changha. — Sun, 31 May 2026 17:05:24 +0900

드디어 나도 최종합격을 하며

첫 회사로 스타트업 백엔드 인턴으로 들어가게 됐다.

작년 9월부터 면접을 보기 시작했으니 9개월 만에 취업성공을 했다.

백엔드는 워낙 포화상태라 더더 힘들었던 것 같다.

특히 AI로 인해 시장에서 요구되는 능력치는 날이 갈수록 올라갔다.

코딩테스트, 과제역량, CS 기본기 등등 프로젝트말고도 준비해야 될 것은 많았다. (취준생들 정말 응원합니다)

올 해 상반기 지원한 내역들 중 일부

도움 되었던 것은

한 세미나에 온라인 참석을 한 적이 있다.

토스,무신사,채널톡을 합격하신 분이 강연자였는데,

빅테크 세미나들을 많이보고 그중 하나를 골라서 프로젝트로 만들어서 이력서에 녹였다는 것이었다.

위 말대로 나도 똑같이 하진 않았지만 빅테크 세미나(유튜브나 기술블로그)들을 최대한 많이 보고 노션에 정리했다.

예전에는 기본기만 잘하라고 했지만 현재는 그것만으로는 시장에서 메리트가 부족하다고 생각하고 느꼈다.

특히 서류에서는 훅이 필요한 것 같다. 눈에 띌만한 요소.

나는 그게 10만건 데이터 처리 파이프라인 구축이었던 것 같다.

이 과정에서 어떤 시행착오가 있었는지 잘 정리하는 게 필요했다.

이러면 면접에서 어떻게 했는지, 그 과정에서 고민한 지점이 무엇 인지들을 물어보게 된다.

어떻게 이 회사에 합격했을까 하면

1차와 2차 면접에서 그동안 내가 했던 적극성이 잘 전달되었던 것 같다.

직접 사이드 플젝(나르지지) 기획 부터 팀 모집, GDSC 활동(면접에서 처음으로 알아주신 분이 계셨다..), 기술에 대한 호기심(ai관련 동향이나 내가 공부했다고 한 것에 대해 질문했을 때 답변)

회사에서 이러한 적극적인 사람을 필요로했고 운 좋게 내가 선발되었던 것 같다.

앞으로의 방향성

지금까지는 동아리, 팀 프로젝트만 많이 했어서, 회사에서의 워크플로우가 궁금하고 많이 배우고 싶다.

개인적으로는 AI 관련하여 그동안 적극적으로 정보를 최신화하면서 따라가지 못했다.

회사에서도 전사적 AX로 방향을 설정한 만큼, 이와 관련해서 많이 공부해보려고 한다.

또한 대규모 데이터 처리에 대해서도 개인적으로 관심이 있어서 공부해볼 것이다.

그동안 고생했다 나!!

잘 찍었다고 느낀 종로 사진

면접스터디 4차 회고

changha. — Mon, 25 May 2026 20:54:31 +0900

다같이 계속 하다보니 서로 사는얘기하는 빈도도 늘어나는 것 같다~ ㅋㅋ

다같은 취준생 입장이다 보니 공감대 형성이 잘 되는 것 같아서 좋다.

이번에 나는 preparedstatement 와 statement차이점에 대해 정리하였다.

https://www.notion.so/319025901eb8802a98cbf0abeda56183?v=319025901eb880a2a618000c2d63983e&p=35dfa15530f78008b75dd9f6e49f8c48&pm=s

우리의 애플리케이션에서 PreparedStatement는 어떻게 동작하고 있는가 | Notion

이 글의 목적:

www.notion.so

사실 이 부분까지 깊게 볼 일이 없어서 잘 모르는 부분이긴 했다.

하지만 평소에 사용하는 db io와 연관되어 있어서 중요한 부분이라고 생각이 들었다.

가장 최근에 이 용어를 접한건 jdbc batch write 부분을 개선하면서 접했다.

어떤부분인가하면

아래사진처럼 대용량 필드 쿼리를 만들때 아래처럼 PreparedStatement 인덱스를 직접 증가시키며 매핑했어야 됐다.

이부분에 대한 해결책은

https://www.notion.so/Batch-Insert-35dfa15530f781b7a7bef1e50e483825

대량 필드 Batch Insert 매핑 개선 | Notion

문제

same-robin-1ff.notion.site

이렇게 정리했다.

본론으로 돌아와서 내가 정리한 블로그 내용의 핵심은

쿼리문 생성과 io 작업을 줄이기 위해 캐시를 사용하는데 이 부분을 최적화 하기위해 관련 파라미터들을 true 설정해야 좋다는 것이었다.

ㅈㅎ님은

mysql db x-lock의 순서와 관련한 칼럼을 소개해주셨다.

fifo방식으로 락이 풀릴까에 대한 궁금증이 있었는데 이 부분은 fifo가 아닌 cats 알고리즘에 의해 작동되었다.

cats는 Contention-Aware Transaction Scheduling의 약자로

해당 트랜잭션이 블로킹하고 있는 트랜잭션 수에 따라 가중치를 할당해 대기 우선 순위를 지정한다.

이 부분에 대해서는 생각해본적이 없었는데 새로 알게되어 재밌었다.

[책 후기] 데이터 중심 애플리케이션 설계

changha. — Fri, 8 May 2026 12:28:43 +0900

이 책은 작년 여름에 인프런 멘토한테 추천받았던 책이다.

그 회사에서 교과서로 취급받는 정도로 유명하고 좋은 책이다라고 들었다.

나도 처음에 도서관에서 우연히 발견했을 때 제목부터 흥미로워서 빌렸다가 1~2장에서 그만둔 기억이 있었다. (글을 읽어도 이해가 잘 안돼서..)

읽어야지 하다가 올 해 3월부터 완독을 목표로 시작하였다.

내용은

5~9장이 나한테 큰 도움이 되었던 것 같다.

분산환경에서 어떤 문제가 발생하고 해결책들이 있는지 이 과정들을 자세히 설명해주었다.

4월에 1회독 마무리를 했지만 뭔가 배운것이 제대로 머릿속에 정리가 안 된 것 같아서 노션에 정리하기도 하였다.

https://www.notion.so/35afa15530f7804ebf24c5e2e6c7a192 (노션 정리 링크)

분산환경에서 통신할 때 각 시간까지 고려해야 된다는 부분도 알려주었는데 이부분은 아직 제대로 이해를 못 한 것 같긴하다.

10장 11장은 배치와 스트림 부분으로써, 2회독을 해도 제대로 써보지 않았기에 읽는데 힘들었다.

그래도 말로만 듣던 hadoop, kafka, zookeeper에 대해 대략적으로 어떤 용도로 쓰이는지 처음 알게 되었다.

작가가 추상화 수준에서 db, os를 비교한 부분이 인상깊었다.

데이터를 저장하고 처리하고 질의하는 용도로

db = 레코드 형태

os = 파일 형태

로 정보를 관리한다는 부분

unix = 하드웨어 추상화를 프로그래머에게 제공

rdb = 고수준 추상화를 프로그래머에게 제공 (디스크 상의 자료 구조, 동시성, 장애 복구 복잡성을 감춤)

이 책은 앞으로도 읽을 때마다 배울점이 생기는 책일 것 같다.

면접 스터디 3차 회고

changha. — Mon, 4 May 2026 18:40:39 +0900

늦었지만 저번주에 진행한 면접 스터디 내용을 복기하려고 한다.

ㅈㅎ님과 나 이렇게 발표했다.

ㅈㅎ님 내용은 토스 테크 블로그의 https://toss.tech/article/34481

캐시를 적용하기 까지의 험난한 길 (TPS 1만 안정적으로 서비스하기)

TPS가 평균 1만, 최대 2만까지 늘어난 약관(terms) 서버에 안정적인 서비스 제공을 위해 캐시를 적용한 이야기를 들려드리려고 해요.

toss.tech

해당 아티클을 발표해주셨다.

내용은

약관 서비스를 캐시 처리를 통해 db 부하를 감소시키려는 목적이었다.

조건: Strong Consistency를 유지해야 된다.

약관은 개인정보와 밀접하여 철회한 이후에도 개인정보 공유가 되는 문제가 발생하면 안되기에

전략: Look-aside 패턴

이유: db의 정보가 자주 변경되지 않았기에

만약 db 정보가 자주 변경된다면 다른 방식 고민

만료처리: @EnitityListner + @TransactionalEventListener 사용

내용: db에 커밋된 이후에 캐시가 만료되도록

이유: db commit전에 만료처리를 하는 경우 다른 요청에서 commit 전 데이터를 적재 할 수 있음

한계: after_commit이어도 cache evict 처리가 실패해도 rollback이 안됨

해결: circuit breaker 활용

내용: evict 실패 시, force open 하여 db 조회하도록 함

문제: commit 이후 cache를 evcit하는 찰나의 순간에 kafka event를 consume한 곳에서 잘못된 캐시 조회

해결: kafka event를 cache evict 처리 이후에 발생하도록

문제: 그래도 commit 이후 cache evict 처리 되기전에 조회하면?

해결: 정책으로 해결(약관 동의 여부는 값이 db에 commit 되는 순간 바로 다음 요청에 db에 저장된 값이 응답되어야 한다.)

캐시를 도입하며 기술적으로 트러블을 해결하려고 하기보다는 로직 순서와 정책 정의를 통해 문제를 풀 수 있는 유용한 case였다고 느꼈다.

나

https://www.notion.so/348fa15530f780e08540ec667c89b5f5?source=copy_link

재고 관리 시스템 | Notion

정해진 재고 만큼만 주문

www.notion.so

면접에 대비하기 위해 재고관리 시스템을 구축해보았다.

여기서 포인트는 동시성 제어, transaction, 정합성(tx outbox pattern) 3가지였다.

여기서 배운것은 분산락을 사용하더라도 예외 케이스(타임아웃)이 발생할 수 있기에

낙관적락을 같이 쓸 수도 있겠구나라는 것을 얻었다.

그리고 재고와 같이 내구성이 중요한 도메인은 redis와 같이 메모리단 보다 db단에서 정합성 관리를 해야된다는

비즈니스적 중요성을 함께 생각할 수 있었다.