독일 스타트업에서 개발하기
소프트웨어 개발자로 지원시에 알아두면 좋을 것들.
일전에 독일 회사에 다니기라는 글로 독일 스타트업에서의 하루 일과를 적어보았던 적이 있다. 그 때 개발 업무에 대해 간략하게 다뤄보았는데, 이번에는 독일 스타트업에 지원할 때 미리 준비하면 좋을 것을 알아보도록 하겠다. 지금 다니는 회사에서 경험을 한 것과 지난해 고통스러운 구직 과정에서 경험한 내용을 바탕으로 작성한 것이다.
1. 애자일, 스크럼
한국 스타트업에서도 대부분 스크럼을 사용하여 프로젝트 관리를 하고 있기 때문에 접할 기회가 많다. 개발 조직의 성향에 따라서 애자일이나 스크럼을 아예 쓰지 못하는 경우도 있는데, 이런 경우에는 반드시 개인 프로젝트를 통해서 개인적으로라도 익숙해질 필요가 있다. 또한 하청 개발이 만연한 한국 IT 여건에서 애자일이나 스크럼을 도입하는 것이 고객사(클라이언트)의 허락이나 양해 없이는 힘들기 때문에 여전히 폭포수 개발 방식으로 프로젝트를 진행하는 경우가 많다. 독일의 대기업에서의 근무 경험이 없다보니 스타트업 이외의 경우에는 어떻게 진행되는지 모르겠지만, 구직 과정에서 검토한 수많은 구인 공고 내용을 살펴보면 애자일과 스크럼 경험은 거의 필수라고 보인다. 독일 스타트업에서는 한국에서 애자일이나 스크럼을 사용할 때보다 좀더 교과서적으로 적용하여 진행하는 것이 매우 인상적이다. 한국에서 애자일을 사용할 때에는 "신속한 개발"에 포커스를 두었다면, "정확한 개발"에 포커스를 두고 진행한다는 느낌이 더 강하게 든다.
스프린트 플래닝을 할 때, PM이나 스크럼 마스터가 필요하다고 생각하다고 판단하여 백로그에 추가해놓은 티켓들을 개발자들과 협의를 하면서 우선순위에 따라서 다음 스프린트에 추가를 한다. 이때 팀원들에게 점수가 쓰여진 카드들을 나눠주고 각각의 티켓에 대한 추정치를 투표한다. 선택되는 카드는 1부터 8 사이의 숫자이며 8은 해당 스프린트 내내 해야할 만큼 작업 공수가 많고 중요한 업무를 의미하며 1은 상대적으로 빨리 끝낼 수 있는 업무를 의미한다. 처음에는 다른 동료들이 어떻게 추정치를 측정하는지 몰라서 뜬금없는 숫자를 냈었으나, 지금은 다른 동료들과 거의 동일한 추정치를 내고 있다. 한국에서 일을 할 때보다 약간 더 시간을 더하면되는데, 처음에는 저렇게 간단한 일인데 너무 높은 추정치를 내는 것이 아닌가 하는 의구심이 들었지만 지금은 그렇게 하는 것이 더 정확하고 제대로 업무를 진행할 수 있다는 것을 깨닫게 되었다. 참고로 필자가 지라를 사용하여 원활하게 커뮤니케이션을 한 것이 필자에 대한 좋은 평가 중에 하나였다.
* 사용 경험이 필요한 도구 : 아틀라시안 (컨플루언스, 지라), 위키
2. CI (Continuous Integration)
대규모 프로젝트를 진행하거나 잘 조직화된 소프트웨어 프로젝트를 진행하는 경우에는 CI(지속적인 통합)가 무척 중요하기 때문에 해당 업무를 전담하는 팀이나 인원이 있어서 효율적인 통합관리를 할 수 있다. 그러나 개발자 인건비만 해도 부담스러운 대부분의 중소기업이나 스타트업에서는 개발자들이 이를 병행해야 하는데, 개발 일정이나 개발 규모 등에 따라서 다르겠지만 일반적으로는 제대로된 CI 환경을 갖추고 개발하는 것이 쉽지는 않다. 다행히 필자는 젠킨스로 CI 환경을 구축하여 개발하는 과정을 경험한 적이 있어서 기본적인 CI에 대한 이해가 있었지만, 아쉽게도 처음부터 직접 세팅을 하고 운영을 해본 경험은 많지 않았었다.
필자가 입사한 뒤 한달 뒤에 2명의 독일인 개발자들이 충원되었는데, 그 중에 한명의 첫번째 임무가 소프트웨어 개발팀 내에 CI 환경을 제대로 구축하는 일이었다. 이 친구(S군)는 한번 코드 리뷰를 하면 100개 이상의 코멘트가 달리는 수십명의 개발자들이 협업을 하던 환경에서 일을 했던 경험이 있었고 성격적으로도 상당히 꼼꼼하고 까탈스러운 사람이라 필자에게는 '시어머니' 같은 첫 인상을 주었었다. 항상 그랬듯이 필자는 여전히 "개발"만하는 데 정신이 없었는데, S군이 CI 환경 구축을 위해 새로운 룰를 하나씩 추가하고 코드 리뷰를 하면서 쏟아내는 코멘트들에 테스트를 추가하라고 압박을 가하는 통에 다소 불편함을 느낄 수 밖에 없었다. 하지만, 잠시 지나서 S군의 룰에 익숙해지기 시작하니 훨씬 더 효율적이고 양질의 코드를 생산해낼 수 있는 방법이라는 것을 깨닫게 되었고 오히려 이런 경험을 할 수 있도록 만들어준 S군이 고맙다는 생각이 들었다. 그래서 그의 의견을 존중하고 따르면서 하나라도 더 배울려고 노력을 했는데, 그래서인지 지금은 많이 친해진 것 같다.
그는 소프트웨어 파트에서 기존부터 사용하던 깃랩(GitLab)의 CI 기능을 이용하여, 별도의 브랜치에서 만든 새로운 기능을 메인 브랜치에 머지를 하기 위한 "머지 리퀘스트" 과정을 강제하였고 이 과정에서 클라이언트/서버의 유닛 테스트와 통합 테스트를 자동화하고, 테스트를 통과하면 파이프라인을 타고 도커로 만들어진 팀 또는 개별 개발자들의 전용 서버에 빌드 및 배포를 자동으로 할 수 있도록 만들었다. 한국에서는 상업용으로는 빗버킷을, 공개용으로는 깃헙을 써왔기에 깃랩 또한 그들과 비슷한 소스 관리툴 정도로만 생각을 했었는데 상당히 강력한 CI 기능을 제공하는 것을 보니 세상은 정말 넓고 배울것은 많다고 느껴진다.
* 사용 경험이 필요한 도구 : 젠킨스, 깃랩 (또는 빗버킷, 깃헙)
3. 테스트
미리 밝히자면, 필자는 한국에서 개발을 할 때 테스트 자동화를 소홀히 하고 반복적인 매뉴얼 테스트에만 의존하던 개발자였다. 솔직히 필자는 테스트의 중요성을 간과하고 테스트 자동화 자체에 그저 관심을 가지지 않았고 익숙해질 때까지 사용하지 않았다. 그러나 독일 스타트업에 구직 활동을 하면서 무엇보다 "테스트"가 중요하다는 것을 깨달았다. 대부분의 코드 챌린지 요구 사항에는 "테스트"가 포함되어 있었는데, 필자는 기본적인 유닛 테스트를 넣는 수준에 그쳤다. 항상 그랬듯이 코드 챌린지를 위해 주어진 대부분의 시간을 요구 사항에 맞게 동작하는 프로그램을 완성하는데에만 할애하고 결과를 만들어내는데 급급했기 때문이다. 그러다보니 구현한 기능에 대한 테스트를 만드는 것은 형식적인 수준에 그칠 수 밖에 없었다. 그렇게 진행한 코드 챌린지 피드백을 받으면서, 리팩토링과 테스트의 중요성을 새삼 깨닫게 되었다.
지금은 자동화된 테스트의 효과에 대해 충분히 경험을 하였기에 테스트에 대한 필요성을 확실하게 깨달았다. 프론트앤드와 백앤드를 넘나들며 수많은 소스 코드를 수정하거나 새로운 기능을 추가하다보면 본의 아니게 실수를 하는 부분들이 많은데 이렇게 자동화된 테스트들은 실수를 미연에 방지하도록 도와주고 나아가서는 더 나은 코드 품질을 보장하도록 해준다. 특히나 웹 개발 시에 백앤드와 프론트앤드를 자동으로 실행 시킨 상태에서 진행하는 통합 테스트는 그야말로 훌륭하다고 밖에 할 수 없다. 여전히 코드 작성에 집중하느라 테스트 만들기에 소홀한 편이지만, 주위 동료들의 푸시 덕분(!?)에 조금씩 나아지고 있다. 머지않아 TDD가 익숙해지도록 더욱 정진해야 겠다.
* 사용 경험이 필요한 도구 : 자신이 사용하는 프로그래밍 언어에 해당하는 테스트 프레임워크 (예> Python unittest 모듈, 웹 어플리케이션 테스트 프레임워크 - Selenium, Cypress, 자바스크립트 테스트 프레임워크 - Mocha 등등)
4. 리팩토링, 코드 리뷰, 페어 프로그래밍
깃랩 CI를 이용한 머지 리퀘스트가 필수가 된 다음부터는 별도로 작업하던 브런치를 머지하려면 동료들의 코드 리뷰를 통과해야 한다. S군과 영국인 K아자씨는 저마다 다른 관점에서 코드 리뷰를 하는데, S군은 알고리즘의 효율성 위주로 보고 K아자씨는 군더더기 없는 깔끔한 코드를 선호한다. 덕분에 무조건 동작하는 코드를 빨리 만들기에 급급한 필자는 늘 제공이 걸리기 마련이다. 지금 이 순간에도 필자는 34개의 코멘트가 달린 머지 리퀘스트를 마무리하느라 고군분투를 하고 있다. PM의 요구 사항대로 정상 동작은 하지만 커밋한 소스 코드 여기 저기에는 동료들의 코멘트가 붙어있기 때문이다. 어떤 코드든 두번 세번 리팩토링을 하면 좋은 코드가 나오기 때문에 솔직히 힘들기는 해도 이들의 리뷰를 통과하고 엄지척을 받으면 기분이 후련하다. 다만 여전히 사소한 오타나 반복되는 실수들이 존재하는 점은 좀더 집중해서 작업을 할 필요성이 있다.
베프인 A군과는 페어 프로그래밍을 많이 했다. 기술 배경이 다른 두 사람이 페어 프로그래밍을 하면 서로에게 도움을 줄 수 있는 경우가 많다. A군은 데이터 사이언티스트에 가까웠기 때문에 프로그래밍 경험이 적었고, 오로지 Python만 사용할 줄 알았기 때문에 필자와 같이 협업하면서 AWS 연동이나 Pub/Sub 통신 등을 배웠기 때문에 때로는 혼자 작업이 어려울 수 밖에 없었다. 그 때마다 같이 페어 프로그래밍을 하면서 같이 결과물을 만들었는데, A군은 이해가 빠르고 응용력도 좋아서 날이 갈수록 금방 성장하는 것이 보였다. A군은 지금 다른 회사에 가서 필자와 같이 했었던 것을 바탕으로 자신의 프로그래밍을 하고 있다. 누군가 언급한 것처럼 스타트업과 같이 수평적인 조직에서 경력자와 초급자가 같이 일을 하다보면 자기 몫을 다하지 못하는 초급자들 때문에 업무에 차질이 생길 수 밖에 없다. 이 때 가장 효율적인 방법은 경력자와 초급자가 페어 프로그래밍을 하는 것으로, 경력자 입장에서는 일이 더 늘어나는 셈이지만 이 정도의 협업을 통해서 초급자가 기본적인 업무 수행을 할 수 있도록 도와주는 것 또한 시니어 개발자의 몫이라고 생각한다.
5. 이메일과 슬랙
필자는 한국에서 일을 할 때, 어떤 종류의 메신저도 사용하지 않았던 사람이다. (경험 상 전화 통화나 메신저로만 소통하겠다는 상대는 항상 최악이었다.) 오히려 독일에 와서 카카오톡 사용을 시작했는데 물론 업무 때문이 아니라 가족들과 독일내 한국 사람들과 소통을 위해서였다. 대신 한국에서는 1990년대 후반부터 오로지 이메일만으로 업무적인 커뮤니케이션을 해왔다. 메신저 내용 역시 법적인 증거가 될 수 있겠지만 내가 필요로 하는 내용을 찾는 것이 불편하고 한계가 있지만, 이메일은 10년 전에 주고 받은 내용을 금방 찾을 수 있고 그 자체가 법적으로 효력이 있는 사문서이기 때문이다. 독일에 와서 적응이 어렵지 않았던 이유 중에 하나는 오랫동안 이메일을 이용해서 커뮤니케이션을 해왔던 습관 덕분이기도 하다. 여기에서는 업무적으로 이메일을 많이 사용하기도 하지만, 학교 선생님이나 자동차 딜러, 집주인, 관공서, 은행 담당자 등 수많은 사람들과 이메일로 커뮤니케이션을 하고 있기 때문에 이메일 사용은 필수라고 할 수 있다. 물론, 이메일로 먼저 연락 후 정식 서류는 우편으로 주고 받는다.
한국 스타트업에서 일을 할 때부터 슬랙을 사용해왔는데, 슬랙은 같은 회사의 모든 직원들과 쉽게 커뮤니케이션을 할 수 있는 좋은 도구이다. 메신저처럼 1:1이나 다수의 사용자들과 커뮤니케이션을 할 수 있는 다이렉트 메시지 기능을 제공하고, 특정 업무나 이슈에 대해서 개별적으로 만들어진 채널을 이용하여 업무를 진행할 수 있다. 얼핏 보면 단순하고 별것 아닌 것 같지만, 슬랙 하나만 잘 활용해도 회사 전체의 업무 진행 상황을 쉽게 파악할 수 있고 자신과 관련된 업무에 대한 커뮤니케이션을 쉽게 할 수 있게 된다. 하나의 슬랙 앱에서 여러 회사의 계정을 등록해서 관리할 수 있기 때문에 다수의 클라이언트와 일을 할 때에도 요긴하게 사용할 수 있다. 메신저를 선호하지 않은 필자 입장에서는 메신저의 단점을 보완해주는 것이 슬랙이라고 생각한다.
* 사용 경험이 필요한 도구 : 아웃룩 (또는 웹 메일 클라이언트), 슬랙
이 이외에도 일을 하다보면 더 많은 개발 도구들이 필요할 것이다. 최소한 여기에 있는 도구들만이라도 잘 활용할 수 있다면 한국이나 독일의 스타트업에서 일하는데에는 도움이 될 것이다.
