SLASH 21 - 실무에서 바로 쓰는 Frontend Clean Code

토스·토스 SLASH 21 2021·2021년

AI 요약

토스 보험 서비스를 웹뷰로 개발한 진유림 발표자가 '실무에서 바로 쓰는 프론트엔드 클린 코드'를 풀어낸다. 실무의 90%가 기존 코드에 기능을 추가하는 일이라는 점에서, 작은 변경 하나로 깔끔하던 코드가 어떻게 무너지는지 실제 사례로 보여준다.

핵심 포인트

클린 코드의 핵심 정의는 '짧은 코드가 아니라 원하는 로직을 빠르게 찾을 수 있는 코드'이며, 변경점 diff만 보지 말고 큰 그림으로 리팩토링해야 한다
세 원칙 — 응집도(같은 목적의 코드를 모으되 핵심 정보는 바깥에 남기고 디테일만 숨김), 단일 책임(이름과 내용이 일치하는 함수·컴포넌트로 분리), 추상화(필요한 만큼만, 단계를 일관되게)
'무엇을 하는지' 선언하면 내부가 알아서 그려 주는 선언적 프로그래밍을 지향하고, 담대한 기존 코드 수정·큰 그림 보기·팀 공감대·문서화를 액션 아이템으로 제시한다

왜 읽나리액트·자바스크립트로 기존 코드를 유지보수하며 가독성과 응집을 높이려는 프론트엔드 개발자에게 즉시 적용할 실전 지침을 준다.

챕터별 상세

010:00 – 5:49

클린 코드는 왜 중요한가 — 좋은 의도가 만든 나쁜 코드

토스 앱의 보험 서비스를 웹뷰로 개발한 진유림 발표자가 '실무에서 바로 쓰는 프론트엔드 클린 코드'를 연다. 클린 코드라고 하면 흔히 코드 줄이기를 떠올리지만, 그 외에 더 섬세하게 코드를 정리하는 스킬이 필요하다며 읽기 좋은 코드를 위한 개념과 액션 아이템을 리액트·자바스크립트 예시로 공유하겠다고 밝힌다. 실무에서 클린 코드가 의미 있는 이유는 '유지보수 시간 단축'이다. 흐름 파악이 어렵고 도메인 맥락이 드러나지 않는 코드는 동료에게 물어봐야 알 수 있어 개발의 병목이 되는데, 시간은 곧 자원이자 돈이므로 고치는 데 하루 걸리는 코드와 사흘 걸리는 코드의 차이는 개발자가 3배 더 필요한 차이다.

핵심 문제의식은 실무의 90%가 새 파일을 짜는 일이 아니라 기존 코드에 기능을 추가하는 일이라는 점이다. 발표자는 보험 질문 입력 페이지에 '설계사가 있으면 사진 든 팝업을 먼저 띄워 달라'는 요구를 받아, 기존 클릭 핸들러에 조건문을 넣고 팝업 컴포넌트를 추가하는 '타당해 보이는' 변경을 했지만 결과적으로 나쁜 코드가 됐다고 고백한다. 그 코드가 왜 나쁜지는 세 가지로 진단된다. 첫째, 하나의 목적을 가진 코드가 여기저기 떨어져 있어 스크롤을 오르내리며 미로 찾기를 해야 한다. 둘째, 하나의 함수가 어느새 세 가지 일을 하게 돼 역할을 알려면 세부 구현을 전부 읽어야 한다. 셋째, 이벤트 핸들러 함수들의 추상화 단계가 제각각이라 비슷한 이름인데 하는 일이 달라 코드를 잘못 지레짐작하게 만든다. 깔끔하던 코드가 작은 기능 하나로 어지러워졌다는 '그때는 맞고 지금은 틀리다'라는 명제로 다음으로 넘어간다.

변경점만 보면 문제를 발견하기 어렵다는 함정을 짚는다. 풀 리퀘스트의 변경 사항(diff)만 보면 틀린 점이 없어 보이지만 전체 그림으로 보면 엉망인데, 발표자가 처음 제출했던 PR이 그랬다. 그래서 큰 그림을 보며 리팩토링한다. 함수의 추상화 단계를 통일해 이벤트 핸들러 이름들의 결을 맞추고, 한쪽은 새 전문가에게 질문하는 로직만, 다른 쪽은 연결 중인 전문가에게 질문하는 로직만 담도록 정리한다. 흩어져 있던 팝업 버튼과 팝업 코드를 '팝업을 띄우는 버튼' 컴포넌트로 뭉치고, 띄울 팝업은 props로 내려보낸다. 또 함수가 한 가지 일만 하도록 약관 동의 로직을 필요한 시점에 따로 부르게 바꾼다. 그 결과 코드는 첫 버전보다 길어졌는데, '클린 코드는 짧은 코드가 아니라 원하는 로직을 빠르게 찾을 수 있는 코드'이기 때문이라는 이 발표의 핵심 정의를 제시한다. 원하는 로직을 빠르게 찾으려면 흩어진 코드는 응집도를 높여 모으고, 여러 일을 하는 함수는 단일 책임으로 쪼개며, 추상화 단계가 제각각이면 단계를 맞춰 핵심 개념만 노출해야 한다는 세 원칙을 예고한다.

