“취미로 개발을 하는 경우와 직업적으로 개발을 하는 경우의 차이점은 무엇인가요?”라고 누가 묻는다면 필자는 아마도 시간이라고 대답할 것이다. 취미로 개발을 하는 경우에는 데드라인이 존재하지 않는다. 전적으로 개발자 자신과의 약속인 것이다. 만들다가 혹 막히거나 힘들다면 프로젝트를 중지하고 발표하지 않아도 그만이다.
하지만 무언가를 직업적으로 개발하는 경우라면 이야기가 180도 달라진다. 항상 데드라인이 존재하고, 기간이 준수되지 않는 것은 실패로 간주된다. 이처럼 중요한 것이 시간임에도 불구하고, 신입 개발자들은 이를 제대로 준수하지 못하는 경우가 적지 않다. 대부분이 함정에 쉽게 빠지기 때문이다. 그럼 그들의 시간을 갉아먹는 함정에는 어떤 것들이 있을까? 여기서 이에 대해 살펴보자.
함정의 근원은 성급함
첫 번째 함정은 설계의 함정이다. 학교에서 소프트웨어 공학 수업을 열심히 들은 신입 개발자들은 그 논리대로 설계를 무척이나 중시한다. 3개월의 개발 기간이 주어지면 두 달 이상의 시간을 설계라는 작업으로 허비하는 것이다. 열심히 노트에 주어진 기능 목록을 나열하고, 다이어그램도 그린다.
하지만 매우 고통스러운 사실은 두 달 동안 설계한 내용들이 코드를 작성하기 시작하는 순간부터 하나 둘 바뀐다는 점이다. 또한 결과물이 없는 두 달 동안 위에서는 그 사람이 일하고 있다고 생각할 수 밖에 없다. 혼자서 코끼리를 만들고 있는지, 로보트를 만들고 있는지 알 길이 없는 것이다. 설계를 검증하는 것이 무의미한 이유는 설계대로 만들지 않기 때문이다. 설계는 늘 우아하고 기품이 넘친다. 하지만 실제 코딩 스킬은 그 설계의 요구 사항을 따라가기에는 부족하다. 따라서 개발에 들어가는 순간부터 설계 명세의 절반은 제외되고 절반은 새롭게 개발된다.
두 번째는 재사용의 함정이다. 학교에서는 흔히 재사용되지 않는 코드는 정말 나쁜 코드인 것처럼 가르친다. 심지어 “심심풀이로 만든 숫자야구 게임이 우주선에 들어가는 컴퓨터에도 사용될 수 있어야 한다”는 이야기만큼이나 학교에서 가르치는 재사용의 범위는 왜곡되어 있다. 재사용이란 지금 당장 돌아가는 코드가 있을 때 생각할 수 있는 문제이다. 이미 있는 코드를 고쳐서 재사용 가능하게 만들기는 쉽지만 처음부터 재사용 가능한 것을 만드는 것은 매우 어렵다. 고참 개발자들에게 뭔가 일이 주어졌을 때 그들이 만들어내는 코드가 재사용하기 좋은 것처럼 보이는 이유는 과거 그들이 그와 같은 코드를 수도 없이 작성했기 때문이다. 반면 신입 개발자들에게는 그와 같은 경험이 없다. 따라서 재사용을 생각하기 이전에 당장 돌아가는 코드를 먼저 작성해 보는 것이 좋다. 비록 두 번 일을 하더라도 처음부터 재사용을 고려해 만들려고 하는 경우보다 시간이 적게 들 것이다.
세 번째 함정은 호환성이다. 호환성의 함정이란 자신의 코드에 지나친 호환성을 부여하려 하는 데서 비롯된다. 가장 흔하게 찾을 수 있는 것이 C/C++ 표준과 운영체제 호환성이다. 자신이 만든 코드가 어떤 C/C++ 컴파일러에서도 돌아가고 다른 운영체제에서도 잘 실행된다는 것은 무척 멋진 일이다. 또한 갈수록 그러한 것이 요구되기도 한다. 하지만 대부분의 경우 여전히 타깃 플랫폼이 존재하고 회사 내부적으로 사용하는 컴파일러가 정해져 있게 마련이다. 이런 상황에서 C/C++ 표준이나 운영체제 독립적인 코드를 운운하는 것은 생산적인 일은 아니다. 해당 운영체제나 컴파일러에서만 잘 돌아가면 일단 프로젝트 진행에는 무리가 없기 때문이다. 심지어 특정 컴파일러의 특수성 때문에 C/C++ 표준이 무시되는 경우도 있다.
필자는 늘 신입 개발자들에게 성급한 최적화만큼이나 성급한 설계, 성급한 재사용, 성급한 호환성이 나쁘다는 이야기를 한다. 대부분의 회사에서 만드는 대부분의 제품은 사용 범위가 특정 환경으로 제한된 경우가 많기 때문이다. 또한 앞에서 이야기 한 것처럼 경험이 많지 않다면 이러한 작업에 시간을 많이 투자하는 것은 결코 좋지 않다. 그러한 작업을 멋지게 끝낸다고 하더라도 그 다음 단계에서 원점으로 돌아가기 때문이다.