onaeonae1

들어가는 글벌써 2025년이 끝나가고 있다.이에 따라 올해 내가 일을 하면서 어떤 선택을 했고, 그에 따른 결과가 어땠는지 정리해보고자 한다.개인적으로 올해는 폭발적인 기술 성장보단 어떤 환경에서 어떤 개발을 하고 싶은지 커리어를 정리하는 한 해가 되었다고 생각된다.일보안 회사 근무(~3월)작년 7월부터 예전에 산업기능요원으로 다니던 회사에서 근무를 하고 있었다.해당 회사에서 내가 맡았던 부분들은 ASM 솔루션 개발이다.팀 내에서는 Python으로 작성된 정보수집/공격 자동화 엔진 개발 쪽으로 간략히 정리하면 다음과 같다.Python 으로 작성된 정보수집/공격 자동화 엔진 고도화MSA 에서 서비스 - 엔진 간 Event-Driven Task OrchestrationDebezium을 통해 MSA 에서 읽기..

들어가는 글본 글에서는 실제 구현에 대해서는 다루지 않고 설계하면서 집중했던 부분들만 공유한다(코드,구현 X)배경회사에서 현재의 서비스를 B2B 에서 B2C 로 확장하고자 한다.기존에는 B2B 계약을 통해 서비스를 허용해주고 있었는데, 이제는 이를 일반적으로 어떤 사용자든 쉽게 구독하고 사용할 수 있도록 변경하는 것이 주요 목적이다. 따라서 카드를 등록하고, 등록된 카드로부터 정기결제, 구독을 갱신해가며 이용할 수 있는 서비스로 바꾸는 과정에서 고려한 사항들을 공유한다즉 요약하면 다음과 같다.[기존] B2B 계약(B2B 승인/권한 부여) 로 서비스 이용 가능[변경] 누구나 가입 → 무료 구독 자동 부여 → 카드 등록 → 정기 결제 기반으로 갱신[목표] 구독 상태 하나만으로 접근 제어/결제/이탈 모두를 표..

Java HashMap, HashTable, ConcurrentHashMap 을 찾아보다가 간단히 정리Java의 HashMap & Python dictJava에서 HashMap의 대표적인 특성은 두 가지로 요약됨.synchronized 처리가 안 된다 → 멀티스레드 환경에서 thread-safe 하지 않음.key와 value에 null을 허용됨Python의 dict 역시 이 두 특성과 매우 유사하다.파이썬의 dict도 key/value에 None을 자유롭게 넣을 수 있음멀티스레드 환경에서 안정성을 보장하지 않는다.(안전하게 쓰고 싶으면 직접 Lock을 써야 한다.)이때 다음과 같은 질문이 나올 수 있다. “파이썬에는 GIL이 있는데, 멀티스레드 안정성 문제는 의미 없는 거 아닌가?”결론부터 말하면 아니다..

최근 업무에서 몇 차례 IDLE한 상황이 있었다.회사 상황이나 기획 일정 등의 이유로 생긴 빈 시간이었지만, 오히려 그 시간을 겪으며 여러 가지를 생각하고 바꾸게 되었다..IDLE 상태란 무엇인가?일단 내가 말하는 ‘IDLE 상태’는 단순히 “할 일이 없는 시간”이 아니다.더 정확히 말하면 업무의 흐름이 멈춰 있고, 내가 다음 액션을 취할 수 없는 상태를 의미한다.구체적으로는 아래와 같은 상황들을 포함한다.할당된 업무가 모두 끝난 상태신규 기획, QA 결과, 추가 요구사항을 기다리는 동안 시간이 비는 경우.파트 간 의존 때문에 더 진행할 수 없는 상태예를 들어 백엔드 구현은 끝났지만 프론트엔드 작업이 끝날 때까지 기다려야 하는 상황처럼, 내가 할 수 있는 범위는 모두 끝난 경우.기획이나 QA 리소스 부..

본 글은 과거 러프하게 작성한 글을 보강한 것이다. 새로 합류한 회사에서는 두 가지 성격이 다른 메시징 기능이 필요했다.경영성과 분석 서비스(이하 성과 서비스) → 매일 아침 성과 요약 리포트를 받아보고 싶은 수요재고/SCM 서비스 → 협업 과정에서 발생하는 이벤트를 실시간으로 공유하고 싶은 수요두 기능은 모두 “알림”이지만, 처리 방식과 요구사항이 전혀 달랐다.그래서 메시징을 하나로 뭉개기보다는 Batch 메시징과 Event 메시징을 분리해서 설계했다.이 글은 그 중에서,성과 서비스에서 사용한 Batch 메시징 설계에 대한 이야기(1편)이다.1. Batch 메시징이 필요했던 배경성과 서비스에서는 매일 새벽에 Batch Job이 돌아가 고객사의 매출·마케팅 등의 지표를 수집하고,이를 기반으로 여러 종류의..

배경현재 업무에서는 import_module 을 통해 다양한 플러그인들을 동적으로 import 하여, 사용자의 입력을 검증하는 부분이 존재한다.이때 구체적으로는 각 플러그인 별 validate 함수를 호출하는 방식으로 처리된다.이러한 validate 함수는 사용자가 어떤 요청을 "생성" 하는 시점에 호출되며 [중복됨, 입력 불충분, ] 과 같은 응답을 제공한다. 문제 사항과거에 validate 는 사용자가 특정 요청을 "생성" 하는 경우에만 필요했다.기획 변경에 의해 "생성", "수정", "재생성"의 시점 모두에서 validate 를 필요로 하게 되었다.따라서, action_type 이라는 optional parameter가 전달 -> 각 플러그인 단에서 validate 로직을 재작성 할 필요가 생겼다..