brunch

You can make anything
by writing

C.S.Lewis

by 콩나물 석이 Mar 07. 2022

첫 6개월과 온콜 (On Call), 배운 점

Vulnerability and Growth Mindset

지난 2월 내 생의 첫 온콜을 마쳤다. 2월 7일부터 13일까지 1주일간 시니어 온콜을 쉐도우 하고, 그다음 주인 2/14일부터 (잊지 못할 밸런타인데이가 되었다) 20일까지 온콜 primary, 2/21일부터 2/27일까지 온콜 secondary 역할을 수행했다. 일단 큰 문제없이 잘 마쳤다, 장하다! 주니어 엔지니어로서 큰 숙제를 해결한 기분이다. 수고했다!

온콜이란, "당직"같은 개념인데, 온콜 primary 롤을 수행하는 중에는, 일반 업무를 수행하지 않고 지금 당장 터지는(?) 일들을 처리하는 일이다. 온콜의 역할, 기간, 그리고 강도는 팀마다 다르다. 고객에게 실시간으로 영향을 미치지 않는 서비스의 경우 온콜이 없는 팀들도 있다 (연구팀 등). 당직을 하는 동안은 중요한 문제가 터졌을 때 바로 확인하고 고쳐야 하기 때문에, 일주일간 올드보이처럼 집안에서 보낸다.

우리 팀의 경우, 사건의 중요도에 따라 Severity 1 - 4까지 나뉘는데, 주로 Sev 3이 제일 많고, 이 경우는 일반 업무 처리 시간 (9시-5시) 사이에 하나씩 처리하면 된다. Sev 2의 경우는 고객에게 영향을 미치는 문제가 생겼을 때 알람이 울리며, 24시간 내내 대기하고 있다가 알람을 받게 되면 새벽에라도 일어나서 고쳐야 한다. 내가 받지 않으면, secondary (백업) 온콜에게 전화가 가고, 그도 받지 않으면 매니저에게, 매니저도 받지 않으면 그 위의 매니저에게 전화가 가기 때문에 정신 똑바로 차리고 받아햐 한다. Sev 1의 경우는 상상조차 하기 싫은 사건인데, 한 지역 이상에 우리 서비스가 다운되는 것 이상의 재앙이다. 이 경우는 온콜이 혼자 해결하지 않고, 모든 팀원들을 다 불러서 (page 한다고 말한다) 다 같이 해결한다. 나는 다행히도 sev1 은 본 적이 없고, 전설처럼 내려오는 썰들을 들었는데 예를 들면 데이터베이스를 주니어 엔지니어가 실수로 다 지웠다는 둥 간담 서늘해지는 이야기이다.

각 팀마다 온콜의 강도는 천지차이이며 주로 클라우드 서비스 쪽이 온콜의 강도가 강하다. 내가 속한 팀도 클라우드 서비스이지만 온 콜의 강도가 그렇게 센 팀은 아니다 보니 한 사람이 1주일 동안 온콜 primary를 수행하고, 그다음 주에 secondary(백업)으로 참여하여 프라이머리 온콜 담당자가 부득이한 상황으로 자리를 비울 때 대신 자리를 맡아준다. 온콜 강도가 센 팀은 2-3일씩 교대를 하기도 하고, 너무 강도가 심한 팀은 12시간씩 교대하는 팀도 보았다. 이 경우에는 2개의 팀이 한 서비스를 담당하며 두 팀이 다른 시차에 있어서 (예) 미국국에 한 팀 유럽에 한 팀) 서로 밤-새벽 시간의 잠은 보장해주는 식의 스케줄이다. 이런 팀에 가면 안 된다 고생길 바로 열린다.

온콜은 자다가 언제 Page 될지 모른다는 두려움(실제로 새벽 1, 2시, 5시에 페이지 당했다), 어려운 일이 터졌을 때 최대한 빠른 시간 안에 해결해야 한다는 압박감, 너무나 다양한 종류의 문제가 터지기 때문에 오늘 본 문제가 내일 본 문제와는 너무 다른 광활한 출제범위에서 오는 무기력감 등 주니어 엔지니어인 나에게는 너무나 무서운 큰 산이였다. 주니어 엔지니어로서의 첫 6개월과 온콜 경험을 통해 느끼게 된 점 몇 가지를 적어본다.

1. 눈치 보지 말고 많이 물어봐야 한다.

