SWE Julie's life

Meta SWE/MLE 면접 후기 - Recruiter Call부터 연봉협상까지

Julie's — Fri, 4 Apr 2025 04:18:01 +0900

일반적으로 미국 내 SWE 취업 성공률을 따질 때 순수히 개인이 지원하는 것보다 Recruiter로부터의 cold mail 혹은 referral을 통한 지원이 훨씬 가능성이 높다고 한다. 내 경우에도 그랬다.

후기를 남기기에 앞서 대략적인 타임라인을 적어보자면,

25년 1월 28일: LinkedIn DM으로 cold mail 받음
25년 1월 30일: Recruiter call
25년 1월 31일: Recruiter call 결과 전달받고 Phone screen 스케줄링
25년 2월 10일: Phone Screen
25년 2월 14일: Phone screen 결과 전달받고 Onsite 설명을 위한 Recruiter call 스케줄링(2월 19일 진행)
25년 3월 6일: Onsite
25년 3월 10일: Recruiter로부터 check-in mail 받음
25년 3월 12일: 합격 결과 받음
25년 3월 13일: 연봉협상 시작, Team matching 없이 사전에 배정된 팀이 있다는 사실을 안내받음
25년 3월 19일: Offer letter 사인

거의 1개월반 정도 걸렸으니 굉장히 빠르게 진행되었다.

본래 Pre-screening 준비하는데 2주, Onsite를 준비하는데 최대 4주 정도로 잡고 총 프로세스가 2-3개월 정도 소요되나, 나는 휴직상태여서 여유시간이 많기도 했고 콜드메일을 받은 JD가 게재된지 꽤 된 (연락받았을 때 이미 1달이 지난 공고였음) 경우였어서 Head count가 닫히기 전에 얼른 해치우는 것을 목표로 했다.

각 단계에 대한 준비과정이나 팁은 다른 게시글에 자세하게 남겨뒀으니 본 글은 좀 더 후기에 가까운 재밌는 이야기들을 적어두려고 한다.

Recruiter Call

가장 첫 단계였던 Recruiter Call은 생각보다 순조롭게 흘러갔다. 한 가지 특이한 사항은 3rd party recruiter였고 Meta에 계약직으로 입사한지는 1달도 안된 따끈따끈한 리크루터였다. 통화에서는 주로 Meta의 인재상과 fit이 맞는지, 내 경험이 어떠한 것인지를 이야기하게 되었다. 이 때 기회를 마지막으로 나는 behavioral interview 외에는 현재 회사에서 어떤 프로젝트를 진행했고, 어떤 사람인지를 어필할 기회가 없었다. 돌이켜보면 미국 테크 기업들은 이전 회사에서의 경험을 기반으로 사람을 평가하는 비중이 한국에 비해 현저히 적은 편인 것 같다. 보통 Recruiter call도 결과가 안좋을 수 있다고 해서 콩닥콩닥했는데 생각보다 통화 중에 지속적으로 다음 단계로의 이동에 대한 암시를 주셨고, Pre-screening에 대해 설명하는 비중도 컸다.

합격 결과를 듣고 나서는 LeetCode Premium을 결제하고선 Meta tagged Top 50 문제(일반적으로 최근 6개월 기출을 많이들 푼다. 더 많은 문제를 풀고싶다면 6개월 > 30일 을 돌아가면서 푸는 것이 일반적인 것 같다)를 반복 풀기를 시작했다.

Pre-screening / Phone screen

나는 이 때의 인터뷰어에게 무한한 감사를 표하며 당시 인터뷰를 본 '나'에 대해서도 무한한 박수를 보내주고싶다. ㅋㅋㅋㅋ

두 개의 코딩 문제를 푸는 것이었는데 모든 문제 다 보지도 못했던 처음 보는 문제였다.

특히 인생에서 첫 코딩 인터뷰였어서 많이 긴장했다. 1) 영어로 설명(특히 메타는 communication을 강조함) + 2) optimal solution찾기 + 3) 코딩 잔실수 줄이기 - 이 삼 박자를 맞추기에 긴장감은 상당한 방해물이었다.

유투브로 본 수 많은 코딩테스트 준비 팁은 끊임없이 말하는 것이었는데 이 인터뷰어는 나에게 코딩할때만큼은 아무말도 안하고 정숙을 유지해도 된다고 해서 당황하기도 했다.

첫 문제는 수학 연산과 관련된 문제였는데 정수/실수 부분 각각에 대한 영어 표현이 생각이 나지않아 정말 장황하게 설명했던 기억이 난다....

코드가 상당히 지저분했는데 (실제 정답 코드도 지저분함, string input이었기 때문에 string <-> int로의 변환이 많았음) 중간 중간 syntax 실수들도 있었다. 간단한 split() 함수에 대해서도 실수가 있었지만, 코드를 써내려가며 반복 행위에 대해 inner function으로 모듈화하는 것을 잊지 않았다. 중간 중간 특정 자료형을 선택하게 된 이유에 대해서도 덧붙여가며 코드를 작성하기를 완성했다.

Dry run을 간단하게 돌리면서 내 결과에 대해 정당함을 증명해내고 나니 총 45분 중 35분이 지나갔다. 망했다고 생각했다.

그 다음 문제를 받기 전, 제발 다음 문제는 내가 알거나 접해보기라도 했던 문제이기를 간절히 기도했지만... 또 전혀 처음 보는 문제가 나왔다.

이 때의 나는 기지를 발휘했다. (내가 '나'에 대해 박수를 보내고 싶었던 이유) 문제를 보자마자 두 가지 경우의 수로 나누었고 가장 어려운 파트였던 마지막 경우의 수에서 뇌가 따르는대로 코드를 작성했고 실제로 동작했다...

원래 면접 시간에서 1-2분 정도 지났을 때 두 문제를 모두 풀었고 착한 인터뷰어는 그럼에도 불구하고 시간을 낼테니 궁금한 것이 있으면 물어보라고 했다. 하지만 나는 이 때 멘탈이 나가있었기에 질문이 없다고(!!!) 대답해버렸다. 그렇게 Bye를 외치며 인터뷰를 종료하고, 정말 혼이 나간 상태로 몇 시간동안 인터뷰 생각에서 벗어나질 못했다.

두 문제는 인터뷰가 끝나고 Leetcode를 뒤져봤는데 첫 번째 문제는 Easy버전의 문제를 tweak하여 Hard 문제로 바꿨고, 두 번째 문제는 실제 워딩 그대로 존재했던 문제이지만 준비하는 사람 입장으로서는 절대 접할 수 없는 문제였다. 그 정도로 빈도수가 낮은 문제였다. 6개월에 기출 1번 될까말까 하는 수준이었던 문제였다.

인터뷰가 끝난 뒤 노션에 복기를 하며 어떤 문제가 있었는지 다시 되짚어봤고, 그 날 저녁엔 남편과 함께 문제를 풀어봤었다. 남편은 두 문제 중 두 번째 문제가 훨씬 어려운 것인데 왜 첫 번째 문제에서 35분을 소비하고선 두 번째 문제는 5분만에 풀었는지를 의아해했다. 그리고 그 답은 나도 찾을 수 없었다..ㅋㅋㅋㅋㅋ ㅠㅠ,,

정말 열심히 준비했는데 처음 보는 문제들이 나오는 것에 무지 속상해했다. 보통 Meta의 코딩 문제들은 기출에서 유래하며 기출에서 살짝 변형되는 수준인지라 커뮤니티에서도 상당수 인터뷰어들이 손쉽게 통과하는 편이다. 나는 왜 그들과 같지 않았는지에 대해 한탄해하기도 했고... 메타를 마음 속에서 보내줘야겠다고 욕심을 내려놓았다.

그렇게 결과를 기다리다 그 주 목요일 정도쯤 리크루터에게 check-in 메일을 보냈다. 그러곤 2-3시간 후 바로 메일로 결과를 받았는데 당시 카페에 있었는데 메일을 받고선 나도 모르게 큰 목소리로 "나 합격했어!!" 하고 남편에게 외쳤던 게 기억이 난다.

돌이켜보면 시간을 꽉 채워서 2문제를 풀었기 때문에 그렇게 쟁쟁한 후보는 아니었지만 틈틈이 파이썬 관련 skill들을 인터뷰어에게 공유했던 것과 끊임없었던 소통이 합격의 키가 아니었나 생각한다.

프리스크리닝이 끝나고 나니 다른 리크루터로 배정되었다. 보통 3rd party를 쓰는 경우 이렇게 Prescreening 후에 메타 내의 HR 리크루터로 배정된다고 들었다. 그리고 나는 온사이트 일주일 전 또 다른 리크루터로 바뀌었는데 그 리크루터는 시니어 리크루터였다. 후에 통화하고 보니 새롭게 배정된 이전 리크루터와 이 리크루터는 서로 잘 아는 사이인 것 같았다. (같은 팀인 것으로 추정)

Onsite

Onsite에서도 코딩 인터뷰가 사실상 합격 여부를 단정짓는 가장 중요한 세션이기 때문에 준비하는 시간/노력의 비중을 훨씬 크게 뒀다. 다행히 Phone screen때 풀어뒀던 문제들이어서 좀 더 효율적으로 준비할 수 있었다.

이 때 Phone screen 준비를 위해 이미 풀어본 문제들을 다시 2-3번씩 더 풀었는데 그럼에도 불구하고 풀면 풀수록 새로웠다. 더 Optimal한 솔루션을 찾을 수 있었고, 내가 안다고 생각했던 것도 영어로 혼자 설명하는 연습을 하다보니 로직에 빈 공간이 보이기 시작했다. 그래서 Phone screen때의 나는 운이 좋았던거였구나 라는 생각을 하며 더 몰입해서 준비했다.

다행히 당일 Onsite 인터뷰에서는 내가 기존에 익히고 있었던 variant들이 출제되었고, 이미 내가 익숙하게 풀이할 수 있는 Hard문제들이 출제되어서 손쉽게 풀었다. 두 세션 각각 두 문제 씩 총 4문제였는데 모두 바로 Time/Space 측면에서 Optimal한 솔루션을 냈으며 심지어 빨리 풀어서 15분씩 남기고 남은 시간동안은 인터뷰어와 서로 잡담을 나눴다. 그러고선 두 세션 모두 5분 일찍 끝냈다. 두 번째 인터뷰어(Onsite 마지막 라운드였다)는 "널 곧 만나길 기대할게"라고도 말해서 합격을 담보받은 느낌도 들었다.

ML system design은 원활하게 진행되었던 것 같고, 개입이 많이 없었던 인터뷰어여서 결과가 어떨지를 전혀 예상하지 못했다. Behavioral 인터뷰어는 생각보다 깐깐했으며 내 대답 중간중간에 끼어들어서 challenging을 많이했다. 예를 들어 conflict가 있었던 상황을 설명하는 중에 끼어들어 왜 이 상황이 <특히> 더 어려웠는지 납득이 안된다고 이유를 구체화하라고 강요받았다. 내가 진행하면서 느낀 Behavioral interview는 훨씬 더 이야기가 detail해야하고 거기서 내 리더십이 돋보여야했다.

