두서 없이 적는 CS 박사의 인더스트리 취업 경험기 (1): 개요편

요새 쓰는 시트콤 시리즈가 자꾸 새드 엔딩으로 가서 좀 심난한데요. 분위기를 바꾸어 보기 위해 저의 취업 과정에서 겪었던 일을 한번 정리해 보려 합니다. 여기에 저보다 선배님들도 많으실 테고 실제로 면접에 참여하시는 분들도 많으신 지라 저 같은 사회 초년차가 이런 글을 적는다는 게 좀 부담스럽긴 합니다. 그래도 곧 졸업 앞두신 분들이 보면 제가 했던 시행착오들을 좀 덜하지 않을까 생각에 적어보게 되었습니다. 물론 제 뇌피셜로 적는 것도 좀 있으니 혹시 제가 잘못 생각하는 게 있으면 가차없이 댓글로 달아주세요. 

 

미리 언급해두지만 이 글은 컴터 관련 전공 특히 박사급 잡 마켓 얘기라서 다른 분야나 학/석사급 구직과는 좀 얘기가 다를 가능성이 있습니다. 마모의 주 토픽 (카드사를 털자) 과는 조금 연관성이 떨어져서 올리면서 주저했는데요. 그래도 census상 고학력자가 많으시고 이쪽 업계 계신 분들도 많은 것 같으니 올려보자고 생각이 들었습니다. 

 

이 글은 아마도 (1) 개요, (2) 지원절차, 인터뷰 준비 및 후기, (3) 네고 편으로 나누어질 예정입니다. 

 

Sanitized 된 제 스펙:

 

이미 제 신상을 아시는 분들이 많은데... 일단 같은 CS 박사라도 본인이 누구냐에 따라서 경험이 많이 달라질 수 있어서 간략하게 적어봅니다.

 

학력=미국 상위권 CS 학교 학부부터 박사까지

연구분야=Software System이라고 해둡시다. 주로 읽는 논문이 OSDI/NSDI/SIGCOMM/Eurosys/SOCC/FAST/ATC/VLDB/SIGMOD 이런 거요. 

논문실적=솔직히 좋은 편은 아닙니다. 아무리 논문 잘 안 나오는 시스템 분야라도요. 인더스트리 포지션 보시면 크게 지장은 없는 것 같습니다. 리서치 포지션 쪽으로 가면 왜케 논문이 없냐는 질문은 나올 수 있어요. 

 

Scope of this text: 

 

크게 나눠보면 미국에서 박사하신 분들의 루트는 아래 정도로 나눌 수 있을 것 같습니다. 

졸업을 생각하는 시점이면 이미 본인 분야 한 사람들이 어느쪽으로 많이 빠지는지 감이 잡힐 겁니다. 디펜스 날짜가 잡혔는데 그게 감이 안잡히면 문제 있는 겁니다. 물론 길이 여러방면이라 고민이 되실 수는 있어요. 그래도 구직전에 어느정도 정리하시는 게 좀 편하실 겁니다. 

 

1. 미국 교직

2. 포닥

3. 미국 리서치랩

4. 미국 non-리서치 회사 포지션

5. 한국 교직 

6. 한국 회사

 

그 중에 제가 시도했던 건 미국 회사 리서치랩 하고 미국 회사였습니다. 물론 둘의 경계는 모호할 수 있습니다. 미국회사 리서치랩에서 일반 SWE같은 포지션으로 갈 수도 있고 (RSDE같은 식으로 얘기하죠) 리서치랩이 따로 없는 회사에서도 리서치 포지션이 있을 수도 있습니다. 페북같은 데는 리서치사이언티스트라고 타이틀은 붙어있지만 실제로 하는 일은 SWE랑 별 차이 없기도 합니다. 그리고 부서에 따라 순수 리서치 포지션은 아닌데 박사급들만 주로 뽑는 부서도 있습니다. 이런데는 분위기가 대학원하고 크게 다르지는 않죠. 

 

1번은 제가 깜량이 안되서 시도도 안해서 패스 합니다. 제 세부 분야는 학교 포닥은 거의 없는 것 같고 (버클리의 네임드 교수랩으로 가는 경우는 드물게 있지만) 회사 포닥이나 리서치 포지션으로 많이들 갑니다. 

