
R.I.P. 내가 만든 시스템이 무지개 다리를 건넌 이야기
카카오뱅크 Oslo 시스템의 도입, 운영, 종료 과정을 통해 기술적 선택의 유한성과 가역성을 돌아보았습니다. 장애 격리에는 성공했지만 장기 운영 비용과 Bus Factor 문제로 EOS를 결정했습니다.

카카오뱅크 Oslo 시스템의 도입, 운영, 종료 과정을 통해 기술적 선택의 유한성과 가역성을 돌아보았습니다. 장애 격리에는 성공했지만 장기 운영 비용과 Bus Factor 문제로 EOS를 결정했습니다.

UI와 리포지터리가 최대 개수 규칙을 암묵적으로 공유하는 구조의 문제를 다뤘습니다. `hasMoreItems` 같은 명시적 속성으로 책임을 분리하는 방법을 제안했습니다.

양방향 변환은 한쪽 로직을 기준으로 다른 쪽을 유도하는 편이 안전했습니다. 중복 값과 누락은 테스트로 보강하는 방식이 유효했습니다.

컬렉션 반환값의 읽기 전용과 변경 가능성은 다를 수 있어 주의가 필요했습니다. 상황에 따라 요소 접근, 스냅샷 복사, 직접 참조 반환을 구분해 사용해야 했습니다.

새 속성을 추가할 때는 기존 이름이 더 이상 적절한지 함께 살펴야 합니다. 이름을 구체화하고 표시 규칙을 분리하면 버그를 줄일 수 있습니다.

줄 바꿈은 코드를 의미 단위로 나눌 때 더 읽기 쉬워집니다. 메서드 체인, 폴백 체인, 엘비스 리턴은 의미가 크게 갈리는 지점에서 끊는 것이 좋습니다.


딜라이트룸 개발그룹의 월간 독서 스터디 운영 방식과 책 선정 사례를 소개했습니다. 함께 읽고 토론하는 과정이 개인 성장과 팀워크를 강화한다고 정리했습니다.


리팩토링을 통해 팀 협업 방식과 코드 구조를 함께 개선한 과정을 공유했습니다. 데일리 미팅, Mob Programming, 점진적 리팩토링으로 유지보수성과 이해도를 높였습니다.

DevPlay 계정 연동의 장점과 Guest 계정의 한계를 설명했습니다. 또한 크로스 게임 프로모션과 리세마라 방지를 위한 서버 처리 방식도 소개했습니다.


외부업체 주소정제 의존을 줄이기 위해 지번 요청과 LOW 레벨 주소를 내재화한 과정을 정리했습니다. 변경이력 DB와 백오피스 보정으로 계약 종료까지 안정적으로 마무리했습니다.

반복문 내부의 큰 조건 분기가 흐름 파악과 대응 관계를 어렵게 만든다고 설명했습니다. 이를 해결하는 네 가지 재구조화 방식과 각 장단점을 정리했습니다.

함수는 값이 이미 확인됐다는 암묵적 가정에 의존하지 않도록 설계해야 합니다. 내부 검증, 반환값 처리, 타입 보장으로 책임을 명확히 나누는 방법을 소개했습니다.