시간과 공간 그리고 진실의 방

퇴사 이후에 제 자신에 대한 성찰과 인고의 시간을 보내며 면접을 보고 공부를 진행하고 있다.

다름 아닌 무엇보다도 걸리는 것은 잦은 이직경력 이랄까

이게 누군가가 보기에는 "어쩔 수 없었다." 라고 대답하기에는 어려웠던 많은 환경들과 수많은 것들

그리고 그러한 부분을 극복하지 못한 것도 결국은 내가 아닌가 싶기도 하고

프리랜서로서 다년간의 활동을 하면서 클라이언트들을 설득하는 커뮤니케이션 스킬을 얻었다고 생각했지만, 결과적으로 나는 커뮤니케이션 스킬에 있어서나 사람을 배려하는 부분에 있어서 부족했던 것은 아닌가 다시금 돌아보게 되는 시간들이 되고 있다

또한 가장 큰 것은 "내 커리어에 있어서 나는 애매한 사람인가? 애매한 사람이 아닌가" 라는 것인데

많은 개발자들과 소프트웨어 엔지니어, 시스템 엔지니어들은 하나의 언어나 주어진 스택쪽으로 일직선을 향해 달리는 반면에 나는 그렇지 못했던 부분이 아쉽게 작용한다

결과적으로는 나도 진득하니 엉덩이를 붙이고 둥지를 틀고 싶은 곳을 찾고 있는데, 그마저도 쉽지 않은 것이 현실이다.

아니 정확하게는 많이 부족한 내 자신이 문제인 것이 맞다고 보는 것이 맞겠다.

더 잘하고 싶고, 더 잘 해내고 싶고, 예전보다 더 끈질기게 물고 늘어져서 성취를 이루어낼 수 있는 자신감은 있지만

그러기엔 아직 나는 좀 부족한 것 같다는 생각이 든다.

그렇게 6개월을 보내다 보니 어느새 이력서를 지원했던 곳과 면접을 진행했던 곳이 140곳을 넘어가고 있다.

드라마 육룡이나르샤 에서 정도전 역할을 맡았던 김명민 배우가 했던 말이 있다

결국은 네가 만들려는 세상과 내가 만들려는 세상이 같은 것인데,
내가 한들 어떠하며, 네가 한들 어떠하겠느냐

고단하구나 방원아

심하게 공감되는 대사가 아닌가 싶다

Recruiting process

서류전형 - 온라인 테스트 (Online Assessment) - 1차 면접 (Technical Interview) - 2차 면접 (Loop Interview) - 최종합격

정말로 정말로 험난한 여정이 아니였나 싶다. 무엇보다도 굉장히 나에게 행운이였던 것은 최종면접까지 바로 갈 수 있는 길이 AWS Event 를 통해서 기회가 주어졌었기 때문이다.

이러한 기회와 경험을 가질 수 있게 해줬던 AWS 에 정말 소중함과 고마움을 느끼고 감사하다.

내가 이번에 치뤘던 부분은 Loop Interview 이고, 추가적으로 Technical interview 까지 겸해서 보게 되었다. 사실상 최종면접임에도 불구하고 Technical Interview 까지 진행된 것을 보니, 아무래도 1차 & 2차 Process 를 통합해서 제공해주셨던 모양이다.

특히 Danny 님께서 제공해주셨던 AWS SE 가 읽어야할 부분에서 Documents 를 읽고 공부하면서 느꼇던 여러가지 부분이 있는데

1. 내가 Linux 에 대해서 자신이 있다고 생각했는데 생각보다 Deep Dive 하게 알지는 못했구나 라는 사실

2. Linux 에서 Legacy 적으로 기본적인 것들이라고 볼 수 있지만, 그런 것들의 개념에 대해서 까먹었었다는 사실 (굉장히 아쉬웠다.)

학창시절에 내가 가장 유일하게 자랑할 수 있었던 무기는 암기능력과 동시에 세세한 설명까지 모두다 외워버리는 스킬을 가지고 있었다. (그 당시는 당시에 배우는 모든 것들이 내가 가는 길에 도움이 될 것이라 자신있게 생각했기 때문이다.)

하지만 역시 세월이 지나고 사람은 녹슬기 마련인지, 갈고 닦지 않아서 그런 것인지는 몰라도 내가 가지고 있던 녹슬은 부분이 어느 정도 드러났구나 라는 부분을 오늘의 Technical Assessment 부분에서 느꼇다. 

하지만 이번에 Technical Assessment 를 진행하면서 기분이 좋았던 점은, 아무래도 "면접을 본다기 보다는 Session 을 즐길 수 있는 시간이 됬었다" 라는 부분이 아닌가 싶다.

"이러한 이러한 개념에 대해서 설명해주세요." 라는 부분을 interviewer 분께 요청 받았을 때에, 내가 내는 답변에 대해서 이것으로 끝이 아니라 지속적으로 물어봐주시고 내가 무언가를 더 생각하고 유도할 수 있도록 생각하게 해주시는 부분에서 확실히 내가 어느정도 알고있기도 하고 생각날 수 있도록 섬세히 배려해주신다는 점이 너무 기분이 좋았다.