Onsite 인터뷰는 목요일에 진행했는데, 인터넷에 도는 말로는 인터뷰어 4명에게서 feedback을 모으는데 그 SLA가 business day로 1일이라고 했다. 그래서 금요일은 사실상 결과를 바로 듣긴 어려운 상황이라 주말 동안 열심히 논 다음 월요일을 맞이했는데, 리크루터 메일이 하나 와있었다. 제목은 <Meta interview check-in>이었다. 간단한 인사와 내 인터뷰 경험이 어땠는지, 긍정적이었는지를 물어봤다.

인터뷰 결과는 당신께서 알고계실텐데 나한테 어땠냐고 물어보다니. 내 리크루터가 매우 친절한 사람으로서 인터뷰 끝난 뒤 후기를 물어봤을 수도 있지만 대부분의 경우 이유 없이 메일을 보내지 않기 때문에 나는 이 메일을 매우 긍정적인 신호로 보았다.

간단하게 결과가 어땠는지 물어봤는데 "trending positive"라고 하며 Hiring Committee 결과를 들어야만 확정지을 수 있다고 그 후에 결과를 알려주겠단다. 그리고 이틀 뒤에 최초 오퍼 메일을 받게 되었다. 결과를 꽤 빨리 받게 되었는데 Pre screening은 한 명의 인터뷰어임에도 5일쯤 걸렸던 걸로 봐서 strong hire에 가깝지 않았을까 싶다. 일단 코딩 인터뷰를 두 개 모두 완벽하게 마무리할 수 있었기 때문에 더 빠른 결과를 받을 수 있었던 것 같다.

Team Matching

연봉협상으로 넘어가기 전 팀매칭에 대해 간단히 말해보자면, 팀매칭 프로세스에서는 면접보듯이 나의 Skill을 증명해보일 필요는 없다. 이미 기본적인 검증을 거친만큼, 이 프로세스는 회사와 지원자가 서로를 더 잘 알아가는 자리라고 보면 된다. 물론 몇 가지 질문을 받을 수 있지만, 평가보다는 지원자의 기술과 관심사를 파악하려는 목적이 더 클 것이다. 다만, 예외적인 경우도 있다. 만약 internal transfer를 많이 지원하는 상황인 경우, 내부 팀원들과 경쟁해야할 수 있다. 이 때는 기존 Meta 직원을 채용하는 것이 소프트랜딩 과정도 필요없으니 더 큰 장점이 될 수 있기에 준비를 해두는 것이 좋다. 그리고 niche한 기술이 필요한 역할이나 팀이라면, 팀매칭이더라도 조금 더 심층된 면접 과정이 될 수도 있다. 확실한 것은 Hiring Manager에게 나를 충분히 어필하는 것이 좋다. 그리고 특정 분야에만 목매지 않고 두루두루 잘 적응할 수 있다는 점을 강조하는 것도 좋다. 어쨌든 팀매칭 프로세스 끝에 내 손에 여러 패가 있는 것이 나에게 도움이 되기 때문이다.

Salary Negotiation

연봉협상에 대한 팁이나 자료는 다른 글에서 충분히 썼으니, 이 글에서는 연봉협상과 관련된 작은 후일담을 남긴다. 일단 내 리크루터는 답장이 굉장히 빨랐다. 10-20분만에 답이 오는 것은 물론, 연협을 시도하면 3-4시간 뒤에 곧 답을 주었다. 하루는 내가 착각하고 '내일 연락하자'는 이야기를 '오늘 오후에 연락하자'라고 받아들여서 퇴근 후에 (리크루터는 뉴욕에 있어서 나와 3시간 시차가 있었다) 연락했음에도 집가서 연락을 받아줬다. 이렇게 좋은 리크루터를 만나는 것도 운이지만, 리크루터에게 불편한(?) 이야기를 지속적으로 나누는 것도 나름 스트레스였다. 인터뷰를 볼 때까지만 해도 합격만 시켜주면 얼마든 줘도 된다는 생각이었지만, 막상 인터뷰를 합격하고 나니 연협까지 마친 사람들이 공유한 숫자들을 보면서 내 마음은 손바닥 뒤집듯이 바뀌었다. 나도 돈 많이 줘..!!

나는 총 두 번의 라운드만 진행했었다. 첫 번째 라운드는 합격하면 누구나 다 받는 오퍼였고, 이 숫자는 아마 Meta에서 줄 수 있는 연봉 중 가장 낮은 값일 것이다. 만약 내가 충분히 찾아보지 않았다면 나는 이 숫자를 네고없이 받아들였을 수 있다. 사실 회사에서는 이 오퍼를 누구나에게 다 주기 때문에 연봉협상에 대한 여지를 남기는 것이지만, 정보 불균형이 있는 지원자 입장에서는 이미 기존회사보다 수배 높은 오퍼였다면 말없이 받아들이는 사람도 있었을 것이다. 그럼 메타만 좋다.. ^^ 첫 라운드를 끝나고 주말 내내 고민하면서 내가 왜 다른 지원자에 비해 능력이 있는지, 그리고 보통 시장에서 어느 정도 연봉을 받는지 등을 나열해서 ChatGPT님의 검열을 여러 번 돌린 뒤 메일을 보냈었다. 리크루터는 쿨하게 Comp team에 다녀오겠다고 남긴 뒤 3-4시간 뒤에 다시 전화로 업데이트된 숫자를 줬다. 이 때는 base, RSU 모두 높여서 받았다. 당시 나는 미국에 대한 연봉 체계를 잘 몰랐기에 모든 결정은 남편과 협의한 후 내리겠다는 암묵적인 약속을 한 상태였기 때문에 또 고민해보겠다는 말만 남기고 그 전화를 끊었다. 그 뒤 RSU만 좀 더 협상해보자는 남편의 의견에 따라 이번엔 메일이 아닌 전화로 남겼고, 리크루터는 이미 top number라고 말했다며 부정적인 의견을 표했다. 연봉협상 관련 팁 영상들을 보면 red flag를 인지하라고 하는 팁이 있는데 그 중 하나도 이것과 같았다. 속으로 이게 마지막 연협이겠구나 싶었고, 그 뒤 더 이상의 업데이트는 없었다. 리크루터가 연협하지 못했다고 전화하면서 굉장히 무신경한듯한 목소리로 말했는데, 사인하겠다는 말을 듣고 난 뒤로는 갑자기 목소리 톤이 높아졌었다. ㅋㅋㅋㅋ 내가 생각하는 기준에 맞춰오지 못했기에 사인하지 않을 것이라 생각했던 것 같았다.

Onboarding

온보딩하기 위해서 check list를 완성해야하는데 꽤 많은 것들을 요구했다. 심지어 I-94, 여권은 4-5번은 제출했던 것 같다. 크게 준비해야하는 것은 Background check, Visa 관련 검증절차이다. 커리어 포탈이 온보딩까지 사용될 줄은 몰랐는데, 온보딩하기 위한 절차가 굉장히 잘 준비되어 있으며 설명자료도 많아서 준비하는데 어렵진 않았다. 그냥 준비 과정이 많았을 뿐.

법인용 휴대폰과 컴퓨터를 선택하는게 있었는데 그게 가장 신나는 일이었다. ^0^

한 가지 신기했던건 개인 Facebook 계정으로 회사 워크스페이스에 접근할 수 있다는 것이어서 개인 페이스북 계정을 한 번 인증해야한다.

그리고 뱃지 사진까지 업로드하고 보니 정말 메타에 입사하는구나 실감이 났다.

항상 남편이 뱃지를 목에 걸고 다니는걸 보고 멋있어했는데 나도 그런 사람이 될 수 있다니.

끝맺으며

미국에 도착해서 취업을 준비하고 보니 느끼는 점이 많았다. Connecting the dots. 이 말이 가장 내 상황을 잘 설명해주는 것 같았다.

한국 회사에 취업했을 때도, 회사에서 미국 대학원 과정을 지원해줄 때도, 거기서 UIUC를 준비해서 합격해냈던 것도, 매 순간 내게 주어진 기회에 최선을 다하면 언젠가 쓰임이 있게 된다. 지금 돌이켜보면 미국 대학원을 졸업했던게 리크루터의 연락을 받을 수 있었던게 아닐까. 내 회사는 글로벌한 회사는 아니었기에 외국인들이 알아보기 쉽지 않았을 것이다. 그리고 Behavioral에서 답변에 사용되었던 일화들도 내가 회사에서 최선을 다하지 못했다면 얻을 수 없는 이야기들이었다. 인생은 내 뜻대로 흘러가는게 없다곤 하지만, 닥치는 상황에서 매번 최선을 다하게 되면 언젠가 그 결과는 나에게 배로 돌아오게 된다.

인생에서 처음 테크회사, 그리고 미국에서 처음 일하게 되어 회사 문화나 개발문화, 그리고 사람들과의 적응이 잘 될지 걱정이 되지만, 그래도 나는 또 최선을 다해 내 몫을 충실히 이행할 것이다. 지금까지 그래왔던 것처럼.

미국 개발자 FAANG 취업후기 - 5. 연봉협상

Julie's — Fri, 4 Apr 2025 04:13:55 +0900

인터뷰에 합격하게 되면 리크루터랑 통화를 하게 된다. 이 때 중요한 것은 연봉협상 관련 이야기를 나눌 수도(!) 있다. 내 경우에는 팀매칭 없이 배정된 팀으로만 진행해야했기에 연봉협상 이야기를 이 때도 나눌 수 있었을 것이다. 연봉협상은 가장 흥미롭기도 하지만 내가 competing offer가 없다면 질 수 밖에 없는 게임이기도 하다. 인터넷에 보니 다수의 사람들이 FAANG 중 여러 competing offer를 받고선 서로 누가 연봉을 더 높게 불러주나 경쟁도 시키고들 했지만 당시 나의 경우에는 이 인터뷰가 가장 빨리 진행되었던 인터뷰이기도 하고, 별다른 곳에서 프로세스가 진행되는 것이 없었기 때문에 불리했다.

연봉협상의 핵심은 <정보 싸움>이라는 것이다. 내게 정보가 많으면 많을수록 유리하다. 그 말은 내가 직접 적극적으로 움직여서 정보를 모아야한다는 것이다.

interviewing.io에서의 연봉협상 팁이나 유투브에 compensation team에서 근무했던 FAANG 매니저급 사람들이 좋은 컨텐츠를 올린 게 많다. 이런 자료들을 충분히 찾아보고 시작하는 것이 좋다. 왜냐하면 재차 강조하지만, 연봉협상은 정말정말.. 정보의 싸움이기 때문이다!

협상과 관련된 전략도 중요하지만 다른 지원자들이 어느 정도의 연봉을 오퍼받았는지, 그리고 연협 과정에서의 팁들은 어떤 것들이 있었는지 등이 중요하다. 어떤 사람들은 최근에 업데이트된 Comp team 정보들도 기재해두기도 한다. ex) 해당 레벨의 가장 top salary range, sign-up bonus가 최근에 upper limit이 낮아졌다는 등

연봉협상의 전략에 관해 내가 정리해둔 몇 가지 팁을 옮겨두자면:

