이 글은 IDG의 아티클을 전재하여 제공합니다.
[원문보기] : https://www.ciokorea.com/column/342472#csidxcfc39911fe018d9b7469c47d41da5e3
시니어 개발자가 되기 위해 무엇이 필요한지에 대한 글을 보면 대부분 소프트 스킬에 초점을 맞추고 있습니다. 기술을 최신 상태로 유지하고, 의사소통 방법을 배우고, 후배 개발자를 멘토링하라는 식입니다. 이런 권장 사항은 모두 필요하고 적절하지만, 솔직히 말해서 다소 공허하기도 합니다. 사실 시니어 개발자와 주니어 개발자의 본질적인 차이는 소프트웨어 개발 현장에서 보낸 시간의 크기와 이에 따른 교훈입니다. 이를 염두에 두고 시니어 개발자가 힘들게 얻은 경험을 통해 알고 있는 4가지를 정리했습니다.
명확한 코드를 작성한다
개발자가 할 수 있는 가장 중요한 일은 읽기 쉬운 코드를 작성하는 것입니다. 이는 너무나 당연하므로 말할 필요도 없습니다. 하지만 세상에는 쉽게 읽을 수 없는 코드가 엄청나게 많습니다. 너무 많은 코드가 미래의 어느 시점에 누군가 읽어야 한다는 사실에 고려하지 않고 작성됩니다. 그리고 우리 대부분은 그 불쌍한 사람이 바로 내가 될 수 있음을 간과합니다. 좋은 코드는 나중에 읽힐 목적으로 작성될 뿐만 아니라, 디버깅을 목적으로 작성되기도 합니다. 모든 언어가 다르고 모든 디버거가 각자의 방식으로 작동하지만, 코드는 항상 디버깅하기 쉬운 방식으로 작성해야 합니다.
놀랍게도 읽기 쉬운 코드를 작성하는 것과 디버깅하기 쉬운 코드를 작성하는 것은 서로 밀접한 관련이 있습니다. 디버깅의 대부분은 특정 순간에 실행 중인 애플리케이션의 상태를 이해하는 것입니다. 코드가 실행될 때 함수, 클래스 등을 명확하게 선언하면 디버거에서 해당 코드가 어떤 상태인지 확인할 수 있습니다. 또한 코드를 가독성 있게 만드는 장점도 있습니다.
코드의 명확성은 주석이 필요 없는 코드를 작성할 때도 중요합니다. 일단 개발자가 코드에 주석을 달 필요가 있다고 느낀다면 그 이유를 자문해야 합니다. 코드가 명확하지 않기 때문에 주석이 필요하다고 생각하는 것이 아닌지 의심해야 합니다. 이런 의견에 동의하지 않는 이들도 있겠지만, 놀랍게도 세상에는 코드에 모든 줄에 주석을 달아야 하는 기업이 있습니다. 하지만 개발 업계에 오래 종사할수록 주석이 필요하지 않다고 더 강하게 믿는다. 코드에 주석을 달아야 할 필요가 있다고 생각되면 코드를 다시 작성하는 것이 맞다. 주석이 필요하지 않도록 처음부터 코드를 작성하는 것이 더 좋은 방법입니다.
단순하고 직관적인 코드를 작성한다
복잡성을 피하는 것은 좋은 코드를 만드는 데 매우 중요합니다. 그리고 코드의 복잡성을 피하는 방법은 사실 간단합니다. 단순하고 직관적으로 쓰되, 복잡한 것은 절대 작성하지 않으면 됩니다. 말장난처럼 들리겠지만 그렇지 않습니다.
실제로 복잡성은 피하기 쉽습니다. 한 가지가 두 가지 이상 기능을 수행하지 않도록 하면 됩니다. 실제로 소프트웨어에서 복잡성이 시작되는 부분이 2가지 이상 기능을 하는 엔티티입니다. 코드 베이스의 모든 엔티티가 단일 기능만 하도록 작성하면, 무엇이든 수정해야 할 때 하나만 고치면 됩니다. 클래스, 메서드, 함수, 코드 한 줄 등도 마찬가지입니다. 모든 것이 한 가지 이상의 일을 해서는 안 됩니다. 물론 '한 가지 일만 하는' 모든 부분이 상호작용하면 복잡해지기 마련입니다. 하지만 무언가가 고장 나면 이를 고쳐도 고장 난 부분에만 영향을 미치고 다른 부분에는 영향을 미치지 않게 됩니다.
단, 코드에서 복잡한 것을 작성하지 않는 것과 복잡한 시스템을 만들지 않는 것은 다릅니다. 고급 스위스 시계가 복잡하고 정교한 기기이긴 하지만 기어와 스프링과 같은 단순한 부품이 모여 이 복잡성을 만들어내는 것과 같습니다. 이런 생각을 염두에 두고 코드를 작성하면 코드의 복잡성을 줄일 수 있습니다.
서두르지 말고, 신중하게 코드를 작성한다
네이비 실의 모토가 바로 "느림은 부드러움이고 부드러움은 빠름"이라는 것입니다. 이들은 긴박한 상황에서 생사를 가르는 결정을 내려야 하지만 그럼에도 이런 모토를 갖고 있습니다. 직관적이지 않은 것 같지만 생각해 보면 완벽하게 이해가 됩니다. 서두르면 실수를 저지르기 쉽고, 서두를수록 실수할 확률이 높기 때문입니다. 실수하면 되돌리는 데 많은 시간이 걸립니다. 서두르지 않고 천천히 진행하면 실수를 줄이거나 없앨 수 있으며, 실수하지 않으면 전체 프로세스가 더 빨라집니다.
노련한 개발자는 이 원칙이 코드에도 적용된다는 것을 알고 있습니다. 서두르는 코드는 나쁜 코드입니다. 시니어 개발자는 시간을 들여 처음부터 올바르게 작업하면 실수가 줄어들고, 이해하기 어려운 코드가 줄어들며, 코드를 유지, 관리할 때 더 좋은 결과를 얻을 수 있음을 압니다. 서두르면 좋을 것이 아무것도 없음을 압니다. 이처럼 훌륭한 소프트웨어는 코드를 작성할 때 신중하고 사려 깊은 태도를 갖는 데서 시작합니다.
장기적인 관점에서 코드를 생각한다
우리 모두 해봤습니다. 주말 동안 새로운 기능을 개발하기 위해 모든 것을 해킹하고, 우리가 하는 일의 품질을 완전히 무시한 채로 작업한 경험 말입니다. 여기에는 여러 가지 이유가 있겠지만, 대부분 돈 때문입니다. 월요일 아침에 자료가 없으면 잠재고객은 계약을 체결하지 않거나 경쟁사로 떠날 것입니다. 때로는 컨퍼런스에서 프레젠테이션을 위해 데모를 완성해야 하는데 그 데모가 실제 기능으로 바뀌는 경우도 있습니다.
그러고는 우리는 항상 후회합니다. 예외가 없습니다. 하지만 피할 수 없는 버그가 발견돼도 코드 자체를 수정하기가 어렵습니다. 기능들을 볼트로 끼워 맞췄기 때문에 애플리케이션의 다른 모듈이 손상돼 또 다른 비즈니스에 차질을 주기도 합니다. 멈추지 않는 회전목마 같은 일이지만, 어쨌든 이런 일이 벌어집니다. 유능한 선임 개발자는 이런 상황을 최대한 피하고, 문제가 발생했을 때 피해를 최소화하는 방법을 알고 있습니다.
마무리
정리하면 커뮤니케이션 기술과 후배 개발자를 멘토링하는 것도 시니어 개발자가 해야 할 중요한 일입니다. 그러나 경험을 통해 알고 있는 것이야말로 시니어 개발자를 진정으로 차별화하는 요소입니다. 시니어 개발자는 코드를 명확하고 단순하게 유지하고, 천천히 진행하며, 긴 안목으로 바라보는 방법을 알고 있습니다.
▶ 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶ 해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.
InfoWorld의 Contributing Writer