2024년 4월은 시간 개념을 잊게 만든 때아닌 눈 소식만큼이나 어리둥절하고 당황스러웠다. 개인적인 사유로 인해 직장에서도, 사회에서도 “괜찮아요? 호상씨, 무슨 일 있어요?”라는 말을 자주 들었던 달이다.

벌써 본론에 도달했다. 그렇다, KPT를 해봐야겠다.

Keep

• 힘들다고 연차를 남발하지 않은 것
• 개인적인 감정이 업무에 영향을 미치지 않도록 한 것
• 오히려 일에 집중하며 생각을 떨치고자 한 것
• 새로운 취미생활을 만든 것 (킥복싱)
• 음주가무를 적당히 즐긴 것
• 취준생의 이력서 피드백을 준 것
• 좌절하지 않고 무너지지 않으며 오히려 더 멋진 방법으로 나를 지킨 것

Problem

• 회사에서 표정 관리를 못해 다른 사람들이 내 감정에 눈치를 보게 한 것
• 생각 없이 지출한 것
• 나 자신을 너무 방치한 것
• 나 자신을 아끼지 않은 것
• 이제서야 깨닫게 된 것

Try

• 모든 일에 있어서 내가 우선일 것
• 매일 아침 스스로를 칭찬할 것

1. Master-Slave 잘 알았다면 하지 않았을 실수

DB 서버의 부하를 줄이기 위해 DB 서버를 두 대로 나누어, 하나는 조회성으로, 다른 하나는 제어성으로 사용하는 기법이 있다. (Scale-out Solutions) 모든 연산이 하나의 DB에서 일어나면 트래픽이 늘어나면서 병목 현상이 발생할 수 있는데, 이를 피하기 위해 Master-Slave DB 간의 정보 싱크를(Replication) 연결한다.

어느 날, Slave DB에서 DELETE문에 서브쿼리로 SELECT를 붙여 실행한 케이스가 있었다. DB safer가 있음에도 불구하고(특정 명령어와 쿼리를 실행을 막아줌) 실행되어 Slave와 Master 간의 replication이 깨져 DB 작동이 멈추었다.

이 문제는 Slave 데이터를 Master로 복구하면 해결되지만, MySQL의 replication은 비동기 방식이라 복구 시간을 기다려야 한다. 즉, 실시간으로 들어오는 데이터는 복사 대상에 포함되지 않는다. 시간이 있을 때 Replication을 연습해보는 것도 좋다. (DBA가 하겠지만…)

2. Event Listener

사수분이 요즘 흥미로운 기술이라며 알려주신 것이 있다. 서버 단에서 하나의 로직에서 두 개의 액티브가 발생할 때, 트랜잭션 관리적인 측면과 결과를 통제할 수 있는 기술이다.

예를 들어, 회원가입 로직에서 성공하면 이메일로 회원가입 성공 메일을 보내는 로직이 있다. 회원가입에 성공했지만 이메일 발송에 실패한다면 해당 로직의 응답은 실패로 처리된다.

Python의 경우 async나 jQuery에서 사용되는 promise처럼 동기/비동기를 넘어 트랜잭션을 구분하고, 퍼사드 패턴을 이용하여 하위 객체의 기능을 조합하면 위의 결과는 사용자 정의 로직에 만족하는 결과를 얻을 수 있다.

-> 신규 기능(콘 적립)에 적용해보자.

Event Listener로 학습 완료 API를 호출하고, 이중 적립 체크 로직을 수행한 후 결과값이 Complete라면 실제 콘 적립 API를 이벤트 방식으로 호출하여 트랜잭션을 구분하고, 실제 콘 적립 API 성공 응답과 관계없이 정상적으로 종료시킬 수 있다.

하루에 이런 카테고리의 글을 작성해보자.

END