리크루터의 역할에 대해 잘 인지하고 있어야한다. 리크루터는 compensation 팀에 가서 당신을 대변하여 연봉협상을 해오는 중개자이며, 당신을 채용하는 것에 목표를 두고 있는 사람이다. 리크루터를 당신의 편으로 만드는 것이 중요하며, 리크루터의 노고에 대해 항상 감사해야한다. 리크루터와 사이가 나빠져서 좋을 것은 단 하나도 없다.
첫 라운드에서는 리크루터에게 무조건 number를 밝히지 않는 것이 좋다. 되려 회사에서의 적정한 salary range가 어느정도 되는지 물어봐라. 그럼 리크루터들은 대부분 알려주지 않으려고 할 것이며, 당신에게 원하는 숫자를 말하라고 한다. 이 줄다리기 싸움을 잘해야한다.
첫 라운드는 대부분 모든 사람들에게 동일한 금액으로 나갈 확률이 높다. FAANG의 경우 디스코드 채널이 있으며 찾아서 가입해본 뒤 다른 사람들도 최초 오퍼를 어떻게 받았는지 알아보라. 만약 동일한 금액이라면 회사에서도 당신이 네고를 해오기를 기대하고 있다는 뜻이다. (즉 부담없이 올려도 된다는 의미)
네고할 때는 RSU와 base salary를 동시에 높이기는 힘들다. 보통 양자택일해야하는데, 승진하게되면 어차피 base salary는 다시 조정될 뿐더러 회사의 경우에도 현금이 나가는 것보다 RSU를 더 높여주는 편이 덜 부담스럽다.
잊지말아야할 중요한 사실은 당신이 이 회사에 높은 관심을 보이고 있다는 것과 정중한 태도이다. 오만하고 거만하게 행동하거나 자칫 다른 회사에 더 관심이 있다는 것을 표현하게 되면 리크루터는 당신에게 관심을 보이지 않을 수 있다.
웬만해서 회사는 verbal offer를 주려고 한다. written offer를 주거나 career 포탈에 반영해서 주게되면 다른 회사와 네고하는 자료로 사용될 수 있기 때문이다. 그래서 리크루터는 통화하는 것을 선호할텐데, 오퍼를 받았을 때 확실한 네고 포인트가 있지 않는 이상 '생각해볼게요'라고 대답하고 이메일로 네고를 시도해보는 것이 좋다.
터무니없이 높은 금액을 시도하거나 배려심없는 행동을 보이지 않는 이상 네고를 한다고 해서 오퍼가 resign되진 않는다. 그러니 당당하게 당신이 받아야하는 금액을 협상해보라! 만약 회사가 작은 기업이고 여러 지원자가 있다면 다른 이야기가 된다.

마지막으로 연봉협상 관련 좋은 자료들을 몇 가지 남기면서 이 글을 마무리하려고 한다:

https://interviewing.io/blog/category/salary-negotiation

https://drive.google.com/drive/folders/1AdUu4jh6DGwmCxfgnDQEMWWyo6_whPHJ

https://www.youtube.com/watch?v=fyn0CKPuPlA

https://www.youtube.com/watch?v=hbyimAc-kV8

미국 개발자 FAANG 취업 후기 - 4. Behavioral 인터뷰 준비

Julie's — Wed, 19 Mar 2025 15:55:47 +0900

다음은 중요하다면 중요하고, 안중요하다면 안중요할 수 있는 애매-한 Behavioral Interview이다. 메타에서는 코딩 인터뷰가 합격/불합격을 결정했다면 이 인터뷰는 레벨을 결정하는 인터뷰이다. 코딩 인터뷰가 binary 로 hire/no hire로 피드백을 매길 수 있다면 이 인터뷰는 훨씬 다양하게 feedback을 줄 수 있다. level + confidence score를 feedback으로 작성하게 된다고 한다. L5로 면접을 보고 있었는데 이 인터뷰를 잘 못봤다면 L4 + strong hire, L5 + low hire를 받을 수도 있는 것이다.

회사마다 중점적으로 보는 가치가 다르다. 하지만 대부분의 경우 growth-mindset이 있는지, collaborative한지, proactive한지를 보게 된다.

skill set들 - Hello Interview 참고

이 인터뷰야말로 ChatGPT의 도움을 가장 많이 받게 될텐데, 내 경험을 기반하여 스토리를 몇 개 만들고 충분히 강한 스토리인지를 판단한 뒤 잘 다듬어야한다. 어떤 질문이 들어올지 모르고 형태도 다양하기 때문에 적절히 몇 가지 스토리를 구상해놓고 유연하게 대답할 줄 알아야한다.

예를 들어 가장 성취감이 있었던 프로젝트를 하나 구상해둔 뒤 이를 가장 challenging했던 프로젝트로 대답한다거나, 내가 가장 proactive하게 일했던 경험으로 이야기한다거나 할 수 있어야한다.

우선 레쥬메를 기반으로 아래와 같은 질문에 대답할 수 있도록 준비해야한다.

자기소개
Why 000? (왜 이 회사에 지원했는지, 내 fit은 무엇인지)
가장 성취감이 있었던 / 가장 business impact가 컸던 프로젝트
동료/리더와 마찰이 있었던 경우
내가 무언가를 배운 순간

위 사진에 보이는 skill set과 대충 비슷하게 매칭될 것이다.

후기를 보니 사람들이 대부분 hello interview 사이트에서 스토리 빌더를 활용하여 몇 가지 어필 포인트를 보강하며 스토리를 구상하는 것 같았다. 그래서 링크를 남겨둔다: https://www.hellointerview.com/learn/behavioral/story-builder

스토리도 스토리이지만, 가장 중요한 것은 디테일이다. 인터뷰어가 굉장히 깊이있게 물어볼 확률이 높기 때문에 거짓말하면 들통나는 경우가 대다수이며, 없으면 없다고, 모르면 모른다고 솔직하게 대답하는 것이 좋다. 개인적으로 갈등에 대한 이야기를 풀어놓는 것이 어려웠는데 나는 누군가와 마찰을 뚜렷하게 만들지 않았기 때문이다. 그럼에도 불구하고 "의견이 달랐던 경우"로 풀어서 스토리를 준비했다. 디테일이라함은 이 때 나는 무슨 발언을 했으며, 상대방은 어떤 행동을 취했고, 어떤 노력의 과정을 거쳤는지, 그 후 결과는 좋았는지 등에 대해 친구에게 후일담을 풀어놓는 수준으로 디테일하게 언급해야한다는 것이다.

이 인터뷰는 내가 유일하게 인터뷰어에게 technical한 면모를 많이 보여주는 것보다 soft skill을 어필하는 순간이다. new-grad가 아니라면 어느 정도의 리더십을 갖추어야하며 수동적으로 일하는 사람이 아닌 적극적으로 아이디어를 제시하고, 사람들을 이끌 수 있는 에피소드들을 준비해놔야한다. 레벨이 올라갈 수록 Behavioral Interview의 중요도는 올라가며 충분한 리더십을 보여주어야 down level당하지 않을 수 있다.

그럼에도 이 프로세스는 오랜 시간 준비하는 것을 추천하지 않는데, 어찌되었든 코딩 인터뷰의 결과가 인터뷰 전체 결과를 크게 좌우하기 때문이다. 나의 경우 Onsite Interview에서의 준비 비중상 이 인터뷰는 최소였다. Coding : System Design : Behavioral이 각 5:2:1 정도로 비중을 차지했다.

또한 Behavioral Interview에는 Framework가 있는데 가장 유명한 것은 STAR(Situation - Task - Action - Result)이고 그 다음으로 많이 채택하는 것이 CARL(Context, Action, Result, Learning)이다. 보통 전자를 많이 추천하지만 나는 후자도 꽤 괜찮았다. 개인의 스토리에 따라 자연스러운 플로우를 선택하면 되는데 (인터뷰어가 듣다가 STAR framework가 아니라고 떨어뜨리는 일은 없을테니) 한 가지 팁은 마지막에 결과, 즉 프로젝트 좋게 끝났어요 수준을 넘어서서 business impact와 lesson learned를 포함하는 것이 좋다.

Recruiter가 onsite interview 전에 이 인터뷰에 대해 팁을 전했는데 그대로 옮겨적으면서 이 글을 마무리하려고 한다.

Meta colleagues come from diverse backgrounds, and navigating conflicts requires thoughtful consideration. Providing a strong example can demonstrate your ability to handle these situations effectively.

A poor response would lack sufficient detail and fail to provide a clear narrative.

For example, when asked about a time you received constructive feedback, a weak answer might simply state that you received XYZ feedback and moved on. A stronger answer would explain how you took time to reflect, sought tips from other team members, and actively worked to build your skill set.

미국 개발자 FAANG 취업 후기 - 3. System Design 인터뷰 준비

Julie's — Wed, 19 Mar 2025 15:33:43 +0900

Onsite 인터뷰 프로세스를 진행하게 되면 최소 1개 이상의 System Design 인터뷰를 준비해야한다. 일반적으로 SWE는 product / infra 중 하나를 골라 인터뷰를 진행하게 되며 내가 지원한 MLE의 경우 Machine Learning System Design 인터뷰를 준비해야한다.

Machine Learning System Design의 경우 전반적인 ML 모델 개발 과정을 다루게 된다. 보통 추천시스템, prediction/classification 종류의 문제를 받게 되며 데이터 수집부터 배포 후 모니터링까지 MLOps 전반적인 단계들에 대해 논의한다. 이 인터뷰의 경우 더욱 인터뷰어와 상호소통하며 진행하는 단계이기도 한데 어떤 인터뷰어의 경우 모델 아키텍쳐에 대해 깊이 있게 물어보는 경우도 있고 어떤 인터뷰어는 실제 사례를 들고와서 어떻게 대처할 것인지를 심도있게 물어보기도 한다.

만약 처음 준비한다면 유명한 책들을 먼저 접해보는 것을 추천한다. 가장 알려진 자료중 하나는 Chip Huyen의 스탠포드 대학에서의 System Design Interview 강의 자료와 Alex Xu의 Machine Learning System Design Interview 책이다. 개인적으로 후자만 읽어도 충분했으며 인터뷰에서 어떻게 대화를 리드해나가야하는지 대략적인 감을 잡기 좋다.

이 글에서는 이상적인 인터뷰 답안 구성에 대한 간략한 설명만 남길 예정이니 디테일한 정보는 책에서 구하는 것이 좋다.

우선 Clarifying Question으로 인터뷰를 시작해야한다. 첫 5분 정도는 인터뷰어가 자기 소개와 더불어 문제를 던져줄텐데 이 때 문제는 보통 모호한 경우가 많다. 예를 들어 추천시스템을 설계한다고 하더라도 어떤 대상으로 추천할 것인지, 어떤 기준인지, 그 기준에 대한 정의는 무엇인지를 인터뷰어와 소통하면서 구체화해나가야한다. 이 때 가장 중요한 것은 business objective를 먼저 확인하고, 이를 ML objective으로 재표현해야하는 것이다. 만약 user engagement를 극대화하는 문제라고 하면 내가 생각하고 있는 ML 모델이 어떻게 이에 기여할 수 있는지 연결고리를 만들어야한다. 이를 통해 비즈니스 문제를 ML 모델로 해석하는 능력을 본다.

