[영국워홀 D+189] 런던 개발자 5개월 회고 - [2] 개발 문화

Probation period가 한 달도 채 안 남았다.

꾸준히 블로그를 쓰고자 다짐했는 데 벌써 저번 글을 쓴 이후로 한 달이 넘게 지나버렸다.

 

런던 첫 뮤지컬 "라이온 킹"

 

 

그동안의 일들을 살짝 UPDATE 해보자면,

• Mid-probation 을 무사히 통과했다! (Productive한 피드백은 덤!)
• 한국 짱친들이 런던을 찾아왔다!
• 포르투갈을 다녀왔다.
• 새로운 한국인 친구들을 사귀었다.
• 한국행 비행기표를 끊었다.
• 새로운 목표를 세웠다.

 

 

세븐시스터즈 📸

 

 

이번 글에서는 우리 회사의 개발 문화에 대해 적어보고자 한다.

영국 전반적인 개발 문화라고 말할 수는 없지만, 내가 경험한 내용을 토대로 영국 스타트업 개발 문화에 대해 기록해보려고 한다.

 

 

개발 문화

 

 

내가 이 회사에서 가장 만족하는 부분 중 하나가 개발 문화인데 그 이유를 나열해 보자면,

• 테스트 코드 작성
• 코드 리뷰
• Engineering guidlines
• 적극적인 지식 공유

 

사실 엄청 특별한 무언가가 있는 건 아니지만, 이 모든 게 유지되고 항상 유지하려고 노력한다는 점에서 나에게 특별한 것 같다.

물론, 내 이전 직장에 이런 문화가 없었기 때문에 더 그렇게 느끼는 것 같기도 하다.

 

하나하나 자세히 적어보자면,

 

테스트 코드 작성

사실 우리 회사는 TDD 까지는 따르지 않는다. 그러나 코드 리뷰에서도 Test code의 중요성을 항상 강조한다.

그리고 대부분의 벡엔드 코드에는 test code가 존재한다.

프론트엔드 영역에서는 unit test 까지 작성하지는 않지만, Cypress test 를 통해 User flow에서 발생할 수 있는 버그를 미리 방지하는 데 큰 도움을 받고 있다.

 

사실 2-3주 단위의 스프린트로 개발을 진행하는 만큼, 모든 종류의 테스트 코드를 다 커버해 가며 개발할 수는 없지만,

최소한 백엔드 개발할 때 unit test, 프론트엔드 개발에서는 cypress test가 실패하는 경우 아예 merge를 할 수 없도록 막아 놓았다는 점에서 배포에 대한 불안감이 줄어드는 건 사실인 것 같다.

 

물론, 아직 향상해야 하는 영역도 많이 남아있다. 

프론트엔드에서의 unit test, 백엔드에서도 Integration, E2E 부분에 대한 더 많은 테스트 코드가 필요하다고 느낀다.

이렇게 향상할 부분이 있다는 건 내가 뭔가 조사해서 리드할 수 있는 프로젝트의 기회가 존재하다는 뜻이기도 해서 커리어적으로 긍정적인 것 같다.

 

 

코드 리뷰

우리 회사 개발팀은 현재 3개의 작은 팀으로 나누어져 있는데, 

그중 내가 속한 팀의 코드 리뷰 문화는 꽤나 적극적인 편이다.

현회사에서는 팀이 담당한 기능 개발의 티켓 단위로는 팀 내부에서 코드 리뷰를 진행하고, 이 기능을 main 브랜치에 병합할 때 다른 팀으로부터 리뷰를 받는다.

 

어떤 내용을 코드 리뷰 하는가?

현재 프론트엔드 Framework를 Vue2에서 Vue3로 업그레이드 한 지 얼마 안되었기 때문에

주로 프론트엔드 코드 리뷰를 할 때는 Vue3에서 지향하는 대로 코드를 작성했는가를 주로 리뷰하는 것 같고,

전체적으로는

코드 복잡도를 낮출 수 있는 대체 방법이 있다면, Suggestions을 통해 남기는 편이고,

설명이 필요한 부분에 대해서는 Comment를 추가해 달라는 부탁을 남긴다.

그리고 좋은 코드에 대해서는 따로 코멘트를 달아 칭찬하기도 한다.

 

적극적인 코드 리뷰의 장점은

다른 사람의 작업을 보며 좋은 점은 학습하고, 실수는 반복하지 않게 된다는 것이 좋은 것 같다.

그리고 내가 작업하지 않은 영역에 대해서도 따로 요구사항이나 디자인을 참고하지 않고도

코드를 통해 기능에 대한 예상 동작을 이해할 수 있게 된다.

 

 

Engineering Guidelines

 Engineering Guidelines 은 회사 Tech 팀 Notion 페이지 중 하나이다.

주로 Suggestions 채널을 통해 새로운 개발 문화나 규칙이 제안되고, Research를 한 후, 다른 개발자들에게 발표를 진행하고, 모두가 내가 제안한 내용을 동의하게 되면 가이드라인으로 자리 잡게 된다.

 

이렇게 가이드라인 채널에 무언가를 제안하고, 이를 공식화하며, 지켜나가는 과정을 통해

개발 문화가 향상되고, 이 과정에서 정말 많은 배움을 얻을 수 있다.

 

한 가지 예시를 공유하자면,

folder structure에 대해 개선하자는 제안이 나왔고,

한 개발가 Research를 담당하여 발표를 진행했고,

다른 개발자들이 모두 동의함으로 인해 가이드라인으로 자리 잡게 되었다.

현재 이 가이드라인은 새로운 코드를 작성할 때 길라잡이 역할을 하며,

코드 리뷰를 할 때 에도 적용된다.

 

 

적극적인 지식 공유

개발팀 내에서는 종종 지식 공유 세션이 열린다.

 

한 번은 터미널 명령어에 대한 4번의 세션이 진행되었고,

최근에는 AI 사용에 대한 여러 개발자들의 발표와 Discussion이 진행됐다.

 

독특한 점이라고 한다면 종종 디자이너나 PM도 참여한다는 점이다.

 

다들 이런 문화를 지향하고, 누군가 세션을 연다면 거의 모두가 참석하는 것 같다.

 

혼자 새로운 모든 지식을 학습하려 한다면 벅찰 수 있지만,

이렇게 여러 머리가 모여 한 가지만 서로 공유한다고 해도 벌써 10가지 지식을 단기간에 습득할 수 있게 된다.

 

---

 

오늘은 영국 스타트업의 개발 문화에 대한 정리를 해보았는데,

이렇게 좋은 개발 문화를 가진 회사에서 일하고 있다는 게 너무 감사한 것 같다.

 

 

나도 얼른 영어가 빨리 늘어서 적극적인 지식 공유자가 되고 싶다.

 

 

마지막으로 런던에서 먹은 첫 Sunday Roast!

Hawksmoor Borough