taeyeong0814 님의 상세페이지 ＞ [6팀 이태영] Chapter 2-1. 클린코드와 리팩토링

[6팀 이태영] Chapter 2-1. 클린코드와 리팩토링

by taeyeong08142025. 7. 28.

배포링크 (https://taeyeong0814.github.io/front_6th_chapter2-1/)

과제 체크포인트

기본과제

  • 코드가 Prettier를 통해 일관된 포맷팅이 적용되어 있는가?
  • 적절한 줄바꿈과 주석을 사용하여 코드의 논리적 단위를 명확히 구분했는가?
  • 변수명과 함수명이 그 역할을 명확히 나타내며, 일관된 네이밍 규칙을 따르는가?
  • 매직 넘버와 문자열을 의미 있는 상수로 추출했는가?
  • 중복 코드를 제거하고 재사용 가능한 형태로 리팩토링했는가?
  • 함수가 단일 책임 원칙을 따르며, 한 가지 작업만 수행하는가?
  • 조건문과 반복문이 간결하고 명확한가? 복잡한 조건을 함수로 추출했는가?
  • 코드의 배치가 의존성과 실행 흐름에 따라 논리적으로 구성되어 있는가?
  • 연관된 코드를 의미 있는 함수나 모듈로 그룹화했는가?
  • ES6+ 문법을 활용하여 코드를 더 간결하고 명확하게 작성했는가?
  • 전역 상태와 부수 효과(side effects)를 최소화했는가?
  • 에러 처리와 예외 상황을 명확히 고려하고 처리했는가?
  • 코드 자체가 자기 문서화되어 있어, 주석 없이도 의도를 파악할 수 있는가?
  • 비즈니스 로직과 UI 로직이 적절히 분리되어 있는가?
  • 코드의 각 부분이 테스트 가능하도록 구조화되어 있는가?
  • 성능 개선을 위해 불필요한 연산이나 렌더링을 제거했는가?
  • 새로운 기능 추가나 변경이 기존 코드에 미치는 영향을 최소화했는가?
  • 코드 리뷰를 통해 다른 개발자들의 피드백을 반영하고 개선했는가?
  • (핵심!) 리팩토링 시 기존 기능을 그대로 유지하면서 점진적으로 개선했는가?

심화과제

  • 변경한 구조와 코드가 기존의 코드보다 가독성이 높고 이해하기 쉬운가?
  • 변경한 구조와 코드가 기존의 코드보다 기능을 수정하거나 확장하기에 용이한가?
  • 변경한 구조와 코드가 기존의 코드보다 테스트를 하기에 더 용이한가?
  • 변경한 구조와 코드가 기존의 모든 기능은 그대로 유지했는가?
  • (핵심!) 변경한 구조와 코드를 새로운 한번에 새로만들지 않고 점진적으로 개선했는가?

과제 셀프회고

과제를 하면서 내가 제일 신경 쓴 부분은 무엇인가요?

이번 과제에서 가장 신경 쓰려고 했던 부분은 리팩토링의 일관성과 커밋 관리였습니다. 기능별로 커밋을 나누고, 커밋 메시지에 gitmoji와 명확한 prefix (refactor, fix 등)를 사용하여 히스토리를 관리하려고 노력했습니다. 또한 기존 JS 코드를 React/TypeScript 구조로 점진적으로 분리하고, 역할별로(순수함수로) 컴포넌트/훅/유틸 함수로 나누는 작업에 집중했습니다. 그 외에도 ESLint, Prettier 등 팀 컨벤션에 맞는 코드 스타일 유지에도 신경 썼습니다.

과제 진행 중 재미있는 삽질? 을 한 기록 입니다. git rebase로 커밋 메시지와 히스토리 정리 첫 날 리팩토링한 커밋 메시지를 gitmoji와 refactor, fix 등으로 정리하고 싶어서 git rebase를 시도했습니다. 여러 번 rebase를 반복하다 보니 히스토리가 꼬이고, 필요 없는 커밋이 남는 등 복잡한 상황이 발생했습니다....... 결국 drop을 통해 불필요한 커밋을 정리했지만, git의 무서움과 강력함을 동시에 체험한 경험이었습니다.

image

첫 날 리팩토링을 진행하면서 commit한 내역을 gitmoji도 추가하고 fix 대신 refactor 로 변경하고 싶어서 git rebase 를 알게 되어 명령어와 함께 진행을 하다가 여러번의 rebase 과정에서 히스토리가 복잡하게 남는 경험을 하였습니다. 결국 필요 없는 commit 내역을 다 drop 하고 정리하였지만 끔찍한 경험이였습니다. image drop을 통해서 commit도 날릴 수 있다!!!!!!!!!

제가 이번 과제를 하면서 느낀 부분은 더티코드로 작성 된 부분 중 눈에 띄는 아니 그냥 제일 문제는

  • 비즈니스 로직과 UI 코드가 뒤섞여 있음 기존 JS 코드(main.original.js 등)는 한 함수에서 데이터 처리, DOM 조작, 이벤트 등록 등 모든 역할이 섞여 있었습니다. 예를 들어, 장바구니 합계 계산, 할인 정책 적용, 포인트 계산, 화면 업데이트가 한 함수에 모두 들어가 있어 가독성이 떨어지고 유지보수가 어려웠습니다.

  • 매직넘버와 하드코딩 할인율, 포인트, 상품 ID 등 중요한 값들이 코드 곳곳에 숫자나 문자열로 직접 사용되고 있었습니다. 정책이 바뀌면 여러 곳을 수정해야 하고, 실수로 잘못된 값을 넣을 위험이 있었습니다.

  • 전역 변수 남용 상태 관리가 전역 변수로 이루어져 있어, 함수 간 의존성이 높고 버그가 발생하기 쉬웠습니다.

  • 함수/컴포넌트의 책임 불분명 한 함수가 너무 많은 일을 하거나, 한 컴포넌트가 여러 역할을 동시에 처리하는 경우가 많았습니다.

그래서 생각한 클린코드 개선 방식은

  • 비즈니스 로직과 UI 분리 할인 계산, 포인트 계산 등 핵심 로직을 별도의 함수/훅/유틸로 분리하고, UI는 React 컴포넌트에서만 담당하도록 구조화했습니다.

  • 상수와 타입 분리 할인율, 포인트 등 정책 관련 값은 constants.ts에, 데이터 구조는 types 폴더에 따로 관리하여 코드의 의미와 변경 용이성을 높였습니다.

  • 상태 관리 개선 React의 useState, useReducer, custom hook 등을 활용해 상태를 명확하게 관리하고, 전역 변수 의존도를 줄였습니다.

  • 컴포넌트 단위 분리 장바구니, 주문 요약, 상품 선택 등 역할별로 컴포넌트를 분리하여 각 컴포넌트가 하나의 책임만 갖도록 리팩토링했습니다.

  • 함수/컴포넌트 네이밍과 역할 명확화 함수와 컴포넌트 이름을 역할에 맞게 명확히 짓고, props와 타입을 통해 데이터 흐름을 명확하게 했습니다.

과제를 다시 해보면 더 잘 할 수 있었겠다 아쉬운 점이 있다면 무엇인가요?

리팩토링을 더 작은 단위로, 더 자주 커밋하고 push했으면 히스토리 관리가 더 쉬웠을 것 같습니다. 초반에 설계와 폴더 구조를 좀 더 명확히 잡고 시작했다면, 중간에 구조를 바꾸는 데 드는 리팩토링 공수가 줄었을 것 같습니다. 그치만 위의 생각은 진짜 머릿속으로만 가능한 생각이고 실제로는 이런 코드를 어디서부터 어떻게 코드를 작성해야 할지 조차 막막한게 현실이였습니다. 다시 과제를 해볼 때는 더티코드 실행 시켜서 화면을 확인 후 화면단에서 레이아웃을 눈으로 나누고 시작 할 것 같습니다. 코드, 함수만 보고 코드 분리를 막연하게 하려고 했던 처음과 달리 눈으로 화면을 보면서 단위를 쪼갤 수 있겠다 싶은 부분을 우선 쪼개보고 그에 맞게 쪼개어 있는지, 안되어 있다면 어디까지 묶여있는지 확인을 하면서 시작 한다면 접근이 더 쉽지 않을까요!??

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문 편하게 남겨주세요 :)

