[PJ] 금융 레거시 시스템 연동을 위한 고정 길이 전문처리와 불변 객체 설계

1. 문제 제기 (Introduction & Problem Statement)

관찰 현상 또는 질문:
현대적인 웹 서비스는 대부분 JSON/REST 방식을 사용하지만, 금융권 코어 뱅킹이나 대외계 시스템(FEP)은 여전히 TCP 소켓 통신 기반의 고정 길이 전문(Fixed-Length Packet)을 표준으로 사용한다. 이 환경에서는 다음과 같은 기술적 제약과 요구사항이 발생한다.

1. 데이터 표현의 차이: Java의 String은 UTF-16 기반이나, 전문은 EUC-KR 인코딩과 바이트(Byte) 단위 길이를 엄격히 준수해야 한다.
2. 데이터 무결성(Integrity): 금전적인 트랜잭션을 다루는 객체(DTO)가 생성 후 변경 가능(Mutable)할 경우, 로직 중간에 의도치 않은 데이터 변조 위험이 있다.

탐구 목표:
본 문서는 EUC-KR 기반의 바이트 패딩(Padding) 로직을 처리하는 유틸리티(FieldUtil) 구현부터, 데이터 무결성을 보장하기 위한 Builder 패턴의 적용 과정을 다룬다. 특히 Setter를 배제하고 불변 객체(Immutable Object)를 생성하는 것이 금융 도메인에서 왜 필수적인지, 그리고 Builder 패턴 내부의 return this와 build() 메서드가 기술적으로 어떤 역할을 수행하는지 분석한다.

2. 기술 분석 및 핵심 원리 (Technical Deep Dive)

2-1. 기본 개념 및 배경지식

• 고정 길이 전문 (Fixed-Length Packet): 필드마다 정해진 바이트 길이(Length)를 가지며, 데이터가 짧을 경우 남은 공간을 특정한 값(공백 0x20 또는 숫자 0x30)으로 채우는 통신 방식.
• 불변 객체 (Immutable Object): 객체 생성 시점에만 값을 할당할 수 있으며, 생성 이후에는 내부 상태를 변경할 수 없는 객체. Multi-thread 환경에서 Thread-safe 하며 데이터의 신뢰성을 보장한다.
• Method Chaining: 메서드가 객체 자신(this)을 반환하여, 여러 메서드 호출을 하나의 문장처럼 연결하여 작성하는 코딩 기법.

2-2. 문제의 원인 및 동작 방식 분석

A. 바이트 변환과 패딩 (FieldUtil)

Java의 문자열 길이는 length()로 구하지만, 전문 통신은 바이트 길이가 기준이다. 특히 한글(EUC-KR)은 2byte를 차지하므로 단순 문자열 잘라내기는 데이터 손실(Half-byte)을 유발할 수 있다.

// 개선된 바이트 변환 로직 (FieldUtil)
public static byte[] toStrBytes(String value, int length) {
    byte[] rawBytes = value.getBytes(Charset.forName("EUC-KR"));
    byte[] result = new byte[length];

    // 1. 버퍼 전체를 공백(0x20)으로 초기화 (Loop 대신 Arrays.fill 사용으로 가독성/안정성 확보)
    Arrays.fill(result, (byte) ' '); 

    // 2. 데이터 복사 (길이 초과 시 Truncate, 미만 시 Padding 유지)
    System.arraycopy(rawBytes, 0, result, 0, Math.min(rawBytes.length, length));

    return result;
}

B. 불변성 확보를 위한 Builder 패턴 구현

일반적인 JavaBean 패턴(Setter)은 객체 생성 후 언제든 값이 변경될 수 있어 트랜잭션의 신뢰성을 떨어뜨린다. 이를 해결하기 위해 생성자 접근을 제한하고 Builder 패턴을 도입한다.

Builder 패턴의 핵심 매커니즘:

1. return this: 메서드 체이닝을 구현하기 위해 자기 자신(Builder 인스턴스)을 반환한다. 이는 연속적인 값 할당을 가능하게 하여 가독성을 높인다.
2. build(): 최종적인 객체 생성 메서드. 이 시점에 필수값 검증(Validation)을 수행하고, 검증이 통과된 경우에만 실제 객체(new TransferRequest(...))를 생성하여 반환한다.

public class TransferRequest {
    private final long amount; // final 키워드로 재할당 원천 봉쇄

    // private 생성자: 외부에서 직접 생성을 막음
    private TransferRequest(Builder builder) {
        this.amount = builder.amount;
    }

    public static class Builder {
        private long amount;

        // 값을 설정하고 'Builder 자신'을 반환 (체이닝 지원)
        public Builder amount(long amount) {
            this.amount = amount;
            return this; 
        }

        // 최종 객체 생성 (검증 + 불변 객체화)
        public TransferRequest build() {
            if (amount < 0) throw new IllegalArgumentException("Invalid Amount");
            return new TransferRequest(this);
        }
    }
}

2-3. 해결 방안 및 Trade-offs 비교

구분	Setter (JavaBean)	전체 생성자 (All-Args)	Builder 패턴
불변성(Immutability)	취약 (언제든 변경 가능)	우수 (final 사용 가능)	우수 (생성 시점 확정)
가독성(Readability)	보통	나쁨 (인자가 많으면 순서 혼동)	우수 (메서드 명으로 의도 표현)
안전성(Validation)	로직 분산됨	생성자 내부 복잡도 증가	build() 메서드에 집중 가능
구현 복잡도	낮음	낮음	높음 (별도 내부 클래스 필요)

결론: 구현 코드는 길어지지만, 금융 거래 데이터의 정합성과 유지보수성이 최우선이므로 Builder 패턴을 채택한다. 특히 인자가 많은 전문 DTO의 경우 전체 생성자 방식보다 Builder가 오용(Human Error) 가능성을 현저히 낮춘다.

3. 결론 및 고찰 (Conclusion & Takeaways)

핵심 요약:

1. 금융 전문 처리는 EUC-KR 인코딩과 바이트 단위 패딩을 정확히 처리하는 유틸리티(FieldUtil)가 필수적이다.
2. System.arraycopy와 Arrays.fill을 활용하면 루프보다 명확하고 안전하게 바이트 배열을 조작할 수 있다.
3. Setter는 데이터 변경 가능성을 열어두어 시스템의 복잡도를 높인다. 반면 Builder 패턴은 객체의 생성(Construction)과 표현(Representation)을 분리하여, 검증된 상태의 불변 객체만을 시스템에 유통시킨다.

기술적 통찰:
Builder 패턴에서 return this는 단순한 문법적 편의(Syntactic Sugar)를 넘어, 객체 설정 과정을 하나의 '흐름(Flow)'으로 만들어준다. 더 중요한 것은 build() 메서드다. 이 메서드는 단순한 객체 생성이 아니라, "이 데이터는 검증되었으며, 이제부터 절대 변하지 않는다"는 시스템적 보증 수표를 발행하는 관문(Gateway) 역할을 한다. 즉, 불변성은 단순한 코딩 스타일이 아니라 방어적 프로그래밍의 핵심 기법이다.

향후 과제:

• 현재는 PacketBuilder에서 수동으로 필드를 매핑하고 있다. Java Reflection과 Custom Annotation(@PacketField)을 도입하여, DTO 정의만으로 전문의 직렬화/역직렬화를 자동화하는 '전문 변환 엔진'으로 고도화할 필요가 있다.
• 단일 객체가 아닌 리스트(List) 형태의 반복부(Repeating Group) 데이터 처리에 대한 구조 설계가 필요하다.