내가 면접을 떨어진 이유 - SRE 인터뷰

몇 달 전 국내 대형 유니콘 IT기업의 SRE 인턴공고를 보고 지원을 하고 서류통과가 되어 운이 좋게 면접을 볼 수 있었습니다.
모두가 아는 유명한 회사이고, 기술적으로도 성장이 대단하고 훌륭한 분들이 많다고 알려진 회사였고, 무엇보다 SRE 쪽은 신입은커녕 인턴도 잘 안 뽑기에 흥미가 많았습니다.

 

면접을 보기 전 솔직한 심정으로는 인턴으로써 기술적으로는 준비가 조금은 되었다고 느꼈었습니다. 아직은 우물 안 개구리지만 학부생 시절에 직접 클라우드 인프라를 설계하고 DevOps를 구축하고 개발을 혼자 주도적으로 한 경험은 제 큰 경쟁력이라고 생각하고, 자부하고 있습니다. 1시간가량의 1대 5 면접도 좋았습니다. 클라우드 인프라에 잔뼈가 굵으신 면접관분들께 제 아키텍처를 보여드리고 설명드리는 일은 부족한 면이 많았겠지만 간단한 피드백을 들을 수 있었고 정말 많은 걸 배울 수 있었습니다.

 

면접관분들은 아키텍처의 서비스를 사용한 이유,고려했던 다른 서비스와의 비교, 서비스 활용의 장단점에 대해 세부적으로 물어보셨고 저는 설계했던 흐름대로 대답을 했습니다. 물론 저에게 부족한 점은 많았습니다. 대표적인 질문으로는,

직접 설계한 프로젝트의 AWS 아키텍처

• 클라우드 워치를 사용했다고 했는데, 유저 트래픽에 대응한 알람 설정을 어떻게 했는지
  • 후술
• AWS Lambda 어렵고 쓰기 까다로워서 다른 팀원들이 사용하기 어려웠을 텐데, 어떻게 해결했는지
  • 백엔드는 저 혼자 개발해서 무리가 없었고, AI파트 팀원이 Lambda를 생소해하고 어려워해서 주석과 기본 코드들을 담은 템플릿을 제공해주었다.
• AWS Lambda 쓰면서 어려운 점 없었는지?
  • api gateway-lambda-dynamodb의 간단한 REST API 요청을 처리하는 과정에서 자꾸 레이턴시가 튀길래 오류를 찾아보니, 람다가 기본 설정 용량이 128MB여서 따로 변경없이 디폴트값으로 적은 기본 용량으로 실행 될 때는 Lambda가 warm start하지 않을 가능성이 크다는 걸 몰랐다. nodeJS런타임 환경의 람다였는데, SDK를 사용해서 lambda-dynamoDB 간 connect를 기본 설정을 하는 시간이 조금 걸린다. Lambda가 계속 cold start를 하니 매 실행마다 connect 설정이 실행되어 레이턴시가 생기게 되었던 것이다. 간단하게 용량만 늘리니 레이턴시 이슈가 해결되었던 경험을 했다. (이어서 AWS Compute Optimizer 얘기도 했으면 좋았을 것 같네요..)
• gitlab CI/CD 어떻게 사용했는지
  • 개발 시간이 촉박해 전체 인프라를 github action - argoCD 등을 붙여서 CI/CD를 완성하는 건 후순위로 미뤘고, 프런트 개발에서 랜딩페이지나 개인정보보호 페이지 등의 정적 콘텐츠 S3를 저장할 때 CI/CD 파이프라인을 완성시켜주어 개발의 편의를 도왔다.
• 메인 페이지 로딩 레이턴시 어떻게 개선했는지? 어떻게 측정했는지? 목표를 몇 ms쯤으로 잡아야 할까?
  • API 테스트할 때 postman의 ms와 AWS api gateway의 ms와 Lambda의 ms를 개별 측정하여 차이를 조사해 병목구간을 찾았다. 목표 ms에 대한 명확한 기준은 없었던 것 같다. 유저의 입장에서 1s안에 메인 페이지로 로드되어야 한다고 생각했다. (여기서는 AWS X-ray가 정답이긴 했을 것 같습니다.)