그 다음은 보통의 ML 개발 과정과 동일하다. 데이터 수집, 전처리 과정, 모델 학습, 모델 성능 평가(Evaluation), 배포 후 모니터링 방법까지. 단계를 하나씩 마무리할 때마다 다음 단계로 진행하기 전 인터뷰어에게 잘 따라오고 있는지, 질문은 없는지 확인하는 것이 좋다.

아무래도 ML system design이다보니 가장 중요한 것은 <모델 학습/Training> 단계에서 어떤 모델을 사용할 것인지를 충분히 논의해야한다는 점이다. 인터뷰어에게 하나의 모델만을 선정해서 알려주는 것이 아니라, 여러 옵션들이 있고 그 중에서 내가 이 모델을 사용하는 이유에 대해 설득해야한다. 예를 들어 prediction 문제의 경우 "간단하게는 logistic regression, decision tree가 있으며 그럼에도 불구하고 neural network로 prediction 문제를 해결하고자 하는 이유는 이 문제를 풀기 위해 모델이 multi modality를 지원할 수 있어야하기 때문이다"와 같이 근거를 들어주어야한다. 각 모델의 장단점을 설명해야하며 이 과정이 없다면 감점이 있을 확률이 크다.

이 인터뷰는 simulation을 통해서 연습해보는 것이 좋은데 주변에 MLE친구가 있다면 함께 준비하는 것이 좋겠지만 나는 쑥쓰러움도 많을 뿐더러 효율성을 위해 ChatGPT와 mock interview를 수차례 진행했다. 문제는 내가 냈지만 clarifying question, 전반적인 인터뷰 흐름 등을 내가 대답하며 ChatGPT에게는 following question을 묻도록 시켰다.

이렇게 인터뷰 전반적인 흐름에 대한 이해가 생겼다면 다음은 이론적인 background를 보강해야한다. Neural network가 어떤 방식으로 학습되는지 알고 있어야하며 각 모델에 대해서도 특징 정도와 loss function, activation function에 대해 제너럴하게 설명할 수 있어야한다. 어떤 사람들은 수식에 대해서 써보라고도 시킨다하여 나는 수식도 간단하게 암기하고 들어갔다.

이쯤 준비하고 보면 대강 template이 생긴다. 아래는 내가 준비하면서 유형화?했던 내용을 그대로 옮겨본다. 일명 Cheatsheet로 볼 수 있다.

Recommendation System
- architecture: multi-stage recommendation system
- strategy: pointwise LTR(Learn to Rank)
- ML selection
  - traditional recsys - content-based filtering, collabroative filtering
  - nerual network based - two tower, multi-task NN
- Loss function
  - cross-entropy
  - if class imblanace, focal loss
PYMK (Person You May Know)
- architecture: multi-stage system (candidate generation > ranked list > re-ranking)
- ML selection
  - GCN(Graph Convolutional Network)
  - GraphSAGE
Ads Click Prediction
- architecture: multi-stage system (candidate generation > ranked list > re-ranking)
- ML selection
  - logistic regression with feature crossing
  - GBDT(Gradient Boosted Decision Tree) + logistic regression
  - FM(Factorization Machine)
  - DeepFM
  - (만약 여유가 된다면) MoE(Mixture of Experts), PLE(Progressive Layered Extraction)
Prediction/Classification Problem
- ML selection
  - binary - logistic regression
  - Decision Tree - ensemble
    - boosted vs bagging
      - boosted -> GBDT, XGBoost
  - Neural Network

그리고 면접하는 회사의 research blog를 보면서 모델 설계과정에 대해 미리 익혀두고 가면 좋다. 뿐만 아니라 유명 테크 회사들의 blog를 보면 좀 더 현실적인 고민들과 모델 선정 과정에 대한 설명이 담겨있어 아래 자료들을 보고 답안을 보강해두면 좋다.

<Multi-stage Recommenders>

https://engineering.fb.com/2023/08/09/ml-applications/scaling-instagram-explore-recommendations-system/

https://medium.com/airbnb-engineering/machine-learning-powered-search-ranking-of-airbnb-experiences-110b4b1a0789

https://careersatdoordash.com/blog/homepage-recommendation-with-exploitation-and-exploration/

https://eng.snap.com/embedding-based-retrieval

https://happystrongcoder.substack.com/p/dcn-v2-improved-deep-and-cross-network

<PYMK>

https://www.linkedin.com/blog/engineering/recommendations/building-a-large-scale-recommendation-system-people-you-may-know

여기서 더 나아가 여유가 된다면 industry paper를 읽는 것인데, 참고할만한 자료들은 아래와 같다:

Deep Neural Networks for Youtube Recommendations
Recommending what video to watch next: a multitask ranking system
Instagram Explorer recommendation system
Pinterest Pixie
Real-time Personalization using Embeddings for Search Ranking at Airbnb
Behavior Sequence Transformer for E-commerce Recommendation in Alibaba
Deep Reinforcement Learning for Online Advertising in Recommender Systems (TikTok)

정리하자면

core ML concept에 대한 복습
clarifying questions/requirement gathering 연습
prepare for the flow
repeat 1-3 above

단계로 준비하는 것을 추천한다.

미국 개발자 FAANG 취업 후기 - 2. 코딩 테스트 준비

Julie's — Wed, 19 Mar 2025 15:02:39 +0900

미국의 대부분 테크 회사들의 경우 프로그래밍 실력을 굉장히 중시한다. 개인적으로 충격적이었던 건 전체 프로세스에서 코딩 인터뷰의 비중이 꽤 크다는 것이다. 가장 덜 중요한 것은 소위 인성면접인 Behavioral Interview이다. 개인적으로는 ~~인성은 어떻더라도 코딩만 잘하면 된다는~~ 인상을 받았다. 회사마다 다르겠지만 내가 준비했던 메타의 경우 전체 프로세스에서 최소 6개의 코딩 문제를 받게 된다. Pre-screening에서 2개, Onsite에서 4개를 받는데 이 라운드들은 모두 해당 면접자를 hire / no hire (채용할 것이냐, 아니냐) 를 가르게 되는 중요한 단계이다. 메타에서는 아무리 다른 라운드의 면접을 잘 보더라도 코딩 문제를 하나 이상 못풀게 되면 합격하기 어려우며 최소 채용 조건이라고 말한다.

그럼 이 중요한 프로세스를 어떻게 준비하느냐. 어려운 것은 코딩 인터뷰는 단기간에 준비한다고 완성되는 것이 아니다. 시간을 들여야한다. 그리고 이해를 요한다. 지금 글을 작성하는 시점에서 돌이켜보면 문제를 많이 푸는 것보다는 유형을 완벽하게 이해하고 파악할 수 있는 능력이 훨씬 중요하다. 그 다음 약간의 tactic/테크닉들을 갖추게 되면 인터뷰할 준비가 되어있을 것이다.

미국으로의 이민이 결정되고 난 이후 나는 코딩테스트를 준비하기 시작했는데, 당시에는 어떻게 접근해야할지 모르겠어서 단순히 Leetcode만을 많이 풀었다. 소위 Leetcode Top 150, Blind 75와 같이 문제 리스트를 순회하면서 풀어나갔다. 처음에는 어떻게 접근해야할지 모르겠어서 Easy 레벨 문제들도 푸는데 오래걸렸다. 이 때의 나에겐 "코딩테스트적인" 사고방식이 갖춰져있지 않았다. 시간을 들여서 고민해보다가도 모르겠다면 답안을 보고 외우는 방식으로 접근했다. 그렇게 문제 리스트를 반복해서 풀기를 여러번, 이제 암기가 된 문제들은 5-10분만에 정답 코드를 작성해나갔다.

단순히 많은 문제들을 반복해서 풀기만 했던 시절

그래도 뭔가 부족한 느낌이 계속 있었다. 나는 목표가 뚜렷하게 보이면 달리는 편인데, 퇴근 후에 짬짬이 문제들을 계속 풀기를 반복했으나 무언가 비어있는 느낌이 계속 들었다. 그래서 유투브로 다시 빅테크 회사들의 면접에 합격했던 사람들의 후기를 찾아보기 시작했다. 공통의 조언은 문제를 풀고 풀이를 간단하게 적어보라는 것이더라. 그래서 또 다시 반복해서 풀면서 풀이를 옮겨적기 시작했다. 이 때서야 비로소 유형별로 묶을 수 있었던 것 같다.

문제별 카테고리와 풀이에 대해 간단히 적어나가보던 시절

이쯤되니 내가 준비가 된 것 같았다. 뭔가 유형들도 그려지는 것 같았고, 중요하다고 하는 문제들을 모두 풀어봤으니 자신감이 있었다. 이 정도로 마무리했을 때가 내가 미국에 막 도착해서 지원서를 써볼까 고민하던 시기였다. 그리고 이 때가 롱디를 마무리하고 남편과 함께 신혼집에 머물면서 저녁 시간에 mock interview를 시작해볼 시기였다.

남편과 Mock Interview를 시작하니 뭔가 단단히 잘못되었음을 깨달았다. 내가 선택한 알고리즘, 작성한 코드에 대해 설명하려다 보니 내가 정말 이를 이해하고 있는 것이 맞나라는 의구심이 생겼다. 그리고 남편이 문제풀이에 대해 해설하며 했던 말들이 나에게는 너무 생소했다. 예를 들어 그래프 문제를 푼다고 했을 때, 그래프란 무엇이며 왜 사람들이 그래프를 사용하는지, 그리고 왜 탐색 알고리즘이 필요한지에 대한 답을 하지 못했다. 남편은 간단하게 "세상의 대부분의 문제들은 그래프로 표현될 수 있어. 학부시절 이론적으로는 SNS 네트워크, 의사결정 모형 등에 대해서만 알려주지만 더 다양하게 활용될 수 있고, 보통 굉장히 고차원이라 사람들이 직관적으로 이해할 수 없는 경우가 대다수야. 그래서 우리가 그래프를 이해하려면 그래프 전체를 탐색하게 될 수 밖에 없어. 그건 굉장히 비효율적이기 때문에 여러 알고리즘들이 나온거야. 가장 단순하게는 이웃한 모든 노드와 엣지를 방문하는 BFS, DFS가 있어. 하지만 엣지에 weight가 생기면 이제 더 이상 동일한(equivalent) 엣지가 아니기 때문에 우선순위를 두면서 방문해볼 수 밖에 없어. 그래서 weight가 있는 경우 Dijkstra 알고리즘을 사용하는거야. 우선순위를 파악하기 위해 Priority Queue를 두고 다음에 방문할 엣지를 결정하는거야"라고 말했다.

그렇다. 코딩 인터뷰를 진행하게 되면 내가 선택한 알고리즘이 왜 optimal한 선택이며 다른 알고리즘에 비해 어떠한 Trade-off가 있는지를 설명해야한다. 그리고 그 알고리즘이 어떤 목적임을 분명히 알고있어야한다. 내가 문제를 푸는 것과 누군가에게 설명할 줄 안다는 것은 전혀 다른 레벨의 이야기이기 때문이다.

얼빠졌던 나에게 남편은 책을 하나 추천해주고 갔다. <Introduction to Algorithms> 이라는 책이며 처음부터 끝까지 모두 정독할 필요는 없지만 아래 챕터들은 충분히 읽을 만 하다.

Advanced Design and Analysis Techniques
Graph Algorithms

