셈웨어 4개월 — 리뉴얼·교육 플랫폼·레거시 마이그레이션, 그리고 SM 풀스택 전환

이 글은 토리스 대표가 셈웨어 재직 중 수행한 프로젝트들을 케이스 스터디 형식으로 정리한 것입니다. 보안을 고려해 프로젝트의 구체적 세부 정보는 제외하고, 기술적 판단과 협업 과정을 중심으로 기록합니다.

1. 배경 — 어떤 일이 주어졌나

항목	내용
회사	셈웨어
기간	2024.08 – 2024.12 (약 4개월)
역할	프론트엔드 개발자(React) → 이후 잇다 SM 프로젝트 풀스택
주요 기술	React, TypeScript, Spring, MyBatis

셈웨어에서의 업무는 크게 두 국면으로 나뉩니다. 초기에는 React 기반 프론트엔드 개발 — 웹사이트 리뉴얼, 교육 콘텐츠 플랫폼, 레거시 마이그레이션 — 에 집중했고, 이후 팀 개편과 함께 잇다 SM 프로젝트에 합류하면서 Spring 백엔드까지 아우르는 풀스택 업무로 범위가 넓어졌습니다.

사용한 스택은 다음과 같습니다.

영역	스택
Frontend	React, TypeScript, Next.js, styled-components, Tailwind CSS, Zustand
Backend	Spring Framework, Spring Boot, MyBatis, iBatis
Legacy	JSP, jQuery
DB	MariaDB, MySQL

2. 제약 조건

• 레거시와의 공존: JSP·jQuery·iBatis로 구성된 기존 시스템이 운영 중이었고, 신규 개발은 이를 한 번에 걷어내는 것이 아니라 운영을 유지하며 점진적으로 전환해야 했습니다.
• 운영(SM) 성격의 프로젝트: 잇다 SM은 새로 만드는 제품이 아니라 운영 중인 시스템을 유지·개선하는 일이었습니다. 변경 하나가 실사용자에게 바로 닿는 환경이라, 리스크를 최소화하는 접근이 우선이었습니다.
• 다양한 역할 간 협업: PM, 디자이너, 외부 업체가 얽힌 구조에서 프론트엔드가 접점 역할을 해야 했습니다.
• 짧은 기간, 넓은 범위: 약 4개월 안에 프론트엔드 프로젝트 복수 개와 풀스택 전환까지 소화해야 했습니다.

3. 프로젝트별 설계와 트레이드오프

3.1 React 기반 웹사이트 리뉴얼

입사 후 처음 맡은 메인 프로젝트는 웹사이트 리뉴얼이었습니다.

설계 판단

• React + styled-components 기반의 컴포넌트 단위 개발로 화면을 재구성했습니다. CSS-in-JS는 컴포넌트와 스타일의 응집도를 높여 주는 대신 런타임 비용과 러닝커브가 있다는 점을 실무에서 직접 확인했고, 이후 프로젝트에서 유틸리티 CSS(Tailwind)와 비교해 선택할 수 있는 기준이 생겼습니다.
• 모바일 퍼스트 반응형을 기본으로 잡고, 시맨틱 HTML과 키보드 내비게이션 등 접근성을 초기 설계에 포함했습니다. 접근성은 나중에 덧대는 것보다 처음부터 넣는 쪽이 비용이 낮습니다.
• 성능은 이미지 최적화, 코드 스플리팅, React.memo를 통한 불필요한 리렌더링 방지로 다뤘습니다.

트레이드오프: 전면 재작성 대신 점진적 마이그레이션을 택했습니다. 기존 내장 라이브러리 의존을 API 기반으로 옮기는 작업이 병행됐기 때문에, 한 번에 갈아엎는 것보다 단계별로 전환하는 쪽이 운영 리스크가 낮았습니다.

3.2 교육 콘텐츠 플랫폼

React와 TypeScript로 교육 콘텐츠 플랫폼 개발에 참여했습니다.

설계 판단

