🔎 데보션 영 SK의 전문가님 인터뷰 - 개발자를 준비하는 사람들을 위한 전문가님의 견해

< 데보션 영 SK의 전문가님 인터뷰 >

- 개발자를 준비하는 사람들을 위한 전문가님의 견해

 

 

데보션 영 활동을 하며 SK의 전문가님과 인터뷰를 하는 좋은 기회가 생겼습니다!!

저는 현업 개발자 분과의 인터뷰가 신뢰 있고 정말 도움이 되는 귀한 정보라고 생각하기에 이를 공유하고자 합니다.

 

제가 인터뷰 한 전문가님은 SK에서 쿠버네티스 전문가로 활동하면서

쿠버네티스 기반의 플랫폼을 만드는 일을 하고 계신 '안승규' 님입니다.

 

안승규님은 DEVOCEAN 내에서도 활동을 아주 열심히 하시고 계십니다!

데보션 영 발대식에서 뵈었었는데 성격도 아주 쾌활하셨어요!

안승규님은 DEVOCEAN 사이트(SK의 기술블로그)의 전문가님 탭에서도 보실 수 있으시니

더 궁금하신 분들은 아래 링크에 방문해 주세요.😊

https://devocean.sk.com/experts/view.do?ID=ahnsk&page=

 

현재 컴퓨터학부 3학년을 다니고 있는 대학생인 저의 입장에서 궁금한 질문을 몇 가지 준비해 보았는데

모두 잘 읽어보시고 조금이라도 도움이 되셨으면 좋겠습니다!

 

---

 

< 질문 및 답변 >

 

🔎 IT 분야는 워낙 빨리 바뀌고 회사에서 쓰는 기술들도 계속해서 변할 텐데 개발 트렌드를 어떻게 따라가시는지, 
새로운 기술에 대한 정보는 어떤 경로를 통해 얻으시는지?

→ 우선 특정 기술에 대해 빨리 배우는 방법은 프로젝트입니다. 그중에서도 이미 선배가 끌어주고 있는 곳에 후배로 들어가서 배우는 것이 가장 빠릅니다. 무엇이든 최종 목적은 실 서비스를 만들려고 하는 것이기 때문에 내가 아무리 혼자 해봤자 따라가지 못합니다. 시간이 오래 걸리기도 하고요. 그렇지만 선배가 없다면 자기가 프로젝트를 하면서 서비스를 만들어 보는 것을 추천합니다. 책을 보고 따라 해보며 공부하시는 분들이 많은데 현장에 가면 안 쓰는 것들일 경우가 많습니다. 자신이 서비스를 만들어 보는 게 개발이 제일 빠릅니다.

 

트렌드를 따라가는 것은 사실 자신이 하다 보면 부족한 것들이 나옵니다. 그전에 기본적으로 배워야 하는 것들이 있는데

1. 프로그래밍 언어 - 언어 하나는 기본적으로 배워야 합니다.

2. 리눅스와 관련된 지식 - 프로세스 보는 법, 메모리, CPU, 리눅스 네트워킹 보는 법 등은 뭐든지에 기본이 됩니다.

+ 스프링 부트, 데이터베이스, 깃, 디자인 패턴 ... 점점 배울 것이 많이 생길 것입니다.

저는 이러한 과정이 5년 정도 걸렸습니다. 이 기본적인 것들을 배우는 과정이 지나면 개발에 자신감이 생기고 해당 부분에 대해 마인드맵이 생깁니다. 이후에는 다른 분야로 넘어가도 더 빨리해 볼 수 있게 됩니다. 저는 앱 개발을 5년 동안 하다가 시스템 엔지니어링 분야로 넘어가 인프라를 구축해 보다가 이후에 컨테이너가 나왔습니다. 그러다 보니 자연스럽게 쿠버네티스까지 자연스럽게 알게 되어 현재까지 쿠버네티스를 하고 있습니다. 

 

제일 중요한 것은 커뮤니티라고 생각합니다. 커뮤니티를 통해 취업도 잘되고 아는 사람도 많이 만납니다. 그렇지만 물론 먼저 실력이 있어야 하겠죠? 글로벌 커뮤니티에 참여하면서 트렌드를 빨리 알게 되기도 했어요.

 

새로운 트렌드는 해외 콘퍼런스가 제일 빠릅니다. 그다음이 국내 콘퍼런스입니다. 이것을 알아들으려면 영어가 되어야 합니다. 따라서 컨퍼런스 내용을 알아들을 만큼은 영어를 알아야 합니다. 이 기술이 뜰 것이다/안 뜰 것이다는 운인 것 같아요.

 

 

 

🔎 중간에 쿠버네티스쪽으로 직무를 바꾸셨다고 하셨는데 그렇게 직무를 바꾸려면 이직을 꼭 해야 하는 건가요?

→ 한 분야를 거의 10년 정도 오랫동안 하면 이미 아는 것을 반복해서 하는 것이기 때문에 평생 이것만 할 수 없다는 생각이 드는 순간이 옵니다. 정체와 한계를 느끼는 것이죠. 저는 애플리케이션 개발을 하다가 그러한 생각이 들었는데 마침 회사에서 새로운 tf가 구성이 되어 지원해서 맨땅에 헤딩하는 식으로 새로운 것을 만들어보았습니다. 반드시 회사를 그만둘 필요는 없으나 1년 정도 가지고 다른 분야를 한다는 것은 말이 안 되는 것 같습니다.

 

 

 

