ax-acryl 인터페이스를 실제 비즈니스 흐름에 맞춰 재설계
목차
ax-acryl 모듈의 HTML 인터페이스를 실제 운영 환경의 데이터 흐름에 맞춰 재설계했다. 초기 구현은 기본 스펙으로 만들어진 것이었다면, 이번 v2는 Jonathan/NADIA·상장 IR·칩 플로우라는 구체적인 비즈니스 요구사항을 반영하면서 발생한 여러 갭을 메꾸는 작업이었다.
왜 v2가 필요했나
프로토타입이나 초기 스펙 기반으로 구축한 시스템이 실제 데이터와 만나면 항상 뭔가 맞지 않는 부분이 생긴다. 컬럼 순서가 이상하거나, 특정 값의 포맷이 안 맞거나, 조건부로 표시되어야 하는 필드가 있거나. ax-acryl도 마찬가지였다. v1은 "시스템이 정의한 데이터 구조"를 그대로 보여줬다면, v2는 "실제 비즈니스 운영자들이 보고 싶은 형태"로 UI를 재정렬해야 했다.
단순히 HTML 마크업을 고치는 것처럼 보이지만, 뒤에는 여러 팀과의 협의가 숨어 있다. Jonathan/NADIA·상장 IR·칩 플로우라는 컨텍스트는 이 시스템이 다루는 데이터의 성격과 사용 패턴을 말해준다. 각 단계마다 특정 정보가 우선되어야 하고, 그 우선순위는 비즈니스 로직과 직접 연결되어 있다.
프론트엔드 정렬, 백엔드 영향
변경 파일이 ax-acryl/index.html 하나뿐이라는 건, 충분히 신중하게 설계했다는 뜻이다. API 응답 구조를 바꾸지 않고, 받아온 데이터를 재해석하는 방식으로 문제를 풀었다는 의미다. 이건 중요한 선택이다.
| 관점 | 고려사항 | v1 결정 | v2 검토 |
|---|---|---|---|
| API 변경 | 백엔드 리팩토링 비용 | X 필요 없음 | ✓ 피함 |
| 필드 순서 | UI 레이아웃 | 데이터 정의 순서 | 비즈니스 우선순위 |
| 조건부 표시 | 런타임 로직 | 기본값으로 모두 표시 | 특정 조건에서만 표시 |
| 배포 영향 | 다른 시스템 영향도 | 높음 | 낮음 |
HTML 변경만으로 끝낼 수 있다는 건, 프론트엔드와 백엔드 계약(contract)이 이미 충분히 유연했다는 뜻이기도 하다. 누군가 초기 설계할 때 "데이터 구조는 최소한의 변경으로 UI는 다양하게 표현할 수 있게" 해둔 것 같다.
버전 나누기의 의미
코드베이스에서 v1, v2를 나누는 패턴은 팀 차원에서 중요한 신호다.
- v1: "스펙을 만족하는 기본 구현"
- v2: "실제 운영 피드백을 반영한 개선판"
이건 단순한 마이너 버전 범프가 아니라, "이 모듈은 이제 실제 환경에서 사용되고 있고, 거기서 나온 요구사항들을 수렴했다"는 신호다. 향후 이 파일의 이력을 추적할 때도 "언제부터 실데이터 맞춤이 시작됐다"는 기점이 된다.
협업 흐름에서 배운 점
Jonathan/NADIA·상장 IR·칩 플로우라는 이름들이 들어간 건, 여러 팀의 의견이 이 변경에 반영되었다는 의미다. 운영팀, 비즈니스팀, 데이터팀이 각각 "이 정보가 먼저 보여야 한다", "이 필드는 항상 함께 나타나야 한다" 같은 요청을 했을 것이다.
이런 식의 변경을 할 때 실수하기 쉬운 부분:
- 모든 의견을 다 반영하려다가 인터페이스가 복잡해지기
- 한 팀의 요구사항만 우선하다가 다른 팀에서 불만이 나오기
- "다음에 개선하자"고 미루다가 계속 개선이 안 되기
v1→v2 단계에서 중요한 건, "이번에는 이 흐름(Jonathan/NADIA·상장 IR·칩 플로우)에 포커스를 맞춘다"는 명확한 결정을 하는 것이다. 모든 요구사항을 다 담을 순 없으니까.
코드리뷰 포인트
이런 UI 변경은 코드 리뷰를 할 때 다음을 체크해야 한다:
<!-- 변경 전 (v1): 데이터 구조 순서대로 -->
<div>정의된필드1</div>
<div>정의된필드2</div>
<div>정의된필드3</div>
<!-- 변경 후 (v2): 비즈니스 우선순위 순서로 -->
<div>핵심필드</div>
<div>검증필드</div>
<div>부가필드</div>
- 데이터 소스는 여전히 같은가? (API 응답 구조 변경 없음)
- 모든 필드가 여전히 렌더링되는가?
- 조건부 렌더링이 정확한가?
- 반응형 레이아웃에서도 정렬이 깨지지 않는가?
마지막 포인트가 특히 중요하다. HTML 순서 변경이 CSS와 맞지 않으면, 특정 화면 크기에서 레이아웃이 깨질 수 있다.
다음 고민
v2가 나왔다는 건 좋지만, 피해야 할 함정이 있다. "v2에서 충분히 개선했으니 이제 안정적이다"고 생각하고 방치하는 것. 실제로는 운영팀에서 v2를 써보면서 새로운 요청이 또 들어올 가능성이 크다.
그때 선택지는:
- v2.1로 작은 개선: 같은 버전 내에서 마이너 조정
- v3으로 다시 설계: 구조적 변경이 필요하면
- 플래그로 옵션화: 사용자 선택지를 만들기
어떤 선택을 하든, "왜 이 순서를 유지하는가", "어느 팀의 요구사항인가"를 명확히 하는 게 중요하다. ax-acryl/index.html 한 파일이지만, 그 뒤에는 여러 비즈니스 의사결정이 녹아 있기 때문이다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.