온콜 쉐도잉을 하면서 더 크게 깨달은 점은, 내가 바보같이 보일 것을 걱정하지 말고 모르면 알 때까지 물어봐야 한다. 그전까지는 몰라도 좀 아는 체도 하고, 정확히 몰라도 대충 이해하고 넘어가려고 하는 경우가 있었다. 너무 꼬치꼬치 캐묻기엔 눈치도 좀 보이고, 내가 아주 아무것도 모르는 멍청이라는 것을 들키지 않을까 하는 창피함에 나중에 찾아봐야지 하고 todo 리스트만 늘려댔다. 하지만 온콜은 대충 아는 체 해가지곤 문제를 해결할 수 없기 때문에 시니어를 쉐도우 하는 동안 정말 많이 물어봤다. 1:1 개인 과외 시간이었는데, 온콜 하느라 자기도 바빴을 텐데 친절하게 알려준 시니어에게 너무 고맙다. 나를 좋게 봐준 사람은 질문하는 나의 모습을 호기심이 많고 배우려는 의지가 강한 사람이라고 판단할 테고, 나를 안 좋게 보는 사람은 질문을 하던 안 하던 나에게 안 좋은 시선을 보낸다는 사실은 너무나도 잘 알려진 사실인데, 이렇게 마음을 먹고 당당하게 살기가 참 어렵다. 똑똑하고 배우려는 의지가 강하고, 같이 일하고 싶은 센스 있는 동료가 되고 싶은 마음에 항상 물어보기 전에 브레이크가 걸린다. 이 마음을 이번 온콜 경험을 통해 참 많이 내려놓았다. 일단 내가 죽겠는데 그런 게 무슨 상관이더냐. 물어보고, 대충 대답해주면 다른 엔지니어에게 가서 또 물어보면 된다. 일은 일이니 상쳐받지 말고 많이 묻고, 많이 고민하고, 많이 배우자.

2. 모를 때 무서운 마음에 너무 휘둘리지 말자. 직면하다 보면 결국 다 해결된다.

엔지니어 일을 하다 보면 이런 경우가 정말 많다. 어떤 업무를 하라고 티켓을 받았는데 이게 도 당최 무슨 소리인지 하나도 모르겠는 경우이다. 이럴 때 나는 무섭고 무기력한 감정이 엄습한다. 이거.. 못하면 어떡하지? 이 티켓 평생 해결 못하면 어떡하지? 수학 학원에서 문제를 못 풀어서 나머지 공부하던 경험이 있다면, 딱 그 느낌이다. 집에 가고 싶어서 마음은 초조한데 어떻게 푸는지는 하나도 모르겠어서 아득한 기분으로 처량하게 문제를 푸는 느낌이다. 이때, 너무 이 마음에 휘둘리지 말고 1번으로 돌아가서 눈치 보지 말고 많이 물어봐야 한다. 이 티켓 정확히 무슨 문제를 말하는 거냐, 어디서 시작하면 좋으냐, 누구한테 물어보는 게 제일 좋으냐, 예전에 비슷한 경우는 어떻게 해결했느냐, 이 문제가 탄생하게 된 배경이 무엇이냐, 어떻게 정확히 해결하기를 원하는 것이냐 등 눈치 보지 말고 적극적으로 물어봐야 한다. 하나의 실마리가 풀리기 시작하면 모든 퍼즐이 맞춰지면서 푸는 속도가 빨라지기 때문에, 문제를 풀기 전 밑바닥을 찬찬히 다져야 한다. 대충 지름길로 풀려고 하다가는 더 꼬여서 고생하다 다시 원점에서 시작하는 경우가 많았다. 당황하지 말고, 천천히 제대로 이해하면서 한걸음 한걸음 작은 단위로 분해해서 해결하다 보면 어느새 해결이 되어있다. 그러면서 또 배우고 성장하는 것이다.

"문제 해결"이라는 말을 계속 쓰다 보니, 개발자가 개발은 안 하고 무슨 문제풀이?라는 의문이 들 것 같기도 하다. 새로운 서비스를 스크래치 단계에서 개발하고 있는 팀이 아니라면, 대부분의 시간은 문제에 대해 고민하고 해결책을 찾는데 쓴다. 기존 코드를 좀 더 효율적으로 만드는 방법, 유지보수가 쉽도록 개선하는 방법, 새로운 기능을 현재의 기능을 전부 유지하면서 추가하는 방법, 더 빠르게 정보처리가 가능하도록 디자인을 바꾸는 문제 등 너무나 다양한 문제 영역이 존재하고 이를 처리하기 위해 고민하는 게 엔지니어이다. 시니어로 갈수록 문제의 규모가 커지고, 이중에 해결 못하는 문제들도 있다. Known issues라고 알고는 있지만 고치지 못하는 문제들도 더러 존재한다. 이렇게 늘 머리를 싸매며 고민하기 때문에 엔지니어 중에 대머리가 많다고 우스갯소리로 말하기도 한다.

