역량 맵
연결 구조로 읽는 역량 그래프
어떤 역량이 중심에 있고 무엇과 연결되는지 먼저 보고, 오른쪽 패널에서 대표 글과 판단 근거를 바로 확인할 수 있습니다.
연결된 역량 그래프
노드를 클릭하면 연결된 역량만 남기고, 오른쪽 패널이 해당 역량의 증거와 설명으로 바뀝니다.
선택한 역량 상세
데이터베이스 내부 동작
트랜잭션, MVCC, 락, 리플리케이션을 표면적 사용법이 아니라 시스템 수준의 사고로 설명합니다.
왜 중요한가
저장소의 내부 동작을 이해해야 정합성과 성능 문제를 설계 수준에서 다룰 수 있다는 점을 보여주는 축입니다.
읽을 때 볼 포인트
- 트랜잭션 정합성과 격리 수준을 실제 설계 판단과 연결합니다.
- 락과 복제처럼 운영 결과에 직접 영향을 주는 내부 메커니즘을 설명합니다.
연결된 역량
정산·배치 정합성
80만 건 규모의 정산 배치에서 처리 시간과 정합성을 동시에 잡기 위해 청크 분할, 분산락 재설계, 명시적 상태 전이를 적용한 실무 기록입니다.
왜 중요한가
실패하면 정산 일정 전체가 흔들리는 흐름에서, 추측이 아니라 계측과 구조로 문제를 닫아본 경험이 있다는 것을 보여주는 축입니다.
읽을 때 볼 포인트
- 분산락이 있는데도 레이스가 난 원인을 로그로 추적하고 소유 토큰과 조건부 해제로 재설계했습니다.
- 삭제·등록 배치를 청크와 병렬 처리로 재설계해 2시간을 5분으로 줄였습니다.
- 삭제중, 삭제완료, 등록중, 등록완료 상태를 명시해 운영자의 호출 순서가 아니라 시스템이 정합성을 강제하게 했습니다.
대표 글
관련 읽기 경로
연결된 역량
결제 정합성 검증
결제·원장 백엔드 ParityPay에서 중복 요청, 동시 차감, 외부 응답 유실, 이벤트 중복·유실·순서 역전, 프로세스 재시작 아래에서 금융 불변조건을 지키는지 부하·장애 실험으로 검증한 기록입니다.
왜 중요한가
실무에서 배운 정합성 원칙을 돈이 걸린 도메인에 한 단계 더 엄밀하게 적용하고, 실험이 찾은 결함과 측정의 실수까지 기록했다는 것을 보여주는 축입니다.
읽을 때 볼 포인트
- 이중부기 원장의 균형과 불변성을 애플리케이션이 아니라 DB 트리거로 강제했습니다.
- 외부 승인 응답 유실을 실패로 확정하지 않고 UNKNOWN 상태로 보존해 조회로 수렴시켰습니다.
- 잠금 보유 구간을 문장 단위로 측정해 17ms에서 1ms로 줄이고, 설명하지 못한 측정 결과는 그대로 남겼습니다.
- 브로커를 죽이고 파티션 키를 흩어 acks와 파티션 키가 정확성의 일부임을 실측했고, 처리할 수 없는 레코드가 조용히 사라지는 경로를 찾아 DLT로 닫았습니다.
대표 글
- ParityPay로 검증하는 결제 정합성 1 - 장애가 나도 지켜야 할 금융 불변조건 여섯 가지
- ParityPay로 검증하는 결제 정합성 2 - 잠금을 필요 이상으로 오래 쥐고 있었다: 추론을 측정으로 바꾼 기록
- ParityPay로 검증하는 결제 정합성 5 - DB 커밋과 Kafka 발행 사이: Transactional Outbox와 at-least-once 소비자
- ParityPay로 검증하는 결제 정합성 8 - Kafka에서 중복·유실·순서 역전을 직접 만들어 보기: 멱등 소비자와 Outbox가 막는 것과 못 막는 것
- ParityPay로 검증하는 결제 정합성 9 - 느린 기관 앞에서 결제 서버를 지키기: 타임아웃, 재시도, 차단기, 리미터, 벌크헤드가 각각 무엇을 막는가
- ParityPay로 검증하는 결제 정합성 10 - 락 lease가 트랜잭션보다 먼저 끝나면 정말 정합성이 깨지는가: SETNX 락, Watchdog, fencing token, 그리고 락 없는 구조의 실측
관련 읽기 경로
연결된 역량
Spring 백엔드
Spring과 Spring Boot에서 런타임 라이프사이클, 프레임워크 경계, 실제 백엔드 애플리케이션 동작을 다룹니다.
왜 중요한가
프레임워크 사용법을 넘어서, 애플리케이션이 어떻게 시작되고 경계를 나누며 운영되는지 설명하는 역량을 보여줍니다.
읽을 때 볼 포인트
- 런타임 라이프사이클과 애노테이션의 실제 의미를 다룹니다.
- 이벤트, 트랜잭션, 구성 경계를 운영 관점으로 연결합니다.
대표 글
연결된 역량
아키텍처와 의사결정
트레이드오프를 명시적으로 드러내고, 설계 선택이 운영 결과와 어떻게 연결되는지 보여줍니다.
왜 중요한가
개별 기술 지식을 실제 구조 선택과 운영 판단으로 이어붙이는 중심 노드입니다.
읽을 때 볼 포인트
- 설계 선택의 비용과 이익을 동시에 설명합니다.
- 네트워크, 저장소, 애플리케이션 계층을 하나의 판단 흐름으로 묶습니다.