5번은 자세한 얘기는 못 드리겠지만 주변을 보면서 팁 하나 드리자면 학회에 오시는 한국 교수님들과 네트워킹 잘 하시고요, 한국 들어갔을 때 관련 랩이 있는 학교에 가서 리서치 톡을 할 수 있는 기회가 생기면 좋지 않을까... 정도만 적어봅니다. 

6번의 경우 대부분의 학교 학생회에 리쿠르팅 공고가 주기적으로 올테니 프로세스는 그걸 참조하시는 게 좋겠습니다.

 

Fit:

 

박사 하시는 분들은 대부분 자기가 하고 싶은 일이 명확하기 때문에 하시는 거잖아요. 그리고 회사 입장에서 박사급을 뽑으면 generalist를 뽑는 건 아닐겁니다. 원하는 바가 좀 더 명확할 가능성이 높습니다. 제 경험상 핏이 안 맞으면 아예 연락조차 오지 않거나 테크인터뷰는 통과 하더라도 팀 매칭에서 실패하거나 최종적으로 오퍼가 안 나올 가능성이 높아요. 말년차에 논문도 계속 나오고 졸업논문도 마무리 해야하고 시간 없는데 인터뷰 한다고 편도 다섯시간씩 비행기 타고 날라갔다 왔는데 허탕치면 그냥 시간만 버린겁니다. 

 

그렇다고 아예 자기가 한 specific한 분야를 하는 곳만 지원해야 된다는 건 당연히 아닙니다. 박사 짧게는 4년 길게는 6년 이상 하셨으면 살짝 다른 것 하고 싶을 수도 있잖아요. 그리고 사람을 찾기 힘든 곳일 수록 (Bay area 외 지역에 있는 회사라던지 자기네들만 하는 독특한 무언가를 한다던지) 핏 부분에 있어서 좀 더 generous해지는 건 있는 것 같습니다. 그리고 학회는 안 겹치는데 생각보다 compatible 한 분야들이 몇 있습니다. 대체로 System쪽은 서로 어느정도 호환되는 것 같아요. 특정 분야 아니라도 전반적으로 System research skill을 갖고 있으면 오케이라고 생각하더라고요. 

 

그래도 자기가 원하는 일을 할 수 있거나 자기가 해왔던 연구나 스킬을 필요로 하는 회사/팀이 어딘지는 좀 파악 해 두시는 게 좋습니다. 본인하고 잘 맞는 회사들만 노려도 시간은 부족합니다. 물론 FAANG 급의 회사는 대부분 어지간한 분야는 할 겁니다. 그래도 그중에서도 본인이 하시는 일과 좀 더 맞는 회사가 있을 겁니다 (학회에 나오는 논문이나 사람들하고 얘기하다보면 각이 나옵니다. 대화가 술술 풀리는 회사 사람들 vs 대화가 걷돌게 되는 회사 사람들). 그 정도급의 대기업이 아니라면 뽑는 분야가 명확할 가능성이 높아요. 

 

예를 들어보자면 저는 분산시스템 관련 연구를 했습니다. 그렇다면 일단 적어도 회사 내부에서 몇 백대 또는 몇 천대 단위로 서버를 돌리는 규모있는 회사로 가는게 적성에 맞을 가능성이 높아요. 아니면 관련 솔루션을 주력으로 미는 스타트업이나요. 반면에 제 이력에는 금융 솔루션 업체 경력도 있고 algo trading 하는 회사에서 algo trading이 아닌 인턴을 한 적이 있습니다. 그래서 그냥 HR 애들이 대충 보고 hft나 algo trading 하는 회사에서 컨택이 많이 옵니다. 이런데는 제껴야 합니다. 이런데는 테크 인터뷰 통과해봤자 아무 소용이 없어요. 걔들은 quant scientist나 FPGA 장인을 뽑는건데 저는 그 일에 관심 없고 걔들이 원하는 걸 잘하는 인재가 아니에요. 

 

그렇다고 무조건 자기한테 잘 맞을 것 같아 보이는 회사만 찾아다는 게 답이 아닐 수도 있어요. 가끔 우리가 상상도 못한 매치가 나오는 경우가 있기 때문에 그렇습니다. 예를 들어보자면 예전에 학회에서 여러분들이 잘 아시는 액티비전/블리자드 사람을 본 적이 있습니다. 게임 회사 사람이 이런데는 왠일이냐고 하니까 자기네들도 자체 스토리지 시스템 개발한답니다. 이런 회사도 스토리지쪽 연구한 사람은 뽑는 겁니다. 다른 예로는 저랑 완전 다른 분야의 팀에 면접 본 적이 있습니다. 난 그쪽 연구는 코스웍 할때나 잠깐 본 정도인데 왜 온사이트를 부르는 거지 하고 봤는데 랩쪽에서 연구한 걸 실제 product로 만드는 팀인데 주된 client가 financial industry입니다. 클라이언트가 뭔 소리 하는지도 모르겠고 랩에서는 자꾸 뜬구름 잡는 소리만 하니 연구도 해보고 금용쪽 경력도 있어서 불렀답니다. 이런 경우는 사람 찾기 힘들기 때문에 오퍼도 쎄게 나오는 편입니다. 

 

