문제

• 프론트 풀빌드에 약 5분 소요. 화면이 늘수록 느려지고, 청크 경계와 해시가 자주 바뀌어 재빌드 캐시가 거의 듣지 않음
• 폐쇄망이라 빌드 서버 증설이나 Vite 같은 신규 번들러 도입으로 우회 불가. 기존 Webpack 설정 안에서 풀어야 하는 조건

원인 규명

• 라우터 lazy-load에서 import 경로와 청크명을 변수로 조합하고 있었음
• Webpack은 경로를 정적으로 결정하지 못하면 context 모듈을 만들고, 해당 폴더에서 정규식에 걸리는 모든 후보 파일을 스캔하고 파싱해 번들 그래프에 올림
• 실제 라우팅되지 않는 화면까지 매 빌드마다 전부 빌드 대상이 되는 구조였음

조치

• 변수 조합 import를 라우트별 정적 경로로 전환해 context 모듈 생성 자체를 제거
• 변수가 섞인 청크명을 고정 webpackChunkName으로 통일해 청크 경계와 해시를 안정화. 변경되지 않은 청크는 캐시가 유지됨
• 동적 로딩이 실제로 필요한 지점은 화이트리스트 매핑 객체로 한정. 임의 문자열로 경로를 만들지 않게 해 정적 분석 가능성과 동적 요구를 함께 충족

왜 번들러를 바꾸지 않았나 라우팅 정의는 URL 계약이 아니라 내부 구성이므로, 정적화해도 외부 계약과 화면 동작이 바뀌지 않습니다. 금융 채널에서 동작 보존이 최우선인데 이 변경은 그 조건을 만족했습니다. 번들러 교체는 폐쇄망 반입 절차와 회귀 리스크가 큰 반면, 같은 효과를 설정 변경으로 얻을 수 있다면 그쪽이 옳다고 판단했습니다.

결과

• 풀빌드 5분대 → 1분대 (약 80% 단축), 해시 안정화로 재빌드 시간도 함께 감소
• Vue 담당 2명이 하루 5회 이상 빌드하는 환경 기준, 월 20영업일로 약 13시간의 대기 시간 절감
• ICT&디지털혁신본부 2025년 상반기 우수직원 선정

배경

• 공공마이데이터 수신 방식이 "매 요청마다 인증정보 동봉"에서 "전자서명 후 토큰 발급, 토큰 기반 묶음정보 수신"으로 변경
• 기존 조회 전문 4종에 토큰 적용 필요. 인증서 선택부터 서명, 발급까지의 흐름을 여러 상품 화면에 붙여야 하는 상황

핵심 설계: 오케스트레이터 래퍼

기존 인증 모달은 부모 컴포넌트의 특정 메서드를 직접 호출하는 구조라, 상품 화면마다 같은 코드를 복사해야 했고 성공과 취소가 같은 콜백으로 들어와 구분이 불가능했습니다. 그런데 이 모달은 이체 등 다른 흐름에서 이미 검증된 코드라 수정하고 싶지 않았습니다.

모달을 자식으로 직접 렌더하는 래퍼 컴포넌트를 만들어, 부모 계약을 래퍼가 단 한 번만 구현하게 했습니다.

• 상품 페이지는 래퍼를 배치하고 open() 호출과 @success / @fail 처리만 하면 됨. 모달의 존재 자체를 몰라도 되는 의존성 역전
• 성공, 취소, 실패를 각각의 이벤트로 분리해 호출부의 분기 실수 제거
• 인증 SDK 중복 콜백 방어 로직을 래퍼 한 곳에 집약해 모든 상품에 자동 적용
• 결과적으로 새 상품 추가가 메타 한 줄과 핸들러 추가로 축소

설계 결정 두 가지 더

환경별 키 관리를 VO 밖으로 요청 VO 안에서 프로파일 값을 직접 주입받는 구조는, new로 생성하면 null이 들어오고 직렬화에도 인프라 필드가 섞입니다. 환경별 키를 enum과 프로퍼티 컴포넌트로 분리하고 VO는 순수 데이터 컨테이너로 유지해, Spring 컨텍스트 없이도 단위 테스트가 가능하게 했습니다.