3. Be kind to myself and ask for feedback

올해 초부터 얼마 되지도 않은 신입 주제에 Imposter Syndrome(가면 증후군)을 겪었다. 가면 증후군은 한마디로 내가 엑스맨이라고 생각하는 것이다. 내 주제에 너무 과분한 팀과 회사에 운 좋게 들어와서, 너무 똑똑한 인재 사이에서 멍청이인 나를 숨기면서 초조해하고 불안해하는 증세이다. 상상 속에서 완벽한 주니어 엔지니어의 모습을 만들어두곤, 그 상상 속의 친구와 나를 끊임없이 비교하고 나를 깎아내렸다. 6개월이나 됐는데 왜 이렇게 퍼포먼스를 못 내지? 나는 왜 이렇게 이해력이 떨어질까? 나는 왜 아직도 헤맬까? 왜 이렇게 팀에게 짐일까? 등 온갖 자기 비하적인 생각을 했다. 웃긴 건 격주마다 진행되는 매니저와의 1:1 면담에서 매니저에게 항상 긍정적인 피드백을 받았는데 이것도 거짓말 같다고 생각했다ㅋㅋ 그냥 좋은 말 해주는 거겠지 뭐, 이런 생각.

온콜이 끝나고 내가 스스로 1주일 동안 팀에게 일어나는 일들을 (주변의 수많은 도움을 통해) 나 스스로 해결할 수 있다는 마음이 들면서 자신감을 서서히 되찾기 시작했다. 매니저와 온콜이 끝난 뒤 2월 마지막 주에 formal performance review를 했는데, 정말 좋게 받았다. 내가 내 솔직한 마음을 이야기하니, 매니저 왈 - "일단 imposter syndrome의 정의를 지금 네가 말하고 있고, 나는 좋은 말을 해주려고 있는 사람이 아니라 너의 동료와 내가 본 점을 너에게 솔직하게 말하는 역할이 직업인 사람"이라고 했다. 정말로 동료들이 네가 잘하고 있다고 생각한다고 생각하고, 자기도 동의한다고. 개선해야 할 점 없이 fantatic 하게 일을 하고 있다고, 앞으로 팀에서 새로운 사람을 뽑을 때 본보기가 되는 사람이라고 말을 해 주었다.

주변 동료들과 매니저에게 모두 들은 나의 가장 강점은, 좀 모호한 부분이 있을 때 상대방에게 끝까지 질문하고 (clearfying questions) 이해하려고 한다는 점을 높게 샀다. 이 덕분에 신입 멤버임에도 규모가 크고 복잡한 업무를 같이 잘 수행한다고 생각한다고 피드백을 받았다. 나는 기죽어서 제대로 물어보지 못하는 것이 가장 약점이라고 생각했는데, 아이러니하게도 동료의 시선에선 정 반대였다. 내가 생각하는 나와 남이 보는 나는 다르다는 것을 다시 한번 깨달았다. 이렇기 때문에, 항상 피드백을 요청해야 한다. 내가 우리 팀에게 맞는 방향으로 잘 설정이 되어 있는지, 나쁜 이야기를 듣고 마음에 상쳐를 받을까 봐 걱정이 되어도, 눈 질끈 감고 객관적이 피드백을 요청해야 한다. 내가 성장하고 싶어서 물어보는데, 잠깐의 창피함과 상쳐에 너무 신경 쓰지 말자. 지금까지 캐나다에 살면서 온갖 흑역사는 다 만들었는데, 이쯤이야!

쫄지말고 당당하게 배우고 성장하자!

Title Photo by Suzanne D. Williams on Unsplash

keyword

콩나물 석이 소속 직업 개발자

Software engineer based in Seattle

구독자 389

작가의 이전글 테크 기업 엔지니어와 피엠은 뭘 할까? 팟캐스트 아메리카노 북클럽 모집 작가의 다음글

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari