쇼핑몰 주문을 ERP로 넘기는 연계 작업에서 이메일이 같은 고객코드를 찾아 붙이면 구현은 간단해집니다. 그러나 주소가 바뀌면 기존 고객을 찾지 못하고, 같은 주소가 여러 기록에 있으면 다른 고객의 주문으로 연결될 수 있습니다. 아래는 특정 회사의 사고 사례가 아닌 설명용 업무 장면을 바탕으로, 이메일을 어디까지 연결 근거로 쓸지 정리한 내용입니다. 같은 이메일과 같은 고객 사이의 간격ERP 고객코드는 개인 구매자뿐 아니라 법인 거래처나 청구 대상을 나타낼 수 있습니다. 쇼핑몰 회원번호는 로그인 계정의 식별자일 수 있으므로, 먼저 두 시스템에서 ‘고객’이 뜻하는 대상을 확인해야 합니다. 여러 구매 담당자가 한 법인 고객코드에 연결되는 구조라면 다대일 관계 자체는 오류가 아닙니다.대표메일을 여러 담당자가 ..

거래처 상품 목록을 엑셀로 정리해 ERP에 올리는 과정에서는 행 수가 맞아도 상품 연결이 어긋날 수 있습니다. 엑셀 원본의 00123이 업로드 과정에서 서식이 변경되어 123으로 바뀐 경우를 보겠습니다. 먼저 확인할 것은 누락 건수보다 상품코드가 어느 단계에서 숫자로 해석됐는지입니다. 화면의 표시와 실제 상품코드의 차이상품코드는 계산할 수량이 아니라 상품을 구별하는 식별자입니다. 기준정보에서 00123과 123을 다른 코드로 관리한다면 앞자리 0도 값의 일부입니다. 숫자로 변환하면 이 구분이 사라지므로, 숫자만 들어 있다는 이유로 숫자형을 선택해서는 안 됩니다.엑셀은 숫자처럼 보이는 입력에서 앞자리 0을 제거할 수 있습니다. 사용자 지정 서식 00000으로 숫자 123을 00123처럼 표시해도 저장값이..

ERP에서 거래처 주문을 수신하는 설명용 업무 장면입니다. 수신 목록에는 A사의 000417이 이미 등록돼 있고, B사 파일에도 000417이 들어 있습니다. 두 회사가 각자 번호를 발급한다면 별개의 주문일 수 있습니다. 이때 외부 주문번호 열에 단일 UNIQUE 제약조건이 걸려 있으면 B사 주문은 저장 단계에서 충돌합니다. PostgreSQL 18을 기준으로 거래처 코드를 키에 넣는 판단과 운영 전 확인 절차를 살펴봅니다. 주문번호 발급 주체와 재사용 범위먼저 연계 명세서와 원본 주문 샘플에서 번호를 누가 발급하는지 확인합니다. 중앙 주문 시스템이 모든 거래처에 걸쳐 번호의 유일성을 보장하면 UNIQUE (order_no)가 맞습니다. 이 경우 거래처별로 같은 번호를 허용하면 중앙 발급 규칙을 위..

Outlook 보안 업데이트를 배포한 뒤에는 실제 설치 빌드를 확인해야 합니다. 업데이트 전에 의심스러운 메시지 파일을 연 PC가 있다면, 당시 외부로 연결됐는지와 Windows가 NTLM 인증을 시도했는지도 살펴야 합니다. PC의 업데이트 설치 이력으로 취약점이 수정된 시점을 확인하고, 인증 로그로 그전에 인증정보가 노출됐을 가능성을 판단합니다. 사용자가 파일을 열 때 발생하는 Outlook 스푸핑 Microsoft는 CVE-2026-124194를 위험한 동작에 대한 경고가 빠진 Outlook 스푸핑 취약점으로 분류했습니다. 스푸핑은 여기서 다른 사용자로 가장하는 것을 뜻합니다. 영향받는 Outlook에서 사용자가 조작된 메시지 파일을 열고 네트워크 연결이 가능하면, O..

주문 조회 화면의 응답이 느려져 고객별 최근 주문을 찾는 쿼리에 인덱스를 추가하려고 합니다. 변경 작업은 조회를 위한 것이지만, 대상인 orders 테이블에는 신규 주문과 배송 상태 변경도 계속 들어옵니다. 배포 계획에는 조회 쿼리의 개선 여부와 함께 인덱스를 만드는 동안 주문 쓰기가 대기할 수 있는지도 적어야 합니다. PostgreSQL 18의 일반 테이블을 기준으로 구성한 설명용 업무 장면입니다. 일반 CREATE INDEX로 진행할 수 있는 시간대가 있는지, 쓰기를 유지해야 한다면 CONCURRENTLY를 어떤 조건으로 실행할지 살펴봅니다. 일반 생성과 동시 생성의 쓰기 잠금 차이 일반 CREATE INDEX는 테이블에 SHARE 잠금을 잡습니다. 일반 SELECT는 이 잠금과 충돌..

