Visual Studio Code Remote Deployment

Vim 과 SSH 에 찌들어 있었는데, 이번 Visual Studio Code 의 베타 기능인 Remote Deployment 를 연결해 보고 나서, 학생 때 쓰던 IDE 로 돌아간 것 같아 너무 좋았다. 언제까지고 구식 도구를 쓰며 부심을 부릴 수만은 없다. 설치 과정이 조금 험난했지만, 간단히 요약해서 써본다.

클라이언트 OS 는 윈도우 10 (빌드 1809), 서버 OS 는 Cent OS 7 기준으로 작성한다.

클라이언트 (윈도우) 준비

처음에 준비할 때는 Visual Studio Code Insider 버전을 설치하라고 되어 있었는데, 이제는 꼭 그럴 필요 없는 것 같다. 일반 Visual Studio Code 를 설치해도 된다.

다음으로, SSH 클라이언트를 설치한다. 윈도우 10 빌드 1807 이상 버전의 윈도우 OS 라면 여기 링크 안내를 따르거나, 아래 요약된 스크린샷을 보면 된다.

시작 > 설정 앱에서, ‘앱’ 을 클릭한 뒤 ‘앱 및 기능’ 탭의 ‘선택적 기능 관리’ 를 클릭한다. 그 다음 아래 ‘OpenSSH 클라이언트’ 를 찾아 설치한다. OpenSSH 서버는 설치할 필요가 없다.

만약에 여러분이 윈도우 10 빌드 1807 이하 버전의 윈도우 OS 라면… 조금 귀찮아진다. 이 문서 에 따르면, Git for windows 를 설치하면서 옵션에서 Use Git and optional Unix tools from the Command Prompt 를 선택하면 된다. 그러면, 같이 설치된 mingw 내부의 SSH 를 클라이언트로 사용한다고 한다. 물론 난 테스트해 보진 않았다! 권한 문제 등등으로 생각보다 꼬일 가능성이 있으므로, 조심해야 한다.

이제 ssh key 를 만들어야 한다. 비대칭 키에 대한 지식이 없다면 암호 대신 SSH Key 로 인증하기 포스팅을 참고하면 된다. 혹시 PuTTY 에서 생성한 비공개 키를 등록하고 쓰고 있으니 이걸로 충분하지 않을까? 그렇게 준비하면 실제 접속할 때 아마 잘 안 될 것이다. 내가 해 봤으니까…

Visual Studio Code 는 OpenSSH (또는 Git 의 ssh) 클라이언트를 쓰기 때문에, Key 호환성 문제로 ‘invalid format’ 에러를 발생시킬 수 있다. 그러니 순순히 (?) 실행 명령 창 (cmd) 을 열어서 다음을 입력하자. 기존에 쓰던 키 저장 경로가 존재한다면, 다른 경로로 설정하는 것을 추천한다. 이 방법은 Visual Studio Code 페이지의 Troubleshooting 에 등록된 내용이다.

ssh-keygen -t rsa -b  4096

 

서버 (리눅스) 준비

원활한 서비스가 가능한 리눅스 OS 목록은 여기를 참고하면 된다. Cent OS 7 은 잘 되므로 별 다른 설정 없이 가능하다. 지원이 안 되는 리눅스들은 workaround 가 있는데 (특시 Cent OS 6) 생각보다 까다롭고 원치 않는 상황이 발생할 수 있기 때문에 신중해야 한다.

접속하고자 하는 계정의 ~/.ssh/authorized_keys 파일에다가, 아까 만들었던 Key Pair 중 ‘공개 키’ 정보를 입력해야 한다. 해당 파일이 없으면 만들면 되고, 있으면 파일 끝에 추가 (append) 해주면 된다.

~/.ssh/authorized_keys 파일의 권한이 600 (계정에서만 읽기/쓰기가 가능) 인지 반드시 체크하고, 아니라면 chmod 명령으로 바꿔주도록 한다. (이건 SSH 일반 접속 때문에 하는 작업이지, Visual Studio Code 라서 하는 것이 아니다.)

 

Visual Studio Code 준비

우여곡절 끝에 준비를 다 했으면, Visual Studio Code 를 열어서 Remote Deployment 를 설치하자. 그 다음, 명령 팔레트를 열어서 (Shift + Ctrl + P) Remote-SSH: Open Configuration File… 을 선택한다. 설정 파일 경로는 수정하거나 기존에 잡아주는 경로를 쓰건 상관없다.

예시는 이렇다.

Host 192.168.0.10
    HostName 192.168.0.10
    User interp
    IdentityFile "C:\Users\interp\ssh_key\id_rsa"
  • Host : 목록에 나올 이름이다. 보통은 HostName 과 같이 지정해주거나 Username@HostName 으로 지정한다.
  • HostName : 실제 접속할 호스트 주소
  • User : 접속할 사용자 계정 이름
  • IdentifyFile : 생성한 Key Pair 중 ‘비공개 키’ 경로

 

Remote 로 접속!

이제 설정 파일을 저장하고, 명령 팔레트를 열어서 (Shift + Ctrl + P) Remote-SSH: Connect to Host… 을 선택한다. 아까 저장한 Host 가 1개만 떠 있을텐데, 접속하면 아예 새로운 Visual Studio Code 창이 하나 더 뜨게 된다.

이것저것 하는 것 같으니 잠시 기다리면, 접속이 되었다는 메시지와 함께 ‘절대로 저 작은 터미널을 닫지 말아주세요’ 라는 경고문이 뜬다. 최소화시키고 작업을 하면 된다!

그래서 우린 뭘 할 수 있죠?