🔎 자신 있는 프로그래밍 언어가 하나 있어야 한다고 말씀하셨는데 해당 언어에 자신이 있다는 것이 백준 사이트에 올라와 있는 문제들과 같이 알고리즘 문제들을 잘 푸는 것을 말하는 건가요?

→ 앱을 개발할 때는 유지 보수할 수 있게 개발을 해야 합니다. 그러려면 구조화를 잘 지켜야 하고 이는 디자인 패턴과 관련 있습니다. if 문이 꼬여있는 등의 코드는 유지 보수가 어려운데 이런 것들을 잘 만들어보자는 개념입니다. 알고리즘과는 조금 다릅니다. 알고리즘은 대부분 미리 구현되어 있는 것이 많습니다. 알고리즘은 문제를 해결하는 능력을 보려고 보는 경우가 많아 기본적인 것만 알아도 됩니다. 코드를 잘 짜는 것은 아키텍처, 디자인 패턴들을 보고 구조를 잘 짜는 것을 말하는 것 같아요. 

 

 

 

🔎 전문가님이 처음에 직무를 선택하시게 된 계기가 있으실까요? 
개발자의 입장에서 좋아하는 일과 전망이 좋은 일 중에서 무엇이 더 우선시 되어야 할지 궁금합니다.

→ 저는 사실 전공자는 아닙니다. 입사를 해서 IT업계로 간 케이스인데 저는 그렇기 때문에 거의 밤 11시까지 몇 년 동안 했습니다. 계속 공부를 해도 끊임이 없었는데 5년 정도 공부해 보니까 적성에 맞구나 알게 되었어요. 적성에 맞는다는 것은 내가 이 일을 주말, 여가 시간에도 할 수 있다는 것 같아요. 그러다 보니 내가 이 분야에서 잘나가고 싶은 욕심이 생겼어요.

 

좋아하는 일과 전망이 좋은 일 중에 선택하라고 하면 저는 내가 재밌는 일 찾아서 재밌게 하면 된다는 생각입니다. 잘하는 것도 하다 보면 재미가 없으면 그만두게 됩니다. IT업계에서는 재밌지 않으면 개발로 성공하는 것보다는 관리자로 성공해야 한다고 생각해요. '왜 항상 새로운 게 많은 거야?'라는 생각이 들면 개발을 하시다가 관련 스펙을 쌓아서 관리자의 길로 가는 것이 나아 보여요. 이것도 싫다면 자신이 좋아하는 일로 바꾸는 것이 맞는다고 생각해요. 물론 돈은 모르겠어요. 하하

 

 

 

🔎 타 부서와의 협업 과정에서 문제가 발생한 경우가 있다면 어떻게 대응하셨는지?

→ 기본적으로 회사의 문화마다 다르긴 합니다. 대기업들은 대부분 협업이 쉽지는 않은 것 같아요. 부서 별로 각자 해야 할 일이 있는데 한쪽 부서에서 그 일을 다 마치지 못하는 경우가 있을 거예요. 그런 경우에는 사실 싸우는 것은 소용이 없어요. '저기가 안 도와줘서 일을 할 수 없다. 안된다'라는 말은 할 필요가 없어요. 차라리 혼나는 게 낫습니다. 그렇게 얘기해 봤자 결국엔 협업이 안 된 것이거든요. 결국 내 일을 못한 셈이고 내 손해예요. 싸우면 괜히 사이만 나빠지는 것 같아요. 그냥 본인이 최대한 노력은 하되 핑계는 대지 않는 게 제일 나아 보여요.

 

 

---

 

 

데보션 사이트에는 다른 전문가분들의 인터뷰도 수시로 올라오고 있습니다. 

인터뷰뿐만 아니라 최신 기술, 응용 분야, 오픈소스 등 개발의 모든 분야에서 폭넓은 상호작용이 이루어지고 있습니다.

저도 데보션을 통해 항상 많은 정보와 지식을 얻어 가고 있어요.😊

앱도 출시되었으니 모두 이용해 보셨으면 좋겠습니다!

 

개발자는 다 이러한 커뮤니티 내의 상호작용으로 성장하는 것 아니겠습니까!? 

함께 더 나은 개발자로 나아가길 바라겠습니다!

 

DEVOCEAN (SK 기술블로그) 사이트 링크 >>  https://devocean.sk.com/

 

 

 

 

 

---

 

<인터뷰 소감>

 

우선 고등학교 이후로 직접 현업자분에게 궁금한 것을 질문하는 인터뷰 자체가 오랜만이라 소중하고 재미있는 경험이었던 것 같다. 질문지를 작성하면서 고민하는 과정도 꽤 즐거웠다. 인터뷰 내용도 현재 진로를 고민하고 있는 나에게 많은 도움이 되었다. 전문가님이 몇 년 동안 쌓으신 경험을 우리에게 잘 전달해 주시며 조언도 해주신 것 같다. 앞으로도 기회가 된다면 가끔 인터뷰를 진행해 보고 싶다는 생각이 들었다. 이 글을 작성하기 위해 기존 데보션 웹 사이트에 있는 전문가님 인터뷰를 보며 더 효과적으로 인터뷰를 진행하는 방법에 대해서 알게 된 것 같다. 질문을 더 작게 쪼개고 세분화하여 준비하는 것이 나을 것 같다는 생각이 들었다.