One Line of Code Changed My Perception of Programming

One Line of Code Changed My Perception of Programming

초기 커리어: “제품을 만드는 개발자”

• 라이브러리 연결, 서드파티 서비스 통합에 능숙했지만, 관심사 분리(Separation of Concerns), 경계, 디자인 패턴에 대한 이해는 부족했음
• 주 업무는 CRUD 애플리케이션이었고, 재직하던 스타트업들도 소프트웨어 설계에 큰 관심이 없었음

운명을 바꾼 한 줄의 코드

어느 날 Node.js 서비스를 살펴보다 유저 권한을 검증하는 함수 하나가 눈에 들어왔다.

abortUnless(user).canDelete(entity)

• 단순히 길게 늘어진 조건문(if/else chain)으로 검증하던 방식과 달리, 간결하고 표현력이 높은 한 줄
• 복잡한 의사결정 로직을 추상화했지만, 잘 설계된 추상화였음: 읽기 쉽고(readable), 재사용 가능하며(reusable), 확장 가능(extensible)

설계 원칙 분석

1. 빌더 패턴 (Builder Pattern) 응용

• 클래스 내부 상태를 유지하는 대신, 함수들을 체이닝하여 영어 문장처럼 읽힘
• abortUnless가 반환하는 객체에 메서드를 계속 추가함으로써 기능 확장 가능
• 각 검증 메서드는 동일한 객체를 반환 → 여러 검증을 체이닝하여 복합 검증 플로우 구성 가능
• 첫 번째로 실패하는 메서드가 에러를 throw하여 실행을 중단

이 패턴을 보기 전까지 디자인 패턴은 “엔터프라이즈 환경에서만 쓰는 것”이라고 생각했다.
하지만 창의성을 발휘하면 잘 알려진 해결책을 적용해 바퀴를 재발명하지 않을 수 있다.

2. 단일 책임 원칙 (Single Responsibility Principle)

3. 명확한 API 설계 (명세 기반 네이밍)

• 비즈니스 로직이 canManage, isAdmin 같은 모호한 이름 뒤에 숨지 않음
• canDelete처럼 고수준 개념을 그대로 API 이름으로 표현 → 비즈니스 로직 누수 없음
• 인지 부하(mental load)가 낮아 코드를 읽는 속도가 빨라짐

So What Changed?

• 이 한 줄을 쓴 사람이 누군지, Stack Overflow에서 가져왔는지, 다른 코드베이스에서 영감을 받았는지 알 수 없음
• 하지만 누군가 설계에 공을 들였고, 그것이 저자를 “개발자(developer)“에서 “장인(craftsman)“으로 변화시켰음

커리어와 철학의 변화

• 스타트업 씬을 떠나 강한 엔지니어링 문화를 가진 회사로 이직하기로 결심
  • “빡빡한 데드라인에 불타는 코드를 배포해도 칭찬받는 곳”이 아닌
  • “좋은 API를 설계하면 칭찬받는 곳“으로
• 모든 고민과 설계적 사고는 결국 여기저기 흩어진 눈에 띄지 않는 코드 한 줄로 귀결됨
• 그렇지만 그 코드들은 분명히 존재하며, 모든 것을 더 좋게 만든다

장인 정신의 습득 방법

“우리나라에서는 ’기술을 배우는 게 아니라 훔치는 것’이라고 말한다.
더 나은 사람이 하는 것을 보고 따라 하다 보면, 결국 자신만의 감각이 생긴다.”

• 더 뛰어난 코드를 보고 **모방(mimic)**하는 것에서 장인 정신이 시작됨
• 자신만의 취향과 기준이 생길 때까지 반복하는 것이 핵심