영문 리딩 결과 출력 형식 고도화

영문 사주 리딩 기능을 개발하면서 핵심 로직과 표현 계층을 명확하게 분리하고 연결하는 작업을 마쳤다. reading.ts와 humanizer.ts를 1층과 2층으로 구조화하면서 생긴 변화와, 팀 차원에서 배운 점을 정리해본다.

왜 층을 나눴나

처음엔 리딩 데이터 생성과 형식화를 한 곳에서 처리하는 게 빠를 줄 알았다. 하지만 실제로 작업하다 보니 문제가 생겼다. 리딩 계산 로직 자체는 복잡한데, 동시에 그 결과를 "사용자가 이해하고 행동할 수 있는 형태"로 만드는 것은 완전히 다른 작업이었다.

예를 들어:
- 계산 결과로 나온 0.8765 같은 점수를 "높음", "중간" 같은 의미 있는 표현으로 변환
- 여러 인사이트를 우선순위 순서대로 정렬하거나 일부만 강조해서 보여주기
- 기술적 설명을 간단한 문체로 다시 쓰거나 예시를 첨부하기

이런 것들을 코어 로직에 섞어두면 코드가 비대해질 뿐 아니라, 나중에 표현 방식만 바꾸려고 해도 계산 부분까지 건드려야 한다. 그래서 책임을 명확히 나누기로 결정했다.

1층과 2층의 역할

1층(reading.ts)은 순수한 리딩 데이터 생성에만 집중한다. 입력을 받아서 필요한 모든 계산을 수행하고 구조화된 결과를 반환한다:

// 1층: 순수 리딩 로직
const readingResult = generateReading(input);
// {
//   scores: { category1: 0.876, category2: 0.654, ... },
//   insights: ["insight A", "insight B"],
//   metadata: { calculatedAt: "...", version: "..." }
// }

2층(humanizer.ts)은 이 결과를 받아서 사용자가 실제로 봐야 할 형태로 변환한다. 숫자는 라벨로, 길이는 UI에 맞게, 구조는 읽기 쉽게:

// 2층: 표현 최적화
const humanized = humanizeReading(readingResult);
// {
//   summary: "높은 창의성을 보이고 있습니다",
//   categories: [
//     { label: "창의성", level: "높음", description: "..." },
//     { label: "분석력", level: "중간", description: "..." }
//   ]
// }

이렇게 분리하니 각 층은 자신의 일만 한다. 1층은 "정확한가"를 고민하고, 2층은 "사용자 경험이 좋은가"를 고민한다.

생긴 변화들

팀 관점에서의 영향

이 구조는 우리 팀의 다른 작업에도 영향을 미쳤다:

• 협업 경계가 명확해진다 — 백엔드는 1층(정확성)에, 프론트엔드는 2층 이후(UX)에 집중할 수 있다.
• 온보딩이 쉬워진다 — 새로운 리딩 기능을 추가할 때 junior 개발자도 "이건 계산 부분, 이건 표현 부분"을 구분하면서 자연스럽게 진행할 수 있다.
• 패턴 재사용 가능 — 다른 언어 버전을 추가하거나, 다른 콘텐츠 포맷(예: 앱용, 메일용, SNS용)을 만들 때도 이 두 층 구조를 따르면 된다.

특히 코드 리뷰할 때 "이 변경이 계산에 영향을 주는가, 아니면 표현만 바꾸는 건가"를 빠르게 판단할 수 있게 된 건 큰 수확이었다.

이번 작업을 통해 배운 것

이 커밋은 겉으로는 작은 기능 추가처럼 보이지만, 아키텍처 관점에서는 "책임 분리"를 실천한 사례다. 계층을 명확히 하고 경계를 지키면, 나중의 변경과 확장이 훨씬 자유로워진다. 비슷한 상황이 나올 때마다 이 패턴을 적용할 수 있다는 확신이 생겼다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 책상조명 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.