AI 활용과 그에 대한 성찰 https://youtube.com/shorts/eXB_eYVtRF0?si=kgaJuy3j7I9ZApjN 금요일 아침 출근 길에 유튜브 숏츠에서 개발자 유튜버 노마드코드가 '코파일럿을 해지한 이유' 라는 영상을 보았는데 처음에는 단순히 '아 코파일럿이 다른 AI 툴보다 단점이 있어서 갈아 탄 걸 말하는 걸까?' 였는데 간단하게 이야기하면 AI 툴을 통해 코딩에 도움을 받는 요즘 시대에 생산성이 극대화 된 것 같아 보이지만 여기에는 치명적인 문제점이 있다고 설명합니다. 학습이 결코 편안해서는 안되고 공원을 슬렁슬렁 산책하는 것이 아니라, 마치 산을 오르는 것처럼 느껴야 한다고 생각해. 라고 말합니다. 숙련된 개발자는 수년간의 직접 답을 찾아가는 노력을 통해 각자만의 기준이 생기고 AI의 제안이 좋은지 아닌지 알 수 있는 기준이 있습니다. 하지만 주니어 개발자나 기준이 없는 사람들은 AI가 제시하는 솔루션을 생각없이 받아드리고 이것이 습관화되어 나쁜 결과물을 만들기가 너무 쉬운 상황이라고 합니다. AI가 문제를 대신 해결해 줄수록 결국 본인의 문제 해결 능력은 떨어지게 되는 것이라 마무리하는데 항해 과제, 현업 업무를 하면서 요즘 많이 느끼게 되는 이야기였습니다.

