좋은 개발자란 무엇인가?

1월부터 일을 시작하였으니 엄연한 실무를 담당하는 개발자로 일을 한지도 대략 3개월 정도가 되었다. 그닥 긴 기간은 아니지만 느낀 점이 많다. 무엇보다도 학교에서 배우던 이론과 비교하여 실무는 정말 다르다는 것을 새삼 깨달았다. 일을 하게 되면서 생각하던 부분은 과연 좋은 개발자란 무엇일까에 대한 본질적인 고민이었다. 그간 느낀 점들을 정리하면서 그러한 태도들을 가슴에 새기도록 노력을 하고자 이 같은 글을 적는다.

 

인내심을 기르자

실무에서 코딩을 하면서 느낀점은 코드를 짜는 것은 정말 일부에 불과하다는 것이었다. 정말 이후에 수많은 에러와 싸워야하는데 더 많은 시간들을 보내야 한다. 비즈니스적으로 실무에서 만들어진 프로그램의 규모는 단순히 백준의 프로그래밍 문제와는 다르다. 매우 큰 규모의 코드를 작성한 후 매우 큰 규모의 데이터들을 대상으로 테스트를 돌렸을 때는 그만큼 많고 다양한 원인의 에러들이 발생한다. 멋쟁이사자처럼의 이두희 대표는 "코딩이라는 것은 10%의 코드작성과 90%의 에러 수정"이라고 했다. 이를 완벽히 해내기 위해선 정말 많은 인내심이 필요하다.

 

안정성을 고려하자

이전에는 단순히 프로그램이 돌아가기만 하면(정상작동하여 맞는 output이 나오면) 완성이라고만 생각했다. 하지만 정말 많은 데이터들을 대상으로 하는 프로그램을 만든다면 안정성이 무엇보다 중요하다. 여기서 말하는 안정성은 중간에 프로그램이 멈추도록 하지 않는 것을 말한다. 멈추지 않고 진행되어 반드시 log를 분석해 추후에 이에 대응할 수 있는 장치들을 마련해 두어야 한다.(물론 critical한 에러의 경우는 중단해야겠지만...)

이렇게 해야 하는데는 몇 가지 이유가 있다. 첫째로, 대규모의 데이터들을 대상으로 어떠한 처리, 가공을 하여 저장, 업로드 하는 것은 많은 computing resource를 소모하는데 단 하나의 예외 상황 때문에 모든 것이 멈추도록 설계하는 것이 굉장히 비효율적이라는 것이다. 둘째로, 위에서 말한대로 우리는 "에러에 대응가능한" 코드를 짜야한다는 것이다. 이를 위해선 반드시 증거를 남기도록(예컨대, log를 찍어서) 설계해야 한다. 이러한 이유 때문에 안정성이 중요한 것이다.

안정성에 위배되는 경우는 예를 들어 "else구문을 사용하는 것의 위험성" 같은 것이 있다. 말하자면, else 구문은 if가 아닌(정말 if의 조건에 해당하지 않는 모든 경우)를 else문 안의 명령들을 실행시키도록 강제한다. 나의 경우도 이 같은 실수때문에 발생한 여러 에러를 고치느라 애를 먹었다. 대안은, else 대신 elif를 사용하여 해당 부분의 코드가 돌기 위한 선행조건을 명확히 제시해 주는 것이다. 그 이외의 예외들은 파이썬의 경우 try ~ except 구문으로 잡아주는 것이다.  

 

누가봐도 이해할 수 있는 코드를 짜라.

요즘의 시대에 '실질적으로' 필요한 프로그램은 대규모이다. 정말 많은 이용자와 그들의 트래픽을 감당하고, 또 아주 많은 발생가능한 예외상황들에 대해 대처해야 하며, 복잡하게 얽힌 구조를 통해 많은 기능을 구현해야 한다. 당연하겠지만 이 정도가 되는 규모의 프로그램이 단순히 1명의 개발자에 의해 만들어질 수가 없다. 때문에 협업이 중요한 것이다.(git이 생긴 이유도 그러하듯이....) 

조금 먼 이야기일수도 있지만 직업의식과 윤리적인 측면에서 말하자면, 우리는 우리의 생산물에 적어도 책임을 져야한다는 것이다. 오늘날 IT로 구성되어 있지 않은 서비스는 없다. 은행, 병원, 학교 등 모든 사회적 인프라들을 관리하는 것은 프로그램들이다. 바꿔말하면, 그러한 서비스들을 담당하여 일부를 만들어내는데 내가 일조한다는 것은 어느 정도의 책임감을 필요로 한다. 그런데도, 오직 나만이 알아볼 수 있는 이기적인 코드를 짜는 것은 '내'가 없으면 해당 서비스를 업데이트하는 것조차 불가능하다는 말이 된다.

이전에는 가독성이 좋은 코드라는 것이 내가 나중에 봐도 이해할 수 있는 코드라고 생각했다. 하지만 그것은 당연히 지켜져야 할 것이며 정말 근본적인 것은 "누가보더라도" 이해할 수 있는 코드를 짜는 것이다. 후자가 지켜진다면 전자는 반드시 따라오기 때문이다. 협업을 통한 코드 작성에서는 무엇보다 '커뮤니케이션'이 중요하고 코드의 '가독성'은 그를 실현하기 위한 정말 기본 중의 기본이라고 본다. 이를 지키기 위해선 다음과 같은 것들이 필요하다.

• 코드에 부분 부분 주석을 다는 것을 소홀히하지 않기.
• 주석은 simple하고 clear하게 적기
• docstring(주석보다 긴 설명으로 주로 함수에 대한 설명에 사용)을 잘 작성하기
  • 해당 함수의 기능에 대한 간단한 설명
  • input과 output의 type과 각각에 대한 설명(이 경우 예시가 있으면 더 좋다.) 
• github repository의 readme.md 귀찮더라도 친절히 설명하기

쓰고나니 기본적이고 내가 아닌 누구라도 알 수 있는 것 같다. 하지만 그 기본이 정말 중요하고, 그것을 매순간 지키기 위해 노력하는 것이 어려운 것이다. 앞으로 느끼게 될 새로운 점들을 추가하며 (힘들겠지만^^...) 위의 사항들을 잘 지키기 위해 가슴에 품고 노력하는 프로그래머가 되도록 노력해야겠다.