• 도메인 데이터와 사용자 상태의 분리: 문제·정답 같은 도메인 데이터와 사용자의 풀이 상태를 구조적으로 분리해, 상태 변경이 도메인 데이터를 오염시키지 않게 했습니다.
• Zustand + persist 미들웨어: 전역 상태를 Zustand로 관리하고 persist 미들웨어로 sessionStorage와 연동했습니다. 별도 직렬화 코드 없이 새로고침에도 풀이 상태가 유지됩니다.
• Record 타입 활용: 문제 ID를 키로 하는 Record 기반 상태 구조로, 조회·갱신 비용을 낮추고 타입 안정성을 확보했습니다.
• 테마 시스템: 초등·중등 테마를 Context API로 분리해, 같은 컴포넌트가 대상 학년에 따라 다른 스타일을 갖게 했습니다. 테마를 시스템으로 만들어 두자 이후 유지보수 비용이 눈에 띄게 줄었습니다.

이 프로젝트에서 확인한 것은, 복잡한 도메인일수록 타입 정의가 곧 설계 문서가 된다는 점입니다. 타입을 먼저 명확히 하면 컴포넌트 구조와 상태 경계가 자연스럽게 따라옵니다.

3.3 레거시 마이그레이션 — 내장 라이브러리에서 API 기반으로

기존 내장 라이브러리를 API 기반 서비스로 전환하는 작업입니다.

진행 순서

1. 레거시 코드 분석 — 기존 동작을 정확히 이해하는 데 먼저 시간을 씀
2. API 엔드포인트 설계 — 프론트엔드가 소비하기 좋은 데이터 구조로 정의
3. 점진적 마이그레이션 전략 수립 — 기능 단위로 전환하며 기존 경로를 유지
4. 프론트엔드-API 연동 및 타입 정의

트레이드오프: 빅뱅 전환은 검증 범위가 통제되지 않아 배제했습니다. 점진 전환은 기간이 길어지는 대신 각 단계에서 되돌릴 수 있어, 운영 중인 시스템에는 이쪽이 맞았습니다. 또한 API 응답 타입을 명확히 정의해 두면 연동 단계의 실수를 컴파일 타임에 잡을 수 있다는 것을 실무로 확인했습니다.

3.4 잇다 SM 프로젝트 — 프론트엔드에서 풀스택으로

약 4개월간 프론트엔드에 집중한 뒤, 팀 개편과 함께 잇다 SM 프로젝트에 합류해 백엔드까지 담당 범위를 넓혔습니다.

담당 업무

• Spring Framework 기반 백엔드 API 개발
• MyBatis XML 매퍼를 통한 데이터베이스 연동
• 프론트엔드-백엔드 연동
• 보안 기능 구현 — OTP 인증 시스템 등
• 이벤트 시스템 설계 및 개발

풀스택 전환에서 얻은 것

• 프론트와 백엔드가 연동되는 전체 흐름을 한 사람의 시야에 넣게 됐습니다. 이후 API를 설계할 때 “프론트엔드 개발자 입장에서 어떤 데이터 구조가 편한지”를 기준으로 삼을 수 있게 된 것이 가장 큰 변화입니다.
• Spring의 DI(의존성 주입)·IoC 개념과 MyBatis XML 매퍼 작성을 실무 수준에서 익혔고, SQL 쿼리 최적화가 화면 성능에 직결된다는 것을 확인했습니다.
• OTP 인증 구현을 통해 인증과 인가의 구분, 보안 흐름 전반에 대한 이해가 생겼습니다. 보안 기능은 “동작하는 것”과 “안전한 것”의 기준이 다르다는 점을 배운 구간입니다.

4. 이해관계자와의 조율

기술보다 오래 남은 것은 역할이 다른 사람들과 일하는 방식이었습니다.

4.1 디자이너와

피그마 시안을 받아 구현하는 흐름에서, 시안대로 만드는 것 이상으로 중요한 것이 기술적 제약을 미리 공유하는 일이었습니다. 구현 단계에서 “이건 어렵다”고 말하면 서로의 작업이 되돌아가지만, 시안 단계에서 제약을 공유하면 디자인 쪽에서 대안을 먼저 반영할 수 있습니다. 또한 디자인 시스템을 이해하고 일관된 스타일을 유지하는 것이 개별 화면의 완성도보다 전체 품질에 더 크게 기여한다는 것을 확인했습니다. 이 협업을 거치며 UI/UX에 대한 이해도가 실질적으로 올라갔습니다.

