by
Dec 06. 2023
기술에 매몰된 개발자는 나쁜 개발자다.
개발자들 사이에서 종종 답이 없는 것으로 갑론을박이 펼쳐지곤 한다. 극단적인 예를 들자면 다음과 같은 것이다.
if (a < 0) return false
if (a < 0) {
return false
}
둘 중 어떤 방법을 쓸까?
이런 것을 따지는 것이 그렇게 중요한가? 중요하지 않다는 것이 아니다. 집착하고 매몰될 필요가 없다는 것이다. 본인이 속한 조직에 가장 알맞은, 아니 적당히 괜찮을 것 같은 통일성을 가지고 컨벤션을 정하면 될 일이다. 대충 정하라는 것이 아니다. 구성원 간 생산성을 증가시키는데 도움이 될 만한 수준이면 충분하다는 의미다.
사소한 예로 시작했지만 만약 이것을 객체 지향, 아키텍처, 클린 코드 등으로 확장하면 어떨까?
완전무결한 기술에 대한 환상
제 아무리 클린 코드니 뭐니 해도 당장 조직에 필요가 없다면 무슨 소용인가? 그리고 어떤 조직이 '우리는 클린 코드를 유지하고 있습니다!'라고 당당하게 말할 수 있을까? 그렇게 보면 클린 코드는 유니콘이다.
물론 그 유니콘이 합리적인 경우가 많다. '아키텍처를 도입하면 개발 속도가 빨라지고 유지보수가 쉬워진다.' 이렇게 말하면 대부분 아키텍처의 일반적인 장점이나 이론을 떠올릴 것이고 결국 수긍할 것이다. 하지만 그 장점과 이론은 어디로부터 나온 것일까? 특히 그 장점을 경험해 본 사람이라면 아마 그에 대한 긍정적 신념이 확고할 것이다.
그러나 아무리 좋은 것도 항상 옳고 좋은 것은 아니다. 특정 아키텍처에 대해 무지한 인원들로 구성된 조직이라면 해당 아키텍처가 적용된 코드가 주어졌을 때 개발 속도가 빨라질까? 이상적이라면 그렇다. 처음엔 큰 변화가 없거나 심지어 악화될 수도 있을 것이다. 하지만 장기간 그 코드를 보게 된다면 결국 적응하게 될 것이다. 하지만 당장 속도가 급하다면?
그 아키텍처에 대해 모른다고 하더라도 잘 짜인 구조 덕분에 새로운 기능 추가나 수정을 하기 좀 더 쉬울 수도 있다. 그런데 아키텍처 자체에 대한 이해 없이 그렇게 욱여넣고 땜질을 하고 시간이 흐르면 결국 엉망진창이 되고 말 것이다. 설사 초기에 해당 아키텍처에 대해 학습을 하고 정말 그 구조를 잘 지키려고 노력했다고 하더라도 여러 가지 현실적인 문제로 하나 둘 구멍이 생길 수 있다.
어쩌면 많은 레거시 코드가 이런 역사를 가졌을지도 모른다.
업계에서 어떤 기술들이 강조되는 이유에 대한 생각
그러면 도대체 이런 유니콘 같은 기술들이 왜 중요하다고 강조될까?
첫째, 그것들이 좋은 것은 사실이다. 이상적인 것이 나쁠 수가 있나? 그리고 이상적인 것을 추구하는 것이 나쁘다고 할 수 있을까? 그걸 달성하려고 노력하는 것은 너무 좋은 것이라고 생각한다. 그리고 그에 대해서 활발히 논의되는 것도 좋다고 생각한다. 어느 공학자가 순수과학을 중요하지 않다고 하겠는가.
둘째, 전염되고 유행이 된다. 이상적인 모습을 갖춘 성공 모델을 만든 경험을 하면 그것은 각종 콘퍼런스나 기술 블로그 등을 통해 전파된다. 그럴 여건이 되는 조직에서 달성한 경험이 마치 정답처럼 번진다. 그렇다면 유행에 민감한 혹은 성장에 목마른 이들이 그 기술을 학습할 것이다. 그런 사람들이 다시 성공 모델을 만들 것이고 그 조직이 잘되면 빅테크가 될 수도 있다.
애초에 그런 사람이 많은 조직은 이미 빅테크일 가능성이 높다. 아니면 어떤 빅테크에서 해당 성공 모델을 도입하기 위해 혹은 그 기술을 내재화하기 위해서 그 기술을 학습한 이들을 채용할 것이다. 결국 그럴만한 여건이 되는 조직에서 그런 기술들을 도입하게 되는 것이고 거기에 그런 사람들이 계속해서 모이게 되는 구조가 된다. 그러면 그런 성향의 사람들이 모였으니 거기서 또 새로운 어떤 것이 만들어지고 전파되는 순환 현상이 발생할 것이다.
보통 그럴만한 여건이 되는 기업은 이미 업계에서 좋은 평가를 받고 있을 가능성이 크다. 그러니 그 기술에 대한 권위가 생기고 신성화가 될지도 모른다. 이제 그 기술은 거의 업계 표준이 되고 당연히 필요한 자격 요건으로 굳어진다.
나아가 해당 기업의 구성원이나 이미 유명한 개발자들이 해당 기술에 대한 발표 등을 한다면 다시 한번 해당 기술에 대한 권위가 강화된다. 더불어 발표자의 인지도와 평판도 올라가게 될 것이다. 이것은 새로운 기술이 등장할 때마다 반복되어 스노우볼 효과로 이어질 것이다.
이러한 것을 잘 이용한 것이 기술 전문가이면서 기술 홍보대사까지 될 수 있는 구글의 GDE, 마이크로소프트의 MS MVP가 아닐까? 해당 기술을 잘 알고 잘 전파하는 이들에게 공식 인증을 통한 권위를 부여함으로써 더욱 강력한 전파력을 가지도록 한다.
우리의 밥 아저씨! 로버트 마틴은 모든 조직에서 최고의 개발자인가? 그렇든 아니든 그의 책 클린 코드가 강력한 권위를 지니고 있다는 것은 부정할 수 없다. 많은 개발자들이 클린 코드를 추구한다. 물론 좋은 내용들이다. 하지만 일정에 쫓겨 시간이 없는 상황에서는 의미가 퇴색된다. 정말 좋은 내용이더라도 상황에 따라 실천하지 못할 수도 있다.
다시 한번 강조하지만 이런 이론들과 기술적 논의가 불필요하다는 것이 아니다. 반드시 필요하다. 일종의 연구 분야로 생각한다. 모든 연구가 무조건 상용화되지는 않고 상용화되기까지 시간도 많이 걸린다. 그리고 상용화되었다고 해서 감기 환자에게 암 치료제를 처방할 수 없는 노릇이다.
개발자의 좋은 기술 vs 사용자의 좋은 기술
좋은 기술이지만 무조건 사용할 수 없는 이유는 무엇일까?
개발자의 관점에서 바라볼 때 그것이 '좋은 기술'일 수는 있지만 그것으로 얻을 수 있는 가치가 별로 없다면 선택받지 못하기 때문이다. 회사는 기술에 매몰되어 개발을 통해 자아실현을 하라고 월급을 주는 곳이 아니다.
기술 도입 목적은 문제 해결을 위한 것이어야 한다. 많은 회사가 해결해야 할 문제는 비즈니스다. 따라서 기술은 비즈니스를 위한 것이야 한다. 사업 전략에 따른 일정을 지키지 못하는 클린 코드는 가치를 인정받지 못한다. 사용자는 코드가 깔끔하든 더럽든 상관이 없다. 본인이 하려고 하는 동작을 문제없이 수행하기만 하면 된다. 최신 아키텍처로 무장한 업데이트를 야심 차게 선보였으나 사소한 버그 등으로 사용자에게 불편함을 제공한다면 무엇을 위한 업데이트인가? 주객전도의 상황이 아닌가. 더 나은 사용성을 제공하기 위한 수단으로써 사용된 아키텍처가 아닌 아키텍처 적용 그 자체가 목적이 되어서는 안 된다는 말이다.
종종 세계적인 빅테크의 앱이 버그를 뿜어댈 때마다 의아했다. 세계 최고의 개발자를 채용하는 회사에서 이런 버그가 발생한다고? 물론 내가 모르는 기술적 어려움이나 내부 사정이 있겠지만 방어 코드로 땜질해서라도 사용자에게 당도하는 문제를 해결하는 게 최우선이 아닌가 싶어서이다.
힘들었던 코로나 시기에 등장해 전 국민에게 편리함을 제공했던 코로나맵과 같은 서비스를 만들 때 아키텍처나 클린 코드 등을 고민하는데 많은 시간을 썼더라면 빠르게 출시하지 못했을 것이다. (물론 잘 짜인 코드일 수도 있다.) 일단 출시가 되면 그 후 개선점에 대한 더 많은 피드백을 받아볼 수도 있고, 여러 가지 지원을 받아 코드를 개선할 수 있는 기회도 생길지 모른다. 당장 일상생활에서 도움을 받을 수 있는 서비스를 제공하는 것. 사용자의 관점에서 바라볼 때 '좋은 기술'은 바로 이런 것이다.
미안하다. 제목은 어그로를 끌기 위함이었다.
