YAGNI (You Ain't Gonna Need It)

YAGNI 원칙, 넌 이게 필요 없을거야 라는 뜻을 가지고 있다. 즉 뭐냐? 개발을 할때 필요한 작업만 하라는 것이다.

코딩을 하다보면, 현재는 사용하지 않지만 미래의 확장성을 대비하여 불필요한 작업들이 있을것이다. 추상화일수도 있고 메서드 분리일수도 있고 어떤 형태로돈 리팩터링을 해놓거나, 혹은 사용되지 않을 쿼리나 패턴들을 적용해놓은 코드 모듈들을 개발해놓을 수도 있을것이다.

과연 그렇게 만들어놓은 것들이 정말 도움이 될까? 난 적어도 그런 취지로 만든 새로운 기능들이나 바뀐 포멧의 코드들이 부채로 남는것을 주로 보았지, 그 변경사항이 다른 코드들에도 적용되고 자주 사용되는 것은 거의 보지 못했다.

현재는 사용하지 않는, 미래 어느 시점에 사용될지 모르는 코드가 많아지면 불필요하게 장황해지고, 보통의 경우엔 팀원들과 공유하기도 힘들것이다. 변경사항을 PR로 올려두게 된다면, 핵심적인 변경사항에 초점을 맞추고 팀원들에게 컨텍스트가 공유가 될텐데 그 중간에 자잘한 리팩터링과 이런저런 기능을 짬뽕해두면 팀원들은 절대 그 변경사항을 인지하지 못한다.

그러니 당장 필요한 작업에 집중하고 쓸데없는 작업은 하지말라는 원칙이다. 오히려 핵심적인 로직에 시간을 쏟아야 하는 상황에서, 다른 작업들로 인해 비용이 소모가 되면서도 소모한 비용이 부채로만 남게 되니까 말이다.

오히려 다른 작업들 이것저것 신경을 쓰면 개발생산성도 저하된다. 많은 작업량에 인지부하로 인해 시작하기도 지체될 수 있으니 말이다.

리팩터링 주기 #

리팩터링이란 것이 참 모호하다. 우리 코드의 생산성과 확장성을 위해 현재 존재하는 기술부채나 레거시 시스템을 정리하고 더 좋은 구조로 바꾸는것을 목표로 둘텐데. 리팩터링을 하다 실수로 동작이 바뀌거나 더 읽기 어려운 코드가 될 수도 있기 때문이다.

리팩터링은 팀원들과 함께 개발을 하는 입장이라면 웬만해서는 리팩터링데이를 잡고 하는것을 추천한다. 몇몇 회사들은 도입중이라고는 하는데. 필자는 사실 코드가 좀 더러워도 팀원들이 잘 컨트롤할 수 있다면 괜찮다는 취지의 입장이긴 하다.

rename이나 죽은 코드 제거(DEAD CODE ELIMINATION) 이런 변경사항들은 자잘자잘한 pr에 겹쳐서 넣어도 난 괜찮다고는 생각하지만, 도메인 코어 로직 분리나 개별 ui의 디자인 시스템화, 스택 전환같은 변경사항들은 충분히 팀원들과 논의해보고 의사결정 후에 진행해보자.

확장성을 높히겠다고 무리한 추상화나 디자인 패턴을 도입하게 된다면, 오히려 데이터 지향 프로그래밍 위주에 코드에서 객체지향으로 변경되는 것을 적응하지 못하고, 반복적인 보일러플레이트 코드가 반복적으로 생기며, 여러가지 사이드 이팩트가 생길수있을거라고 생각된다.

그리고 몇몇 코드들에는 타협점이 생겨 하드하게 들어간 부분들도 있을 것인데, 타협으로 인한 하드코딩이 나쁘다고 생각하면 안된다. 물론 더러운건 부정할 수 없지만, 해당 타협으로 인해 아낄 수 있는 리소스를 생각하면 괜찮은 트레이드 오프라고 생각한다. (ex. 특정 uid의 유저에 대해서는 이렇게 동작하기 .. 와 같은 코드 아래참고)

fun doSomething(userUid: Int) {
    if(userUid == 12234) {
        reject()
    } else {
        validate()
        accept()
    }
}

위와 같은 코드도 더럽긴하지만, userUid 11234에 대한 특정 작업처리가 복잡하다면, 그리고 식별하기가 복잡하다면 저런 방식도 좋은 선택이라고 볼 수 있다. 1년뒤에 삭제해놓자고 주석같은걸 달아놓거나 하긴 해야겠지만 말이다.

트레이드 오프 #

일단 개발을 하다보면 많은 트레이드 오프 사이에서 의사결정을 할건데, 자주 보이는 실수가 지금 당장보다는 미래상황에 비중이 가있는 회의가 많다는 것이다. 웃긴건 미래를 예측하는데 선형회귀와 같은 방법으로 지표를 뽑아내는 것도 아니고 그냥 휴리스틱하게 그러지 않을까라는 생각을 하는 분들이 보일때가 있다.

물론 새로운 엣지 케이스 검출이나 그런 부분에 대해서 검출하는 것은 좋다. 그건 user flow에서 발생할 수 있는 오동작들을 방지하는것이니 좋지만, 내가 여기서 말하는 바는 쉬운 솔루션이나 팀원들이 익숙한 솔루션들로도 감당이 가능한 경우지만 그저 네임벨류나 빅테크 기업들의 글들로 인해 이게 정답이라는 억지를 부리는 것이다. (정작 왜 좋은지도 모른다. 안다면 안골랐겠지 애초에)

그것이 지적 허영심이나, 내가 성장하고 싶어서일수도 있겠지만. 그것은 이유가 될 수 없다. 우리는 회사에서 개발을 하고있고 회사 프로덕트에 있는 자원을 최대한 활용해 최소한의 손해와 최선의 결과를 내는것이 좋은 개발자다. (만약 아니라고 생각한다면 혼자 개발하고 창업하는 것을 추천한다. 조직이동을 해보거나 이직을 하거나. 나쁘다는 의미로 말하는것은 아니니 오해하지 말아줬으면 한다)

나도 신기술 많이 써보고싶고, 이런저런 기술들 다 해보고싶지만, 결과적으로 핵심적인것은 그런 역량보다 지금 당장 회사에서 내려진 미션을 수행하는 것이 가장 중요하다고 생각한다. 근데 이것은 개발자로서 실격이 아니고 수직적인 것도 아니다. 일단 고객에게 만족을 주는것이 우선되어야 사업에 성공하는 것이고, 사업이 성공해야 다양한 기회들과 여러 기술들을 사용해볼 수 있는 범위가 넓어진다.

아쉽게도 기술에 편향된 개발자들치고 클라이언트의 반응을 중요시 여기지 않는 개발자분들은 한분도 본적이 없는것같다 아직까지