네트워킹: 

 

이미 졸업하실 때 쯤이 되면 이건 이미 어느정도 감을 잡고 계실텐데요. 매우 중요합니다. 학회에 가시면 친구들하고만 놀지 마시고 생판 모르는 사람들하고 많이 얘기하세요. 학교에 가끔 톡 하러 오시는 분들 있는데 보통 관련 분야면 1:1 타임 잡을 수 있으시죠? 이런거 꾸준하게 하시고요. 할 말이 없어서 그렇다 싶어도 요새 뭐 하고 계신지 그 분이 뭐 하시는 분인지 묻다보면 시간 훅훅갑니다. 얼굴만 알던 얼마 전 졸업 한 친구들한테도 구직 하실 때 연락 돌리는 걸 주저하지 마시고요. 개인적으로 저는 링크드인으로 연락오는 리쿠르터들은 그냥 찔러보는 애들이라 그런지 영양가가 없었습니다. 

 

제가 생각했을 때 이렇게 쌓아진 인맥은 여러가지 방면으로 유용하게 쓰입니다. 

- Referral: 학부/석사 잡 서칭 하신 분들이 있을지는 모르겠지만 박사급 포지션 지원에서는 일반적으로 맨땅에 공채 지원보다는 리퍼럴을 통해서 지원하는 게 많은 것 같아요. 특히 팀단위로 채용이 진행되는 회사에서는 바로 팀 담당 리크루터한테 직접 이력서가 들어가서 채용이 진행될 가능성이 높고요, 무조건 공채로 진행되는 회사라도 hr에 이력서 넣어줄 겁니다. 하이어링 프리즈라도 다른쪽 오프닝이 있으면 넘겨줄 가능성도 높아요. 그리고 리퍼럴도 당연히 끗발 쎄신 분이 리퍼럴 해주는 게 더 효과가 크겠죠? 엔지니어가 매니저한테 이런 애가 있다더라 하는 거하고 하이어링 디시젼 내릴 수 있는 디렉터가 "여기 내가 학회에서 봤던 괜찮은 애가 있어 한번 레주메좀 봐바" 하는 거하고 차이가 있을 수 밖에 없어요. 

- 정보 수집: 정보 수집은 채용의 모든 과정에서 중요합니다. 내부에 아는 사람이 있어야 원할하게 될 수 밖에 없어요. 회사에서 요새 뭐하는지 알고 있어야 인터뷰 준비도 수월하고요. 레주메 테일러링 하기도 좋습니다. 팀 매칭 할 때도 팀 분위기 아는데 도움이 되고. 오퍼 네고 할 때도 대충 회사의 성향을 알아야 전략을 짤 수 있습니다. 

- 인터뷰 연습: 학회나 톡 하러 오신 분 만나면 대부분 본인이 뭐 하는 지 설명하고 다른 분이 뭐 하시는 설명하는 걸 토대로 대화를 하는 게 주죠? 인터뷰도 똑같습니다. 자기가 뭐하는 지를 모르는 사람한테 설명하는 건 많이 연습할 수록 수월해 집니다. 

- HR과의 커뮤니케이션 미스 최소화: 아래에 더 자세히 적지만 지원하실 때 리쿠르터와 나는 누구누구와 비슷한 일을 하는 사람이다라고 얘기를 하시면 이상한 부서로 인터뷰 되거나 본인이 하는 일을 전혀 이해하지 못하는 사람들과 인터뷰 하는 상황을 막을 수 있습니다. 

 

HR과의 communication miss 의 가능성:

 

