brunch

매거진 개발자 스웨덴 이직기

라이킷 16 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 개발자 꿀 Sep 17. 2020

인프라 중심 회사에서 배우면서 일하기

나의 두 번째 직장은 첫 번째 직장보다 훨씬 소프트웨어 인프라 중심 회사다.

첫 번째 회사는 구글 같은 구조라서 하나의 브랜드 아래 서로 다른 서비스들이 아주 많았다. 서비스마다 적어도 한 개의 팀이 필요한데 덩치가 큰 것들도 많았기 때문에 자연스럽게 상당수의 개발자들이 사용자를 직접 대면하는 서비스를 개발하고 있었다.

이런 구조 안에서는 팀들이 각개전투를 한다. 몇 개의 서비스는 서로 연결고리가 있기도 하지만 그것이 전체를 연결하는 것은 아니기 때문에, 결국 각자의 계획과 필살기로 알아서 살아남아야 한다. 자연스럽게 개발자들의 초점은 '우리' 서비스 개발에 맞춰지고 기술 스택을 결정할 때 이미 검증된 안전한 길을 선택하게 된다.

현재 회사는 주력 상품이 딱 하나다. 그래서 주력 상품을 만지지 않는 나를 포함한 나머지(?) 개발자들은 최전선의 서비스가 사람 없이도 잘 굴러가고 부산물 데이터가 잘 처리되도록, 혹은 다른 개발자들의 업무를 쉽게 하는 인프라를 만드는 일을 한다. 다르게 말해서, 전 회사에서 팀마다 차 한 대씩을 만든다면 지금 회사는 모든 사람들이 차 한 대를 만든다.

여기는 소프트웨어 개발의 모든 요소 하나하나가 공통화되어있고 담당팀이 있다. 그래서 회사 외부 오픈소스는 사실 거의 쓸 일이 없다. 더 인프라적 면을 보여주는 것은 비즈니스 로직 개발 외에 상당수의 operation 업무(DNS, 서버 리소스 관리, 모니터링 등)가 설정으로 동작한다는 거다. 예를 들어 정해진 위치에 dns:true로 설정하면 코드를 배포할 때 사내 DNS를 관리하는 서비스가 설정을 읽어서 정해진 이름으로 등록해준다.

최근에는 모니터링 대시보드까지 공통화가 이루어져 대시보드와 모니터링 알람을 전부 코드로 정의한다. 전에는 UI에서 클릭으로 그래프를 추가했는데 지금은 모니터링 인프라가 코드를 읽어서 자동으로 만들어주기 때문에 수작업이 거의 없어졌다.

이직 후에 개발 관련 도서를 전만큼 많이 읽지 않는 것에 대해 생각해본다. 나는 내가 쓰는 것들에 대한 이해를 높이려고 책을 읽었고, 그래서 대부분 회사에서 쓰거나 써보고 싶은 오픈소스 시스템에 대한 책을 읽곤 했다. 기본 개념과 동작 원리, best practices 같은 내용을 책으로 훑으면서 앞으로 어떻게 써야 할지 감을 잡았다. 하지만 지금은 in-house 시스템을 많이 쓰는 구조 때문에 책에서 업무에 필요한 내용을 얻는데 당연히 한계가 있고 읽을만한 것은 사내 문서뿐이다. 요즘 업무 시간 중에 구글에서 검색하는 것은 Docker와 K8S가 전부인 것 같다.

처음에는 매뉴얼 같은 글 읽기가 너무너무 지겨웠다. 책은 보통 친절하게 'A를 하려면 B를 한다' 다음에 '왜냐하면 C처럼 동작하기 때문이다'라고 설명해주는데, 사내 문서는 A를 하려는 사람들이 빨리 B를 찾을 수 있게 도와주는 것만으로 본분을 다 하기 때문인지 보통 C에 대한 부분이 빠져있는 것이다. 예전에 책 읽기를 좋아했던 이유가 바로 C를 알려주기 때문이었는데 더 이상 사내 문서를 읽는 것 만으로는 좀 더 깊이 아는 즐거움을 느낄 수 없게 되었다.

공부하는 방식이 달라질 때가 온 거다. 책 속의 누군가의 경험과 친절한 정리에서 벗어나 야생에서 살아남기 위한. 사실 야생에서는 원하는 것은 전부 얻을 수 있었다. 다른 팀 코드까지 찾아보고, 담당자에게 직접 물어보고, 틀린 부분이나 부족한 내용에 피드백을 보내고 직접 고치는 것 모두 가능했다. 처음 시작하기까지 1년이나 걸렸지만, 회사라는 작은 커뮤니티 안에서 짧은 문서가 설명하지 않는 세상까지 나의 손이 닿는 영역으로 보기 시작한 때였다.