면접을 보고 나서 Tech Assessment 에서 어느 정도 털린 부분 (사실상 많이 답변 못한 부분)이 많이 있긴 하지만 아무래도 평소에 갈고닦던 스킬들이나 개념들에 대해서 정확히 알고 넘어가는 부분은 반드시 다시 필요해보인다.

그래서 앞으로 계획하고 있는 것은, Danny 님께서 건내주신 것을 기반으로 SE가 알아야 될 부분들에 대한 Document 들을 세세하게 읽고 공부해볼 생각이다. AWS에 합격하던 합격하지 못하는 것과는 더불어 1주일 간 공부를 하면서 너무나 행복했기 때문이다.

추가적으로 Loop interview 를 겪으면서 내가 가지고 있던 "이건 나의 Story 이자 History 요.."  를 기반으로 LP에 접목하여 AWS와 얼마나 Fit이 잘 맞는가에 대한 부분을 겪어보는 것을 가졌었는데, 아무래도 LP보다는 Technical Interview 에 대해서 더욱 심층적으로 힘을 썻던 탓인지 생각보다 잘 준비해서 치르진 못했다.

심지어 16 LP 중에서 8가지의 LP만 나온하셨는데, 몇몇의 interviewer 분들 께서는 LP를 3개 ~ 4개 들고 오신 것 같은 느낌까지 받을 정도로 빡셋던 부분이 있다. (마지막 Session 에서 치뤗던 Interviewer 님께 받은 부분이였다.)

내가 준비했던 사례가 적절하지 않았거나 뭔가 부족하거나 시간이 부족했거나 더욱 더 확인하고 싶으셨던 것이겠지라고  좋게좋게 생각하고 있지만 사실 마지막 Session 때에 식은땀을 엄청나게 흘렸다.

(안그래도 땀돌이인데 나자신 홍수를 낼 뻔했다.)

이번에 채용 프로세스를 진행하게 되면서 내가 가장 크게 느낀 것 중 하나는, 내가 Linux 를 정말 좋아하고 사랑한다고는 하였지만 정말 그렇게까지 사랑했던 것이 맞는 의문을 다시한번끔 다시 가지게 되었다

내가 정말 찐으로 Linux 를 좋아하고 사랑하는지를 많은 사람들 앞에서 조금 더 당당하게 드러낼 수 있도록 많은 부분을 갈고 닦아야 겠다고 느꼈고, 결과적으로 떨어질 것으로 직감하고 있기에 취업이 될 지는 모르겠으나, 또다시 AWS 에 1년~2년뒤에 도전해보게 되지 않을까 싶다.

그렇게 해서 내가 지원했던 결과는 꽤나 많은 횟수를 자랑하는데

AWS Solutions Architect (서류합격 이후 1차 인터뷰 보고 광탈)

AWS CSE - DMS (서류합격 이후 1차 인터뷰 보고 광탈 - 여기서는 아무래도 Development 가 두드러지지 않았나.)

AWS TAM (요기는 그냥 서류광탈)

AWS CSE - LIIN (얼떨결에 AWS에 많은 부분을 지원한 부분 통하여 사랑을 받은 것인지 몰라도 꽤나 인상깊게 봐주셔서 너무 감사했다.)

비록 Back-end Developer 로 시작했으나 DevOps 이자 SE 로써의 방향또한 놓치고 싶지 않고, 내가 좋아하는 것 또한 구조를 학습하고 개선하고 공유하며 남들을 Support 하는 부분이기에, 꼬옥 AWS 와 함께 해보고 싶다.

음 일단 대충 요약하자면

서류 전형  - 코딩테스트 - 1차 전형 - 2차 전형 - 연봉협상  

이 단계로 이뤄질꺼고, 서류단계에서 합격한 상태에서 코딩테스트를 진행했다.

일단 코딩테스트에 응한 바를 살펴보면 난이도는 지금까지 봣던 코딩테스트중에 최상을 자랑했다.

문제 유출하면 안된다고 해서 언급할 수는 없지만, 일반적으로  골드 찍을 정도면 충분히 풀겠지? 라고 했다가는 큰코가 날아가버린다.

내 경우는 클라우드인프라팀에 Backend Engineer 직군이였고, 

자격요건은 Java 개발 경험 5년에 해당하거나 준하는 경력 이상 등과

등을 요구하는 포지션이다.

정확하게는 야놀자에 서류썻다가 광탈당한게 5번은 넘었던 것 같은데, 

LinkedIn 을 통해서 HR 담당자님과의 별도의 커피챗 이후에 2 포지션으로 지원해서 합격했다.

사실 가장 해보고싶던 것은 DevOps 계열이긴 한데,

JPA 에 클라우드 인프라가 합쳐진것도 너무 끌려서 결코 놓치고 싶지 않았다. (사실 여기가 난이도가 더 빡세보여서 기피하려던건 안비밀이다)

코딩테스트가 합격할진 모르겟는데 2문제가 주어졌고 90분인가 95분이 주어졌었다

