t/h.TAEHYEON
PORTFOLIO
프로젝트 목록PROJECT / CASE STUDY

회사 프로젝트 · 엔젠바이오/2022.08 — 2023.02

조직적합성 변이 분석 시스템 프론트엔드 개발.

HLA 변이검출 플랫폼 — 회사 첫 프론트엔드 개발자로 만든 기반

담당 역할회사 첫 프론트엔드 개발자 · 1인 개발 — UI 기획, 퍼블리싱, 상태 관리, 컴포넌트 구조 설계
회사 · 기간엔젠바이오 SW 개발팀 · 2022.08 — 2023.02 (7개월)
도메인HLA 유전자 변이 기반 조직적합성 분석
프론트엔드Next.js · React · TypeScript · Material UI
상태 관리Redux Toolkit
개발 환경 · 테스트ESLint 코드 기준 · MSW 모의 API · Cypress
Panel 설정 — 유전자·Exon 선택 화면

01 / OVERVIEW

어떤 프로젝트인가요?

HLA 유전자 변이를 기반으로 조직적합성을 분석하는 의료 소프트웨어의 프론트엔드를 개발했습니다. 회사에 프론트엔드 개발자가 없던 시점에 첫 개발자로 합류해, 기술 선택부터 화면 기획과 구현까지 프론트엔드의 처음을 만들었습니다. 패널 설정부터 분석 결과까지 이어지는 검사 흐름을 화면으로 완성하는 동시에, 이후 합류할 개발자가 바로 일할 수 있는 개발 기반을 만드는 것이 핵심 과제였습니다.

02 / DEEP DIVE

핵심 기능 집중 소개

01

제로베이스에서 기술 스택과 개발 환경 구축

어떤 고민이 있었는가

  • 회사의 첫 프론트엔드 개발자였기 때문에 참고할 사내 컨벤션도, 물어볼 선임도 없었습니다. 게다가 백엔드 API보다 화면 개발이 먼저 시작되는 일정이라, API 없이도 화면을 만들 방법이 필요했습니다.

어떻게 해결했는가

MSW 모의 API — 화면 코드는 그대로 두고 Service Worker가 요청을 가로채 모의 응답을 돌려줌. 백엔드가 준비되면 핸들러만 제거
  1. Start: 화면 컴포넌트가 API를 호출한다. 백엔드보다 화면 개발이 먼저 시작되는 일정이었다.
  2. 개발 환경에서는 MSW(Service Worker)가 요청을 가로채, 등록된 핸들러가 있으면 모의 응답을 돌려준다.
  3. 핸들러가 없거나 운영 환경이면 실제 백엔드로 보낸다. 화면 코드는 두 경우를 구분하지 않는다.
  4. 백엔드 API가 준비되면 핸들러를 빼기만 하면 된다. 이 환경은 다음 프로젝트(유전체 검사·분석 시스템)로 이어졌다.
  • React · Next.js · TypeScript 스택을 선정하고 ESLint 규칙을 구성해, 이후 합류할 사람도 같은 기준으로 코드를 쓰도록 했습니다.
  • MSW로 모의 API 환경을 구축했습니다. 화면 코드는 실제 경로로 요청하고, 개발 환경에서는 Service Worker가 가로채 모의 응답을 돌려주며, 백엔드가 준비되면 핸들러만 빼면 됩니다.

결과적으로

  • API가 없어도 화면 개발이 진행되는 환경을 만들었고, 이 스택과 환경은 다음 프로젝트(유전체 검사 · 분석 시스템)의 출발점이 됐습니다.
02

패널 설정부터 분석까지 전체 컴포넌트 계층 설계

어떤 고민이 있었는가

  • 전담 디자이너 · 기획자 없이 개발자가 UI 기획까지 맡아야 했고, 검사 설정과 분석 화면은 위계가 깊고 상태가 많은 구조였습니다.

어떻게 해결했는가

  • 전체 화면을 직접 기획하고, 조직 패널 설정 → 유전자 · 임계값 구성 → 분석 결과까지 이어지는 컴포넌트 계층을 먼저 설계한 뒤 Material UI로 구현했습니다. 같은 입력 · 표 · 패널 요소는 공통 컴포넌트로 묶어 화면마다 다시 만들지 않았습니다.

결과적으로

  • 검사 흐름 전체가 일관된 구조로 이어지는 화면을 완성했고, UI 기획과 구현을 한 사람이 오가며 의사결정 비용을 줄였습니다.
03

로그인 입력 리렌더링 15회 → 1회

어떤 고민이 있었는가

  • 로그인 화면에서 타이핑할 때마다 유효성 검사가 실행돼 입력 1회당 평균 15회의 리렌더링이 발생했고, 저사양 환경에서는 입력 지연이 체감됐습니다.

어떻게 해결했는가

로그인 입력 — 글자마다 검사하던 흐름을 setTimeout + useEffect cleanup 디바운스로 바꿔, 입력이 멈춘 뒤 한 번만 검사·렌더링
  1. Start: 사용자가 로그인 입력창에 한 글자를 입력한다.
  2. 이전에는 글자마다 유효성 검사와 리렌더링이 즉시 일어나 입력 1회당 평균 15회 렌더링됐다.
  3. 개선 후: 입력이 들어오면 useEffect cleanup이 직전 타이머를 취소하고 setTimeout으로 새 타이머를 건다.
  4. 타이머가 끝나기 전에 다음 글자가 오면 같은 과정을 반복한다. 입력이 멈춰 타이머가 끝나면 그때 한 번만 유효성 검사와 렌더링을 한다.
  5. 검토 후 기각한 대안: useRef로 값을 잡아 렌더링을 없애는 방법은 입력 중 실시간 유효성 표시 요구와 충돌했다.
  • useRef로 값을 잡아 리렌더링을 없애는 방식을 먼저 검토했지만, 입력 중 실시간으로 유효성을 표시해야 한다는 요구와 충돌해 기각했습니다.
  • 대신 setTimeout과 useEffect cleanup을 조합한 디바운스를 적용했습니다. 글자가 들어올 때마다 직전 타이머를 취소하고 새로 걸어, 입력이 멈춘 뒤 한 번만 검사와 렌더링이 일어납니다.

결과적으로

  • 입력당 리렌더링이 평균 15회에서 1회로 줄어 체감 입력 지연이 사라졌습니다. 원인 계측 → 대안 비교 → 기각 사유 기록까지 거친 첫 성능 개선 경험이었습니다.

03 / SCREENS

서비스 화면

Panel 임계값 설정 — Cut Ratio 컬러 테이블
기관 관리 — 사이트·권한 목록

04 / REFLECTION

배운 점

"첫 번째 개발자"의 일은 코드보다 기준을 만드는 일이었습니다. 여기서 만든 스택과 컨벤션이 다음 프로젝트의 출발점이 되는 것을 보며, 재사용되는 것은 컴포넌트가 아니라 결정이라는 것을 배웠습니다.

다음 프로젝트엑셀주식