​

들어가며

안녕하세요. 개발을 시작하고부터 이제 갓 2년을 넘긴 안드로이드 개발자 최예나입니다. 오늘은 다른 글보다는 조금 캐주얼하게 딜리셔스 개발 문화에 관해 얘기해보려고 합니다.

제가 입사했던 2019년도 봄에 딜리셔스는 막 160억 원 대의 시리즈 B 투자를 유치한 상태였습니다. 덕분에 넓고 쾌적한 새 사무실로 이사를 마치고 개발자를 포함한 인원 채용과 사업 확장에 힘을 기울이고 있었습니다. 당시에도 스타트업이라고 하기에는 이미 작지 않은 규모였지만, 개발팀의 각 파트 별 인원은 2~4명밖에 되지 않아 개발 문화라고 부를 뚜렷한 것은 없었습니다. 하지만 한 주 한 주 사람이 늘어나며 외딴섬 같던 개발팀 공간은 책상으로 가득 차게 되었고 딜리셔스 개발팀의 특징이 생겨났습니다.

회사가 성장하는 과정에서 자연스럽게 탄생한 개발 문화를 지켜본 것이 뜻깊어서 주니어 시점으로 관찰일지를 적어 보려고 합니다. ​
​

1. 좋은 기술 욕심내기

우리도 이거 써 볼까요?

지금 당장 새로운 서비스를 시작한다면 원하는 언어와 최신 기술 트렌드를 마음껏 적용해 볼 수 있겠지만, 회사에서 몇 년간 지속하여 온 서비스에 적용하기는 쉽지 않습니다. 새로운 스타일을 적용하기 위해서는 가장 기본적으로 기존 기능이 유지되어야 하고, 이전 버전과 호환도 되어야 하고, 과연 효율적일지 비교도 해봐야 하고, 사이드 이펙트도 조심해야 하기 때문입니다.

정말 기쁘게도 딜리셔스는 이러한 점을 충분히 이해해 주는 편이고, 대규모 리팩토링이 필요할 때에는 리팩토링 외 다른 업무를 모두 일시 중단하는 것을 허가해 주기도 했습니다. (언빌리버블!) 레거시 PHP 서버 리팩토링과 iOS Swift 컨버팅에 관해서는 아래 포스트에서 자세히 읽어볼 수 있습니다.

• 레거시 코드 및 시스템 리팩토링 - ABARA
• iOS 컨버팅의 추억

안드로이드의 경우 기존 언어인 Java와 새로운 언어 Kotlin 간의 호환성이 뛰어나기 때문에 한 번에 교체할 필요는 없었습니다. 대신 작업을 시작하거나 코드를 수정할 일이 있으면 조금씩 고쳐 가는 방식을 선택했습니다. 일례로, 이전에 써드파티 라이브러리를 통해 API 통신을 하던 것을 Retrofit이라는 통신 라이브러리로 모두 교체한 적이 있습니다. 이때 RxJava를 같이 도입해서 공통으로 쓰이는 통신 성공, 실패, 취소 후의 작업이나 API 다중 호출에 대한 처리를 함께 추가했습니다. 또한, app 모듈을 정리함과 동시에 통신과 관련된 부분만 분리한 덕분에 테스트 코드를 처음으로 작성해보는 기회를 얻을 수 있었습니다.

같이 작업한 안드로이드 파트의 동료들 모두 새로운 라이브러리에 관심이 많았기 때문에 아이디어를 잘 모을 수 있었고, 결론적으로는 간편하게 사용할 수 있는 스타일을 만들 수 있었습니다. 추가로 줄줄이 길었던 묵은 코드와 클래스를 삭제하는 후련함을 맛볼 수 있었습니다.

모여봐요 공부의 숲

여느 개발자들이 그러하듯 개발 공부에 대한 게으름은 부끄럽기 마련입니다. 모두 ‘아 운동해야 하는데’ 처럼 늘 의지를 갖고 있어서 누군가 자발적으로 스터디를 만들면 인원이 금세 차고는 했습니다. 머신러닝 스터디 모임, SQLD 자격증 모임, 심지어 변수명을 잘 쓰기 위한 영단어 외우기 모임 등 취미로(?) 진행되는 모임이 있는가 하면 실무에 사용하기 위한 언어나 라이브러리에 대한 스터디도 파트 별로 자유롭게 진행되고 있습니다.

지금의 딜리셔스 기술 블로그도 이러한 자율적인 모임에서 비롯되었습니다. 개인 개발 블로그를 운영하는 사람들끼리 ‘저는 최근에 쓴 글이 없어서 보여드리기 민망하네요’ 와 같은 대화에서 시작되어 서로 쓴 글을 공유하는 블로그 모임이 만들어졌습니다. 벌금 + 시즌 내 탈출 불가라는 룰은 많은 포스트를 만들어냈습니다. 같은 프로젝트를 진행한 다른 파트원이 어떻게 개발 했는지 설명해 주셔서 궁금증이 풀리기도 했고, 구글링으로 레퍼런스를 찾다가 언제부턴가 검색 결과 상단에 포스트가 노출되는 것을 발견하여 신기해하기도 했습니다. 이러한 소소한 재미를 느껴 딜리셔스 개발팀에 관한 내용을 좀 더 알릴 수 있게 시작된 것이 본 기술 블로그입니다. (딜리셔스 기술 블로그에 관해서는 이후에 별도로 포스팅이 올라올 예정입니다.)