위의 이야기를 통해 하고 싶은 말은 요즘 AI 많이 쓰니까 다 쓰니까 당연히 써야지! 이용해 먹어야지! 하며 쓰는 것보다 어떻게 활용해야 나 자신도 성장하며 효율적으로 성장하고 해결 할 수 있을까? 에 대한 숙제가 생겼습니다.

어떤 수준까지 AI를 활용하는 것이 **"건강한 학습"**이라고 생각하시나요? 저는 폴더 구조만 구조화 후 코드는 직접 작성하려고 했지만 결국 AI에게 모든 코딩까지 위임한 정도로 의존도가 높았습니다... 이 부분 관련하여 멘토링 시간은 아니지만 테오의 생각을 간단하게 혹은 임팩트 있게 답변 주시면 감사드립니다. 예를 들어, 이번 과제에 AI를 잘 활용하여 진행하라고 하셨는데 원했던 방향은 이런 식이다~ 등.

또, 폴더 구조나 설계 방향을 미리 정하는 데 있어서 더 좋은 연습법이 있다면 알려주시면 감사하겠습니다. 이번 과제에서 제가 만든 폴더 구조 방향은 아래 이미지와 같습니다. image

기본 과제 js 구조이지만 components, data, events, hooks, utils 로 나누어서 components에서는 화면을 data에서는 현재는 더미 데이터를 events에서는 클릭 이벤트와 setTimeout을 통한 이벤트를 hooks, utils로 나누어 보았습니다. 그래야 심화과제를 할 때 React 폴더 구조와 최대한 비슷하게 가져 갈 수 있을 것 같다는 생각으로요.

과제 피드백

이태영님, 정말 수고하셨습니다! 이번 과제는 더티코드를 클린코드로 개선하면서 React/TypeScript 기반의 현대적 아키텍처로 전환하는 것이 목표였어요. 회고를 읽어보니 과제의 핵심을 정확히 파악하고 정말 체계적으로 접근하셨네요.

"제가 이번 과제를 하면서 느낀 부분은 더티코드로 작성 된 부분 중 눈에 띄는 아니 그냥 제일 문제는" 으로 시작되는 구절이 인상깊네요. "비즈니스 로직과 UI 코드가 뒤섞여 있음", "함수/컴포넌트의 책임 불분명" 등 왜 소프트웨어 공학에서 말하는 좋은 코드의 원칙과 개념적인 학습 등에서 이런 것들을 분리하고 구조화를 하라는지 확실히 느낀 것 같아서 좋습니다.

