코드 스타일에 성격이 묻어날까?

리뷰를 하다 보면 가끔 코드 자체보다 "왜 굳이 이렇게 짰지?"라는 생각이 먼저 드는 순간이 있다. 예를 들면 이런 거다.

A 클래스 안에서 충분히 해결 가능한 로직인데, 굳이 B, C까지 람다로 끌고 와서 처리하는 코드.

이걸 보다가 문득 궁금해졌다. 이런 코드 스타일에 그 사람 성격이 반영되는 걸까?

성격일까, 습관일까

결론부터 말하면 "성격"이라기보다는 습관이 굳어진 방식에 가깝다. 다만 그 습관이 만들어지는 배경에는 확실히 성향이 어느 정도 묻어난다.

성향이 비교적 잘 드러나는 부분

• 과설계(over-engineering) 성향: "나중에 확장될지도 모르니까" 하면서 인터페이스를 몇 겹씩 감싸는 경우. 불안이 많거나 완벽주의적 성향과 연결되는 경우가 많다.
• 예외 처리의 촘촘함: 예외 케이스를 꼼꼼히 다루는 사람과 해피패스만 짜고 마는 사람의 차이는 꽤 신뢰감 있게 성향을 반영하는 편이다.
• 커밋 메시지의 정성도: 이건 커뮤니케이션 태도가 꽤 잘 드러나는 지표다.

오히려 성격 판단이 위험한 경우

정작 "A에서 되는데 B, C까지 람다로 끌고 가는" 것 같은 사례는 성격보다는:

• 그 시점의 시간 압박
• 처음 설계할 때 확장성을 고려하다 과했던 흔적
• 리팩토링 타이밍을 놓친 것

인 경우가 훨씬 많다. 구질구질해 보이는 코드도, 알고 보면 과거의 다른 요구사항 때문에 남은 흔적인 경우가 태반이다. 그래서 코드 한 조각만 보고 "이 사람 우유부단하네" 하고 판단하면 꽤 자주 틀린다.

진짜 신뢰할 만한 신호는 "일관성"

한 번의 지저분한 코드가 아니라, 그 사람이 짜는 코드 전반에서 반복되는 패턴이 있는지가 중요하다. 예를 들어 항상 책임을 명확히 나누지 않고 여러 클래스에 로직을 걸치는 경향이 매번 나타난다면, 그건 설계할 때 "경계를 정하는 결정"을 미루는 성향과 연결 지어볼 수 있다.

다만 이것도 "쿨하지 못하다" 같은 가치 판단보다는, "결정을 늦게 내리는 편" 정도의 중립적인 표현이 더 정확할 것 같다.

Kotlin 코드에서는 특히 확장 함수나 람다로 슬쩍 로직을 다른 곳으로 떠넘기는 패턴이 자주 보인다. 다음에 비슷한 코드를 만나면, 성격 판단 대신 "이게 과거 요구사항의 흔적인지, 반복되는 설계 습관인지"부터 구분해보려 한다.