* 한 가지 참고해야할 것은 회사마다 중점으로 두는 알고리즘들이 다르다. 이건 Leetcode premium을 결제하게 되면 문제마다 회사가 tagging이 되어있는데 준비하고자 하는 회사가 tag된 문제들을 보면 대충 유형을 뽑을 수 있다. 내가 준비했던 메타는 Binary Search, Graph 중에서도 특히 Tree 관련 문제를 좋아했다. 내가 알고있는 바로는 웬만한 회사들은 Graph문제들을 좋아하는 편이다.

책을 보면서 내가 했던 것은 정리 노트를 만드는 것이었다. 예를 들어 그래프에 대해 공부한다고 치면, 아래와 같은 Tablel of Contents를 뽑아낼 수 있다:

Graph
1. Traversal - DFS, BFS
2. Single-Source Shortest Path
  1. BFS
  2. Dijkstra's
  3. Bellman-Ford
3. All-Pairs Shortest Path
4. Topological Sort ~ DAG
5. Strongly Connected Components (SCC)
6. Minimum Spanning Tree

책을 보게 되면 이 알고리즘이 왜 이러한 approach를 취했는지에 대한 설명이 있다. 예를 들어 MST를 찾는 문제에서 Kruskal과 Prim 알고리즘 두 개로 나뉜다고 해보자. Kruskal은 edge 중심의 접근방식이며 Prim은 vertex 중심이다. Kruskal은 disjoint set으로 MST를 구현하는데 edge를 weight에 따라 우선 정렬하며 가중치가 낮은 edge부터 disjoint set (=MST)에 추가하며 다음으로 큰 weight의 edge를 구성하는 vertex의 양끝 노드가 이미 MST에 존재하면 cycle을 구성하는 것이기 때문에 skip한다. Prim은 vertex로 MST를 그려나가는데 BFS같은 방식으로 priority queue를 두고 visited set으로 cycle이 생기는 것을 방지한다. 이렇게 두 알고리즘의 접근방식이 다르다는 것을 이해하면 알고리즘들의 디테일들을 억지로 외우지 않더라도 이해할 수 있게 된다. 앞서 disjoint set으로 Kruskal을 구현한다고 하면 cycle이 있는지 확인하기 위해서는 union 함수의 결과가 False가 아니어야한다는 등..

왜 이러한 방식으로 공부하는 것이 중요한지를 언급하기 위해 또 다른 예시를 들어보겠다. Dijkstra 알고리즘을 공부한다고 쳐보자. 일단 dijkstra를 구현하는 template 코드가 있다. 이 코드를 보면 과거의 나는 일단 디테일들을 외웠다. 1) Priority Queue를 둔다. 2) 음수일 땐 사용할 수 없다. 하지만 Dijkstra를 이해하면 그 디테일들을 암기할 필요가 없다. 다시 Dijkstra알고리즘이 어떤 것인지를 생각해보자. 노드 주변의 최단 경로만을 선택하는 그리디 알고리즘이다. 가중치가 음수일 때 사용할 수 없는 이유는 당연하다. 매 순간 지금까지의 최소 경로는 모두 방문해봤다는 가정인 알고리즘인데 음수인 edge를 만나게 되면 그 가정이 깨지기 때문이다. 그리디 알고리즘이 그리디하지 않다는 모순이 생기게 된다. 이렇게 이해하게 되면 그 알고리즘의 구현 방식도 자연스럽게 머릿 속에 그려지게 된다.

이렇게 알고리즘들에 대해 익숙해진 다음 우리가 해야할 일은 어떤 순간에 어떤 알고리즘을 선택해야하는지를 아는 것이다. 이건 어떻게 보면 문제를 많이 풀수록 익혀지는 감이기도 하다. 하지만 문제를 많이 풀어야한다는 건 시간을 그만큼 투자해야한다는 것이기에 이를 단축하기 위해 이 사이트에서는 알고리즘들의 접근 방향을 flow chart로 그렸다.

Algomonster의 알고리즘 decision tree

지금까지가 어떤 기업이든 코딩테스트를 준비하기 위한 이상적인 단계들을 설명이었다. 이제는 좀 더 인터뷰하고자 하는 기업에 특화된 이야기를 다루려고 한다. 앞서 간단하게 언급했다시피 회사마다 인터뷰에서 자주 물어보는 알고리즘 유형들이 어느 정도 정해져있다. 이에 대한 정보는 검색을 해보는 수밖에 없다. LeetCode 혹은 Blind를 검색해보면 회사별로 좋아하는 알고리즘 문제들에 대한 정보가 나와있다. 검색이 어렵다면 LeetCode에서 돈주고 Premium을 끊은 뒤 준비하는 회사 tag 문제들을 보면 된다. 이 알고리즘들에 대해 빠삭하게 이해하고 있는 것이 가장 첫 준비 단계이다.

그 다음으로 해야할 일은 회사마다 다른데, 만약 회사가 자주 출제되는 문제가 반복적으로 있다면 (내부 interview question bank가 있고 거기서 반복적으로 출제한다면) 이 출제 문제들을 긁어모으는 것이다. LeetCode에는 문제은행 외에 강력한 다른 feature가 있는데 바로 <커뮤니티>이다. Discuss 메뉴를 들어가도 조회할 수 있고, 회사 tag된 문제 리스트에서도 회사 특정 discussion 채널이 따로 있다.

이 정보의 가장 큰! 막강한! 장점은 최신 기출문제를 볼 수 있다는 것이다. 그리고 기출문제별 인터뷰어가 어떤 것을 중점적으로 보는지를 확인할 수 있다. 동일한 문제도 space optimal하게 푸는 방법, time optimal하게 푸는 방법이 접근방식이 다르다. 회사마다, 인터뷰어마다 어떤 접근을 선호하는지에 대한 정보가 이 커뮤니티에서 얻을 수 있다. 메타는 Meta-tagged Top 100 만 풀어도 준비할 수 있는 것으로 유명한 회사인데, 사실 LeetCode 문제를 그대로 출제한다기보단 말을 바꾸거나, 살짝 꼬아서 다른 것을 물어보기도 한다. 그러한 variant 문제들을 확인할 수 있는 것도 이 LeetCode discussion이다. 만약 당신이 메타를 준비한다면 이 유투브 채널도 추천한다.

인터뷰 일정이 잡히고서 나의 주된 준비방법은 이러했다:

Meta tagged Top 100 Question 반복 풀기
- Variant 함께 풀기
- Opitmal solution 확인하기 - Time/Space complexity 체크
Discussion 채널에서 최신 기출문제 1달치 뽑아 풀기

인터뷰 직전까지도 코딩인터뷰는 준비된 듯 하면서도 준비되지 않은 것 같은 느낌이 든다. 지금 글을 쓰는 순간의 나 역시도 가장 자신없는 파트이기도 하다. 코딩인터뷰는 전체 프로세스 중에서도 가장 긴 싸움이 될 것이다. 때문에 지금 글을 읽고 있는 당신에게 응원의 힘을 보낸다! 노력은 빛을 발하기 마련이고 최선을 다하는 것이 최고의 전략이다.

미국 개발자 FAANG 취업 후기 - 1. Recruiter Call

Julie's — Sat, 15 Mar 2025 15:30:00 +0900

일반적으로 SWE의 채용 프로세스는 아래와 같다.

Recruiter Call > Pre-screening > Onsite > Team Matching

* recruiter call은 referral을 통하는 경우 제외될 수 있음.

맨 앞의 recruiter call은 약간 서류 단계와 비슷한건데, candidate가 오픈된 JD(Job Description)에 기재된 자격에 부합하는지 확인한 후, 다음 단계로 진행할지 결정한다. 주로 30분 정도 짧게 통화하며 아래와 같은 내용을 이야기한다.

Resume 검토 후 포지션과의 적합성 확인
회사 및 팀에 대한 간략한 소개
인터뷰 프로세스 안내
비자 관련 사항 논의 (Optional)

Referral은 소위 서류 단계를 통과하는데 용이하게 만들어준다. 보통 LinkedIn을 통해 이미 재직중인 누군가에게 부탁하거나 지인들을 통해 작성하게 되는데 직장 동료이거나 전 직장 manager였다면 훨씬 강력하게 작용한다. 보통 1) 어떻게 아는지 2) 얼마나 아는지 3) 얼마나 강력하게 추천하는지 3가지를 작성하게 된다. 당연하겠지만 1,2,3 signal이 강할수록 더 강력한 candidate가 되는 것이다.

Recruiter Call은 만약 리크루터가 먼저 연락왔다면 대부분 fit이 맞는지 먼저 검증하였기 때문에 비교적 쉽게 흘러간다. 그럼에도 절대 간과해선 안된다. 대략적으로 회사가 원하는 인재상에 맞는 인물인지 확인하기 때문이다.

이 때의 Recruiter도 어떤 recruiter이냐가 나뉘게 된다. 큰 회사의 경우 아웃소싱을 해서 FTE(Full Time Employee)가 아닌 계약관계일 수 있다(LinkedIn에 Contractor로 표시함). 이 경우 Pre-screening을 합격하게 되면 지원한 회사 내의 recruiter로 바뀔 확률이 높다. 또는 처음부터 회사 내의 FTE recruiter와 매칭될 수도 있다. 이 차이에 대해서는 interviewing.io의 인터뷰 책자 29p - 31p에 잘 설명되어있다.

나는 Recruiter Call도 꽤 공들여(?) 준비를 했는데, 주로 아래와 같은 내용들을 미리 작성해서 전화할 때 참고하면서 말했다.

자기소개
- JD의 qualification에 맞도록 준비, 강점 몇 가지와 짧은 이력 소개
- 주로 growth-mindset, collaborative, proactive한 면모를 보여주는 것에 강점을 둬야한다.
프로젝트 간략 설명
- Impactful Project 2-3개 준비
  - 실제 수치로 나타나는 business impact도 포함되어있어야함
Why 000? / 왜 이직하려고 하는지?
- 회사에 대해 리서치했고 관심이 있다는 것을 표현해주어야하는 항목
JD minimum qualification
- 당시 나의 JD에는 Python / ML framework 숙련도가 기재되어있어 이와 관련된 간단한 내용을 준비했다.
내가 회사에 묻고 싶은 질문들
- 이 때 Recruiter가 technician이 아니기 때문에 기술 관련된 내용은 묻더라도 잘 대답해주지 않는다.
- 주로 인터뷰 프로세스에 대한 timeline

실제로 위 내용이 30분 통화 내용에 모두 포함되었고 강조하고 싶은 표현들을 반복 연습을 통해 입에 익게 해뒀더니 유용하게 사용되었다.

나의 경우에는 third-party recruiter여서 인터뷰 과정에서 사실상 리크루터가 여러번 교체되었지만, 만약 첫 매칭된 리크루터가 끝까지 함께할 것 같은 경우 좋은 관계를 쌓아두는 것이 좋다. 추후 team matching에서 당신의 연봉 희망 정보를 가지고 compensation team에게 전달하고, 원하는 숫자를 전달해줄 사람이기 때문이다.

그리고 잊지 말아야할 사실은 recruiter와의 통화도 인터뷰의 일부라는 것이다. 나는 Onsite Interview 전에 리크루터와 통화할 때 <여러 Offer가 있다면 어떤 점을 중요하게 생각하느냐> 라는 질문에 워라벨이라고 대답해버렸다 ㅎㅎ; 일에 대한 열정을 보여줘야할 마당에 취업 처음해보는 사람처럼 답변을 줬던 이유는... 긴장감 부족이 아니었을까.

미국 개발자 FAANG 취업 후기 - 0. 글을 시작하며

Julie's — Sat, 15 Mar 2025 15:00:40 +0900

25년 1월 중순, 샌프란시스코에 딱 떨어지게 되었다. 5년을 다녔던 회사에 휴직계를 내고, 갑자기 맞이하게 된 기약없는 휴식기간에 약간 얼이 빠졌다. 6개월 일찍 홀로 미국에서 정착하고 있던 남편이 구해둔 신혼집에서 낮시간 동안 하릴없이 지냈다. 대충 가구와 기본적인 식기류들이 마련되어 있었다. 연고가 전혀 없는 지역이었던지라 주말엔 남편의 친구들을 소개받았다. 그럼에도 새로운 곳에 덩그러니 남겨진 공허함이 시간이 지날수록 짙어졌다.

문득 나만의 것이 없다는 느낌이 들었다. 집도 가구도 분명하게 '우리'의 것이지만 그래도 남편이 구해둔 공간에 내가 들어가 지내는 느낌이 들었다. 남편 친구들도 모두 소속이 있어 자신만의 삶을 그려나가는 느낌이었다. 나도 나만의 회사, 나만의 공간, 나만의 것을 갖고 싶다는 생각이 강하게 들었다. 아, 취업을 해야겠구나.

이제 목표를 정했다. 근데 어떻게 다가가야할지 모르겠다. 이렇게 아무것도 없는 백지에서 무언가 그려내야할 때는 노션 페이지를 하나 만들고 본다. 무작정 "정착"이라고 이름을 짓고 큰 덩어리부터 그려본다.

일단 내가 어떤 회사를 원하는지 정해봐야한다. 한국에서 다닌 회사는 테크 회사가 아니었다. 그러다보니 비즈니스가 필요한 상황에 맞춰 Role을 유연하게 바꿔야했고 덕분에 얕지만 다양한 범주의 경험을 해볼 수 있었다. Specialized expertise는 없었다. 뿐만 아니라 리더십은 기술 background가 부족했다. 그에 따라 기술 조직은 리드하는 조직이 아닌 따라다니는 조직이었다. 기타 여러한 이유로 나는 당시 막연히 빅테크 회사들에 대한 동경이 있었다. 그럼 회사는 대략 미국 테크 회사로 좁혀졌다.

이제 절차를 알아야겠다. 어떤 것들을 준비해야하는지 알려면 통상 미국 회사의 채용 프로세스가 어떠한지 알아봐야했다. 그 뒤 각 절차별로 어떤 것들을 해야하는지 잡아나가면 된다. 구글에 무작정 <big tech interview process>라고 쳐본다. 다행히 대충 비슷비슷했다. 일단 제일 중요한건 코딩테스트라고 한다. 그래서 리트코드 결제를 했다.

알고리즘 책도 구매해서 읽고 LeetCode를 한창 풀어보며 지내던 중 갑자기 LinkedIn DM으로 장난같은 연락을 받게 된다. 이 때가 1월 말이었다. 돌이켜보면 미국 랜딩하고 2주 뒤었다. 처음엔 스캠인줄 의심했다.

Meta Recruiter의 첫 연락

하단엔 call schedule을 잡을 수 있도록 recruiter의 availability가 담긴 캘린더가 있었고, Meta 웹사이트로 이동되었다. 그 때서야 새삼 실감이 났다. 나 진짜 실리콘벨리에 있구나!

좋은 마음과 더불어 덜컥 겁부터 났다. 아직 준비된게 하나도 없는데, 코딩 테스트라곤 한 번도 해본적이 없고 아직 알고리즘들을 다 아는 상태가 아니라서 떨어질게 뻔했다. 영어도 면접을 볼 수 있는 수준인지 확신이 없었다. 카페에서 음료 주문할 때도 쩔쩔매던 나였는데.

그래도 언젠간 마주해야할 순간이었고 테스트베드처럼 프로세스를 한 번 타보는것도 좋은 경험일 것 같았다. (~~테스트베드로 삼기엔 너무 좋았던 메타..~~) 이틀 뒤인 1월 30일로 스케줄을 하고 리쿠르터 콜을 준비하기 시작했다. 내 취업 대서사는 이제 시작이다.

그래프 순회 - BFS, DFS

Julie's — Sun, 15 Sep 2024 15:09:41 +0900

그래프는 인접행렬(Adjacency Matrix) 또는 인접 리스트(Adjacency List)로 표현된다. 이 그래프들을 주로 input으로 받아 순회하는 알고리즘을 통해 문제를 해결해야하는 경우가 생긴다.

오늘은 그래프 순회 알고리즘의 Python 구현 코드와 개념에 대해 간단히 다뤄보려고 한다.

그래프 순회는 크게 깊이우선탐색(BFS), 너비우선탐색(DFS)로 나뉜다. 대부분의 알고리즘 문제들은 DFS로 해결이 되는 편이긴 하나 그래프의 최단 경로를 구하는 경우 BFS 알고리즘을 사용할 때도 있다.

DFS는 주로 스택을 활용하거나 재귀를 통해 구현되며, BFS는 큐로 구현된다.

이 그래프를 예시로 살펴보자.

# 그래프는 인접 리스트로 표현
graph = [
    [],         # 0번 노드는 사용하지 않음
    [2, 3, 8],  # 1번 노드와 연결된 노드들
    [1, 7],
    [1, 4, 5],
    [3, 5],
    [3, 4],
    [7],
    [2, 6, 8],
    [1, 7]
]

# DFS 함수 정의
def dfs(graph, v, visited):
    # 현재 노드를 방문 처리
    visited[v] = True
    print(v, end=' ')  # 방문한 노드 출력
    
    # 현재 노드와 연결된 다른 노드를 재귀적으로 방문
    for i in graph[v]:
        if not visited[i]:
            dfs(graph, i, visited)

# 방문 기록 리스트 (노드의 개수만큼 False로 초기화)
visited = [False] * 9

# DFS 호출
dfs(graph, 1, visited)

예시 그래프를 DFS하게 된다면 이 순서로 노드가 출력된다.

1 2 7 6 8 3 4 5

여기서 visited 리스트를 관리하는 이유는 adjacency list를 iteration하다가 이전에 방문했던 노드를 만나게 되면 또 다시 recursion에 빠지기 때문에 재귀가 끝나지 않기 때문이다.

이 외에 스택을 통해 구현할 수 있는 방법도 있다.

# DFS 함수 정의 (스택 사용)
def dfs_stack(graph, start):
    # 방문 기록 리스트
    visited = [False] * len(graph)
    stack = [start]  # 시작 노드를 스택에 넣음
    
    # 스택이 빌 때까지 반복
    while stack:
        v = stack.pop()  # 스택에서 가장 마지막 노드를 꺼냄
        
        # 방문하지 않은 노드라면
        if not visited[v]:
            print(v, end=' ')  # 방문한 노드 출력
            visited[v] = True  # 방문 처리
            
            # 현재 노드와 연결된 노드들을 스택에 추가
            # (역순으로 추가하면, 작은 노드부터 방문하게 됨) # reversed(graph[v])
            for neighbor in graph[v]: 
                if not visited[neighbor]:
                    stack.append(neighbor)

# 그래프는 인접 리스트로 표현
graph = [
    [],         # 0번 노드는 사용하지 않음
    [2, 3, 8],  # 1번 노드와 연결된 노드들
    [1, 7],
    [1, 4, 5],
    [3, 5],
    [3, 4],
    [7],
    [2, 6, 8],
    [1, 7]
]

# DFS 호출 (스택 사용)
dfs_stack(graph, 1)

스택을 통해 구현한 DFS 알고리즘을 구현하여 수행하면 아래와 같이 노드를 탐색한다.

1 8 7 6 2 3 5 4

동일한 DFS 알고리즘이더라도 두 개의 순회 순서가 다른데, 스택은 특성상 가장 top에 있는 원소부터 pop하여 탐색하기 때문이다. 만약 재귀형태처럼 인접한 노드의 자식들부터 탐색하고 싶다면 위 코드에서 comment 처리가 된 reversed() 를 사용하면 아래와 같이 출력된다:

1 2 7 6 8 3 4 5

DFS는 백트래킹, 즉 문제에서 정의한 조건에 충족하지 못했을 경우 탐색하지 않는 방향으로 프로그래밍을 하여 시간을 줄일 수 있다. 즉 가능성이 없을 경우에는 탐색하지 않음으로서 효율성을 높일 수 있다.

BFS로 구현한 코드는 아래와 같다.

from collections import deque

# BFS 함수 정의 (큐 사용)
def bfs(graph, start):
    # 방문 기록 리스트
    visited = [False] * len(graph)
    queue = deque([start])  # 시작 노드를 큐에 넣음
    visited[start] = True  # 시작 노드 방문 처리
    
    # 큐가 빌 때까지 반복
    while queue:
        v = queue.popleft()  # 큐에서 가장 앞의 노드를 꺼냄
        print(v, end=' ')  # 방문한 노드 출력
        
        # 현재 노드와 연결된 노드들 중 방문하지 않은 노드를 큐에 추가
        for neighbor in graph[v]:
            if not visited[neighbor]:
                queue.append(neighbor)
                visited[neighbor] = True  # 방문 처리

# 그래프는 인접 리스트로 표현
graph = [
    [],         # 0번 노드는 사용하지 않음
    [2, 3, 8],  # 1번 노드와 연결된 노드들
    [1, 7],
    [1, 4, 5],
    [3, 5],
    [3, 4],
    [7],
    [2, 6, 8],
    [1, 7]
]

# BFS 호출 (큐 사용)
bfs(graph, 1)

DFS와는 다르게 첫 노드를 방문했던 것으로 기록하여 순차적으로 인접 노드를 탐험하며 방문 처리를 한다.

위 코드를 수행하면 아래와 같은 결과가 나온다.

1 2 3 8 7 4 5 6

한 가지 주의해야할 점은 BFS는 재귀로 동작하지 않는다는 것이다. 이 알고리즘은 큐로만 구현이 가능하다.

그럼 BFS, DFS간의 차이를 요약해보자면

BFS (Breadth-First Search):

Queue-based (FIFO): BFS는 다음 레벨의 노드로 넘어가기 전 현재 레벨에 있는 모든 노드들을 우선 탐색한다.
Immediate visit: 첫 노드가 큐에 적재되기 이전에 방문했다고 체킹된다. 이는 방문했던 노드를 한 번 더 큐에 넣는 것을 방지하기 위함이며 노드가 발견이 될 때 즉시 방문 여부를 남겨 큐에 다시 추가되는 것을 막는다.

DFS (Depth-First Search):

Stack-based (LIFO): 백트래킹 이전 그래프의 한 branch에 대해 깊이 있게 우선 탐색한다.
Post-processing visit: 스택에서 pop되는 순간 방문했다고 체크하게 되며 DFS의 원리처럼 banch의 leaf node에 도달할 때까지 깊이를 우선하여 탐색하기 때문에 모든 아래 노드들을 탐색한 뒤 방문을 체크하게 된다.