채용 과정중에 주의하셔야 할 건 HR과의 커뮤니케이션 미스입니다. HR에 계시는 분들을 디스하고자 하는 건 절대로 아닌데요. 아무리 테크 회사 HR이라고 해도 비전문가라는 건 바뀌지 않습니다. 솔직히 같은 CS박사라도 다른 분야 사람이면 한두줄 적힌 레주메만 보고서는 이 사람이 어떤 연구를 했는지 어떤 일을 하고 싶은지가 명확하게 생각나지 않을 가능성이 높습니다. 따라서 얘들이 초기에 스크리닝 과정이나 인터뷰 배정과정에서 실수를 할 수도 있습니다. 아니면 HR이 생각하는 채용 우선순위가 본인의 선호도하고 갈리는 경우도 있습니다. 영 분위기 이상하다 싶으면 얘기 바로바로 하셔야 합니다. 

 

예를 들어보겠습니다. 

- 초기에 저는 링크드인으로 바이오쪽 스타트업이나 관련 기업 HR이 연락을 많이 왔습니다. 예전에 데이터 센터 서버들의 health monitoring 관련 인턴은 한 적이 있거든요. 얘들이 health checking이라는 단어만 딱 보고 health 관련 일을 한 줄 알고 그렇게 연락을 오는 겁니다. 

- 위에 언급했던 금융 관련도 마찬가지고요. 

- 회사 팀매칭 인터뷰 때 마찬가지로 단어 (구체적인 건 개인 식별이 가능한 정보라 검열삭제)는 비슷한데 전혀 다른 팀이랑 인터뷰 한 적 있습니다. 생각해 보니 그것도 서버 대상으로 쓴 단어인데 사람 대상으로 생각해서 혼동이 일어난 문제였네요.

 

이게 해소가 안되면 쌩둥맞은 부서로 서류가 넘어가서 서로 엥 얘가 왜 여기있지. 난 누구 여긴 어디 하시면서 시간 낭비 하시는 겁니다. 나중에라도 HR이 다른 데로 돌려주면 다행인데 핏이 안 맞네 미안 하고 오퍼 못 주겠다는 연락이 오기도 합니다. 나중에 그 회사의 희망 부서 사람을 만났는데 "뭐라고 너가 지원을 했다고? 벌써 떨어졌다고? 우리쪽에는 아무 것도 안 물어보던데? HR  이놈들을 그냥..."라는 소리 들으면 이미 늦은거에요. 

 

그외에 이런 사태를 방지하는 방법은 리퍼럴이나 미리 연락입니다. 리퍼럴 받으면 리퍼럴 해주시는 분이 채용 과정을 트랙킹 할 수 있어서 이런 경우가 방지되는 것 같고요. 리퍼럴을 안 받고 잡 포스팅으로 지원하는 경우라도 아는 분께 나 이번에 이 포지션 지원할 것 같다고 연락 주면 역시 이런 사태를 막을 수 있습니다. 구글이나 페북 같은 경우는 일단 테크 인터뷰를 통과해야 팀매칭이 되는 데요. 팀 매칭 과정에서도 미리 관심있는 팀에 있는 사람이나 같은 umbrella 밑에 있는 사람에게 연락을 해두면 그 팀 담당 리쿠르터가 파일을 요청해서 우리는 이 사람에 관심있다고 표명을 할 수 있습니다. 

 

구직시기:

 

제 경우나 다른 케이스를 봤을 때 5월 졸업 기준을 볼 때 구직시기는 아마 졸업 전 해 가을, 졸업 년도 초, 디펜스 직후 로 나눌 수 있는 것 같습니다. 각각 장단이 있으니 감안하시는 게 좋을 것 같습니다. 제 추천은 전 해 가을부터 조금씩 뿌리시지만 실질적으로 결론이 나오는 건 디펜스날짜가 가까워 졌을 때나 되는 것 같으니 채용과정이 늘어져도 너무 조급해 하시지 마시기를 바랍니다. 

 

전 해 가을: 보통 테크 회사의 학/석사 공채는 여름 인턴이 끝날 떄쯤인 8월말 9월 초에 시작됩니다. 케바케지만 박사 only position이라는 게 그렇게 흔한건 아니라서 너무 늦게 구직을 시작하시면 이미 올 school year의 head count를 이미 채워버렸을 수도 있습니다. 그런 회사의 경우 적어도 졸업 전 해에는 채용절차에 들어가야 오프닝이 나올 가능성이 있습니다. F가 그런 경우라는 것 같습니다 (물론 큰 회사라 부서 별로 사정이 다를 수도 있습니다만 제 친구가 연말 졸업예정인데 초 여름에 컨택했더니 올해 quota는 이미 다 채웠다는 답이 왔다더군요). 특히 포지션이 항상 열리는 Bay/Seattle/NY가 아니라 어른의 사정으로 그 외 지역에서 구직을 하셔야 하는 경우 조금 시간을 길게두고 계속 포지션 열리는 걸 보셔야 하는 것 같습니다. 

 