주문 상태를 자주 갱신하는 테이블에서 n_dead_tup이 계속 늘어납니다. 운영 담당자가 확인한 통계에는 최근 autovacuum 실행 시각이 남아 있습니다. 같은 DB에서 보고서 SQL은 끝났는데 트랜잭션이 idle in transaction 상태로 남은 세션도 보입니다. PostgreSQL 18을 기준으로 구성한 설명용 업무 장면입니다. 먼저 대상 테이블의 VACUUM 이력과 진행 단계를 확인합니다. 실행을 마쳤는데도 지울 수 없었던 행 버전이 로그에 남아 있다면, 그 시각에 오래된 트랜잭션이 유지되었는지 대조합니다. VACUUM이 실행돼도 이전 행 버전이 남는 이유 PostgreSQL은 UPDATE나 DELETE가 일어나도 이전 행 버전을 즉시 지우지 않습니다. 여러..

사내 AI 모델 서버가 127.0.0.1에서만 연결을 받더라도, 같은 서버의 리버스 프록시가 요청을 전달하면 외부에서 관리자 API에 닿을 수 있습니다. 리버스 프록시는 클라이언트 대신 백엔드에 연결해 요청을 넘기는 중계 서버입니다. GPUStack은 이 중계 연결을 로컬 요청으로 판단했을 때 로그인 없이 관리자 권한을 부여하는 경로가 있었습니다. 미국 사이버보안·인프라보안국(CISA)은 2026년 11월 9일 이 취약점을 실제 악용 취약점 목록(KEV)에 추가했습니다. GPUStack 공식 보안 권고 · CISA KEV 공식 미러 프록시 뒤에서 로컬로 보이는 요청 GPUStack은 AI 모델 배포와 추론을 관리하는 오픈소스 GPU 클러스터 관리 도구입니다. 2.2.0 미..

아침에 ERP 매출 현황을 열었는데 전날 집계가 아직 반영되지 않았습니다. 운영 담당자가 작업 이력을 열어 보니 일일 집계 배치의 실행 시간이 평소보다 길었습니다. 같은 시간대의 MySQL 슬로우 쿼리 로그에는 매출 테이블을 읽는 SQL이 여럿 보입니다. 이 중 어떤 문장이 일일 집계에 쓰였는지 알아야 다음 점검 대상을 정할 수 있습니다. 이 글은 ERP 운영을 바탕으로 구성한 설명용 업무 장면입니다. MySQL 8.4에서 배치 실행 이력과 슬로우 쿼리 로그를 대조해, 다음에 확인할 SQL을 좁히는 순서를 다룹니다. 배치 실행 이력으로 시간 범위 좁히기 스케줄러에서 지연된 실행 건의 실제 시작·종료 시각과 재시도 이력을 먼저 확인합니다. 재시도한 경우 실행 건별로 시간 범위를 ..

출고 마감에 앞서 주문 연동 담당자가 쇼핑몰에서 들어온 주문과 사내 주문 목록을 대조합니다. 쇼핑몰에는 접수 기록이 있는데 사내 목록에 아직 나타나지 않는 건이 있습니다. 재처리 화면에서 해당 주문을 다시 보내도 저장 응답이 늦어지면, 담당자는 앞선 등록 작업이 끝났는지부터 확인해야 합니다. 이 글은 주문 연동 운영을 바탕으로 구성한 설명용 업무 장면입니다. MySQL 8.4의 InnoDB에서 기다리는 등록 요청과 잠금을 보유한 작업을 연결하는 순서로 살펴봅니다. 주문 목록에 나타나기 전의 INSERT 연동 작업이 주문 행을 넣었더라도 트랜잭션을 아직 커밋하지 않았다면, 다른 연결의 일반 조회에서 그 행이 보이지 않을 수 있습니다. 트랜잭션은 관련 DB 변경을 묶어 확정하거..

구글 검색 결과에서 회사 홈페이지의 관리자 주소가 발견됐다고 가정해 봅시다. 서버 설정을 보니 robots.txt에 이미 Disallow: /admin/이 있습니다. 이때 먼저 열어 볼 것은 설정 파일보다 관리자 URL입니다. 로그아웃 상태에서 주소를 열었을 때 로그인 화면만 뜨는지, 관리자 전용 데이터까지 내려오는지에 따라 대응 순서가 달라집니다. 공개 파일에 적힌 수집 규칙 robots.txt는 검색 엔진 크롤러처럼 웹페이지를 자동으로 읽는 프로그램에 어느 경로를 수집할지 안내하는 공개 파일입니다. 예를 들어 아래 설정은 이 규칙을 따르는 크롤러에 /admin/으로 시작하는 경로를 가져가지 말라고 요청합니다. 이 파일을 수정해도 브라우저에서 같은 주소를 직접 요청했을 때 ..