모두의 개발 블로그

형상 관리와 소스 관리, 그리고 CI까지

1. 왜 형상 관리 시스템을 다시 정리했는가개발 조직에서 형상 관리(Source / Configuration Management) 는단순히 “코드를 저장하는 도구”가 아니다.협업 방식배포 전략장애 대응보안 정책비용 구조까지 모두 연결된다.이 글은GitHub / GitLab / Bitbucket을 실제 운영 관점에서 비교하고,Jenkins 기반 CI 연동까지 포함해 정리한 실무 기준 기록이다.특정 회사나 프로젝트가 아니라,일반적인 개발 조직에서 충분히 겪을 수 있는 선택지를 기준으로 정리했다.2. 형상 관리 vs 소스 관리먼저 개념부터 짚고 간다.소스 관리(Source Control)→ 코드의 버전 관리 (Git, SVN 등)형상 관리(Configuration Management)→ 코드 + 설정 + 빌드..

ERP(Ecount 계열) API 연동 개발 정리

ERP(Ecount 계열) API 연동 개발 정리— 거래처 등록 / 입하 등록 자동화 구현 경험1. 정리 배경사내 MES 또는 관리 시스템에서외부 ERP 시스템과 데이터를 연동해야 하는 요구는 매우 흔하다.그중에서도 자주 등장하는 시나리오는 다음과 같다.거래처 정보를 ERP에 자동 등록입하(자재 수불) 데이터를 ERP로 전송엑셀/수기 입력 제거“이미 전송된 데이터”의 중복 처리 방지이 글은ERP(Ecount 계열) Open API를 활용해거래처 등록과 입하 등록을 연동 구현하면서 정리한 실무 개발 흐름과 주의점을기술 블로그 형태로 정리한 기록이다.2. 전체 구조 개요연동 구조는 다음과 같은 흐름을 가진다.사내 화면(스프레드시트/그리드)에서 데이터 관리사용자가 “ERP 저장” 버튼 클릭체크된 행만 대상으로..

Kafka 기반 데이터 이관 실행 계획 정리

1. 정리 배경대용량 PostgreSQL 데이터를 Oracle로 이관하면서,단순한 “이론적 설계”가 아니라 실제 실행 단계에서 필요한 준비·순서·주의사항을명확히 정리할 필요가 있었다.Kafka + Debezium 기반 CDC 구조는구성 요소가 많고, 순서를 잘못 잡으면 장애나 데이터 정합성 문제가 발생하기 쉽다.이 글은 실제 운영 환경을 일반화하여 재구성한 Kafka 실행 계획과 체크리스트를기술 블로그 형태로 정리한 것이다.2. 전체 실행 흐름 요약Kafka 기반 데이터 이관은 다음 흐름으로 진행된다.PostgreSQL DB 백업백업본 외부 저장Kafka 및 관련 컴포넌트 설치Kafka를 통한 초기 데이터 이관 실행이관 결과 검증기존 데이터 정리실시간 CDC 이관 전환핵심은“백업 → 일괄 이관 → 검증 ..

AWS 비용 최적화와 인프라 선택에 대한 현실적인 고민

— 클라우드, 내부 서버, IDC를 비교하며 정리한 판단 기준1. 왜 이 글을 정리하게 되었나AWS를 운영하다 보면 언젠가 다음 질문에 도달한다.“지금 구조가 정말 비용 대비 적절한가?”“트래픽이 크지 않은데 클라우드를 계속 써야 할까?”“온프레미스나 IDC가 더 나은 선택일 수도 있지 않을까?”이 글은실제 운영 데이터를 기반으로 비용 최적화를 고민하면서,AWS · 내부 서버 · IDC 인프라를 비교 검토한 사고 과정을 정리한 기록이다.특정 회사나 고객사의 내부 자료가 아니라,일반적인 중소·중견 규모 서비스에서 충분히 겪을 수 있는 상황을 일반화한 내용이다.2. 전제 조건 (일반화)트래픽은 크지 않으며 급격한 변동도 드묾API 서버 위주의 구조컨테이너 기반(ECS/Fargate 유사)무중단 배포는 필요하..

현실적인 프로젝트 구조 설계 고민

현실적인 프로젝트 구조 설계 고민— 온프레미스 전환을 가정한 두 가지 시나리오 정리1. 정리 배경클라우드(AWS) 기반 시스템을 운영하다 보면,비용·보안·운영 복잡도 문제로 인해 한 번쯤은 이런 질문을 하게 된다.“이 구조를 온프레미스로도 운영할 수 있을까?”“클라우드를 걷어내면 실제로 어디까지 감당 가능한가?”“비용을 줄이기 위해 감수해야 하는 리스크는 무엇인가?”이 글은AWS 의존 구조를 온프레미스 환경으로 옮긴다고 가정했을 때의현실적인 프로젝트 구조 시나리오와 그 한계를 정리한 기록이다.실제 특정 회사나 고객사 환경이 아니라,일반화된 시스템 구조를 기반으로 한 사고 실험에 가깝다.2. 전제 조건PDA / Mobile / Admin 성격의 서버가 분리되어 있음각 서버는 HTTP API 기반으로 통신인..