첫 번째 원칙 응집도는 '같은 목적의 코드는 뭉쳐 두자'는 뜻이다. 앞 코드에서 팝업을 조작하는 코드가 세 군데로 떨어져 있어 한 번에 파악되지 않고 버그 위험도 높았다. 해결로 커스텀 훅을 써 흩어진 코드를 모아 openPopup 호출만으로 팝업을 열 수 있게 했다. 그런데 이렇게 무작정 뭉쳤더니 오히려 읽기 힘든 코드가 됐다. 가장 중요한 '어떤 내용의 팝업을 띄우는지'와 '버튼을 눌렀을 때 어떤 액션을 하는지'가 모두 훅 속에 가려졌기 때문이다. 발표자는 이를 '보기 더러우니 일단 뭉쳐 두는' 커스텀 훅의 대표적 안티 패턴이라 부르며, 무엇을 뭉쳐야 하는가라는 물음에 답은 '당장 몰라도 되는 디테일'이라고 제시한다.

응집과 단일 책임의 올바른 적용을 정리한다. 뭉치면 답답해지는 요소는 코드 파악에 필수적인 핵심 정보이므로, 핵심 데이터(팝업 클릭 시 액션·제목·내용)는 바깥에 남기고 세부 구현(상태·마크업·버튼 바인딩)만 숨겨야 한다. openPopup 컴포넌트에 제목·내용·액션을 바깥에서 넘기면 세부 구현을 보지 않고도 어떤 팝업인지 파악된다. 이렇게 '무엇을 하는지'를 선언하면 내부가 알아서 그려 주는 스타일이 선언적 프로그래밍으로, 빠른 이해·세부 구현 은닉·재사용 용이가 특징이다. 반대로 세부 구현을 하나하나 작성하는 명령형도 props로 세부 동작을 넘겨야 할 때는 필요해 균형이 중요하다. 다음으로 단일 책임은 하나의 일을 하는 뚜렷한 이름의 함수를 만드는 것이다. 약관 체크와 질문 제출이 섞인 함수를 handleQuestionSubmit이라 붙이면 이름과 내용이 어긋나 신뢰가 떨어지고, 기능이 계속 덧붙으면 '그 코드는 안 건드리는 게 좋다'는 데자뷰가 생긴다. 함수뿐 아니라 컴포넌트로도 분리할 수 있어, 로그를 찍는 코드는 LogClick 래핑 컴포넌트로, 겹침을 판별하는 IntersectionObserver는 별도 컴포넌트로 떼어 낸다. 도메인이 복잡해 영어 이름이 길어지거나 조건문이 복잡할 때는 한국어 변수·상수명이 주석 같은 효과를 내며 직관성을 높인다는 팁도 권한다.

세 번째 원칙 추상화는 로직에서 핵심 개념을 뽑아내는 것이다. 피카소가 소 그림에서 디테일을 지워 개념만 남긴 연작과 복잡한 지하철을 노선도로 단순화한 예로 추상화의 본질을 설명한다. 추상화의 정도에는 정답이 없어 상황에 따라 조절하는데, 컨펌 창을 띄우는 구체적 코드를 ConfirmButton으로 추상화하고 onConfirm이나 message prop만 넘겨 더 간단하게, 나아가 모든 기능을 하나의 이름 아래로 더 추상화할 수도 있다. 핵심은 필요한 만큼만 추상화하라는 것이다. 또 한 레벨 안에 추상화 수준이 섞여 있으면 파악이 어려우므로 단계를 일관되게 맞춰야 한다. 마무리로 네 가지 액션 아이템을 제시한다. 추가만 하지 말고 '담대하게 기존 코드 수정하기'(걱정되면 별도 리팩토링 PR), '큰 그림 보는 연습', 사소해도 일관성을 깨는 코드는 명시적으로 공유하는 '팀과 공감대 형성', 그리고 모호한 개념을 명확히 하는 '문서로 적어 보기'다. '아름다운 사람들은 머문 자리도 아름답다'는 말로 발표를 맺는다.