GPT Tokenizer에 대해 알아보자

Julie's — Fri, 8 Mar 2024 16:13:29 +0900

GPT에 대해 더 깊이 있게 이해하려면 Tokenizer에 대해서도 심도있게 살펴볼 필요가 있다.

ChatGPT를 써본 경험이 있는 사람이라면 아래 의문들 중 하나 이상을 마주해본 적이 있을 것이다.

왜 스펠링이 안될까?
왜 문장을 거꾸로 말하라고 하거나 정렬해보라고 하면 안될까?
영어가 아닌 한글로 말할때는 왜 더 안좋은 대답을 줄까?
단순한 수학 연산에 왜 약할까?
GPT-2가 왜 비정상적으로 Python coding 성능이 안좋았을까?
왜 |endoftext|라는 string을 보면 멈출까?
LLM에서 JSON보다는 YAML을 사용하는게 더 좋을까?

위의 질문에 대한 답은 모두 Tokenization 문제이다.

LLM Tokenization 과정은 LLM과 완전히 별도로 분리된 모듈이다. 일반적으로는 아래 그림과 같이 텍스트 → byte encode → encode → token sequence → byte decode → decode → text로 순환하는 구조이다.

본격적으로 GPT Tokenizer를 해부해보기 전에 시각적으로 확인할 수 있는 사이트인 Tiktokenizer에서 예제 텍스트를 넣고 결과를 보면 토큰들이 어떻게 잡히는지 확인해볼 수 있다.

위에서 볼 수 있듯이 하나의 단어가 여러 개로 쪼개지게 된다.

Tokenization → Token + ization
Egg. → E + gg + .
egg. → egg + .
8041 → 804 + 1

숫자도 나뉘고 영어도 대문자/소문자일 때 나뉘는 패턴이 다르게 된다.

그리고 영문이 아닌 다른 언어의 경우(위 예제에서는 한글) 동일한 의미를 전달하는 것이라도 chunk가 훨씬 많이 나뉘게 되어 불리하다.

즉 토큰을 더 많이 잡아먹는 상황인 것이다.

코드의 경우에도 Python indentation의 경우 다수의 whitepsace로 구성되어있는데, 이 각각이 하나의 토큰으로 분류되면 토큰 용량을 많이 잡아먹는다.

하지만 GPT 3.5-turbo의 토크나이저의 경우 tab과 double tab이 각각 하나의 토큰으로 분류되는 것을 볼 수 있다.

그럼 이제 본격적으로 Tokenizer의 인코딩 방법에 대해 들여다보자.

일반적으로 우리가 익숙한 Unicode Byte Encoding(ASCII, UTF-8, UTF-16, UTF-32)에서 BPE, 즉 Byte Pair Encoding를 GPT Tokenizer가 채택하고 있다. BPE알고리즘은 간단하게 빈번히 등장하는 짝끼리 묶어 치환한 뒤 인코딩하는 방식이다.

예로, aaaabbcc라는 문자열이 있을 때 자주 등장하는 aa를 X로 치환하면 XXbbcc로 바뀌고, 여기서 다시 bb = Y로 치환하게 되면 XXYcc라는 문자열, 그리고 반복이다.

코드로 살펴보면,

def get_stats(ids):
    counts = {}
    for pair in zip(ids, ids[1:]): # Pythonic way to iterate consecutive elements
        counts[pair] = counts.get(pair, 0) + 1
    return counts

stats = get_stats(tokens)
# print(stats)
# print(sorted(((v,k) for k,v in stats.items()), reverse=True))

vocab_size = 276 # the desired final vocabulary size
num_merges = vocab_size - 256
ids = list(tokens) # copy so we don't destroy the original list

merges = {} # (int, int) -> int
for i in range(num_merges):
  stats = get_stats(ids)
  pair = max(stats, key=stats.get)
  idx = 256 + i
  print(f"merging {pair} into a new token {idx}")
  ids = merge(ids, pair, idx)
  merges[pair] = idx

get_stats()라는 함수가 문자열에서 가장 빈번히 등장한 byte pair끼리 frequency를 뽑고 통계치를 dictionary로 저장하고 있다. 이 stats를 활용하여 pair를 맺어줄 byte 조합을 찾게 되는데, 원하는 vocab_size를 지정하고, 그것과 256(=UTF-8의 인코딩 최대 표현 가능한 값)간의 차이만큼의 pair를 생성하게 된다. 즉 내가 10개 byte pair를 생성하고 싶다면 상위 10개의 빈번한 pair 조합을 merge 대상으로 지정하는 것이다. 이 역시 dictionary로 저장해둔 뒤 추후 input으로 들어오는 문자열에 대해 UTF-8로 인코딩하고, 그 byte code들 중 빈번한 pair를 병합하면서 최종 인코딩 결과를 뱉는다.

하지만 이러한 인코딩 알고리즘은 단순하기에 단어를 섣불리 분리해서 그 의미를 온전히 전달하지 못하게끔 할 때가 있다.

그래서 GPT2에서는 정규식으로 특정 패턴은 분리될 수 없게 강제하게끔 후처리를 한다.

실제로 GPT2 논문을 보면 단순한 BPE 알고리즘은 sub-obtimal하다고 말한다.

예를 들어 학습 대상 텍스트에 dog / dog. / dog! 와 같은 단어가 빈번히 등장한다면 이들은 각각 별도로 tokenization이 될 수 있기 때문에 특정 패턴은 분리되어 Tokenization이 될 수 없도록 강제해야한다며 아래 정규식 표현을 제시한다:

's|'t|'re|'ve|'m|'ll|'d| ?\\p{L}+| ?\\p{N}+| ?[^\\s\\p{L}\\p{N}]+|\\s+(?!\\S)|\\s+

위 식은

apostrophe + 문자열
문자(Letter) 구분
숫자 구분
문자도 숫자도 아닌 punctuation marks (느낌표, 물음표 등) 구분
whitespace 묶음 구분 (\p는 whitespace)

순으로 우선순위를 따져 분리한다.

즉 문자는 문자대로, 숫자는 숫자대로, 느낌표 등은 따로, 그리고 일반적인 띄어쓰기가 아닌 2개 연속된 띄어쓰기는 별도로 구분한다.

ex) World123 → “World” + “123”, I’ve → “I” + “’ve”

단 예제에서도 볼 수 있듯 휘어진 apostrophe(’)는 분리되지 않는다. '만 해당된다.

눈여겨볼만한 것은 문장의 시작 단어를 제외하고는 스페이스바를 포함하고 나눈다는 것이다. 즉 Hello World는 “Hello”와 “ World”로 나뉘게 된다. 가끔 ChatGPT를 사용하면서 trailing space 에러가 날 때가 이러한 경우이다.

GPT2 Tokenizer를 우리는 inference 용으로만 사용하고 있어 그 내막에 대해 더 자세히 알 순 없지만 RegEx pattern과 BPE알고리즘 외에 추가로 손 본 것들이 있을 것으로 예상된다.

GPT4는 GPT2에서 좀 더 발전되었는데 유의하게 볼만한 것들은 아래와 같다.

GPT4에서는 연속된 whitespace가 각기 다른 token으로 나뉘지 않고 하나로 묶여서 tokenization된다.

주로 Python coding을 위함인 목적이 컸을텐데, 그냥 스페이스바와 4개/8개 스페이스바를 각 하나씩 묶는다.

그리고 apostrophe 조합에서 대소문자를 구분하고 있었는데, 이 패턴이 case insensitive하도록 설정하였다.

즉 ‘s이든 ‘S이든 동일하게 토큰화가 된다.

숫자의 경우 세 자리만 함께 묶인다. 그래서 네 자리 숫자는 각각 세 자리와 한 자리로 나뉘게된다. 1000 → 100 + 0.

Tokenization 결과는 토큰, merge pairs(BPE알고리즘) 그리고 special token으로 구성되어있다.

이 사이트에서 Tokenization 결과를 보면 special token인 <|endoftext|>를 완전히 입력하기 전까진 다른 토큰으로 분류되었다가, 완전히 입력하게 되면 바로 special token으로 분류되는데 이는 BPE 알고리즘 외에 후처리로 special token만을 인지하고 별도 ID로 리턴한다는 것을 알 수 있다.

GPT2에는 “<|endoftext|>”라는 special token이 하나있으며,

다시 처음으로 돌아가 GPT 의혹들에 답을 하면 좀 더 GPT에 대해 이해할 수 있다.

1. 왜 스펠링이 안될까?

→ 문자를 Split하여 학습하기 때문이다.

2. String processing task가 안될까? (reverse 등)

→ 마찬가지로 문자를 Split하여 학습하기 때문. 하지만 띄어쓰기로 떨어뜨려서 reverse시키면 잘 대답함 ex) detection을 d e t e c t i o n으로 쓰고 reverse하라고 하면 잘 대답한다.

3. non-English language에는 성능이 낮을까?

→ 학습 데이터에 상대적으로 부족함. 그래서 tokenization 결과가 의미를 잘 전달하지 못할 수 있다.

4. 단순한 수학 연산에 왜 약할까?

→ 마찬가지로 숫자 tokenization 때문이다. 일반적으로 덧셈만 생각하더라도 우리는 숫자를 일의 자리부터 점점 큰 단위로 더해가지 앞 자리수부터 더하지 않는다. 게다가 이 자료를 보면 숫자를 구성할 수 있는 가짓수가 굉장히 많은데 이를 제대로된 연산으로 처리하기 위해서는 별도로 special case를 두고 학습해야한다.

“There is always inconsistent chunking of large numbers into tokens and the occasional unique token to contend with”

5. GPT-2가 왜 비정상적으로 Python coding 성능이 안좋았을까?

→ indentation(= 연속된 스페이스바)를 어떻게 토큰화하느냐의 차이이다.

6. 왜 |endoftext|라는 string을 보면 멈출까?

→ special token이기 때문이다. 마찬가지로 .DefaultCellStyle과 같이 특수한 토큰들은 일부만 입력하더라도 이러한 단어를 학습데이터에서 보기가 드물기 때문에 예측한 Token distribution이 괴랄할 것이다. 따라서 Completion API를 이용하여 쿼리로 던지게 되면 에러메시지를 뱉는다. 특히 스페이스만 하나 더 추가해서 쿼리를 던지더라도 앞서 본 tokenization 과정에서 알 수 있듯 단어의 시작은 늘 스페이스를 포함하고 있기 때문에 에러를 뱉게 된다. Tiktoken 코드에 “unstable token”이라고 검색하게 되면 실제로 수기로 처리하는 특수 토큰들이 많는다.

7. LLM에서 JSON보다는 YAML을 사용하는게 더 좋을까?

위: JSON, 아래: YAML, 오른쪽 화면을 보면 색칠된 구간이 JSON일 때 더 많음

→ YAML에서의 토큰 활용도가 훨씬 높는다. JSON은 토큰 효율성이 좋지 않는다.

8. 특정 단어에 답을 하지 못하는 경우 (ex. SolidGoldMagikarp)

→ 이 사이트에 따르면 Embedding 모델 학습 과정에서 유사한 단어끼리 임베딩 공간에 클러스터링하는데, 가끔 어떤 클러스터에서 이상한 단어들이 묶여있을 때가 있다.