이 회사에서 좀 잘한다는 사람들은 대놓고 말은 안 해도 이런 식으로 일을 한다. 모두에게 열려있는 커뮤니티를 최대한 이용해서 자기들의 발자국을 많이 찍어놓고 여기저기를 들쑤시고 다닌다. 옆 팀에 'magician L'이라고 모르는 게 없는 것 같은 개발자가 있다. 그가 다른 서비스 코드에 얼마나 관심이 많은 사람인지 최근까지 몰랐는데, 내가 업무로 생성한 외부 라이브러리를 바꾸는 PR에 그가 코멘트를 다는 것을 보고 놀란 적이 있다. 그 라이브러리는 그와 어떤 업무적 관련도 없었는데, 내 PR을 진짜 리뷰해야 할 어떤 사람보다도 그가 먼저 PR을 확인했다. 또 한 번은 내가 동일한 기능에 다른 프로토콜을 쓰는 클라이언트 v2를 만들었을 때 어떤 팀에서 쓰고 싶어 할 것 같다고 DM으로 코드 링크를 보내준 적이 있다. v1을 내가 새로 추가한 프로토콜로 쓰기 위해서 직접 우회하는 코드였는데 이것 역시 어떻게 찾았는지 신기할 정도로 나는 존재도 모르던 코드였다.

뒤돌아보면 사람들이 많이 쓰는 오픈소스를 이렇게나 깊게 이해하고 있다는 자만심에 가까운 자부심이 기술 서적을 탐닉하는 원동력이었던 것 같다. 나는 자랑스럽게 링크드인에 자부심을 부렸고 지금 회사에 면접을 볼 때도 책에서 배운 내용들을 써먹었으니 투자가 값어치를 하긴 했다. 독서량이 줄었을 때 나도 모르게 느꼈던 걱정도 아마 사람들에게 쉽게 뽐낼 수 있는 지식이 늘어나지 않는데서 나왔을 것이다.

그동안 기술 서적에 대한 생각이 많이 변해서, 진짜 읽어야 하는 책은 신간보다 고전, 실용서보다는 개념서라고 생각한다. 신간은 사람들이 빨리 기술을 배워서 써먹고 싶은 욕구를 타겟팅하는 경우가 많은데, 요즘에는 오픈소스의 기술 문서가 상향 평준화되었기 때문에 가능하다면 reference 읽기를 도전하는 게 좋은 것 같다. 회사에서 사내 문서를 작성하는 개발자의 한 사람으로서 한 줄 한 줄에 라이브러리 작성자와 사용자의 의도, 경험, 걱정 같은 것들이 압축되었다고 믿기 때문에, 거기서부터 출발하면 책과 다른 맛이 있을 것이다.

좋은 개념서는 자주 세상에 나오지 않지만 한 번 나오면 신기하게 주변 사람들이 모두 알아보고 고민 없이 구매한다. 최근 2~3년 동안 가장 좋았던 기술서는 Martin Kleppmann의 'Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems'라는 책으로, 데이터 엔지니어로 분야를 바꾸어 이직을 준비할 때 알게 되었다. 제목 그대로 data-intensive application을 만들 때 고려해야 할 지점을 알려주는데 e-book으로 읽다가 종이책도 사고 스웨덴으로 이사 올 때도 가지고 왔다. 이 책은 친한 동료의 집에도 꽂혀있었고 우리 팀에도 좋아한 사람이 있다.

인프라 중심 분위기와 서비스 중심 분위기에서 각자 장단점이 있기 때문에 이 글을 읽고 둘 중 하나가 더 낫다는 결론을 내리지 않았으면 좋겠다. 사람들과 이야기해보면 성향에 따라 좋아하는 분위기도 다른 것 같더라. 나는 지금 업무에 만족하지만 가끔 하루 종일 바쁘게 코딩하고 앱에서 내가 개발한 기능을 바로 확인하던 속도감과 결과가 눈으로 보이는 경험이 그립다.

양쪽을 다 경험하는 것은 중요하다. 나는 서비스에서 점점 인프라로 넘어왔는데, 인프라에만 있었던 사람들은 내가 서비스를 만들 때 중요했던 것을 별로 생각하지 않는 경우가 있었다. 그래서 당연히 필요한 일을 했는데 엄청 좋은 피드백을 받은 적이 있다. 또 반대로 인프라를 오래 했던 사람들만의 장점이 있어서 2년째 옆에서 열심히 따라 하는 중이다.

그러니까 지금 어디에서 일을 하든 배울 수 있는 것을 성실하게 배우고, 기회가 오면 용감하게 변화를 받아들이길!

14th September 2020

#스웨덴 #개발자 #해외취업 #해외개발자

keyword