• 만약 유저 트래픽을 클라우드 워치로 지표 알림을 설정한다면 몇% 일 때 어떤 설정을 업데이트해야 할까?
  • 후술
• Lambda에 VPC는 사용하지 않았는지, 안 했다면 왜?
  • 현재의 구성에는 고객의 민감한 개인정보나 크리티컬한 부분 등의 필수적인 보안사항이 아니라 판단해 개발을 후순위로 미루게 되었다. 
• 다른 Iac 선택지 중에 왜 Terraform을 사용했는지, 써보니까 장단점은?
  • Cloudformation과 Terraform을 초기에는 고민했으나 멀티 클라우드에도 관심이 있어 AWS내에서 한정적으로만 쓰이는 Cloudformation보다는 더 넓은 영역으로 확대될 수 있는 Terraform을 사용했다. 인프라를 코드로 관리한다는 장점은 정말 편하고 좋았지만 Lambda와 Terraform의 연계성이 조금 아쉽다. Lambda 코드를 작성하고 예제 JSON을 테스트하려면 docker로 Lambda 런타임 띄워서 다시 테스트하고 zip 압축해서 Terraform plan, apply 시키는 과정이 조금 불편했다.
• 오픈소스 개발해보고 싶은 것 있는지?
  • 아까 말씀드렸던 Terraform-Lambda의 개발-테스트-배포 자동화 오픈소스를 제작해보고 싶다.
• Serverless Framework와 Lambda 중에 왜 Lambda를 사용했는지?
  • 서버리스 프레임워크는 애초 고려대상이 아니어서 서버리스 아키텍처를 선택한 후 바로 Lambda를 사용했다.
• 왜 서버리스 아키텍처를 택했는지? 실제로 어떤 이득이 있었는지? 그 이득으로 프로젝트에 어떤 효과를 얻었는지?
  • 애자일 방식대로 빠른 개발을 목표로 했고, 이를 위해 MSA의 한 종류인 서버리스 아키텍처에 관심이 있었다. 더욱이 예산 몇백 원이 소중한 초기 스타트업 형태를 뗬기 때문에, 사용자가 적을 때 서비스 비용을 확실히 줄일 수 있는 장점이 있었고 지속적인 서비스 요구에 빠른 대응이 필요했기 때문에 사용했다. 실제로 모놀리식 아키텍처에 비해 약 90% 정도 예산의 절감이 있었고 이 이득을 마케팅 예산으로 책정했다. 하지만 배포가 늦어져 마케팅 예산을 모두 활용하지 못했던 건 아쉬웠다.
• 왜 첫 서비스 배포가 늦어졌는가?
  • 기획을 마치고 서비스를 개발하는 단계에서 머신러닝 모델의 한계와 서비스 확장성에 문제가 있다는 결론을 내려, 급하게 서비스의 기획을 조금 수정하게 되었다. 때문에 바뀐 기획에 맞게 더 완성도 있게 첫 배포를 시도하는 게 맞겠다고 판단했다. 개발 속도의 문제 때문만은 아니었다.

 

기술적인 질문 중 기억에 남는 대화는,

🥸면접관님 : 만약 유저 트래픽을 클라우드 워치로 추적해 지표 알림을 설정한다면 몇% 일 때 어떤 설정을 업데이트해야 할까요?

🐵나 : 가능한 동시성의 80%가 찬다면 AWS ApiGateway의 캐싱 기능을 on 해서 증가세를 억제할 것 같습니다.

🥸면접관님 :80% 일 때의 해당 대응을 한다면 조금 늦지 않을까요? 다른 방법은 없을까요?

🐵나 : 아.. 답변을 정정하겠습니다. 30%일 때 캐싱 기능을 업데이트하고 70%일 때 AWS Lambda의 예약된 동시성( provisioned concurrency)을 on 할 수 있도록 클라우드 워치를 구성할 수 있습니다.

🥸면접관님 : 그 수치를 정한 구체적인 방법이나 근거가 있나요?

 

