안녕하세요.
월요일이라 체력안좋은 프로덕트 디자이너 메리입니다.👴🏻
오늘의 주제는 코드 리팩토링의 개념과, 디자인 시스템의 연관관계를 써보려합니다.
(옥시싹싹 짤과 연관된 내용입니다.)
저 같은 경우엔 연차가 쌓이다보니 자주 하는 일들이 새로운 기능을 개발하기보다,
기존 서비스에 대한 유지보수 작업을 하게 되는 경우가 굉장히 많은데요.
(오히려 신입일 때 서비스 런칭을 더 많이한거 같음..)
개발자에겐 유지보수 작업에 꼭 필요한 "코드 리팩토링"
그리고 디자이너들이 주기적으로 하는 하는 "디자인 시스템 정리"
이 작업은 아 다르고 어 다르지만, 유지보수 측면에서 사실 둘 다 같은일을 하고 있는 거라는 생각이 들어요.
자, 그럼 코드 리팩토링은 뭐고,(이게뭐고) 왜 필요할까요?
코드 리팩토링은 기능은 그대로 유지한 채, 내부 코드의 구조를 더 깔끔하게, 읽기 좋게, 유지보수하기 쉽게 다듬는 작업입니다. 주로 코드의 가독성을 높이고, 유지보수를 편하게 하는 작업입니다.
예를 들어 기능은 잘 동작하지만 변수명이 혼란스럽거나 중복된 함수가 많을 때, 에러는 없지만 개발자 본인도 다시 보면 어지러운 코드들... 이런 걸 정리하는 거예요.
리팩토링은 버그 수정이나 새로운 기능 개발과는 다르지만, 결국 전체 개발 생산성을 크게 높여주는 핵심 작업입니다.
특히 IT업계의 경우 다른 업계와 달리 근속연수가 짧고, 처음에 개발한 멤버와 나중에 유지보수하는 멤버가 다른경우가 굉장히 많기 때문에, 다음 작업자를 위해서 알잘딱깔쎈 클린코드를 쓰는게 매너(?)인 것 같아요.
피그마로 치자면 기능 구분없이 한 페이지에 UI 300개를 한번에 냅다 박아버리는 디자이너가 있는 반면, 디자인 시스템 / 기능 01 / 기능 02 이런식으로 잘 구분해놓은 디자이너가 있듯 말이죠. 당연히 후자가 최고겠죵?
리팩토링을 할 때는 코드 품질 진단 도구들이 큰 도움이 됩니다. 예시로는,
- SonarQube : 코드 스멜, 중복, 버그 가능성 등 자동 감지해주는 정적 분석 도구
- ESLint / Prettier : 자바스크립트/타입스크립트 코드 스타일 자동 정리
- CodeClimate : 코드 복잡도, 테스트 커버리지까지 종합 관리
- GitHub Actions 와 CI 도구 : 리팩토링 이후 테스트 자동화와 배포까지 연계
이렇게 있는데요. 이런 툴을 통해 '문제 있는 코드'를 빠르게 인지하고, 팀원끼리 리뷰 기준도 통일할 수 있어요. SonarQube는 회사 개발자분께서 쓰시는걸 봤는데, 이야 이거 기가 맥히더군요. 여러분도 써보시길 바랍니다.
네. 정말 그렇습니다. 디자이너의 컴포넌트 정리 상태, 버전 관리 방식, 핸드오프 툴 사용법은 개발자가 어떤 구조로 코드를 짤지에 영향을 줍니다. 예를 들자면,
- Figma 파일 내에서 버튼 컴포넌트가 정리되어 있고, 상태별로 Variants가 잘 구성돼 있다면?
→ 😍 개발자는 이를 기준으로 디자인 시스템 컴포넌트를 만들고, 중복 없이 코드화 가능- 반대로, 디자이너가 매 화면마다 버튼 스타일이 다르고 명명도 제각각이라면?
→ 🤬 개발자는 하나의 컴포넌트를 만들 수 없고, 매 화면마다 반복된 코드가 생기고 유지보수도 힘들어집니다.
이건 코드로 보면 마치 매 기능마다 함수와 변수명이 다르게 뒤섞여 있는 느낌과 비슷해요.
또한, 디자이너가 화면별로 버전관리를 잘 관리하지 않으면 개발자는 어떤 디자인이 최신인지, 어떤 브랜치에 반영해야 하는지 혼란스러워지기 쉬워요.
🔁 그래서 실제로 디자이너의 디자인 파일 관리법 = 개발자의 Git 브랜치 전략과 굉장히 닮아 있습니다.
- '메인 디자인 시스템 = main branch'
- '특정 기능 UI 개선안 = feature/...'
- 'QA 결과 반영 = hotfix/...'
이런 구조를 의식하고 디자인 파일을 정리하면, 협업 효율은 상상 이상으로 올라갑니다.
나중에 Github에 대한 개념도 작성할 예정인데요.
Github에서 어떻게 코드를 관리하는 지를 알면 디자인 파일도 완즈이 깔끔하게 정리할 수 있다는 4실 !
✅ 신규 기능 개발 시 기존 코드 이해가 어려워서 생산성 저하
✅ 버그가 발생했을 때 원인 파악이 어려움
✅ 새로운 팀원이 온보딩할 때 진입장벽이 높아짐
✅ 디자인이 바뀌었을 때 관련된 모든 컴포넌트를 수정해야 함 (재사용 불가)
✅ 코드 중복 증가 → 파일 커지고, 테스트 어려워지고, 수정 충돌까지
즉, 리팩토링을 하지 않으면 기능은 계속 추가되지만 구조는 점점 무너지는 상황이 되는 거예요.
개발자 입장에서는 '건물이 멀쩡해 보이지만 배선이 엉망이라 나중에 아무 데서나 불 나는 집' 같은 상태죠.
집 컴퓨터 보면 본체 뒷면에 전선 꼬여있어서 풀생각을 안하죠? 그것과 비슷합니다.

리팩토링은 단지 개발자만의 일이 아닙니다.
디자이너가 컴포넌트 단위로 UI를 설계하고, 정리된 파일을 공유하며, 명확한 버전 구조를 유지한다면,
개발자에게는 그게 곧 깨끗한 설계서가 됩니다.
디자인과 코드의 구조는 연결돼 있어요. 서로 깔끔하게 정리하면, 결국 유지보수는 덜 힘들고 팀은 더 빠르게 움직일 수 있습니다.
제가 하는일이 유지보수가 많다보니.. 어떻게 하면 이 유지보수를 퀵하게 끝낼 수 있을까.. 하는 고민에 이런 주제로 찾아오게 되는데요. 다음에는 버전관리의 중요성, 그리고 Github 기능 등등으로 찾아오려합니다!
유지보수 하는 모든이들에게 도움이 됐길 바라며.. (도움이 됐다면 마라탕 한그릇 사주십시오)