토큰 수명 주기 성공 시 클라이언트 저장소에서 삭제, 실패 시 재사용 가능하도록 보존하는 하이브리드 모델을 택했습니다. 별도 사용 여부 플래그를 두지 않고 토큰의 존재 자체를 유효 신호로 삼아 상태를 하나로 줄였습니다. 저장 키에는 사용자 식별 요소를 포함해 공용 기기에서의 교차 사용을 차단했습니다.

결과

• 조회 전문 4종 전환 완료. 기관 명세나 서명 포맷이 바뀌어도 한 파일 수정으로 전 상품 반영
• 기존 모달과 다른 인증 흐름은 무수정이라 회귀 리스크 최소화
• 특정 인증 경로에서 전자서명 원문이 반환되지 않던 원인을 서비스 계층 역추적으로 규명하고, 플래그 방식으로 기존 이체 및 본인확인 흐름에 영향 없이 해소
• 인증 SDK가 동일 서명 데이터로 콜백을 두 번 발화해 재전송이 거부되던 건을 중복 처리 가드로 차단

기록해 둔 것 개발 환경에서 토큰 미전송 시에도 정상 응답이 수신되어 신규 경로 적용 여부를 자체 검증할 수 없는 잔여 리스크를 확인하고, 기획 부서에 공식 공유했습니다.

• 여신거래 안심차단과 오픈뱅킹 안심차단 2개 유형의 신청, 조회, 해제 전 구간을 비대면 채널에 신규 구축
• 상품 가입 흐름의 약관 및 동의 절차에 안심차단 항목을 기존 동작 영향 없이 통합
• 작업 중 안심차단 약관 노출 분기가 특정 상품 코드에만 걸려 있어 신상품 추가 시 고지가 누락될 수 있는 구조를 발견. 상품별 분기 자체를 제거해 향후 신상품 추가 시 누락 리스크를 구조적으로 없앰
• 계좌 목록 조회에 오버 스크롤 기반 추가 로딩을 적용해 목록 규모 증가에 대응

왜 분기를 제거했나 버그를 고치는 방법은 두 가지입니다. 누락된 상품 코드를 분기에 추가하거나, 분기가 필요 없는 구조로 바꾸거나. 전자는 다음 신상품에서 같은 문제가 반복됩니다. 제도 대응 과제는 고지 누락이 곧 규제 리스크라 후자를 택했습니다.

문제 팝업과 공지 이미지를 등록할 때마다 개발자가 수동으로 파일을 반입해야 했고, 채널마다 이미지 서빙 방식이 달랐습니다.

시행착오와 최종 구조

1. 관리자 WAS에서 프론트 파일 서버 경로에 직접 쓰기 → 두 컨테이너가 서로 다른 망에 있어 파일시스템 접근 불가
2. SFTP 자동화 → 로컬은 성공했으나 개발 서버 아웃바운드 차단으로 실패. 더 근본적으로는 내부망 WAS가 DMZ로 SSH를 여는 구조 자체가 망 분리 원칙 위반이라 방화벽을 열어달라고 요청하는 것이 답이 아니라고 판단
3. 최종: 공유 스토리지에 저장하고 각 채널이 같은 마운트를 읽어 서빙. 망 경계 이동을 원천 제거

왜 방화벽 개통을 요청하지 않았나 2번은 기술적으로는 동작시킬 수 있었습니다. 하지만 그 경로가 열리면 이후 다른 기능도 같은 경로를 쓰게 되고, 망 분리 설계가 예외의 누적으로 무너집니다. 한 번 뚫은 구멍은 회수하기 어렵다고 봤습니다.

결과

