brunch

미국 개발자의 TMI: 풀리모트 5년 차의 자기소개

일하는 회사와 하는 일, 업무 방식

by 밍풀

안녕하세요.

그동안 이 매거진에는 그때그때 떠오른 생각들을 단편적으로 남겨왔습니다.

그러다가 최근 네이버 블로그에서 작은 설문을 진행해 보았는데, 제 글을 찾아주시는 상당수가 ‘해외에서 개발자로 일하는 이야기’를 궁금해한다는 걸 알게 되었어요.


그래서 앞으로는 이 매거진을 ‘미국 개발자의 TMI’라는 주제로 조금 더 구조화해서 적어보려 합니다.

제목 그대로, 가끔은 별로 궁금하지 않을 수도 있는 이야기들이 섞일 수 있지만, 그냥 ‘이런 방식으로 일하는 사람도 있구나’ 하고 편하게 봐주시면 좋겠습니다.






이번 글은 그 시작으로, 자문자답 형식의 간단한 자기소개입니다.



Q. 어느 회사에서 무슨 일을 하시나요?


소개 페이지에서는 ‘빅테크’라고 뭉뚱그려 적었지만 조금 더 자세히 말하자면, 저는 데이터베이스(DB) 분야에서 역사가 꽤 오래된 기업의 클라우드 팀에서 일하고 있어요. 그중에서도 B2B 고객 대상 서비스를 만드는 팀에 속해 있습니다.



저희 팀의 역할을 설명할 때는 보통 이렇게 이야기합니다.


“앱을 만들 때는 DB, 서버, 프런트엔드 등 여러 요소가 안정적으로 연결돼야 하는데, 저희는 이 구조들이 끊김 없이 운영되도록 관리하고 유지보수하는 서비스를 만드는 팀이에요.”


쉽게 말해, 고객 기업들이 직접 관리하지 않아도 되도록 백엔드의 안정성을 대신 책임지는 팀이라고 할 수 있습니다.




Q. 어떤 언어를 쓰고, 어떤 업무를 맡고 있나요?


주로 사용하는 언어는 Java, 그리고 필요에 따라 Go, Python, Bash script 등 다양한 언어를 사용합니다. 그동안 업무는 크게 두 가지 흐름으로 나뉘었던 것 같아요.



1) 신입 시절 – 서비스 초기 개발 참여


제가 입사했을 때 팀의 서비스가 아직 출시 전이었습니다. 덕분에 대기업 속 미니 스타트업처럼 MVP를 만드는 과정을 직접 보고 함께 참여하면서, API 정의부터 작은 컴포넌트 개발까지 전 과정을 가까이서 경험할 수 있었습니다.


주니어였던 저는 시니어와 Principal 엔지니어들의 리뷰와 감독 아래,

디자인 문서 작성과 함께 로직 구성

팀 미팅으로 디자인 문서 리뷰 참여 & 다른 팀들과 리뷰 승인 과정 협업

코드 구현

테스트

까지의 흐름을 처음부터 끝까지 해볼 수 있었습니다.



2) 서비스 배포 이후 – 온콜과 운영 경험


서비스가 공식 출시된 뒤에는 본격적으로 온콜(oncall)을 시작했습니다. 신생 서비스였기 때문에 온콜을 위한 환경도 새로 구축해야 했고 덕분에

Grafana 대시보드 처음부터 구축

필요한 메트릭(metrics)/알람(alarms) 구성

코드 레벨에서 알람 추가

같은 운영 관련 업무도 맡았습니다.


또 작년에는 팀이 워낙 마이너 한 조직이다 보니, 매니저의 추천으로 공개 서비스(public facing)를 위한 프로젝트에 반년 간 투입되기도 했습니다. 그동안 한 팀에서 일을 하면서, 어쩌면 회사 내에서도 우물 안 개구리처럼 근시안적으로 밖에 못 봤는데 다른 팀에서 일하면서 또 다른 팀 문화를 알 수 있게 됐습니다.



그때 느꼈던 점들은 아래 두 글들을 참조해 주시면 될 것 같아요. 지금 보면 너무 세세하게 테크니컬 한 부분까지 적어서 실제 제 경험이 다른 분들에게 도움이 될지는 잘 모르겠지만, 그래도 비슷한 분야에서 일을 하는 분들에게 도움이 되었으면 좋겠습니다.


새로운 팀에서의 두 달

팀 협업 프로젝트 마감일을 지키기 위한 노력들




Q. 리모트 환경에서 어떻게 일하나요?


저는 코로나가 한창이던 2021년에 일을 시작해서 자연스럽게 재택근무를 하게 되었고, 중간에 오피스가 다른 주(state)로 이전하면서 현재까지 계속 풀 리모트로 일하고 있습니다. 사용하는 도구는 대부분 비슷합니다.


Slack — 팀 커뮤니케이션

JIRA — 업무 및 태스크 관리

Confluence — 문서화

사내 DevOps 도구 — 온콜/배포/모니터링



저희 팀은 미국 팀과 인도 팀이 12시간씩 온콜을 나누어 맡습니다. 그래서 24시간 7일을 붙잡고 있어야 하는 팀에 비하면 비교적 안정적인 편이에요. (같은 개발자인 남편은 온콜 날에는 밤을 새우는 경우도 종종 있어서, 이 환경에 감사할 때가 많아요.)


아쉬운 점이 있다면, 팀원들이 모두 다른 주 - 캘리포니아, 워싱턴, 텍사스 등- 에 흩어져 있어 직접 얼굴을 본 건 단 한 번 뿐입니다. 그마저도 모든 팀원들을 본 건 아니고, 같은 주에 있던 동료 개발자들과 잠깐 만나 커피챗을 한 정도였습니다. 그럼에도 팀이 신설될 때부터 함께한 멤버들이라 4년 반 동안 여러 번의 매니저 교체와 팀 해산 위기까지 함께 겪으면서 서로에게 묘한 ‘동료애’ 같은 게 생겼어요.



실제로 얼굴을 마주한 적은 없어도, 느슨하고 편안한 끈끈함이 있는 팀입니다.




재택근무에 대한 개인적인 생각


많은 분들이 '재택이면 너무 좋겠다'라고 말씀해 주시고, 저도 그 말에 동의합니다.


다만 재택의 장점을 온전히 누리기 위해선 시간 관리와 자기 관리 능력이 잘 되어야 한다는 전제가 따라옵니다. 그리고 이 두 가지는 생각보다 쉽지 않다는 것도 함께 느끼고 있고요. 앞으로 이 부분에 대한 경험도 차차 나눠보려고 합니다.




마무리하며


쓰다 보니 레쥬메나 인터뷰 답변처럼 정돈된 글이 되어버렸네요.


연차가 쌓이면서 업무가 반복되고, 팀의 미래나 신분 문제처럼 현실적인 고민들도 겹치다 보니 예전보다 글감이 잘 떠오르지 않았던 것도 사실이에요. 주변에 뛰어난 엔지니어들부터 커리어를 치열하게 설계하는 분들도 많아서 제 이야기가 얼마나 도움이 될까 고민하며 글을 망설이기도 했습니다.


그럼에도 누군가에게는 또 하나의 시각이 될 수 있다는 마음으로 이 시리즈를 틈틈이 적어보려고 합니다.




혹시 궁금한 점이 있다면 편하게 남겨주세요. 글감으로 큰 도움이 될 것 같습니다.




keyword
매거진의 이전글실리콘 밸리 개발자 회고록: 커리어를 위한 중요한 교훈