단점은 시간이 있다보니 채용절차가 세월아 네월아 하는 경향이 있다는 겁니다. 회사 입장에서도 지금 당장 일할 수 있는게 아니라서 serious하게 consider하지 않을 수도 있고요. 그리고 가끔 head count가 그 해 3-4월에나 열리는 경우가 좀 있습니다. 그런 경우는 아무리 팀에서 괜찮게 생각하는 candidate이라도 그 때까지는 무한 대기 할 수 밖에 없습니다. 후기에도 언급하겠지만 팀에서 헤드카운트가 나올 것이라 예상하고 인터뷰 진행했는데 헤드카운트 때문에 오퍼가 안 나오는 상황도 있더라고요.

 

디펜스 직후: 간혹가다가 디펜스 까지는 졸업에만 신경쓰고 디펜스 이후에 잡 서칭하시는 분들도 있습니다. 그걸 strongly suggest (라고 쓰지만 학생들은 강요라고 읽습니...) 하시는 교수님들도 계시고요. 이 방법의 장점은 디펜스에만 집중을 해서 논문 끝낼 수 있고요. 일 시작할 수 있는 날짜가 확정적이라 현재 갈 수 있는 포지션도 눈에 딱 보이고요. 회사 입장에서도 바로 쓸 수 있는 사람이라 채용절차가 빠르게 진행되는 편이긴 합니다. 

 

최대 단점은 빨리 잡 안 잡히면 망한다는 겁니다. 옵션이 많이 줄어들었을 가능성도 있고요. 그 해 헤드카운트는 이미 다 찼을 가능성도 있습니다. 가장 큰 건 OPT 무직 90일 넘기는 순간 OPT 자동 소멸입니다. 심적으로 쪼들리기 때문에 오퍼 협상에서 좀 불리해 질 가능성도 있고요. 만약 교수님의 의견으로 디펜스 후에 구직하시게 되면 박사 논문 제출을 조금 늦추시는 방법으로 학생 신분 유지를 좀 하시고 OPT지원 시기를 늦추셔서 시간을 벌어 놓는 걸 추천드립니다. 

 

졸업 년도 초: 아마 이게 절충형에 가까운 것 같습니다. 겨울방학/1월 초에 집중적으로 지원하시는 거죠. 제가 봤을 때 이게 시기상으로도 나쁘지 않고 회사 입장에서도 어느정도 바로 쓸 수 있고 헤드카운트도 어느정도 윤곽이 나오는 편입니다. 다만 단점은 인터뷰 절차가 늘어지면 졸업논문이 늦어질 수 있으니 열심히 시간 아껴가시면서 논문 마무리 하셔야 합니다. 

 

Job Outlook:

 

확실히 2년전에 비해 잡 마켓이 타이트 해지는 게 눈에 보입니다. 헤드카운트 이슈로 어려움을 겪는 케이스가 귀에 가끔씩 들려오고 있고요 미친듯이 올라가던 compensation이 하향 안정을 찾고 있는 것 같습니다. 그래도 아직까지는 제 주변에서 CS 박사가 잡 못 찾았다는 얘기는 못 들어봤습니다. 

 

이것도 분야에 따라 다른 건 인지하실 겁니다. System 쪽 박사야 워낙 인더스트리로 나가는 케이스가 많고 수요가 꾸준한 업종인 편이고요. 제대로 딥러닝 하신 분들은 회사들이 못 찾아서 난리겠지요. 

 

원래부터 그랬지만 트렌드는 바뀌고 있어서 traditional한 리서치 사이언티스트 head count는 점차 주는 추세인 것 같긴 합니다. 제가 인터뷰 한 MSR 팀쪽도 RSDE를 더 많이 뽑고 리서치 사이언티스트는 많이 안 뽑더라고요. 순수 리서치 포지션은 ML/AI 쪽 외에는 이제 흔한 편은 아닌 것 같습니다. 물론 이건 제가 부족한거고 그래도 실력 있으신 분들은 못 데려가서 난리겠죠? 

 

신분: 

 

