[개발 일정관리] #2. 개발 업무에 대한 이해
안녕하세요! (주)이노핀의 CTO를 맡은 김한울 입니다. 지난번에 작성한 글에 제 생각 이상으로 많은 분이 호응을 보내주셔서, 좀 더 짧은 주기로 글들을 더 연재해볼까 합니다.
지난번 글에서 개발 일정산정이 어려운 이유 중 3번째로 "개발자의 업무 특성"에 대해 언급 드린바 있는데, 이번 글에서는 이 주제로 글을 적어보도록 하겠습니다.
편의상 말을 낮춰서 적는 점 양해 바랍니다.
—
"개발 업무의 특성은 무엇인가?"
이 질문은 비 개발자에게는 매우 이해하기 어려운 주제이고, 심지어 그것은 개발자에게도 마찬가지이다(개발자들은 동의할 것이다. 내가 하는 업무를 비개발자에게 설명하기란 정말 어렵다). 개발자를 이해하고자 하는 글은 비교적 많은 편인데, 이 글에서는 오히려 개발 업무에 대한 설명을 함으로써 역으로 개발자를 이해할 수 있는 쪽으로 글을 전개해보겠다. 더불어 이러한 특성을 개발 일정 산정과 연결해 그것이 왜 어려운지에 대한 부분도 함께 언급하고자 한다.
개발 업무는 언뜻 생각하기에 수치, 효율, 정형화, 정량 등의 특성을 반영한다고 오해하기 쉽다. 논리적이고 수치적이니 예측하기도 쉽고, 딱 떨어질 것이라는 그런 생각 말이다. 작은 SW프로젝트는 오두막을 짓는 것에, 큰 SW프로젝트는 빌딩을 짓는 것에 비유하면서, 구현된 설계도를 바탕으로 정확히 단계를 밟아 건설하는 형태를 떠올릴 수도 있겠다.
그러나 실상은 전혀 다르다. 14년차 개발자로서, 나는 개발 업무는 논리를 요구하지만, 그 업무의 형태는 오히려 예술가의 그것과 비슷하다는 생각을 한다. 창조적이고, 정량화하기 힘들며, 때로는 영감이 필요한 그러한 예술의 작업 말이다. 나는 이러한 개발 업무의 특성을 아래 3가지로 정리해서 설명해보고자 한다.
- 더 좋은 코드가 존재한다.
- 사고가 난다. 비교적 자주.
- 몰입상태를 요구한다.
—
“더 좋은 코드가 존재한다.”
얼마 전에 레고 타이타닉이 출시되었다. 굉장히 많은 부품 수를 자랑하는 제품인데, 이 제품은 7살짜리가 만들든, 레고 경력 10년의 전문가(?)가 만들든 설명서대로 잘 만들었다면 그 제품은 동일하다. 더 잘 만든 제품도, 덜 잘 만든 제품도 없다. 위에서 건설을 예로 들었는데, 아파트 101동 101호나 102호에 존재하는 문이나 창문의 형태는 같은 것과 마찬가지다.
그러나 개발 업무는 이렇지 않다. 요구된 기능을 구현하는 것은 1차적인 문제이다. 더 좋은 코드가 존재한다. 더 안정적인 코드가 존재한다. 예외처리를 더 많이 한 코드가 존재한다. 검증(테스트)을 더 많이한 코드가 존재한다. 유지보수하기 더 쉬운 코드가 존재한다. 클린한 코드가 존재한다.
주니어 개발자와 시니어 개발자에게 동일한 기능의 구현을 맡기면 반드시 다른 코드가 나온다. 실력이 뛰어난 개발자일수록 남들이 이해하기에 더 쉬우면서도 깔끔하고, 주니어가 생각하지 못한 예외 사항을 다 커버하며, 안정적이고 테스트 코드 또한 마련되어 있다. 확장하기도 쉬우며, 재사용할 수 있는 부분을 분리한다.
그리고 올바른 개발자라면, “더 좋은 코드를 작성하고 싶다.” 마치 예술가가 더 좋은 작품을 만들고 싶은 것처럼 말이다. 반복 사용되는 코드를 제거하고, 구조화를 하고, 변수명 하나에도 심혈을 기울이며(괴로워하며) 요구사항을 구현하고자 한다.
그런데 이러한 개발자의 특성이 왜 개발 일정 관리와 연결되는가? 그것은 만약 여유가 없는 빡빡한 일정에 개발하라고 한다면, 개발자는 ‘기능 구현’이라는 TO DO 그 이상을 잘 하려고 하지 않을 것이기 때문이다. 코드의 질이 떨어지는 것이다.
이는 자기만족을 위한 업무와는 다른 이야기이다. 작곡가가 A급 곡이 아닌 C급 곡을 만들어냈다고 해서 딱히 문제가 생기지는 않을 것이다. 그냥 곡이 잘 안 팔릴 뿐일 것이다. 그러나 개발 업무에서는 그렇지 않다. 실무에서 굳이 S급 코드를 작성할 필요는 없을 수 있다(S급 코드는 자기만족의 영역일 수 있다). 그러나 그 코드가 C급, D급이라면 기능은 구현된 것 같지만, 정작 테스트/실사용 때 버그를 쏟아내기 시작할 것이다. 나중에 재작업을 해야 할 수도 있고, 아예 코드를 폐기해야 할 수도 있다.
즉 개발 업무에서 충분히 좋은 코드를 작성하지 않는 한, 그 코드는 언제든 문제를 일으킬 수 있다는 것이다. 그리고 이러한 부분들이 아무리 좋은 개발자라도 좋은 개발 문화의 바탕 없이는 좋은 결과를 낼 수가 없는 이유이기도 하다(이에 대해서는 기회가 되면 더 다뤄보겠다).
—
“사고가 난다. 비교적 자주.”
개발자의 업무를 측정할 수 있는가? 가능하다. '일반적'으로라면 유능한 개발자일수록 매우 정확하게 측정할 수 있다. 개발경험이 풍부한 팀장은, ‘일반적인 상황’에서의 팀원들의 개발 속도를 충분하게 측정할 수 있다.
그러나 현실은 그렇지 않다. 개발자가 작성하는 코드가 ‘독립적이지 않기 때문’에 예상치 못한 사고가 나기 때문이다. 네비를 찍고 차량을 운전하면, 네비에서 예측하는 도착시각과 크게 다르지 않게 갈 수 있다. 그러나 만약 도로에서 어떤 사고가 났다면? 10분 거리가 갑자기 1시간이 되기도 한다. 이러한 일이 개발 업무에서는 ‘비교적 자주’일어난다.
내가 운전하다 사고를 낼 수도 있듯, 스스로의 논리 문제로 사고가 날 수도 있다. 그러나 그것 뿐이라면 ‘비교적 자주’라고 덧붙이지 않았을 것이다. 개발 업무에서는 내가 통제할 수 없는 수십 개 이상의 외부요인이 있기 때문이다. 작은 프로젝트에도 의존하는 오픈소스 라이브러리나 모듈 등이(dependencies) 많이 존재한다. 그뿐만이 아니다. 웹 개발이라면 브라우저를 고려해야 한다. PC/모바일 환경을 분리해 생각해야 한다. 앱이라면 안드로이드/iOS를 고려해야 한다. 게임 개발은 CPU/그래픽카드 등 하드웨어까지 고려해야 한다.
그래서 예측하지 못한 사고가 난다(흔히 개발자들은 이를 ‘삽질’이라고 표현한다). 오늘 충분히 완료될 수 있을 것 같았던 부분에 갑자기 알 수 없는 에러가 발생한다. 왜 안 되는지, 이게 왜 이러는지 고민하면서 인터넷을 뒤져본다. 바로 해결이 되면 다행이지만, 종종 어떤 문제들은 개발자를 며칠간 고생시키기도 한다.
알고보면 쉬운 문제이기도 하고, 알고 보면 어이없는 문제이기도 하다. 논리적 오류일 수도 있고, 의존하고 있던 모듈에서 발생한 버그이기도 하다. A라는 모듈과 B 모듈을 따로 쓸 때는 문제 없었는데, 같이 쓸 때 충돌이 발생하는 경우도 있다. 안드로이드OS 문제이기도 하고, 버전 업에 따른 iOS 버그이기도 하다.
경험 많고 뛰어난 개발자는 사고를 덜 겪긴 하지만 사고에서 벗어날 수는 없다. 트렌드의 전환이 빠른 개발 영역일수록, 계속해서 더 새로운 라이브러리와 기술들이 등장하는데, 내가 의존하는 모든 것들에 대해 완전히 알기란 불가능하며 그럴 필요도 없기 때문이다.
흔히 농담의 주제로도 사용되곤 ‘대학생 조별과제’를 떠올려보자. 고작 4명 정도가 조를 짜서 과제를 해도 사고가 나기에 공포의 대상이 되었다. ‘변수’란 말 그대로 가변적 요인인데, 개발 업무는 혼자 맡은 업무도 항상 10명 이상이 조를 짜서 과제를 하는 것처럼, 가변적 요인을 항상 안고 떠안고 업무를 한다고 이해하면 되겠다. 그리고 이러한 요인이 개발 일정 관리를 어렵게 하는 이유 중 하나이다.
—
“몰입상태를 요구한다.”
개발자들이 업무를 하는 모습을 지켜보면, 대다수 이어폰이나 헤드셋을 착용하고 있는 것을 종종 볼 수 있다. 이는 음악을 듣기 위함이라기보다, 외부로부터 자신을 차단하기 위함이다. 기본적으로 개발 업무는, 마치 수학문제를 풀 때처럼 몰입상태를 요구한다.
몰입(flow)을 요구한다 함은, 개발자는 업무를 할 때 항상 일련의 흐름에 동행하는 집중을 해야 한다는 것이다. 영 단어를 암기할 때는 흐름이라는 것이 딱히 존재하지 않지만, 글 속에서 주제를 찾아내는 과정의 집중에는 흐름이 필요한 것처럼 말이다. 1번 문제를 거의 다 풀었는데 누군가 갑자기 자신을 불러서 그 흐름이 깨지면? 다시 그 연산의 과정을 머리로 밟아야 한다면? 매우 스트레스를 받을 뿐 아니라 업무가 늘어지게 된다.
복잡한 부분을 코딩하고 있을수록, 이러한 몰입상태는 개발자에게 몰입하고 있다는 고양 감과 함께 의지력을 많이 소모하게 한다. 그리고 이러한 몰입의 상태는 ‘일을 안 하고 있는 것처럼 보여도’ 지속되곤 한다.
글의 앞부분에 개발 업무가 예술과 언뜻 비슷한 부분이 있다고 한 이유가 여기 하나 더 있는데, 마치 예술가가 영감을 받아 시를 써내려가거나 곡을 만드는 것과 같이 개발자도 어느 한순간에 코드를 쏟아내고 하기 때문이다. 물론 개발자의 영감이란 것 역시 다른 예술가들이 그러하듯 머릿속으로 끊임 없이 논리구조와 알고리즘을 고민하다가 나타나는 것이며, 우연의 산물은 아니다.
문제는 이러한 개발 업무의 특성 때문에, 책상 앞에 앉아 있는 시간이 꼭 개발자의 아웃풋과 비례하지는 않는다는 것이다. 매우 중요하고 어려운 부분을 개발하다 보면, 머릿속에서는 그 문제에 관한 내용을 계속 곱씹게 된다. 심지어는 의식하지 못하는 사이에도 그러하며, 침대에 누웠을 때나 꿈에서까지 그러기도 한다. 자다가 깨서 갑자기 코딩했다는 이야기도 종종 듣는다.
물론 이러한 특성과 몰입에 대한 내용은 개발 업무에만 국한되는 특성이 아니다. 모든 업무의 형태에는 설거지와 같이 거의 생각 없이 손만 놀려서 할 수 있는 일과, 집중하지 않으면 아예 진행되지 않는 일이 있을 것이다. 그러나 개발 업무는 대부분 집중을 요구하는 특성을 가지고 있다.
참고로, 이러한 흐름의 특성 때문에 동일한 8시간을 A프로젝트에만 쏟는 것과, A에 4시간, B프로젝트에 4시간을 쏟는 것에는 그 효율에서 매우 큰 차이가 난다. 후자는 프로젝트를 전환하고 새로운 흐름에 동화되기 위한 의지력 소모가 또 필요하고 이는 상당히 스트레스를 주는 일이기 때문이다.
—
글의 초반부에 개발 업무는 “창조적이고, 정량화하기 힘들며, 때로는 영감이 필요한” 예술의 작업과 유사한 부분이 있다고 하였다. 이는 위에 설명하였듯,
- 다양하고 번뜩이는 방법으로 더 좋은 코드를 작성할 수 있기에 창조적이고
- 코딩이란 독립적이지 않기에 변수가 많아 정량화하기 어렵고
- 몰입하다가 한꺼번에 많은 코드를 작성하기에 마치 영감을 받는 것 같은
특성을 보이기 때문이다. 마치 인생의 여러 부분에서 양 극단에 있는 것처럼 보이는 것들이 실상 닮은 모양새를 보이는 것과 같이 말이다. 그래서 무엇보다 논리적인 작업의 집합으로만 보이는 SW 프로젝트들의 일정 달성률이 처참한(?) 이유가 아닐까.
이번 글을 끝으로 “개발 일정 산정이 어려운 이유” 3가지를 모두 다루어보았다. 이제 다음 글부터는 본격적으로 어떻게 하면 효과적으로 개발 일정을 관리할 수 있는지에 대한 주제를 다루어보도록 하겠다.