회사에서도 이러한 활동을 뒷받침해 주기 위해 여러 가지 지원을 해 주고 있습니다. 우선 다달이 읽고 싶은 책을 신청하면 회사에서 구매해 주기 때문에 책값에 대한 부담이 없습니다. 또, 업무와 관련하여 새로 공부해야 할 것이 있다면 온라인 강의도 지원해 줍니다. 이 글을 쓰는 현재는 코로나 사태로 인해 오프라인 컨퍼런스가 거의 열리지 않고 있지만, 참석하고 싶은 컨퍼런스가 있을 때는 쿨하게 보내주곤 했습니다. 물론 지금도 업무 도중 온라인 컨퍼런스에 참석하는 것도 자유롭게 가능합니다. 눈치 보지 않고 지원받으며 하고 싶은 공부를 할 수 있는 것도, 또 그로 인해 실제 프로젝트가 쓰기 좋고 효율적으로 변화하는 것도 개발자로서 아주 즐거운 일입니다.

2. 모두가 주도적인 업무 진행

딜리셔스에서 일하며 또 하나 즐거운 점은 ‘오늘도 무사히’와 같은 수동적인 태도를 지닌 사람이 없다는 것입니다. 자기 일에 책임을 다하는 것은 너무나 당연한 일이고, 나아가 우리 회사의 서비스나 다른 동료들에게 도움이 되기 위한 일을 내 일처럼 고민해 주는 모습에 감동하곤 합니다.

프로젝트를 만드는 것이 아닌 서비스를 만드는 과정

앱 개발자의 업무 특성상 비교적 다양한 파트, 다양한 부서와 의견을 나누게 됩니다. 저는 처음에 기능 정의는 기획자가, 디자인은 디자이너가 해주시고 개발자는 문서에 쓰인 대로만 구현하면 이론상 완벽한 협업이 이루어지는 것으로 생각했습니다. 하지만 이곳에서 한 회의는 그것보다는 조금 더 활발했습니다.

서비스를 유도하기 위한 좋은 생각이 있을 때, 기능이 너무 복잡해서 사용자들이 사용에 혼란을 겪을 것 같을 때, 심지어 사소한 문구나 UX/UI이더라도 의견이 있다면 제시해보는 편입니다. 처음에는 ‘개발자인데 이런 거 말해도 되려나? 내 권한 밖의 일은 아닐까?’ 하는 의문과 미안함이 들었습니다. 감사하게도 모두 적극적으로 검토하거나 반영해 주시는 편이고, 그렇지 않은 상황에는 이유를 자세히 설명해 주셔서 편-안한 마음으로 작업할 수 있도록 도와주셨습니다.

다행히도 같이 일하는 다른 클라이언트 개발자분들도 성향이 비슷합니다. 분명 이걸 고치는 작업이 더 번거로울 걸 알지만 더 나은 서비스를 위해서 시간을 더 들여서라도 작업하는 편입니다. 오히려 ‘이게 맞나?’ 싶을 정도로 모호한 프로덕트를 만드는 것이 더 괴로울 것입니다. 다들 시키는 대로만 하는 것이 아닌, 애정으로 서비스를 만드는 것이 느껴질 때 일하는 보람이 느껴집니다.

정성 들인 코드 리뷰와 내부 테스트

저희 파트에서는 기능 개발만큼이나 마무리 후 테스트, 코드 점검도 꼼꼼히 진행하고 있습니다. 사실 자기 코드의 이상한 점이나 버그는 자신의 눈에는 잘 안 보이는데, 다른 동료에게 보여주면 기가 막히게 잘 찾게 됩니다. 그래서 PR을 검토하는 것도 큰 업무로 보고 시간을 많이 할애하여 체크합니다.

크게는 앱에서 에러가 날 수 있을 만한 상황을 발견하기도 하고, 작게는 코드 스타일 일관성에서 벗어나거나 불명확한 코드 수정을 요청하고, 더 사소하게는 오타나 주석까지도 체크해서 코멘트를 달아 두기도 합니다. 남의 코드를 읽는 것은 시간과 노력을 많이 요구하는 일이기 때문에, 코드 리뷰가 전투의 시간이 아니라 아주 감사한 피드백임을 잘 알고 있습니다. 그래서 댓글이 달리면 답글을 항상 1:1로 달며 모든 피드백을 확인합니다.