솔직히 CS 박사급 정도 되면 어지간해서는 신분은 문제 안됩니다. 여러분이 가시는 회사 대부분이 영주권 스폰서 까지 알아서 해줄 겁니다. STEM OPT 동안 H1B 추첨이 안되도 O비자 받으면 됩니다. 그게 어렵다 싶으면 캐나다 지사가서 1년간 뭉개고 오시면 됩니다. 학교의 경우 cap-exempt h1b라는 옵션이 있고요. 제가 지원했을 때 취업비자 스폰이 불가능 하다고 했던 회사는 중국계 회사 하나였습니다. We are not authorized to sponsor H1Bs 라고 해서 뭔가 섬칫했었죠. 

 

대부분의 CS 박사분들은 재학중에 NIW 영주권이 가능할 겁니다. 제가 봤을 때 영주권 있다고 지원 가능한 포지션이 늘어나는 건 아닙니다. 물론 영주권 있으면 인생이 편해져요. OPT 신청 신경 쓸 필요도 없고 일 좀 쉬어도 되고 h1b 추첨 노심초사 안해도 되고요. 포닥을 하는 분야라면 영주권이 있으면 NSF fellowship 지원이 가능하게되는 장점이 있을 수 있습니다. 제 주변의 경우 CS박사 재학중에 영주권(NIW) 신청하는 분들은 대부분 배우자분이 신분이 필요한 경우가 대다수였습니다. 물론 내 인생에 추첨 운 절대로 없고 나는 도람뿌 리스크를 hedge 하고 싶다 하시면 졸업 2-3년전쯤에 미리 해두는 것도 나쁘지 않습니다. 

 

분야에 따라 다르겠지만 시민권 AND/OR security clearance 통과가 가능한 상황이라면 갈 수 있는 포지션이 조금은 더 열릴 수 있습니다. 예를들면 네셔널 랩은 보통 포닥은 괜찮을 텐데 정직원이면 SC 필요한 경우가 가끔 있는 것 같습니다. Federal gov't 랑 같이 일하는 회사도 시민권자만 되는 포지션이 있는 듯 합니다. 

 

인턴:

 

물론 당연히 교수님이 인턴 가는 걸 허락해 주셔야 겠죠? 허락해 주시면 여름에 한두번은 가는 걸 강추합니다. 은근히 졸업준비 다 마치고 인턴을 간 다음 (특히 컨버젼 오퍼가 잘 나오는 회사로) 인턴이 끝나는 쯔음으로 디펜스 날짜 잡는 사람들이 종종 있습니다. 

 

제가 생각하는 장점:

* (특히 졸업 예정 1년이내 인턴) 잘 될 경우 인턴 후 풀 타임 오퍼를 주는 회사도 있습니다. F가 그렇다는 것 같았고요. 

* 풀 타임 오퍼를 안 주는 회사라도 풀타임 지원시 바로 온사이트 보내주는 게 관례인 듯 합니다. 폰 스크리닝 이런거 제끼고요. 당연히 채용 과정에서 인턴 때 기록 반영되고요.

* 그 회사 분위기가 어떤지 어떤 일을 하는지 뭐가 중요한 지 어떤 사람들이 있는지 알 수 있죠. 네트워킹 하기 좋고요. 온사이트 가셔도 아 나 어느 팀에 누구랑 일했었다 얘기하면 대화가 수월해 집니다. 

* 인터뷰 가면 당연히 학교에서 뭐하는지 궁금해 할 수도 있지만 은근히 work experience 섹션만 물어보는 인터뷰어도 꽤 됩니다. 

* MSR 같은 경우 인턴 프로젝트 하다가 잘 풀리면 그 연구 학교 돌아가서도 같이 협업해서 결국 submission까지는 가더라고요. 물론 그게 억셉 될지 안 될지는 다른 얘기인 건 아시죠...?

 

단점:

* 뭔가 기록이 있으면 사람이 물어보는데 프로젝트 말아먹었으면 좀 얘기하기가...

* 시간낭비의 가능성: 연구 못하고 엔지니어링만 하게 될 수도 있습니다. 

* 아니면 기껏 인턴 프로젝트 마치고 논문까지 썼는데 legal에서 빠꾸먹으면 멘탈이 아작납니다. 인턴 프로젝트로 논문 쓰고 억셉이 되고 심지어 Best student paper로 선정까지 된 상태였는데 회사에서 태클걸어서 retract해야 했던 케이스도 있습니다.

 

(to be continued)