어제 세웠던 Try 돌아보기

• 매출 통합과 이상치 탐지의 물리적 업무 분리

  • Jira 티켓 분리는 물론, 작업 문서와 메모장까지 탭을 나누어 무의식적인 디펜던시 연결을 강제로 차단한다.

• 기존 인프라 기반의 우회 전략 수립 및 빠른 싱크

  • 신규 서버 대신 Lambda나 기존 API 서버의 자원을 활용하는 아키텍처를 도출하고, 확정 전 동료들에게 짧게 공유하여 리스크를 체크한다.

• 컨텍스트 스위칭 방어막 및 리커버리 루틴 도입

  • 외부 요청으로 흐름이 끊겼을 때, 복귀 후 바로 코딩/설계를 하지 않고 '직전 작업 로그 5분 복기' 시간을 가져 컨텍스트를 빠르게 회복한다.

• 데이터 생명주기 도식화 우선순위 상향

  • 설계의 근거가 되는 데이터 흐름도(Data Flow) 작성을 내일 오전 최우선 순위로 배치하여 '체득 및 공유'의 토대를 마련한다.

• 2026년 연초 장애 대비 시나리오 작성

  • 파악된 3가지 크리티컬 이슈(날짜, 중복, 코드)를 기반으로 사람이 아닌 데이터가 판단할 수 있는 블랙박스 테스트 케이스를 구체화한다.

개인적으로 작성중인 회고 파일이 사내에서 확인이 어려워 계획한 내용이 회사에서 이어지지 않았다. 어쩌면 욕심에 너무 과한 업무 계획을 세우고 있는건 아닐지, 혹은 너무 추상적인 Try들이 아니였을지 돌아보는 시간이였다.

위 try에 대한 회고를 해보자면

• 매출 통합과 이상치 탐지의 물리적 업무 분리 매출 통합과 이상치 탐지에 대한 분리를 했다. 매출통합은 서비스 전체적인 영향도가 있기 때문에 임팩트는 확실히 크지만 연말/연초 이슈가 있기 때문에 타 부서간 협업이 원활하게 이뤄지지 않는다는 문제점이 있어 1달이라는 기간내로 수행하기에는 어려움이 있다는 결론을 내렸다.

• 컨텍스트 스위칭 방어막 및 리커버리 루틴 도입 오늘은 회의가 많은 날이였다. 기존에 업무일지를 obsidian으로 기록하고 있는데 노트북 환경이 컨텍스트 유지에 적절하지 않다는 생각을 했다. 슬랙 알림에 영향을 많이 받는 편이라 기록하다가도 흐름이 깨지는 모습이 있었다.

다소 불편하더라도 업무몰입을 위해 노트에 정리하는 습관을 가져야겠다.

• 기존 인프라 기반의 우회 전략 수립 및 빠른 싱크 | 데이터 생명주기 도식화 우선순위 상향 | 2026년 연초 장애 대비 시나리오 작성 위의 것들은 다른 일정으로 진행하지 못했거나 업무 우선순위를 재다보니 할 필요가 없어진 것들이다.

퇴근 전에는 팀원분과 함께 계획을 검토하는 시간을 가져봤다. 어젯밤 혼자 고민했던 내용에 대해 함께 이야기해보면서 impact에 대한 기준을 논해봤다.

주로 정리된 내용은 다음과 같았다.

• 매출데이터 통합은 1달내로 어려울것 같다. (연말/연초 - 타팀 디펜던시 이슈가 많음)
• 알림톡 이상치감지는 충분히 임팩트가 있을것이다.
  • 현재 주요 트래픽이 알림톡에서 발생하는 구조임.
  • 과거에 미발송중인 알림톡을 DB 보기전에 감지 못한적도 있고, 지금도 그런 알림톡이 없을것이라는 보장을 못하는 상황임.
  • 100% 사람의 확인에 의존중인 상황임.

Keep

잘 한점. 혹은 유지할만한점

• 팀원분과 따로 시간을 잡고 몰입해서 이야기하는 시간을 확보하면서 방향성을 구체화시켰다.
• 매출통합에 대한 미련(?)을 버릴 수 있었다. (우선순위 조정)
  • 중요하고 impact가 너무 크기때문에 장기적으로 챙겨가야할 목표.
  • 이상치감지가 일찍 끝난다면 내년초에 바로 진행할 수 있을 정도로 목표를 구체화시키려고한다.

Problem

문제점. 개선할점

• try 목표 설정 방식이 잘못되었다.
  • 업무 수행 시간을 고려하여 가능한 선의 계획을 세우자.
• 컨텍스트 스위칭이 너무 잦고, 목표에 대한 얼라인이 모호했다.
  • 문제를 정의할때 3번 이상 구체화를 시도해봐야겠다.
• 스케줄링 중앙화가 병목지점으로 인지되었다.
  • 휴먼에러가 발생할 여지는 있지만 적어도 현재 미탐지되고 있는 내용들에 대해서만큼은 커버하면서 내년에 마이그레이션을 할 수 있는 구조를 고안중이다. (batch 인프라 이관)

Try

새롭게 시도할점

• 현재 구성되어있는 알림톡 목록의 발송일자, 발송규칙을 정리한다.
• 각각의 이상치 탐지 기준을 정의한다.
• 1시간마다 발송 현황을 올리는 채널은 유지하면서 별도의 batch로 이상치 감지 패턴을 추가한다.

느낀점 및 자유로운 생각

작은 성공을 쌓아서 impact를 만들어야겠다. 한번에 다 하려니까 욕심이 과해서 하루에 명확하게 남는게 없어서 아쉽다.

알림톡 관리/이상치감지/휴먼에러 줄이기 이야기를 하다보면 결국 알림톡 관리 플랫폼이 하나 필요한게 아닌가? 라는 생각이 든다.

알림톡별로 메시지에 사용되는 어트리뷰트, 발송대상 등이 무수히 많은데 중복되는 어트리뷰트나 대상도 많이 있었다.

플랫폼 먼저보단 code가 문서가 되도록 중앙화해보는 것부터 진행해봐야겠다.