이번 과제를 통해 리팩토링의 진정한 어려움과 가치를 몸소 체험하셨을 거예요. 특히 "점진적 개선"의 중요성을 실감하셨을 텐데, 이런 경험이 쌓여서 나중에는 더 큰 규모의 코드베이스에서도 안전하고 효과적으로 개선 작업을 할 수 있는 감각이 생길 거예요.

Q) 어떤 수준까지 AI를 활용하는 것이 "건강한 학습"이라고 생각하시나요?

AI 활용에 대한 성찰 부분도 정말 깊이 있는 고민이었습니다. 노마드코더 영상을 보고 "학습이 결코 편안해서는 안 된다"는 깨달음을 얻으신 것, 그리고 "어떻게 활용해야 나 자신도 성장하며 효율적으로 성장할 수 있을까?"라는 질문을 던지신 것이 정말 중요한 인사이트라고 생각해요.

우리는 개발자로써 문제를 해결하고 결과를 만들어 내야 하죠. 이 때에는 혼자서 코드를 생각하고 만들어내는 것보다 라이브러리를 쓰고 필요한 코드를 구글에서 찾아서 어쩄든 문제를 해결하고 결과를 만들어내는게 잘 하는 개발자입니다. AI도 개발자에게는 새로운 도구이며 이를 잘 활용해서 결과를 만들어내는 건 개발자로써 중요한 소양이지요.

그런데 학습이라는 측면에서는 조금 다릅니다. 왜 이게 나쁜 해결책 인지 좋은 해결책인지 여러가지 시행착오를 하는 과정에서 배우고 느낄 수 있죠. 그리고 스스로 생각하는 힘을 통해서 처음에는 어렵지만 점점 익숙해지면서 다양한 문제들을 만난 경험들이 새로운 문제를 만났을 때 해결하는 힘과 끈기를 만들어준다고 생각합니다.

건강한 AI 활용은 내가 목표를 설정하고 방향을 제시하되, 구체적인 구현 작업에서 도움을 받는 정도라고 생각해요. 예를 들어 "이 함수를 순수함수로 만들어줘", "이 컴포넌트에서 비즈니스 로직을 분리해줘"처럼 내가 원하는 바를 명확히 알고 있을 때 AI를 활용하는 거죠. 이때는 AI를 해결의 도구로 활용하고 있는걸 꺼에요.

반대로 "어떻게 해야 할지 모르겠으니 알아서 해줘"는 어떨까요? 이렇게 해서 문제를 해결하는건 도움이 되지 않습니다. 내가 생각한 바가 있는게 아니니까요. 그렇지만 힌트는 되어줄거라 생각합니다. 왜 이 방식이 좋은 방식인지 혹은 다른 방식도 생각해볼 수 가 있을지 그렇게 고민을 하면서 내것으로 만든 뒤에는 학습이 되었다고 생각합니다. 사실 이러한 방식은 기존에 구글링이나 스택 오버 플로우를 통해서 문제 해결 뒤 학습까지 이어지는것과 다름 없죠.

뇌는 너무 편하면 그걸 의미있게 생각하지는 않는다고 해요. 고생을 한다는 얘기는 에너지가 필요로 한다는 뜻이고 이걸 더 편하게하기 위한 방법을 찾는 거죠. 그리고 편해졌다는 얘기는 더 이상 신경 쓰지 않아도 된다는 의미라고 생각해요. AI를 통해서도 얼마든지 고민하고 물어보고 학습을 할 수 있다고 생각합니다. 모르는 일을 대신 해주는 존재가 아니라 내가 원하는 걸 하기 위해서 혹은 학습하기 위해서 충분히 에너지를 들인다면 내 것이 된다고 생각해요.

책을 읽을때 마음에 드는 구절을 필사를 하면서 몸에 새기는 것 처럼 AI와 함께 하더라도 괜찮은 코드들은 내가 따라 쳐보기도 하고 AI없이 다시 만들어 보기도 하고, 그렇지 않고 컨트롤 C+V를 하더라도 의식적으로 충분히 학습할 수 있다고 생각해요.

수고하셨습니다. 5주차도 화이팅입니다!