• 현업이 관리자 페이지에서 직접 등록 가능해져 개발자 수동 반입 절차 제거
• 업로드와 서빙 API 표준 구현체를 스마트뱅킹에 선구현해 타 3개 채널이 참조 개발 가능하도록 제공
• 파일명 화이트리스트와 경로 정규화 검증으로 경로 조작 차단
• 채널 간 계약(파일명 규칙, 설정 키, 마운트 정책)을 문서화해 파트 내 공유

과정에서 정리한 것 MultipartFile.transferTo가 상대 경로를 컨테이너 임시 디렉터리 기준으로 해석하는 동작, 물리 저장 경로와 서빙 URL을 분리 설정해야 하는 이유, catch (Exception e)가 실제 IOException을 삼켜 원인 규명을 늦추는 패턴을 팀 컨벤션 문서에 반영했습니다.

설계 결정 두 가지

항목을 컬럼이 아니라 행으로 분기 1행에 50개 이상 컬럼을 두는 wide 테이블 대신 분기 마스터와 항목 상세 2테이블로 분리했습니다. 공시 항목 증감 시 ALTER가 불필요하고, 특정 분기에 상품별 표 자체가 없는 케이스를 행을 넣지 않는 것만으로 표현할 수 있습니다. 컬럼 방식으로는 "이 분기에는 그 표가 존재하지 않았다"는 상태를 나타낼 방법이 없습니다.

수치 컬럼 전량 VARCHAR 원본 표기에 -, N/A, 39.4%, 21,800%가 혼재합니다. 숫자 타입으로 변환하면 공시 표기가 훼손되므로 표기값 보존을 우선하고, 화면과 서버에서 합계나 증감률을 재계산하지 않는 원칙을 확립했습니다. 산술은 등록 시점에 수행하고 결과 문자열을 저장하는 방식으로 책임을 옮겼습니다. 금융 공시 데이터는 원천과 미세하게 어긋나는 순간 신뢰를 잃기 때문에, 계산 편의보다 표기 보존이 상위 원칙이라고 봤습니다.

이관 검증

• 41개 분기 556행을 수기 작성하지 않고 스크립트로 생성한 뒤 컬럼 수, 따옴표 짝, 분기별 항목 수를 자동 검증
• 이 과정에서 존재하지 않는 날짜, 열 밀림, 종료일 오타, 분기 간 데이터 복사 후 미수정 등 원본 데이터 오류를 다수 검출하고 교정 내역을 별도 문서로 정리
• 기간 표기 문자열만 예외적으로 분기 코드 기준 서버 생성으로 전환해 날짜 오타 재발을 구조적으로 차단

후속 개선 매퍼를 수동 목록에 등록하는 방식은 등록을 빠뜨려도 빌드가 성공해 배포 시점까지 드러나지 않습니다. 디렉터리 패턴 기반 자동 스캔으로 전환해 누락 자체가 불가능하도록 구조를 바꿨습니다.

제약 운영 중인 금융 앱이라 CSS, 화면 동작, API 계약을 바꿀 수 없는 상태에서 스크린리더 대응만 추가해야 했습니다. 접근성 개선이 시각적 회귀를 만들면 그 자체가 더 큰 문제가 됩니다.

대표 사례 두 건

선택 상태가 스크린리더에 전달되지 않던 문제 Vue 2는 aria-pressed를 불리언 false로 바인딩하면 속성을 DOM에서 제거합니다. 미선택 버튼에 속성이 아예 없으니 스크린리더가 토글 버튼으로 인식하지 못했고, 클릭 시 변화도 "속성 없음 → 속성 생김"이라 상태 변경으로 읽히지 않았습니다. 문자열 바인딩으로 전환해 속성이 항상 렌더링되도록 정정하고 14개 카테고리 전체에 적용했습니다. 버튼 역할이 아닌 요소에 잘못 부여된 속성도 함께 제거했습니다. 적용 전 CSS 셀렉터를 전수 확인해 aria-pressed를 참조하는 스타일이 없음을 검증했습니다.