그리고 PR을 확인함과 동시에 앱을 내부 테스트를 진행합니다. 저는 안드로이드 파트이다 보니 주로 다른 동료의 브랜치에서 안드로이드 앱을 테스트하거나 iOS와 함께 크로스체크를 진행하곤 했습니다. 최근에는 웹 파트의 테스트를 모바일에서, 모바일의 체크를 웹에서 하는 등 타 플랫폼의 체크도 활발히 진행하고 있습니다. 위에서 언급했듯 다른 사람이 같이 봐주면 에러를, 혹은 에러같이 생긴 것을 더 쉽게 찾을 수 있기 때문이지요. (이건 사이언스입니다.) QA 파트에 전달하기 전에 기능이나 구현 로직을 최대한 맞추고 가는 편입니다.

3. 사람들 속에 잘 녹아드는 사람들

신입으로 입사했던 저는 개발팀에 대해 막연히 아저씨 같은 이미지일 것으로 생각했습니다. 각자의 자리에서 무뚝뚝하게 일하다가 ‘국밥이나 먹으러 가지.’ 하고 일어나는 모습을 상상했지만, 전혀 아니었습니다.

‘수평적이고 자유로운 문화, 좋은 동료들’

딜리셔스 직원들에게 회사의 장점에 관해 물으면 가장 먼저, 가장 많이 듣게 되는 대답입니다. 직급이 아닌 이름 + ‘님’ 존칭을 쓰기 때문에 무엇이든 더욱 활발히 이야기하게 된다고 느낍니다. 업무에 관한 얘기가 자주 오갈수록 오해나 실수는 줄어들고 유대감이 높아집니다.

데일리 스탠드업 미팅

매일 오전에 개발팀의 각 파트 별로 다 같이 모여 어제와 오늘의 일과를 공유하는 스탠드업 미팅이 진행됩니다. 총 10분 정도밖에 되지 않는 시간이지만 오전 출근 후에 제가 어제 무슨 작업을 했는지, 오늘 어떤 업무가 남아있는지 정리하는 데에 도움이 됩니다. (특히 월요일이나 공휴일 이후에 리프레시를 할 때 효과를 경험합니다) 또 동료가 하던 일을 마쳤는지, 아니라면 어떤 부분에서 어려움을 겪고 있는지 알 수 있어서 해결책을 함께 모색하기도 합니다. 스탠드업 미팅이 끝난 이후에는 바쁘지 않다면 커피 타임을 갖거나 스몰톡을 하고, 탁구를 치며 파트 간 친목을 도모하기도 합니다.

이 사람들은 탁구에 진심입니다

수평적인 문화에 가장 많이 이바지한 것은 바로 라운지에 있는 탁구대일 것입니다. 딜리셔스에서 탁구대는 명백히 문화이며 업무 시간이나 점심시간 등에 얽매이지 않고 이용할 수 있으므로 자유의 상징이기도 합니다. 개발을 하다 보면 언제나 일정한 속도로 답이 도출되는 것이 아니기 때문에, 집중이 안 되거나 잠이 올 때 라운지로 나가게 됩니다. 가벼운 탁구 게임은 개발팀뿐 아니라 다른 파트 사람들과도 쉽게 친해지는 계기가 되고, 자리로 돌아가서 충전된 상태로 개발을 다시 시작할 수 있게 해주는 에너지원입니다.

마치며

여기까지 딜리셔스 개발팀에서 느꼈던 점을 적어보았습니다. 이곳에서 일하는 방식을 아주 짧게 요약하면 ‘합리적이다’라는 생각이 들었습니다. 업무 시간 안에 주어진 몫을 하기 위해 열심히 달리고, 동료들과 더 효율적으로 일할 수 있는 방법을 모색하고, 다른 부서 사람들과도 적극적으로 소통하며 더 나은 서비스를 만드는 곳이라는 생각이 듭니다.

딜리셔스 개발자들과 이야기해보면 대체로 회사 생활에 대한 만족도가 높았습니다. 극단적인 사례로 이곳은 천국이라는 표현까지 들어 보았습니다. 누가 ‘이런 분위기를 만듭시다’라고 시킨 게 아니라 실제 일하는 사람들이 가장 원활하게 일할 수 있는 방식대로 만들어진 문화이고, 회사에서는 이러한 문화를 존중해 주고 서포트 해주기 때문에 개발자들이 만족하며 근무하는 것 같습니다. 저 역시 시간 가는 줄 모르고 2년을 근무했지만, 여전히 배울 수 있는 것도 많고 빨리 바꾸고 싶은 코드들도 남아 있기에 일 욕심이 계속 생깁니다.

좋은 개발 문화를 가지고 있다는 것, 막연하고 추상적인 것처럼 느껴지지만 ‘개발이 하고 싶어지는’ 환경을 나타내는 말 아닐까요. 저도 회사도 앞으로 좋은 개발 문화와 함께 발전해가고 싶습니다.