SW 개발을 잘하기 위해서 필요한 것들

SW 업계에 처음 발을 들여놓는 사람들을 위한 안내

뛰어난 SW 개발자는 굉장히 드뭅니다. 그 이유 중 하나는 SW 개발을 잘하기 위해서는 여러 가지 기술과 능력들이 필요하기 때문입니다. 그리고 사실 스타트업으로 성공시키는 개발자가 훌륭한 건지, 뛰어난 기술을 만드는 개발자가 훌륭한 건지, 많은 돈을 버는 제품이나 서비스를 만드는 개발자가 훌륭한 것인지 기준이 좀 애매한 면이 있기는 하지만, 이번에는 SW 개발을 잘하기 위해서 알고 있어야 하는 내용들에 대해서 알아보려고 합니다.

대학 졸업생이나 신입 개발자를 현업에 바로 투입시키기 어렵고 오랜 시간 수련이 필요한 이유 중 하나가 바로 밑에 말할 내용들 때문입니다. 경력 개발자들 중에서도 이런 부분들이 잘 트레이닝되어 있지 않은 경우가 많은데요, 사람마다 중요하다고 생각하는 부분이 다를 수는 있으나 그냥 제 마음대로, 의식의 흐름대로 써보겠습니다.

1. 프로그래밍 언어와 프레임워크

너무나 당연한 이야기입니다. 혹자는 프로그래밍 언어는 단지 도구일 뿐이어서 중요치 않다고 하기도 하는데, 언어는 단지 도구일 뿐이긴 하지만 그 도구를 잘 쓰는 사람과 잘 못 쓰는 사람의 생산성 차이는 큽니다. 평소에는 그 차이가 크게 벌어지지 않지만, 좀 어려운 문제가 주어질 경우 그 차이가 확실하게 드러나게 됩니다.

예를 들어, Java를 주로 사용하는 Android 개발자 중 reflection의 개념을 아는 사람이 많을까요? 많지는 않을 겁니다. 물론 필요할 때마다 찾아서 쓰면 되기는 하지만 이런 개념들은 모른다면, 이런 개념들이 필요한 문제를 해결할 때 아는 사람과의 차이가 벌어집니다. 특정 언어에서 고급 기능들이라 불리는 개념들을 알고 어떻게 쓸지 알고 있다면 이런저런 트릭을 쓰는 방법들로 개발 효율성을 높일 수도 있고요. 이런 것들 때문에 개발자들의 몸값은 극과 극을 달리게 됩니다.

자신이 사용하는 프레임워크나 라이브러리에 대한 이해 또한 중요합니다. 그냥 가져다 쓰기만 하는 개발자는 필요한 기능을 추가하거나, 기능을 수정하기 힘들어하는 경우가 많습니다. 또한 오픈소스 라이브러리의 경우 버그가 있는 경우도 흔하기 때문에 어떤 문제가 있는지 찾고 스스로 수정할 수 있을 만큼의 이해도 필요합니다. 자신이 사용하는 언어나 프레임워크의 보안이나 병렬 처리 등과 관련된 개념들도 잘 알고 있는 것도 중요하겠죠.

2. 객체지향 (OOP) 개념과 디자인패턴

사실 요즘같이 수많은 프로그래밍 방법론들이 난무하는 시대에 OOP 개념을 이야기하는 것은 좀 애매한 감도 있기는 하지만, 제 생각에 객체지향의 수명은 아직 많이 남은 것 같습니다. 그리고 객체지향 프로그래밍은 대규모 환경에서 효과적이기도 하고요. 또한, 현업에서 일해볼 때 신입들이 많이 부족했던 것 중 하나가 바로 객체지향 개념입니다. 학교에서 배우긴 하겠지만, 이걸 효과적으로 활용하여 개발하는 경우는 잘 없었습니다. 디자인 패턴과 같은 것도 사실 호불호가 갈릴 수 있기는 하지만, 규모가 어느 정도 있는 서비스를 개발한다면 이런 개념들을 모르는 사람과 알고 쓰는 사람의 차이는 크다고 생각합니다.

3. 자료구조/알고리즘

사실 항상 시간이 부족한 개발자에게 자료구조나 알고리즘은 그냥 라이브러리를 사용하는 것이 대부분이며, 내부 구조를 까보거나 할 일이 많지는 않습니다. 하지만 새로운 문제를 풀어야 할 때, 남들이 일반적으로는 하지 않는 task 가 주어졌을 때 그 문제를 어떻게 풀지 다각도로 고민하며 접근방식을 만들기 위해선 알고리즘 등과 관련된 지식이 중요합니다.

