오늘은 삼바 TV와의 인터뷰가 잡혔다.
그동안 (블로그에 전부 언급하지는 않았지만) 수많은 인터뷰 전화를 받았고, 대부분 work authorization을 확인하고는 거기에서 인터뷰 프로세스는 중지 된다.
이럴 때일 수록 정신력이 강해야 한다. 사람은 몸이 피곤해서가 아니라 수많은 좌절 때문에 정신적으로 무기력해지기 때문이다. 이쯤 되면 큰 기대는 잘 안하고 무심하게 인터뷰를 맞이하게 된다.
점심을 먹고 커피 한잔을 즐기며 여유롭게 페북질을 하고 있을 때 전화가 왔다.
만디 라는 인도인이다.
인도인 발음은 이쯤 되면 또 그냥 일상이 되었다...
곳곳에서 만난 수많은 인도인 친구들 발음에도 조금씩 익숙해져 가고, 패턴이 조금씩 보이긴 하는데, 아직 딱히 솔루션이 없다. 많이 듣는 수 밖에.
안들려? 익숙해질 때도 됐잖아?
만디는 간단하게 회사 소개를 하고 자신의 직급을 이야기 했는데, 잘 못들었다. 희미하게 Engineer라는 단어만 들렸을 뿐.
아... 오랜만에 조금 깊이가 있는 기술 면접 보겠구나..
안녕 스티브 쏭?
안녕~ 만나서 반가워 (습관적으로 전화상에서 Nice to meet you를 말해 버렸다. 미국인들은 전화상에서 이런말 안한다.)
어.. 응 너랑 이야기 하게 되서 반가워 (조금 당황한 만디, Nice to talk to you 로 응수 한다)
전에 있던 회사에서 무슨 일을 했니...와 같은 통상적인 질문들이 이어지고 바로 기술적인 질문을 쏟아냈다.
리눅스에서 어플리케이션 개발을 많이 했니, 커널과 디바이스 드라이버를 많이 했니?
난 커널을 수정하는 일은 거의 안했어. 디바이스 드라이버는 스토리지 제어 관련 기능을 좀 추가 하느라고 수정한 적은 있지. 대부분 멀티미디어 SoC 위에서 임베디드 어플리케이션을 개발했어.
오, 너가 리눅스 기반에서 어플리케이션 개발을 많이 했구나. 그래 그럼 질문을 할게, 유저 영역과 커널 영역에서 프로그래밍의 차이점을 말해줄 수 있어?
리눅스 시스템은 유저 영역과 커널 영역으로 나뉘어져 있는데 유저 레벨에서 프로그래밍을 할 때는 기본적으로 커널에 시스템 자원을 요청하는데 커널이 시스템 자원을 관리해 주기 때문에 상대적으로 신경을 덜 쓰고 안전하게 프로그램을 작성할 수 있지. 하지만 커널 레벨에서 프로그래밍을 할 때는 굉장히 조심해야 하는데 커널 레벨에서 메모리를 할당하고 쓸 때는 메모리 관리 등을 해주지 않기 때문에 관리를 잘 해주지 않으면 위험해.
좋아, 유저 영역에서 Null 포인터에 접근을 하려고 하면 어떤일이 발생하지?
Null pointer를 접근하면 프로그램이 더이상 수행을 할 수가 없기 때문에 커널에서 해당 프로세스를 종료 시키고 정리를 해. 그리고 에러 코드를 리턴해 줘. 예를 들면 SIGSEGV 같은 시그널과 함께 에러가 발생한 영역의 주소 정보들을 알려주고, 유저 영역에서는 이를 기반으로 어디에서 프로그램이 오동작 했는지 추적할 수 있지.
좋아. 다음 질문. 프로세스와 스레드의 차이점은?
프로세스는 기본적으로 커널 레벨에서 서로 다른 context 로 나뉘고 각각의 프로세스는 고유의 메모리 영역을 갖지. 스택이나 힙, 그 밖에 다른 세그먼트들. 커널의 프로세스 스케줄러가 프로세스의 동작을 스케줄링을 한다.
스레드는 프로세스에 비해 굉장히 가볍고 생성하는데 자원을 덜 소모해. 하나의 프로세스 내에 여러개의 스레드가 자원을 공유한다. 스레드 끼리는 공유 메모리를 통해서 데이터를 주고 받기 쉽지만, 프로세스 끼리는 특정한 IPC 메커니즘을 이용해야 하지. pipe같은것.
오, 그래. 프로세스 간 통신 이야기가 나와서 말인데, 하나 질문 하지.
하나의 프로세스가 malloc으로 메모리를 할당했어. 그리고 또 다른 프로세스와 통신을 해. 그렇다면 그 프로세스는 이 프로세스가 할당한 메모리의 주소를 통해 접근이 가능하니?
아니. 그건 안되지. 왜냐하면 프로세스가 메모리 할당을 했을 때 반환되는 메모리 주소는 가상 메모리 주소잖아. 하나의 프로세스는 4GB의 가상 메모리 공간을 모두 사용하고 실제로 물리 메모리로 변환 되기 때문에 한 프로세스가 다른 프로세스의 메모리 주소로 직접 접근을 할 수가 없어.
굿. 가상 메모리 이야기가 나와서 말인데 하나의 프로세스가 갖는 메모리 영역 크기는 얼마나 되지?
32비트 컴퓨터 기준으로 말한다면 4GB야.
프로세스가 그걸 모두 사용하니?
아니, 커널 영역이 처음 1GB를 사용하고 나머지 3GB 영역을 유저 영역을 위해 할당되어 있어.
그래. 만약에 물리 메모리가 4GB가 있고, malloc으로 4GB를 할당하면 어떻게 되지?
어.. 음, 물리 메모리? 물리 메모리가 4GB 가 있다고 하지만 커널이 조금 쓰고 있지 않아? 그렇게 되면 4GB 를 할당 못할텐데, 스왑 메모리 영역을 쓰려나?
다시 설명해 줄래?
4GB 할당을 시도 했을 때 메모리가 부족해서 에러를 리턴한다고 생각해.
응, 그래. 너 말대로 커널이 1GB영역을 쓰고 유저 영역이 3GB 영역을 사용한다고 하면, 그러면 물리 메모리가 1GB가 있을 때 1GB 를 malloc 으로 할당하면 어떻게 되니?
응, 유저 영역의 가상 메모리가 3GB 라서 이론적으로 1GB 할당은 가능하지. 근데 물리 메모리가 부족하잖아? 커널이 조금 쓰고 있을테니까. 그러면 이론적으로 할당을 됐지만 실제로 1GB의 물리 메모리를 모두 할당하진 않아. 그 대신 내가 메모리를 사용하다가 실제로 물리 메모리가 모자라면, 커널이 swap 메모리 등을 사용해서 나한테 실제로 쓸 수 있는 메모리를 반환해 주지.
스왑 메모리로 메모리가 스왑될 때, 어떤 메모리가 저장되지?
그건 커널 정책에 따라 달려있긴 한데, 일반적으로 사용하지 않은지 오래된 영역의 메모리 부터 스왑 영역으로 보내주고 나한테 메모리를 할당해 주지.
그래 좋아. 너 네트워크 소켓 프로그래밍 해봤지?
응, 네트워크로 비디오 스트리밍 했으니까 많이 해봤지.
좋아. 그러면 RTP 와 RTSP가 어떤 프로토콜 위에서 동작하는지 설명해 볼래?
응 RTP 는 주로 UDP 프로토콜 위에서 동작하고 RTSP는 TCP 위에서 동작해. RTP는 그래서 손실이 발생할 수가 있어.
UDP와 TCP 차이점을 설명해봐.
TCP는 데이터 손실이 없는 프로토콜이고, UDP 는 데이터 손실이 있어. UDP 패킷이 훨씬 더 가볍고, TCP 는 통신 메커니즘이 더 복잡하지. 연결 설정이나 핸드 쉐이킹, 에 또.. 뭐냐 (흐름 제어를 설명하려고 했는데 까먹었다). 그래서 UDP 같은 경우 패킷 순서를 알 수 있는 정보가 있어서 수신부 네트워크 스택에서 데이터를 받고 재 정렬해서 어플리케이션으로 보내줘.
응, UDP와 TCP를 사용한 다른 예를 들어볼래?
무슨 뜻이야? 이해가 안가는데..
UDP프로토콜을 이용한 예시와 TCP 를 이용한 예시.
음... 뭐가 있을까. TCP를 이용한 예시로는 FTP 프로토콜이 있지. 파일 전송은 데이터의 완벽한 전송이 보장되어야 하니까. 대신 FTP프로토콜을 이용하기 위한 부가적인 프로토콜, 예를 들면 디렉토리 변경이나 파일 리스트 요청 같은건 덜 중요하기 때문에 UDP로 구현하기도 하는 걸로 알고 있어.
그렇구나. 좋아. 스티브 시간상 여기까지 인터뷰를 하자. 뭐 또, 궁금한거 있니?
응, 너네 회사 제품들을 봤는데 디바이스 같은건 안만드는거 같은데, 임베디드 소프트웨어를 왜 채용하는거야? 셋탑 박스 같은거 만드니?
아니, 우린 디바이스 안만들고 TV기반 광고와 서비스를 제공하는 회사야. 하드웨어를 따로 만들진 않지만 TV나 모바일 디바이스 같이 멀티 플랫폼을 지원해. 임베디드 소프트웨어 엔지니어는 로우 레벨 소프트웨어 쪽 지원을 위해 채용중이야.
응, 그렇구나 알았어.
그렇게 삼바 TV와의 인터뷰는 끝났다.
간만에 인터뷰 다운 인터뷰를 한 것 같아서 조금 개운했다.
여태껏 몇번의 기술 인터뷰를 봤는데, 보통은 나의 기술적인 백그라운드를 묻는 질문들이 주를 이룬다. 또는 코딩 인터뷰와 병행하기도 하고, 어떤 스타트업들은 대뜸 코딩 문제부터 풀어보라고 메일을 보내기도 한다.
내가 인터뷰 내용을 대략적으로 기록을 해 놓고 보니 내가 질문에 대답을 하면 그 대답과 연관성이 있는 또 다른 기술적인 이슈들로 질문들을 이어져 나가곤 했다.
가령
프로세스/스레드 차이 질문 -> 프로세스간 통신 질문 -> 프로세스의 가상 메모리 영역 질문 -> 메모리 할당 질문..
이런 식이다.
그러니까 내가 대답을 한 내용에서 키워드들을 추려내고, 그것을 정말 이해하고 대답했는지.. 아니면 책보고 외워서 대답 했는지를 알아내기 위한 것이다.
사실은 그동안 인터뷰 준비랄 것도 없이 그냥 저냥 시간을 보내고는 했다. (어차피 무슨 질문을 할지 알수도 없다.)
코딩 문제야 뭐 문제를 풀어야 통과가 되겠지만, 백그라운드 체크는 평소에 기본기를 다져놓지 않으면 대답할 수가 없는 질문들이다. 인터뷰를 마치고 바로 바로 기록을 해놓고 다시 공부를 하는 이유이기도 하다.
내가 뭘 잘못 알고 있었나, 내가 무슨 대답을 제대로 못했나, 어떻게 대답하고 무엇을 언급했어야 좋았을 뻔했나... 등을 되새겨 보자.
기본기와 영어가 부족하면 인터뷰도 통과할 수 없다.
전혀 성장하지 않았어.
기초를 가르쳐 주는 사람이 있는겐가?
저 녀석 영어는 괜찮은 건가?
의사 소통이 되지 않는 것 같아.
흠.. 이번에는 과연 온사이트 인터뷰를 볼 수 있을까..?
그럼에도 불구하고 신분 문제 때문에 끝날 가능성도 크다만.. ㅋㅋㅋ