AWS 비용 최적화 실무 정리

1. 정리 배경AWS를 운영하다 보면 어느 순간 이런 질문에 도달한다.리소스를 줄여도 괜찮은가?비용을 줄이면서도 안정성은 유지할 수 있는가?트래픽이 크지 않은 서비스에서 Blue-Green 배포는 과한가?이 글은ECS Fargate + ALB 기반 서비스 운영 경험을 바탕으로,실제 사용률을 근거로 비용 최적화를 고민한 과정과 판단 기준을 정리한 기록이다.특정 고객사나 서비스의 내부 정보가 아니라,일반화된 운영 시나리오와 사고 흐름에 초점을 맞췄다.2. 관찰된 운영 환경 (일반화)ECS 서비스 다수 운영모든 서비스에서CPU 사용률: 지속적으로 낮은 수준메모리 사용률: 여유 있음트래픽 급증 거의 없음무중단 배포 필요성은 있으나,대규모 트래픽을 전제한 구조는 아님즉,“항상 2개 이상의 Fargate 태스크를 ..

Spring Batch 기반PostgreSQL → Oracle 데이터 이관 설계 구상안 정리

Spring Batch 기반PostgreSQL → Oracle 데이터 이관 설계 구상안 정리1. 작성 배경대용량 PostgreSQL 테이블의 데이터를 Oracle로 이관해야 하는 상황에서,**단순 일회성 마이그레이션이 아닌 “운영 중에도 안정적으로 이어갈 수 있는 구조”**가 필요했다.특히 다음과 같은 조건이 있었다.수백만 건 이상의 대용량 테이블이관 중에도 신규 데이터가 지속적으로 INSERT서버 중단 / 오류 발생 시 중단 지점부터 재개 가능데이터 정합성 및 누락 여부를 명확히 확인 가능해야 함이 글은 해당 요구사항을 바탕으로 Spring Batch 기반 데이터 이관 구조를 어떻게 설계했는지에 대한 구상 정리이다.2. 구상안 요구 조건데이터 이관 진행 상황을 기록할 로그 테이블 신규 생성서버 재기동,..

Kafka 기반 데이터 이관 트러블 슈팅 정리

— 실환경에서 실제로 해결한 사례만 기록서론Kafka 기반 데이터 이관 및 CDC(Change Data Capture) 환경을 운영하면서문제는 반드시 발생한다.중요한 점은“이론적으로 가능한 해결책”이 아니라,“실제 운영 환경에서 검증된 해결 방법” 이다.이 글에 정리한 내용은 다음 기준을 따른다.실제 운영 환경에서 직접 겪은 문제재현 가능했고, 적용 후 정상 동작을 확인한 해결 방법추측이나 미검증 방법은 배제본 글은 문제 발생 시 빠르게 원인을 파악하고, 재발 방지를 돕기 위한 실무 기록이다.목적Kafka 기반 데이터 이관 과정에서 발생한 주요 트러블 정리문제 원인을 구조적으로 분석재현 가능하고 검증된 해결 방법 문서화향후 유사 장애 발생 시 빠른 대응을 위한 레퍼런스 확보1. Kafka 로그 프로세스 ..

Kafka를 배우면서 가장 힘들었던 점 – 개념이 아니라 ‘맥락’이었다

1. 개념은 이해했는데, 왜 확신이 생기지 않았을까Kafka의 기본 개념 자체는 난이도가 아주 높다고 느끼지는 않았다.문제는 자료의 성격이었다.같은 질문이라도A 관점에서 물으면 A가 정답처럼 보이고B 관점에서 물으면 B가 또 정답처럼 보였다.둘 다 틀렸다고 말할 수는 없는데,어느 쪽이 “지금 상황에서의 사실”인지는 판단하기 어려웠다.AI를 통해 학습하면서 이 현상은 더 강해졌다.답변은 항상 논리적으로 맞는 것처럼 보였지만,그 답이 전제 조건을 포함한 답인지,아니면 일반론인지 구분하기가 쉽지 않았다.결과적으로이해는 한 것 같은데, 확신은 전혀 생기지 않는 상태에 머물렀다.2. Kafka 자체보다 더 무거웠던 것은 ‘사용되는 맥락’Kafka를 사용하는 대부분의 사례는대규모·대용량 데이터를 전제로 한다.내가 ..