첫번째 문제 푸느라 진짜 골머리를 부셧던거 같은데 다행히 Edge Case는 다 통과했고 45분인가 40분 남은 시점에서 2번째 문제로 넘어갈 수 있었다.

문제는 두번째 문제가 나름 그나마 쉽게 만날 수 있는 Problem Solving 류의 영역이였는데, Edge Case 풀다가 5개중에 4개밖에 잡질 못했다.

살다살다 그 문제에서 Edge Case 다 잡지 못하리라고 생각한건 처음이였는데 어마무시한 일이였고,

그 때문에 코드를 수십번도 지우고 다시짯던 것 같다 (그 40분동안 진짜 알고있는 관련지식은 다 짜집기하고 넣어서 짜보려고 노력했었다)

그런데 결국은 실패했다. (어 그럼 떨어지겟지?)

결론적으로 HR쪽에 있는 원석님이 언급해주신 대로 야놀자에서는 Problem Solving 쪽을 굉장히 강화해놓은 것 같다. 단연코 내가 풀었던 코테중에는 최상급이였다고 믿고있다.

난 항상 면접이 끝날 때마다 면접관분들에게 "짧은 시간만으로는 알 수 없겠지만, 제 이력이나 면접에서 볼 때에 어떤 부분을 공부하고 더 알아갔으면 좋겠는지" 를 여쭤보는 편이다.

당근마켓

이하 바니바니 바니바니 당근 당근에 SRE Part 에 지원하였고, 서류전형은 합격하였지만 화상면접은 글쎄다...

일단 면접 후기와 면접관님에 의한 부분을 좀 보완하자면 내가 실제로 해야할 부분들은 앞으로 

Ashon 님의 조언은 Terraform 을 실전적으로 사용해보라는 말씀을 가장 중점적으로 언급해주셨다.

네트워크 부분에서 이론적인 부분을 학습하였다면, SRE Engineer 로써 성장하기 위해서는 실제적으로 다뤄보는 것이 가장 중요한 부분이긴 하니까 말이다.

아무래도 AWS CloudFormation 을 사용해본 경험은 있지만, Cloud Formation 의 경우 AWS Product 군에만 한정적이고 Terraform 같은 경우에는 Cloud Provider 들을 넘나들어서 Microsoft Azure, Google GCP, AWS CloudFormation 을 다 지원할 수 있다는 것이 장점이 되겠다

그러니까 빠르고 좋은 Go 언어를 사용해서 자사에서 Public Cloud 제품군들을 여러 곳에서 사용 중 이라면, 해당 부분에 대하여 자동으로 배포할 수 있도록 설정할 수 있으니까 이것이 개꿀따리가 아니겠는가. 아무래도 이건 꼭 해봐야겠다 싶었다

그리고 추가적으로 Ozzy 님 같은 경우도 조언을 주셨는데 

1. 실제적으로 어느 정도 트래픽을 제어할 수 있는 부분에 대한 경험들을 해볼 것

예를 들어서 Java 에서는 GC 가 관여하고 있는데, 이 GC 의 Heap Size 를 조절하는 것에 대해서도 이야기 해주셨다.

이 부분에 대해서 가장 흥미로웠던 부분이 무었이냐면 기본적으로 JVM 에서 GC 는 Heap 영역에 대해서 Memory 를 turn over 하는 역할을 가지고 있는데 이 부분에 대해서 Heap Size 를 조절할 경우 Latency 를 조절 할 수도 있다는 생각이 들었다.

2. 트래픽을 제어함에 있어서 포트가 고갈 되는 상황이 왔었는 지를 물어보셨다

이는 분명 댕근댕근 마켓에서는 배포를 해서 들어갔는데 유저가 너무 많이 몰려서 포트가 고갈될 수도 있다는 이야기이다. 그렇다면 이 경우에는 어떻게 해야할까? 과연 HTTP 2.0 을 지원하고 브라우저에서 Auto Compression 을 지원한다고 해도 트래픽이 전부다 처리가 안 될수 있다는 이야기 이다.

그렇다고 해서 네트워크 트래픽에 대해서 포트로 들어오는 데이터들을 전부다 바이너리화 해서 메모리 아껴쓰자고 010101010100000 이따구로 보낼 수는 없는 노릇이고, 다만 HTTP 2.0 에서 어느정도 Prioritization 과 Multiplexing 을 지원함으로 인해서 HTTP 1.1 때보다는 이 부분에 대해서 처리할 수 있을 것만 같다는 생각이 들긴 했다.

3. Socket Descriptor 가 뻗은 상황이 있었는지에 대해서 물어보셨었다

그래 있었다.. 그 전직장에서 PHP-FPM 이 뻗은 상황이 있었고, 이 부분에 대해서 emergency restart setting 으로 간신히 그걸 처리해서 어느정도 확보하긴 했었지만 Socket Descriptor 가 뻗은 경우는 단순히 그런 경우가 아닐 것이다

분명한 것은 위에서 언급한 것들을 처리하려면 TPS 에 대한 처리가 필요할 것 같은데, 그렇다면 Scale Up, Scale Out, HA 이외에도 캐시를 두는 것과 CDN 을 직접 구축해서 효율화 해야하는 것도 있을 것이다.