CSS 가상요소로 그려진 아이콘의 대체텍스트 ::after로 그려진 아이콘은 대체텍스트를 부여할 방법이 없습니다. 컨테이너 맨 앞에 화면에서만 숨겨지는 텍스트를 삽입해 읽기 순서를 자연스럽게 만들었고, CSS는 한 줄도 수정하지 않았습니다. FAQ 화면 72개 항목에 일괄 적용.

결과 심사 지적 웹 영역 전건 대응, 1차 심사 통과. 공통 유틸 수정 범위는 타 팀 담당과 분리해 회귀 위험을 관리했습니다. 2027년 인증 갱신을 목표로 잔여 항목을 계속 대응 중입니다.

발견 그룹 행사 연계 이벤트로 타 금융사 앱 배너에서 저축은행 제휴 페이지로 진입시키는 연동을 준비하던 중, 상대사가 폐기된 구 경로를 진입 URL로 인지하고 있다는 사실을 확인했습니다. 금년부터 해당 제휴 진입은 단일 엔드포인트로 통일된 상태였습니다. 그대로 오픈했다면 배너 클릭이 오픈일에 바로 오류로 드러났을 상황입니다.

판단 우리 쪽에서 구 경로를 다시 열어 맞춰줄 수도 있었습니다. 그러면 폐기 대상 경로가 이벤트 트래픽 때문에 되살아나면서 레거시가 고착됩니다. 진입점을 하나로 유지해야 이후 인증, 채널 식별, 로깅 지점을 한 곳에서 관리할 수 있다고 보고, 상대 쪽 호출 URL 정정을 요청하는 방향을 택했습니다.

커뮤니케이션 방식 "틀렸다"로 시작하면 협의가 길어집니다. 상대사 앱에서 저축은행으로 진입하는 기존 경로 3건을 전수 확인해 모두 신규 경로로 동작 중임을 먼저 확보한 뒤, 그 현황을 근거로 정정 요청을 보냈습니다. 우리 주장이 아니라 확인된 사실이 되면 왕복이 줄어듭니다. 여기에 우리에게만 당연했던 환경별 도메인 규칙까지 문서화해 함께 전달해, 개발 테스트 단계에서 다시 물어볼 일을 미리 없앴습니다.

배운 점 우리 쪽에서 규격을 정리했더라도 그 사실이 상대에게 전달되지 않으면, 계약이 어긋난 채로 오픈일에 드러납니다. 상대가 인지하고 있는 규격이 최신인지 확인하는 절차 자체가 개발만큼 중요합니다.

• LLM 통제형 코치: 모델이 자유롭게 조언하게 두지 않고, 서버가 허용한 행동 집합만 설명하도록 경계를 뒀습니다. 생성형 모델을 그대로 신뢰하면 농업 의사결정에 근거 없는 조언이 섞일 수 있습니다
• 폴백 우선 설계: LLM 장애나 예산 초과 시에도 정적 코치가 동작합니다. 외부 의존이 있는 기능은 그것이 없을 때의 동작을 먼저 정의해야 한다고 봤습니다
• 책임 경계 명시: 자체 예측은 참고 정보이고 공식 가뭄 예경보가 항상 우선한다는 원칙을 UI와 문서에 고정했습니다. 공공 데이터를 재해석하는 서비스는 이 경계를 흐리면 안 됩니다
• 개인정보 최소 수집: 회원가입과 로그인이 없고, 주소 원문과 지역 설정을 서버에 저장하지 않습니다. 수집하지 않으면 지킬 것도 없습니다
• 모노레포와 공용 계약: 웹과 Android가 OpenAPI 계약 패키지를 공유해 클라이언트 2종의 스펙 불일치를 구조적으로 차단했습니다. 실무에서 채널마다 계약이 어긋나는 비용을 겪어 본 경험이 반영된 선택입니다

구성 apps/web (Next.js, Vercel Route Handler API), apps/android (Kotlin, Jetpack Compose), packages/contracts (웹과 Android 공용 OpenAPI 계약), packages/llm (LLM 서버 경계와 정적 폴백), infra/supabase (PostgreSQL 마이그레이션과 테스트)