4.2 PM·외부 업체와

PM, 디자이너, 외부 업체가 얽힌 구조에서는 기술 용어를 쓰지 않고 설명하는 능력이 곧 프로젝트 속도였습니다. 같은 기능도 상대의 언어로 번역해 전달해야 의사결정이 빨라집니다. 정기적인 회의와 진행 상황 업데이트로 각 역할이 서로의 상태를 알 수 있게 유지하는 것 — 당연해 보이지만 이것이 무너지면 일정도 함께 무너진다는 것을 여러 역할이 얽힌 프로젝트에서 배웠습니다.

4.3 운영 시스템이라는 이해관계자

SM 프로젝트에서는 “지금 쓰고 있는 사용자”가 가장 큰 이해관계자입니다. 새 기능보다 기존 동작의 보존이 우선이고, 그래서 레거시 분석에 시간을 먼저 쓰는 것, 점진적으로 전환하는 것이 단순한 취향이 아니라 운영 환경의 요구사항이었습니다.

5. 결과와 운영

• 웹사이트 리뉴얼을 컴포넌트 기반·반응형·접근성 고려 구조로 완료하고, 내장 라이브러리 의존을 API 기반으로 전환하는 마이그레이션을 병행했습니다.
• 교육 콘텐츠 플랫폼에 도메인/상태 분리 구조와 테마 시스템을 구축해 유지보수성을 확보했습니다.
• 잇다 SM 프로젝트에서 OTP 인증, 이벤트 시스템 등 백엔드 기능을 개발·연동하며 프론트엔드 전담에서 풀스택으로 역할을 확장했습니다.

한계로 남긴 것

케이스 스터디로서 정직하게 남겨 둘 부분도 있습니다.

항목	무엇이 부족했나	이후 어떻게 바뀌었나
테스트 코드	기능 동작 확인에 집중해 대부분의 프로젝트에서 테스트를 작성하지 못함	테스트를 일정의 일부로 산정하는 기준 확립
문서화	”이 코드가 왜 이렇게 작성됐지?”를 나중에 되묻는 일이 잦았음	결정의 이유를 코드와 함께 남기는 습관
성능 모니터링	실사용자가 겪는 성능을 측정하는 체계 부재	측정 없는 최적화는 하지 않는다는 원칙
코드 품질	중복 코드, 부족한 에러 처리	에러 경로를 정상 경로와 같은 비중으로 설계

6. 재사용 가능한 교훈

1. 점진적 마이그레이션은 취향이 아니라 운영 환경의 요구사항이다. 운영 중인 시스템에서는 되돌릴 수 있는 단위로 전환하는 것이 리스크 관리의 본질입니다.
2. 타입 정의가 곧 설계다. 복잡한 도메인일수록 타입을 먼저 명확히 하면 상태 경계와 컴포넌트 구조가 따라옵니다.
3. API는 소비자의 입장에서 설계한다. 백엔드를 직접 만들어 본 경험이 프론트엔드 관점의 API 설계 기준을 만들어 줍니다.
4. 제약은 구현 단계가 아니라 시안 단계에서 공유한다. 디자이너·PM과의 마찰 대부분은 정보가 늦게 전달돼서 생깁니다.
5. 비개발자의 언어로 번역하는 능력이 일정 속도를 결정한다. 여러 역할이 얽힌 프로젝트일수록 그렇습니다.
6. 아쉬움은 다음 프로젝트의 기준이 된다. 테스트·문서화·모니터링·에러 처리 — 이 시기에 부족했던 항목들이 이후 프로젝트의 기본 체크리스트가 됐습니다.

---

이 글은 재직 당시 경험을 정리한 케이스 스터디이며, 보안을 고려해 프로젝트의 구체적 세부 정보는 포함하지 않았습니다.