제목, 태그, 카테고리로 검색

모든 태그

# EAI

2개의 글

전문·TCP와 JSON·REST 사이에 통역기를 세운 아홉 단계, 관문(gwanmun) 총정리

은행 계정계는 고정길이 전문(電文)과 TCP로만, 모바일 앱은 JSON과 HTTP REST로만 말합니다. 둘 다 못 고치니 가운데에 통역기를 세웁니다. 전문과 JSON을 변환하는 연계층, 그리고 그 통로를 지키는 API 게이트웨이층입니다. 이 글은 그 통역기를 목업 계정계까지 세워 직접 만든 9단계의 총정리입니다. 계정계를 실제로 죽여 서킷이 OPEN으로 열리고 503으로 격리하는 과정, RuntimeException 하나(풀 고갈)가 서킷을 열고 원장 4건을 증발시킨 감사 결함과 그 수정(503과 원장 완결), 부하가 서킷 stale 레이스를 staleResultsTotal=197로 실증한 기록, 한계 약 10~12k req/s와 게이트웨이 오버헤드 약 0.21ms, 죽은 백엔드에서 서킷 off 351 vs on 9,425 req/s, 같은 멱등키를 두 번 보내도 계정계 호출 1회에 원장 1행으로 이중거래가 0이었던 것까지 담았습니다. 전부 VERIFICATION에 명령과 출력이 남은 실측이고, 안 만든 것은 왜 안 만들었는지 적었습니다.

고정길이 전문 파서와 TCP 프레이밍을 손으로 짜며 배운 것, 바이트가 진실이다

은행 계정계의 고정길이 전문(電文)을 모바일 앱이 알아듣는 JSON으로, 그 반대로도 바꾸는 변환 엔진을 만들고(1부), 그 파서를 실제 TCP 소켓 앞에 세웠습니다(2부). 1부의 핵심은 하나입니다. 한글이 섞인 전문을 String.substring으로 자르면 깨진다는 것입니다. EUC-KR에서 한글 한 글자는 2byte라, 자르기도 패딩 제거도 전부 byte[] 위에서 해야 합니다. 필드 레이아웃을 어노테이션 스펙으로 선언하고 오프셋을 자동 계산해 byte[]↔DTO↔JSON을 양방향 변환하는 과정을, 왕복 무손실 테스트와 hex 덤프로 검증했습니다. 2부의 함정은 TCP가 바이트 스트림이라는 사실입니다. '고정 61byte 전문'이라도 소켓 read 한 번이 그걸 온전히 준다는 보장이 없습니다. 반쪽만 왔다가 나머지가 뒤에 오고(partial read), 두 전문이 붙어 오기도 합니다(뭉침). 필요한 바이트가 다 모일 때까지 버퍼에 누적한 뒤에야 한 전문으로 넘기는 프레이밍을 순수 java.net 소켓으로 직접 짜고, 목업 계정계 TCP 서버를 세워 REST→전문→TCP→전문→JSON 왕복을 실제 두 프로세스로 붙였습니다. 반쪽 도착 재조립을 테스트로 강제하고, 소켓을 타고 오간 진짜 hex를 화면과 curl로 남겼습니다.