이 이야기는 좀 더 써 보고 2부에서 계속 하도록 하겠다.

경력직 면접의 단상

처음에는 경력직을 선호했고, 나도 그랬다.

개발자를 충원하자는 계획에 맞춰, 공고를 등록하고 경력직 이력서를 받으면서 이 정도 커리어면 뭐든지 붙을 수 있을거라고 생각했을 것이다. 하지만 그 때의 실패들이 쌓여 이제는 경력직이나 신입이나 동일 선상에 놓고 평가하고 있다.

내가 몸 담고 있는 필드는 국내에서 잘 하지 않는 분야다. 없진 않지만, 사용자 경험과 컴퓨터 구조를 동시에 신경 써야 하는 조직이다. (물론 개발자 1인이 모두 신경 쓰는 것은 아니다.) 그런데, 소위 SI 업체나 프리랜서 개발자들의 면접을 보면 괜히 미안해진다. 면접이 매끄럽지 못해서 미안한게 아니고, 이미 그들의 표정에서 ‘이걸 대체 왜 물어보는 건지’ 싶은 느낌이 표정에 드러나기 때문이다.

이야기를 나눠보면, 지원자 중 절반은 말 그대로 ‘잘못 왔다’. 그냥 솔루션 개발 쯤으로 알고 왔는데, 열어보니 이건 이상하다 싶었겠지. 나머지 반은 본인 실력을 다 못 보여준다. 왜냐하면 전혀 새로운 분야에서 요구되는 능력들이 자기가 일궈온 것과 좀 다르니까 거부감이 드는 것이다. 그래서 나도, 그들도 같이 지친다.

어느 대기업 연구원 관리직의 댓글을 봤다. 오히려 박사/포닥 후 입사한 친구들이 너무 협소한 시각으로 보고서를 작성하기 때문에 설득력이 떨어진다는 것이다. 자기 분야에서만 논거를 찾아서 주장하거나, 다른 분야 사람이 오펜스라도 할라 치면 ‘당신이 뭘 알아’ 라는 스탠스를 취한 경우를 많이 봤단다. 학교에서는 비즈니스나 의사소통을 가르쳐주지 않기 때문이라고 하면서. 차라리 회사에서 신나게 구르던 동일 경력의 친구들이 더 뛰어난 경우를 많이 봐왔다고 한다.

이 이야기를 왜 꺼냈을까. 박사과정을 마친 사람들을, 하이 커리어를 쌓으신 많은 경력 개발자를 폄훼하기 위해서인가. 아니다. 그냥, 좋은 능력을 가지신 분들이 보인 부적응 현상들이 안타까워서 그랬다. 이제는 경력과 신입을 동일선상에 놓고 보고 있다. 기술 질문도 차이가 거의 없어졌다. 다만 한 가지, 소통하는 능력이 있는지를 본다. 달리 말하면 배우고자 하는 열의가 있는지 반드시 보고 다음 면접으로 올린다.

나는 꼬리에 꼬리를 무는 질문을 좋아한다. 그래야 이 사람의 대응 방식을 볼 수 있다. 꼬리를 물렸을 때 대개는 따가워한다. 싫은 거다. 그래도 답하고 되물어봐야 한다. 힌트를 달라고 해도 좋다. 시험이 아니라 면접인데, 좀 물어보면 어떤가. 나와 논쟁을 한 지원자도 있었다. 내용이 좀 틀려도 괜찮았다. 둘 모두 기술면접을 통과했다.

비즈니스는, 의사소통은 학교에서 가르쳐주지 않는다. 그런데… 경력은 이미 경험한 것들이다. 경력을 뽑는 가장 큰 이유는, 적응력이 신입보다 좋을 거라 기대하기 때문이다. 그것이 기술적이건 의사소통 능력이건 간에 말이다. 둘 다 못하면, 지금처럼 동일 선상에 세울 수 밖에 없을 것이다.

최소한  자신이 가진 아집 정도는 벗어주면 좋겠다. 그래야 저런 소리 안 듣고 귀한 평가를 받을 것이다.

리더의 1원칙

메모로 남긴다.

  • 사람은 모두 다르다. 아주 많이.
  • 각자의 장점이 드러나도록 경험하게 해주고 발전하게 하라. 그리고, 장점과 그 성과를 열심히 칭찬해줘라.
  • 무언가를 잘하는 사람은 결국 그걸 좋아하게 되어 있다.
  • 무언가를 잘하고 좋아하게 되면, 자신의 자존감이 올라간다.
  • 자존감이 올라간 후엔, 자존감을 지키지 위해서 알아서 움직인다.

이 말을 관통하는 TODO 는 딱 하나. 장점이 드러나도록 밀어주고, 칭찬해줘라.

철칙처럼 지켜야 한다는 생각이 들었다. 여기에 내 생각을 덧붙인다.

  • 뭘 잘하는지 찾는 건 굉장히 어렵다. 잘 한다고 생각했는데 통수맞을 확률이 생각보다 높다.
  • 잘 하는데 하기 싫어하는 경우에 대한 과정도 중요하다.
  • 일이란게 늘 그렇듯, 그 사람이 잘 하는 것만 시킬 수 없다. 이에 대한 과정 역시 중요하다.
  • 사람이 늘 그렇듯, 단점이 크게 보인다. 못 본 척 하려고 노력하는 것도 쉽지 않을 정도로.

결론은, 이 철칙을 쉽게 지킬 수 없지만 지키기 위해 노력해야 된다는 것.
참고로, 이 원칙은 육아에도 적용된다고 한다. 덧붙인 내 생각도 육아에 적용되겠단 생각을 해 본다.