이런 클라우드워치 설정에 제가 약했습니다. 프로젝트 과정에서 개발과 배포에만 집중했지 운영 경험은 사실상 0이었기 때문에 알람 설정이나 대응 부분에서의 답변은 완벽한 실수였습니다. 80%에서 캐싱을 켠다니... 사실 지금도 30%,70% 대응은 확실하게 모르는 상태입니다. 관련 서적을 읽은 내용을 토대로 답변을 했는데, 어느 서적의 어느 부분인지 정확하게 기억이 나진 않아서, 조금은 더 공부가 필요합니다.

 

하지만 제가 생각한 탈락 요인의 가장 중요한 부분은 이런 기술적인 부분은 아닙니다. 

 

컬처 핏 : ‘조직 문화’ 라고 불리는 조직의 특성에 얼마나 잘 맞는가?

 

부족한 기술을 채우는 일은 쉽습니다. 무엇이 부족하고, 어떻게 개선해 나갈지만 안다면, 할 일은 분명하죠. 하지만 내가 이 조직에 일원이 되어 다른 지원자보다 어떤 시너지를 일으켜 어떤 긍정적인 효과를 낼 것인지 아는 것은, 참 어렵습니다. 내가 지금 이 조직에 중요하고 필수적이고 우선적인 일이 무엇인지 찾고, 개선시켜나가는 방법을 아는 것은 매우 중요합니다.

 

저의 경우를 예시로 들면, 결과적으로 제가 수행한 임무는 실패입니다. 서버리스 아키텍처를 선택한 이유도 분명히 보여주지 않았습니다. 서버리스는 정말 좋은 기술이고, 잘 쓴다면 효율적이지만 분명 신기술에 속하고 익숙하지 않으며 한계도 분명합니다. AI파트에서 모듈을 Lambda로 이식하는데 시간이 많이 들어 머신러닝 모델 개선 작업에 시간을 쏟지 못해 생각했던 퍼포먼스를 실패했다면 제가 선택한 서버리스는 실패이고 조직에 마이너스를 준 겁니다. 요금을 90%나 줄였으나 개발 일정이 늦어져 더 큰 마케팅 비용을 써보지도 못한 채 프로젝트 일정이 종료되었다면 역시 제가 선택한 서버리스는 실패입니다. 장점을 하나도 못 살린 게 된 거죠.

어떻게 보면 신기술에 매료된 채 다른 팀원들의 기술 진입 장벽은 신경 쓰지도 않고 막무가내로 진행해 전체 조직에 피해만 준 셈입니다. 모든 프로젝트 타이밍 각각에는 우선시해야 하는 일이 있습니다. 기술적 완성도에만 심취해 프로젝트 초기에 중요한 마케팅, 기획, 다른 팀원들의 개발 도와주기에 힘을 쏟지 못한 건 잘못된 일입니다. 기술 도입은 나 혼자만 노력해서 되는 것이 아니라, 팀원 대부분이 뜻을 함께하고 공부해야 합니다. 그러기에 다른 팀원들의 시간적 비용을 계산해야 했을 것입니다. 

면접 때는 이 생각을 전혀 못한 상태였습니다. 나는 기술 이 정도로 했고, 완성도도 좋았다고는 하지만 면접관분들은 결국 내가 조직에 미친 영향, 다른 팀원들은 힘들지 않았나, 결국 어떤 이득이 있었는가 를 지속적으로 질문하셨고 저는 그때마다 큰 조직을 보지 못하고 저라는 한 개인에게만 몰두해 대답했습니다. 이기적이었고 편협했습니다.

 

---

 

50분짜리 면접으로 정말 많은 경험을 할 수 있었습니다. 5분의 면접관분들께 감사드리고, 더욱 그 회사에 관심이 갔습니다. 물론 컬처 핏이니 뭐니 해도 그냥 기술이 부족해서 일 수도 있어서 둘 다 부족했다고 생각하고 마지막 남은 학교생활 1년을 열심히 갈고닦아 더 성장할 계기로 만들겠습니다. SRE면접 후기글이니만큼 다른 지원자분들에게 조금이라도 도움이 되셨으면 좋겠습니다.