그것이 바로 많은 회사들이 입사 때 알고리즘과 코딩 테스트를 하는 이유 중 하나라고 생각합니다. (물론 면접같이 긴장된 환경에서의 코딩 테스트가 효과적인지는 또 다른 논란거리이지만) 어쨌든, 시간과 메모리를 절약하기 위한 최선의 알고리즘을 찾는 것은 언제나, 항상 중요합니다. 알고리즘 최적화는 개발에 있어서 언제나 중요한 문제입니다.

4. 리눅스 (Linux/Unix)

개발자로 일한다면 필수적으로 마주칠 수밖에 없는 환경이 바로 리눅스입니다. 우분투와 같은 리눅스를 잘 써야 한다는 내용은 아니고, 리눅스든 MacOS든 쉘과 CLI로 작업하는 데 익숙해져야 한다는 것입니다. 리눅스/유닉스 계열의 CLI 환경은 어떻게 보면 시대에 뒤떨어져 보일 수도 있겠습니다만, 아직도 수많은 프로그램들이 CLI 환경만을 지원하는 경우가 많으며, 생산성 향상을 위해서도 리눅스나 유닉스 계열에 대해 이해하는 것은 중요합니다.

5. 테스트 (TDD)

테스트 또한 현업에서 일할 때 신입들이 잘 안 되는 부분입니다. TDD와 같은 개념들은 실제로 한정된 시간 내로 개발할 때 누구나 잘 안 되는 부분이긴 합니다만, 많은 뛰어난 개발자들이 테스트를 강조하는 데는 다 이유가 있습니다.

물론 대부분 개발자들이 unit test 나 regression test 등이 생산성 향상에 도움된다는 내용들은 많이들 알고 있지만, 실제로 여러 가지 테스트들을 직접 작성해 보고 프로젝트에 적용해 보고, 생산성 향상을 이끌어내는 경우는 그리 많지 않습니다.

신입들의 경우 학교에서 테스트까지 작성해가며 프로젝트를 하는 경우는 잘 없기 때문에, 이 부분이 학교와 회사와의 괴리가 큰 부분 중 하나라고 할 수 있습니다. 따라서, 프로젝트를 할 때면 초기부터 테스트 작성에 습관을 들일 필요가 있습니다.

6. VCS (git)

버전 관리 시스템은 CVS, SVN이 예전엔 쓰였지만, 현재는 git으로 통일되었습니다. 기존의 VCS 들은 거의 사라지는 추세고 git이 천하통일을 한 건 이유가 있어서겠죠. 제대로 쓰면 확실히 좋습니다. 사실 git을 모르는 개발자는 거의 없을 거라고 확신합니다만, git을 제대로 활용하는 개발자들은 그리 많지 않은 것 같습니다.

그 이유 중 하나도 학교와 회사의 차이 때문입니다. git의 장점은 분산 버전 관리로 인한 스마트한 머지 전략과 branching 전략을 다양하게 가져갈 수 있음에서 오는데, 회사에서는 규모가 큰 협업 프로젝트가 많지만 학교에서는 이런 경우가 거의 없기 때문입니다. 그렇기 때문에 많은 개발자들이 git을 마치 SVN 사용하듯 사용하는 경우가 많으며, 그럴 거면 그냥 SVN 쓰는 게 나을 수도 있습니다. 따라서, 신입 개발자라면 규모가 좀 있는 협업 프로젝트를 경험해 보거나 그럴 기회가 없다면 오픈소스 라이브러리 개발에 참여해 보는 것이 좋고, 몇 번 기여를 하다 보면 git에도 많이 익숙해질 것이고 왜 git이 뛰어난 VCS 인지도 알 수 있습니다.

7. 스타일가이드

스타일 가이드 또한 신입들이 잘 모르지만 중요한 부분이며, 어떻게 보면 사소해 보일 수도 있지만 실제 대규모 협업 프로젝트를 한다면 굉장히 중요한 부분 중 하나입니다.

프로그램의 규모가 그리 크지 않았던 옛날에는 존 카멕과 같은 소수의 천재 프로그래머가 짜는 난해한 코드들이 뛰어나다는 평가를 받곤 했습니다. 물론, 지금도 천재 프로그래머의 코드는 아름답습니다. 하지만 요즘은 프로그램의 복잡도가 많이 올라가서 개인의 개성을 드러내기보다는 생산성과 효율성을 따지고 최적화를 하고 버그를 최대한 줄이는 방향으로 코드를 작성하는 추세입니다.

