리뷰하다 보면 코드보다 "이걸 왜 굳이 이렇게 짰지"가 먼저 눈에 들어오는 순간이 있다. 예를 들면 이런 거다.

A 클래스 안에서 끝낼 수 있는 로직인데, 굳이 B, C까지 람다로 끌고 가서 처리하는 코드.

이거 볼 때마다 궁금했다. 이런 코드 스타일에 그 사람 성격이 묻어나는 걸까?

성격이냐, 습관이냐

솔직히 성격보다는 습관이다. 근데 그 습관이 왜 굳어졌는지 파고들면 성향이 슬쩍 드러나긴 한다.

성향이 티 나는 부분

  • 과설계: "나중에 확장될지도 모르니까"라면서 인터페이스를 몇 겹씩 감싸는 사람. 십중팔구 불안하거나 완벽주의다.
  • 예외 처리: 예외 케이스 꼼꼼히 챙기는 사람과 해피패스만 짜고 끝내는 사람, 이 둘 사이엔 확실히 성향 차이가 있다.
  • 커밋 메시지 정성: 이건 그냥 커뮤니케이션 태도 그 자체다. 숨길 수가 없다.

성격으로 판단하면 안 되는 경우

"A에서 되는데 B, C까지 람다로 끌고 가는" 코드는 사실 성격 문제가 아닐 때가 훨씬 많다.

  • 그때 시간에 쫓겼거나
  • 처음에 확장성 고려하다 오버했거나
  • 리팩토링 타이밍을 그냥 놓쳤거나

이 셋 중 하나다. 구질구질해 보이는 코드도 파보면 과거 요구사항 흔적인 경우가 태반이다. 코드 한 줄 보고 "이 사람 우유부단하네" 하고 단정하면, 반은 틀린다.

진짜 봐야 할 건 "일관성"

한 번 지저분한 코드 갖고 왈가왈부할 게 아니라, 그 사람 코드 전반에서 같은 패턴이 반복되는지가 진짜다. 책임 분리 안 하고 로직을 여러 클래스에 걸쳐 놓는 게 매번 나온다면, 그건 그냥 "경계 정하는 결정을 미루는 습관"이다. 성격 탓할 일이 아니라 습관 탓할 일이다.

Kotlin 코드에서는 확장 함수나 람다로 로직 슬쩍 떠넘기는 패턴이 유독 자주 보인다. 다음에 이런 코드 만나면 성격 판단할 시간에 "이거 과거 흔적이야, 아니면 그냥 굳은 습관이야?"부터 따져볼 생각이다.