아마도 이러한 단어들은 이커머스 홈페이지/Reddit threads/게이밍 플랫폼 로그기록 등에서 나온 단어들일 것이고 학습 데이터에서 비중이 크지 않아 마주하게 되었을 때 어떻게 해야할지 모를 수 있다. 이러한 이상행동들은 forward propagation에서의 floating point error로 추정되고 있다.

실제로 GPT에게 해당 단어를 물어보게 되면 다른 단어로 답변을 하거나, 답을 피하거나, hallucination이 섞여있거나 욕으로 되받아치거나, 등 이상 행동을 보이게 된다.

결국 LLM 모델도 어떻게 데이터를 전처리해서 넣어주느냐가 중요하다.

Build my own tokenizer

나만의 데이터로 Tokenizer를 학습하고싶다면 Sentencepiece같은 오픈 소스가 있다.

Sentencepiece
- Llama와 Mistral에서 사용하는 학습/추론 모두 가능한 tokenizer, BPE 알고리즘을 포함하고 있음
- Google에서 제공하는 GitHub 코드가 있는데, sentencepiece는 tiktoken과는 flow가 다름
  - tiktoken: 문장을 UTF-8로 변환, 그 다음이 BPE
  - sentencepiece: Unicode code point를 바로 BPE로 변환하고 character_coverage 값에 따라 희귀한(빈번하지 않은) code point에 대해서는 UNK 토큰으로 변환하거나 byte_fallback이라는 옵션이 True라면 UTF-8로 변환한 뒤 raw byte를 인코딩함
    - byte_fallback = False라면 UNK토큰으로 분류되어 “안녕하세요” 전체가 UNK token의 ID값을 지님
    - ex) byte_fallback = True라면 영문으로 학습된 Tokenizer에 “안녕하세요”라고 넣으면 UNK 토큰으로 분류하지 않고 UTF-8로 인코딩한 뒤 그 raw byte를 다시 vocab에 따라 인코딩함

이 외에 이 글을 작성하게 된 배경인 Andrej Karphaty가 간소화한 minBPE도 활용이 가능하다.

기타 팁
- vocab_size 는 얼마가 적당한가?
  vocab_size 파라미터는 embedding layer, linear layer에 사용된다. 많이 늘릴수록 모든 vocab 속 토큰마다의 확률값을 계산해야하고, 임베딩 학습 레이어의 연산복잡도도 올라간다. 또 너무 vocab size가 크다면 under-training될 확률도 올라가는데, 더 많은 문자(character)에 대해 학습하기 때문에 상대적으로 빈번한 토큰 패턴도 덜 빈번하게/유의하게 학습될 것이기 때문이다. 게다가 vocab_size가 크다면 긴 문자열을 짧게 인코딩하게 되기 때문에 모델이 충분히 단어간 의미에 대해 학습할 여유를 줄여버리게 된다.

주변 친구 찾기 - 웹소켓, Redis, Redis Pub/Sub

Julie's — Thu, 15 Feb 2024 20:24:41 +0900

본 글은 아래 책을 읽고 요약된 정보입니다.

https://product.kyobobook.co.kr/detail/S000211656186

1장에서 보았던 근접성 서비스와는 살짝 다른 특징
- 근처 사업장 주소는 정적인 정보이지만 주변 친구는 위치가 자주 바뀔 수 있음

개요

지원자: ‘주변에 있다’는 기준은 수치적으로 얼마나 가까운 것인지?

5마일

지원자: 이를 직선거리로 가정해도 되는지?

지원자: 얼마나 많은 사람들이 이 앱을 사용하는지? 10억명 중 10% 정도?

지원자: 사용자의 이동 이력 보관 여부

지원자: 친구 관계에 있는 사용자가 10분 이상 비활성 상태면 사용자를 목록에서 사라지게?

지원자: GDPR, CCPA 같은 사생활 및 데이터 보호법 고민 필요?

좋은 지적, 일단 생략

요구사항

해당 친구까지의 거리
해당 정보가 마지막으로 갱신된 시각(timestamp)
친구 목록은 몇 초마다 갱신되어야함

비기능 요구사항

낮은 지연시간
안정성
결과적 일관성: strong consistency가 아니어도 됨

개략적 규모 추정

‘주변 친구’는 5마일(8km) 반경 이내 친구로 정의
친구 위치 정보는 30초 주기로 갱신. 사람이 걷는 속도를 감안했을 때 주변 친구 검색 결과가 크게 달라지지 않을 것이기 때문
동시 접속 사용자 수는 DAU의 10%로 추산
평균적으로 한 사용자가 400명의 친구를 갖는다고 가정. 그 모두가 주변 친구 검색 기능을 활용
페이지당 20명의 주변 친구를 표시, 사용자 요청이 있을 때 더 많은 친구들을 보여줌

개략적 설계안

API 설계
- 위치 정보를 모든 친구에게 전송해야함. 이 때문에 클라이언트-서버 간 통신을 단순히 HTTP 프로토콜로 구성할 수는 없음
- 사용자는 근방의 모든 활성 상태 친구의 새 위치 정보를 수신해야함
1. P2P방식 - 가장 단순
활성 상태인 근방 모든 친구들과 항구적 통신 상태를 유지하지만 대규모 시스템에서는 적합하지 않음. 엄청난 양의 갱신 요청과 수신을 해야함

2. 소규모 백엔드 → 더 큰 규모로 확장 가능하도록 변경
- 로드밸런서: RESTful API 서버와 웹소켓 서버 앞단에 위치
- RESTful API 서버: 친구를 추가/삭제 혹은 사용자 정보를 갱신하는 등의 부가적인 작업을 처리
- 웹소켓 서버: 친구 위치 정보 변경을 거의 실시간에 가깝게 처리. 클라이언트는 서버 한 대와 연결을 지속함
- Redis 위치 정보 캐시: 활성 상태 사용자의 가장 최근 위치 정보를 캐시하는데 사용, TTL 필드를 활용할 것
- 사용자 데이터베이스: 사용자 정보와 사용자의 친구 관계 정보를 저장, 관계형 혹은 NoSQL도 가능
- 위치 이동 이력 데이터베이스: 사용자의 위치 변동 이력을 보관. 주변 친구 표시와 직접적으로 관계된 기능은 아님
- Redis Pub/Sub 서버: 초경량 메시지 버스.
  - 웹소켓 서버에서 수신한 특정 사용자의 위치 정보 변경 event를 해당 사용자에게 배정된 pub/sub채널에 배정
  - Subscriber: 해당 사용자의 친구 각각과 연결된 웹소켓 연결 핸들러
  - Publisher: 위치 정보가 갱신되었다는 event를 발행하려는 사용자들
  1. 위치 정보가 갱신되었다는 event를 발행하는 사용자가 publisher로 등록됨
  2. 해당 publisher별로 구독하고 있는 subscriber (친구들 각각의 웹소캣 연결 핸들러)로 broadcast. 이 때 친구가 활성상태이면 거리를 재계산
  3. 재계산한 거리가 검색 반경 이내이면 갱신된 위치와 갱신 시각을 웹소켓 연결을 통해 해당 친구의 웹소켓 서버를 통해 클라이언트 앱으로 보냄
  한 사용자당 평균 400명의 친구, 그 중에서 활성상태 친구가 10%를 차지한다고 가정했으니 한 사용자의 위치가 바뀔 때마다 위치 정보는 총 40건이 발생할 것임
- API 설계
  - 서버 API: 주기적인 위치 정보 갱신, 웹소켓 초기화 API
  - 클라이언트 API: 갱신된 친구 위치를 수신할 API, 새 친구 구독 API, 구독 해지 API
두 사용자 사이의 거리가 특정 임계치보다 먼 경우에는 변경 내역을 전송하지 않음

데이터 모델

위치 정보 캐시
- Redis와 같은 캐시로 구현
- ‘주변 친구’ 기능은 사용자의 현재 위치만을 이용하기 때문
위치 이동이력 데이터베이스
- 스키마
  User_id | Latitude | Longtitude | Timestamp
- 막대한 쓰기 연산 부하를 감당할 수 있어야함
- 수평적 규모 확장이 가능해야함
- 관계형 DB를 사용할 수도 있으나 이력 내용이 담기기 때문에 한 대에 보관하기에 너무 무거울 수 있어 샤딩이 필요함. 보통 사용자ID를 기준으로 샤딩
- 카산드라 DB를 추천

규모 확장성

API서버, 특히 RESTful API 서버는 stateless 서버이기 때문에 손쉽게 확장 가능
웹소켓 서버인 경우는 stateful 서버라 기존 연결이 종료될 수 있게끔 처리해야함
사용자 DB의 경우 데이터를 샤딩하여 수평적 규모 확장이 가능함
위치 정보 캐시의 경우 활성사용자의 수와 정보 보관에 필요한 바이트 수를 추산하여 필요한 서버 수를 예측한다. 이 역시 샤딩을 손쉽게 할 수 있어 수평적 규모 확장이 가능하다
레디스 펍/섭은 채널을 만드는 비용이 매우 저렴하다. 채널 하나를 유지할 때 구독자 관계를 추적하기 위하여 해시테이블과 연결리스트가 필요한데 이는 매우 소량의 메모리만을 잡아먹는다.
분산 레디스 펍/섭 서버 클러스터
- 모든 채널이 서로 독립적이기 때문에 메시지를 발행할 사용자 ID를 기준으로 펍/섭 서버들을 샤딩하면 됨. 하지만 좀 더 매끄럽게 동작하게끔 하기 위해 서비스 탐색(service discovery) 컴포넌트를 도입
  - 키-값 저장소, 즉 해시 링으로 가능한 서버 목록을 유지하게 됨
  - 값은 레디스 펍/섭 서버가 됨. 예를 들어 총 4대의 서버가 있다고 했을 때 채널의 해시값을 구한 뒤 그 해시값이 속한 범주를 담당하는 레디스 펍/섭 서버를 찾음
레디스 펍/섭 서버 클러스터는 stateful 서버 클러스터일까?
- 특정한 채널을 담당하던 펍/섭 서버를 교체하거나 해시 링에서 제거하게 되는 경우 채널은 다른 서버로 이동시켜야하고, 해당 채널의 모든 구독자에게 그 사실을 알려야함. 그래야만 기존 채널에 대한 구독 관계를 해지하고 새 서버에 마련된 대체 채널을 다시 구독할 수 있기 때문. 이 관점에서는 stateful 서버
- Stateful 서버 클러스터는 규모를 늘리거나 줄일 때 운영 부담과 위험이 크다. 그래서 일반적으로 오버 프로비저닝을 한다.

변형

임의의 친구 정보
- 만약 친구관계가 아니지만 정보제공에 동의하여 주변 친구들을 찾을 수 있는 기능이 있다면?
  - 지오해시에 따라 구축된 펍/섭 채널 풀을 두면 됨
  - 정보제공에 동의한 사용자들에 한해 위치정보를 지오해시에 매핑하여 그 값의 채널을 구독하고있게함
  - 이 때 격자 경계 부근에 있는 사용자를 처리하기 위해 본인이 위치한 지오해시 외에 주변 지오해시 격자 채널들에도 구독함