Google, Airbnb 등 굴지의 실리콘벨리 공룡기업들이 괜히 style guide를 만드는 게 아닙니다. 스타일 가이드를 읽어보면 버그를 줄이고, 효율성과 생산성 향상을 위하여 많은 고민이 들어갔다는 것을 느낄 수 있습니다. 물론 코드 스타일에 정답은 없습니다. 하지만 팀이나 회사가 가이드를 정하고, 그 가이드에 프로그램의 목적에 맞는 개념들을 넣는 것은 요즘 같은 때에 중요할 수밖에 없습니다.

8. 협업 (CI, CD, 문서화)

앞에서 이미 협업과 관련된 여러 가지를 언급했는데, 그런 것들을 종합하여 CI, CD 환경을 구성하고 문서화를 하는 것 또한 중요합니다. 이런 부분들은 실제로 규모가 좀 있는 프로젝트를 경험해 보지 않으면 잘 모르기 때문에 신입들이 부족한 부분 중 하나이기도 합니다.

신입의 경우 CI 툴을 이용하여 git 기반의 branching 전략을 적용하고, 커밋 시마다 테스트와 스타일 가이드 체크를 하도록 하고 자동으로 커밋에 대해 테스트 리포트를 작성하게 하거나 배포를 하게 하는 등 프로젝트의 효율성을 높이는 것을 어떻게든 경험을 해 보는 것이 좋습니다.

문서화의 경우 문서화하는 시간이 낭비라고 볼 수도 있기 때문에 의견이 충돌하는 경우가 좀 있는 이슈이기는 합니다. 하지만 정답은 없다고 생각합니다. 회사나 프로젝트 환경마다 최적의 생산성을 낼 수 있는 방향으로 하면 될 것입니다.

다만 신입들의 경우 이런 경험을 아예 못해본 경우가 많으므로, 문서화가 잘 된 많은 오픈소스 프로젝트를 참고하여 프로젝트에 적용해 보는 것을 추천합니다. 포트폴리오를 제출할 때도 깔끔한 문서화가 되어 있고 api doc과 같은 것들이 있다면 좋은 인상을 줄 수 있습니다.

9. 그 외

좋은 SW를 만들기 위해서는 domain knowledge가 가장 중요할 수도 있습니다. 타깃 유저가 잘 사용하고 좋아하는 SW가 훌륭한 SW 이기 때문에 만들려는 SW를 어떻게 해야 잘 만들지는 domain knowledge가 있어야 알 수 있습니다.

또한 의사소통 능력도 중요합니다. 요즘은 혼자 개발하기는 쉽지 않고 협업을 해야 하므로 개발자와의 의사소통이든 다른 직군의 사람들과의 의사소통이든 다 잘해야 합니다.

학습능력도 아주 중요하며, 별 경력이 없는 개발자를 뽑을 때 잠재성으로 평가하는데 일반적으로 학습능력이 얼마나 뛰어나 보이는지에서 판가름 나는 경우가 많습니다. 기술은 너무나 빨리 항상 바뀌기 때문에 학습 능력은 아무리 강조해도 지나치지 않을 것입니다.

또한 수학이나 영어도 중요할 수 있습니다. 수학은 연구할 때 필요하고, 영어는 논문을 찾아 읽든, 기술 블로그나 StackOverflow나 github에서 이슈에 올라온 글을 읽든 항상 중요합니다.

여기에 많은 것들을 적었지만, 어떤 분야인지, 어떤 회사인지에 따라 중요한 것도 다르고, 여기 안 적은 훨씬 더 중요한 것들도 많을 것입니다. 그리고 중요한 것은, 다 잘할 필요는 없으며 천재가 아닌 이상 그럴 수도 없다는 점입니다. 저도 사회성에 문제가 있어서 의사소통도 잘 못하고, 개발하거나 공부할 때 도저히 이해가 안 돼서 부족함을 탓하며 우울해하는 경우도 많습니다. 제가 위에 적은 것들을 다 잘했다면 이미 Google이나 Facebook에 있었겠죠 ㅎㅎ 다만 더 나은 개발자가 되기 위해 항상 노력하고 있습니다.

그러니 SW 개발자의 꿈을 꾸시는 분들은 해야 할 것이 많다는 점에서 압도당해 부담을 느끼지 마시고 그냥 하나씩 하나씩 경험 해 가며 노력하시면 됩니다.