DEVOCEAN

데보션영 1기로 활동하고 있는 저희 Dev-dive팀(구민정, 김현지, 박민아, 채상엽)은 지난 11월 9일 서울 워커힐 호텔에서 개최된 SK Tech Summit에 참여하였습니다.

이 글에서는 행사 이후, 워커힐 호텔 내에 위치한 공유 오피스에서 만나뵌 SKT 클라우드 기술 지원팀의 배기도 마스터님과의 인터뷰를 남겨보려 합니다😁

Q: 안녕하세요 기도님! 간단한 자기 소개와 더불어 현재 하시는 업무 소개 간략하게 부탁드립니다! 어떤 부서에서 어떤 일을 하고 계신가요?

네. 저는 개발자 배기도라고 하고요, 현재 SKT의 클라우드 기술 지원 팀에서 일하고 있습니다.

다들 아시다시피 최근 많은 소프트웨어들이 클라우드 시스템으로 전환하고 있잖아요?

클라우드는 굉장히 편리한 기술이지만 기존 체계가 전통적으로 사용하던 한 기조에서 아예 다른 방식으로 바꾼다는 게 말처럼 쉬운 일은 아니에요.

그 과정을 자세히 보면 중간에 소프트웨어 아키텍처 설계나 비기능 테스트, 그러니까 성능, 가용성, 확장성 같은 성질들을 확인하는 세세한 작업들도 중요하고요.

요즘은 대부분 그런 일들을 하고 있다고 보시면 되겠네요. 물론 저도 아직 많이 배우고 있는 상태예요.

Q: 그럼 본격적으로 시작하기에 앞서 간단한 아이스 브레이킹 질문으로 시작해볼까해요. 머릿속에 떠오르는 대로 편하게 대답해주시면 됩니다! 그럼 제일 먼저, 기도 님께서는 언제부터 프로그래밍에 관심이 있으셨나요?

그건… 아주 먼 옛날까지 거슬러 올라가야겠네요. 제가 초등학생 때 일인데, 부모님이 컴퓨터를 한 대 사주셨어요.

시대를 생각해보면 굉장히 비쌌겠죠, 아마도? 물론 전 그걸로 매일 같이 게임만 했던 거 같지만요.

그래도 그런 경험이 자연스럽게 프로그래밍에 대한 관심으로 이어졌던 것 같아요. 대학 진학도 컴퓨터 계열이었고요.

그런데 대학교 공부는, 여러분도 아시겠지만 대부분 이론 위주잖아요. 학부생 신분으로는 어디서 실습이나 프로젝트를 직접 진행해 볼 기회가 적었어요.

그렇게 이론은 무척 빠삭한데 이게 도대체 어디에 쓰이는 건 지를 모르는 상태가 된 거죠.

본격적으로 실무 경험이 쌓인 건 운 좋게 선배 회사에 입사하게 된 이후입니다.

그 이후로도 일 하면서 정말 다양한 프로젝트를 많이 진행해봤고 또 그런 경험을 통해 제 자신도 꾸준히 성장할 수 있었던거 같아요.

그리고 저는 원래도 프로그램 개발이나 소프트웨어 공학 같은 공부에 상당히 관심이 많았거든요.

현업 SI를 이어 나가면서도 그런 이론적인 바탕은 계속해서 업데이트 해나가는 것이 중요하다고 생각되어서 나름 시간을 내서 공부도 많이 했고요.

그러다 보니 놓치고 싶지 않은 굉장한 기회들이 찾아왔을 때 놓치지 않고 잡을 수 있었던 것 같네요.

Q: IT는 진짜 끝없이 공부해야 하는 분야인 것 같아요. 개발자는 평생 학생이다 라는 말도 있잖아요. 그런데! 데보션 사이트를 보면 기도 님 프로필 하단 ‘전문 분야’ 태그 카테고리 양이 정말 어마어마합니다. 아마 마스터 분들 중에서도 손에 꼽힐 정도로 많은 것 같은데, 어쩌다 그렇게 많은 기술을 섭렵하게 되신 건가요? 기도 님만의 특별한 공부 방법이라도 있는 건가요?

우선 제가 막 일을 시작한 시점에는 업계가 지금 같지 않았어요. 지금은 백엔드, 프론드엔드, 데이터… 이런 영역들이 전부 분리되어 있잖아요.

근데 옛날에는 안 그랬어요. 한 사람이 프론트엔드, 백엔드, html, 자바 스크립트 같은 다양한 영역을 전부 커버했어야 했죠. 요즘은 그걸 풀스택 개발자라고 따로 부르죠?

그 땐 거의 전부가 풀스택 개발자였다고 보면 돼요. 그랬던 분위기도 제 성장 배경에 한 몫 했던 것 같고요.

그런데 가장 중요한 포인트는 이거인 것 같아요. 여러분들도 차후 사회에 진출하시면 회사 업무를 하게 되겠죠?

그 때 예를 들어 백엔드 업무를 한다고 치면, 그 백엔드 업무에 능통하게 되겠죠. 이 알고리즘이 이 레벨에서는 어떻게 동작하고 저 레벨에서는 어떻게 동작하는지 손에 익게 될 거예요.

그 상태에서 프론드엔드 업무를 한다고 생각해보세요. 물론 다른 분야의 개발 업무기는 하지만 결국은 다 같은 프로그래밍이잖아요. 베이스 기술은 서로 비슷한 것들이 많아요.

프론트 엔드가 REST API를 호출해서 sub side를 호출할 때 그걸 제공해주는 건 결국 백엔드예요.

그 때 connecton time out이라거나 read time out 같은 예외 상황들을 우리는 전부 고민해야 하고요.

그런데 이 기술들에 대해 제대로 알지 못하는 개발자라면 그런 상호 보완적 위기 상황에 맞닥뜨렸을 때 제대로 된 대처를 못하겠죠.

그런 위험 대비가 전혀 안 되어 있는 프로젝트도 실제로는 상당히 많고요. 요청해서 서버가 응답이 없으면 하루 종일 기다리는 것 말고는 대책이 없는 사이트들 본 적 있으시죠?

이런 상황에 처하지 않기 위해서는 다양한 분야의 근본적인 구조를 파악하는 게 큰 도움이 되거든요.

그렇게 새로운 업무를 만날 때마다 그에 도움이 될 만한 분야들을 하나하나 집중해서 공부하다 보니 관심 분야도 다양하게 생긴 것 같아요.

Q: 그럼 이렇게 많은 관심 분야 중 가장 자신 있고 좋아하는 분야를 꼽으라면?

그렇게 물으신다면 저는 DB라고 답하겠습니다. 제가 한창 개발에 막 입문했을 시절 대한민국에는 DB를 컨설팅하는 메이저 회사가 딱 두 개 밖에 없었어요.

엔코아하고 비투엔. 그러던 시절에 이제 제가 어떤 si 프로젝트에 합류해 있었는데, 함께 일하던 DB 파트 분이 제 선배들을 불러서 무척 날카로운 질문들을 던지시는 거예요.

이 부분의 DB는 어떻게 구성되어 있냐, 드라이빙 테이블은 어떻게 디자인했느냐, 어떤 동작으로 테이블에서 쿼리를 가져오느냐 하는 자세한 사항들을 물으시는데 선배들은 대답을 못하고.

전 옆에서 들으면서 이게 그렇게까지 대단한 기술인가? 하고 생각했던 기억이 나네요. 그걸 계기로 DB에 본격적으로 관심을 가지게 됐어요.

여러분도 아시는 지 모르겠는데 「대용량 데이터베이스 솔루션」이라는 책이 있거든요.

이 책을 제가 si하면서 거의 3번은 읽은 것 같네요. DB 계의 바이블이라고 불리는 책이니까 관심 있으시면 한 번 읽어보세요.

최근에는 MSA가 도입되면서 DB에 대한 관심이 옛날만큼 열광적이지는 않은 것 같아요.

하지만 아무리 MSA가 상용화되고 클라우드 기술이 일반화된다고 하더라도 결국은 DB 튜닝이 되어야 비용도 아끼고 성능도 개선할 수 있거든요.

그런 면에서 DB는 지금 시대에도 여전히 중요한 파트를 맡고 있다고 할 수 있죠.

Q: 쭉 듣다 보니까 기도 님은 지금까지 굉장히 다양한 프로젝트를 진행해보신 것 같은데요. 혹시 그 중에서 가장 기억에 남는 프로젝트가 있으실까요?

아, 굉장히 많은데요. 그중에서도 제일 먼저 떠오른 프로젝트를 고르라면 생각나는 프로젝트가 하나 있긴 해요.

타 회사 이직 전에 화장품 쇼핑물 리뉴얼 개발 리더로 참여한 경험이 있는데요.

제가 아무리 뛰어난 개발자라고 하더라도 프로젝트 개발이란 걸 저 혼자 할 수는 없잖아요. 근데 그 때 했던 팀 리딩 경험이 아직도 생생해요. 생각보다 너무 힘들었거든요.

함께 일하셨던 크루 분들 중 최장 경력이 2년, 나머지 대부분은 1년 미만이신 주니어 분들이라서 진행 기간 내내 교육과 업무를 병행해야 했어요.

평일 주말 구분도 없이 일했고, 마지막 즈음 가서는 도저히 못 하겠다고 도망치시는 분들 잡으러 다니고. 이 때 원형 탈모도 왔다니까요.

그런데 매니지먼트 측면에서는 정말 많은 걸 배웠다고 생각해요.

기술 리더는 어떤 방식으로 일하는 게 좋은지, 어떤 역량이 필요한지. 알고 있는 기술이 많다고 해서 좋은 리더가 되는 건 아니라는 것도 배웠죠.

이 때의 고민과 경험이 없었다면 아마도 지금 같은 사람이 되지 못했을 거예요.

Q: 원형 탈모는 완치되셨나요?

프로젝트가 끝나니까 다행히 완치되었습니다.(웃음)

Q: 축하드립니다. 아. 그리고 아까 잠시 트렌드를 따라가기 위해 계속해서 공부를 하고 계시다고 말씀 하셨는데, 원어 강좌를 활용하신다고도 들었어요. 저희도 개발하다보면 주요 자료들이나 사이트가 전부 영어로 되어있어서 영어 역량의 필요성을 느끼곤 하는데요. 이렇게 개발자를 꿈꾸는 사람들과 현업 개발자들에게 추천하는 영어 공부 방식이 있을까요?

사실 전 영어를 잘 못 해요. 그냥 듣는 수준인거죠. 지금의 아내 분이 예전에 어린이 영어 강사셨거든요.

그 분이 추천해주신 게 애니메이션을 잘게 조각 내서 장면 단위로 따라 해보라는 거였어요. 그걸 열심히 따라했죠. 그랬더니 청해에 대한 울렁증이 좀 사라진 거 같아요.

아무래도 이런 울렁증을 없애는 것부터가 공부의 시작인 것 같아요. 옛날에는 모니터로 영어 구문만 봐도 속이 막 울렁거렸거든요.

그런데 이제 그걸 끝까지 버티고 보니까 점점 영어가 늘기 시작했죠. 그리고 또 저는 개발 관련 업무로 영어를 많이 쓰게 된 거잖아요?

그렇게 실제 업무에 써야하는 기술들을 찾거나, 기사를 찾고 나서는 꼭 하루에 한 개씩이라도 번역에서 개인 노트에 적었거든요.

그렇게 안 되는 영어로 열심히 독해하고, 쌓고, 쌓고, 또 쌓다 보니 지금 여기까지 와 있네요. 이런 노력이 나름대로 영어를 잘할 수 있게 된 비결이 아닐까 싶습니다.

Q: 요즘 MSA가 핫한 트렌드로 떠올라 있는데**, skt 서비스에서 msa가 적용된 사례가 있을까요?**

되게 많기는 하지만, 예를 들어보면 티맵 택시 리뉴얼을 하는데 마이크로 서비스 아키텍쳐와 애자일 방법론 두 가지를 합쳐서 일을 했었어요.

그 전에는 공통 모듈팀, 백엔드 팀, 프론트엔드 팀 이렇게 나뉘어져 있었습니다.

그렇게 일을 하면서 아키텍쳐 리뷰를 들으러 갔었는데, 전체를 설계하고 운영하시는 분께서 이 중간의 연결 공간이 블랙홀이라고 얘기를 하시더라구요.

이건 아니라는 생각이 들었고, 기존 소프트웨어 분석을 진행한 뒤에 마이크로 서비스 아키텍쳐를 쪼개나갔어요.

Q: 마이크로 서비스 아키텍쳐는 구체적으로 어떤 과정으로 나뉘어졌나요?

회원, 배치, 어드민 이렇게 대략적으로 3개 정도만 나누었어요.

그 이유는 최근 트렌드가 MSA라고 해서, 모든 프로젝트를 msa로 나누려고 한다면 큰일 날 수 있기 때문이에요.

그 이유는 모든 서비스 아키텍쳐는 비즈니스 로직을 담기 때문인데, 예를 들어 어떤 팀이 업무를 할 때 외부에서 요청이 들어오면, 해당 팀에서 그 업무를 끝내게 돼요.

그런데 이 팀의 업무 자체를 여러개의 마이크로 서비스로 나누어버리게 되면,

이 팀 내에서도 리소스가 분산되어버리는 것이기 때문에 기존 모놀리틱 보다 훨씬 더 장애가 나기 쉬운 상황이 되기 때문이죠.

그래서 커뮤니케이션을 병행하며 msa를 진행하는게 가장 현명한 방법이라고 생각해요.

처음에 운영이 가능한 정도에서 서비스를 나누고, 그 다음에 사업이 커지면 조금씩 더 나누고 하는 방식으로 진행하는게 좋다고 생각해요.

Q: 사용하셨던 기술 중에서 MyBatis가 자주 등장하는데, 요즘 많이 쓰인다고 하는 JPA는 보이지 않는것 같아요. SKT에서 JPA는 채택하지 않고 있는건지 궁금합니다.

최근에는 JPA를 사용하고 있어요. 조직에 따라서 JPA를 쓰는 곳도 있고, 안쓰는 곳도 있어요. 조직 구성원들의 기술 수준과 성향에 따라 결정되기 때문이에요.

최신 기술이 물론 좋기는 하지만, 모든 조직원들이 최신 기술을 따라가는 것은 조금 어려운 부분이 있기도 해요.

만약 과거에 사용하던 기술이 문제가 있다면 최신 기술로 변경하는 것이 좋지만, 그런것이 아니라면 팀의 역량을 고려하여 기술을 선정하는 것이 중요하다고 생각해요.

실제로 네이버 쇼핑에서 재직하던 시절에 JPA가 막 떠오르고 있었는데,

상품조직에선 JPA를 사용하고 주문 결제 조직에서는 JPA에 익숙하지 않았기 때문에, MyBatis를 채택해서 사용했었어요.

Q: 성능테스트는 어떻게 진행되나요?

먼저 사용자가 제일 먼저 들어오는 메인 페이지라던가, 중요도가 높은 로그인이나 상품 결제 같은 부분들을 중요도에 따라 예상 TPS를 만들어요.

이렇게 구성을 해 놓은 상태에서 부하 생성기를 통해서 강제로 부하를 걸어보게 되면, Redis같은 부분에서 병목 구간이 생길 수도 있고,

어떤 기능에서 문제가 생기는지 파악할 수 있게 되는거죠.

그래서 이런 부분들을 파악하고 해결하는게 성능테스트가 진행되는 과정이라고 할 수 있어요.

Q: 성능테스트를 통해 성능을 개선한 사례가 있을까요?

며칠 전 정말 최근에 있었어요. Redis와 관련해서 병목 구간이 있었는데, 보통 예전에는 사용자 세션 관리를 Http 세션에서 저장을 했었죠.

그런데 MSA가 되면서, 한 군데에서 세션을 저장하면 다른 곳에서 이 세션 정보를 사용하기 위해서는 매번 조회하고 넣어주는 과정을 반복하게 되어버렸어요.

또 이 과정에서 세션 정보가 바뀌면 다 틀어지는 이슈가 발생할 가능성이 생긴거죠.

캐시에 담아 두었다가 사용하도록 해서 db부하를 줄이기 위해 Redis를 사용하고 있어요.

이번에 발생했던 이슈는 SKT의 사용자 정보는 정말 어마어마하게 많은데, 이 사용자들의 세션을 모두 Redis에 넣는다고 하면,

매번 Rest Api 호출할 때마다 Redis를 거치게 되면, 결국은 Redis가 죽게 돼요.

Redis가 빠르다고들 알고 있지만, 생각보다 되게 느리기 때문이에요.

그래서 이걸 해결하기 위해서, 로컬 캐시라는걸 사용해서 로컬을 먼저 조회하고 로컬에 데이터가 없다면 DB를 조회하도록 해서 성능을 개선할 수 있었어요.

나름 성능이 많이 개선되어서 뿌듯함을 느끼고 있습니다.(웃음)

Q: 빅데이터 기반 기술에 관심이 많으신걸로 알고 있는데, 조금 추상적일수는 있겠지만 빅데이터의 미래가 어떻게 될 것 같은지 말씀해실 수 있을까요?

사실 빅데이터는 미래라고 하기보다는 이미 시작이 되었고, 인프라적인 빅데이터를 모으는 기술은 몇 년 전부터 대부분 회사들이 다 가지고 있게 되었어요.

그래서 빅데이터를 수집하는 기술과 이 빅데이터를 가지고 분석하는 데이터 아날리시스트들이 최근 높은 연봉을 받고 있죠.

개인적인 생각이지만, 이걸 이제 서비스로 연결하고 AI로 연결하고

이런 작업들을 통해서 더 큰 세계관을 만들 수 있는 사람이 앞으로 미래에 크게 성공할 수 있는 사람이 되지 않을까라고 생각해요.

Q: 많은 회사들 중에서 SKT라는 회사를 선택하시게 된 이유는 무엇인가요? (혹시 연봉..?)

skt가 연봉이 높긴 하지만, IT업계 탑은 아니에요(웃음) 개발만 해오다가 네이버에 처음 갔을 때, 전체 아키텍처를 사람들한테 설명하고 그 아키텍처를 그리는 작업을 많이 연습했어요.

보다 글로벌 기업인 라인으로 전출을 가서는 외국 사람들과 업무를 해야 했는데 데이터 구조같은 시스템에 차이가 있어서 이걸 어떻게 접목할 수 있을지 고민을 많이 했던 것 같아요.

다양한 프로젝트가 우리 쪽으로 들어올 때, 공통화해서 추상화시켜서 업무를 할 수 있을까, 하는 아키텍처에 대한 고민을 많이 한 시기였어요.

쿠팡에 가서는 애자일과 msa 아키텍쳐를 제대로 배웠다고 생각해요. 쿠팡은 정말 작은 조직들로 다 쪼개져 있어요.

예를 들어서 상품 조직과 판매자 조직이 있고 전시 조직이 있으면, 각 조직마다 기획자(PO)들이 따로 있고,

이 PO들이 각자 자기의 니즈 그리고 고객에 대한 피드백 받은 것 자기 조직에 맞게 업무들을 가져오면 개발이 빨리 이루어져요.

쿠팡이 이만큼 발전된 건 애자일 조직으로 구성이 됐고, msa 아키텍처를 적절하게 잘 이용하면서 많아진 트래픽의 경우 클라우드로 잘 넘겼기 때문이라고 생각해요.

회사를 다니다보면 나를 증명해야 하는 시기가 오는데, 그간 경험하며 쌓아온 기술들을 잘 발휘해서 리더에게 가장 높은 평가를 받았었어요.

그 리더를 따라 SKT에 왔고 내가 제일 잘하는 것을 여기서 제일 잘할 수 있게 됐구나, 하는 생각이 들어요.

또 제 취미가 공부하는건데, SKT라는 회사는 새로운 것을 시도할 때 아낌없는 지원을 해주어요. 취미를 지원해주는 회사라니, 정말 좋은 회사죠.(웃음)

Q: SK에는 ‘스터디 메이트’ 라는 사내 스터디 프로그램이 있던데, 카프카 관련 호스트로 활동하시면서 어떤 점이 도움이 되었나요?

카프카는 사실 예전에는 사용자로만 썼었어요.

그러다 메시징 시스템이 우리가 공통 유틸을 만드는 조직인데 카프카도 공통 유틸로 만들 수 있는 부분이 당연히 있을 테니

이걸 스터디 해볼까해서 올해 초에 개인적으로 공부를 하게 됐어요.

쭉 해오다가 스터디메이트라는 걸 하게 됐고, 조직 후배들이 각종 프로젝트에 들어가서 기술적으로 지원을 해줘야 되는데 카프카 이슈가 생기게 됐어요.

예를 들어 프로듀싱을 엄청 빠르게 했는데 이걸 컨슈밍이 빠르게 못하면 카프카의 데이터가 쌓이게 되고, 쌓인 데이터를 정상적으로 해결을 해줘야 하는데 이슈가 생긴거죠.

이거를 어떻게 해결해야 되는지를 모르고 있던 중에 스터디 메이트라는 게 있으니까 카프카를 스터디하자해서 시작했고,

스터디 메이트를 만드니 주변에 있는 다른 조직에 있는 사람들 다 들어와서 함께 공부를 하게 됐어요.

스터디라는 건 그런 것 같아요. 현재 하고 있는 사업들은 기술의 연장선이죠. 그걸 위해 별도로 공부하는 게 아니라,

연장선으로 공부하다 보면 어느 순간 이렇게 기회가 오고 남들한테 강의하면서는 내가 더 많이 배우기도 하는 것 같아요.

Q: 업무 효율이나 몰입도를 높이는 노하우가 있을까요?

“내가 이 일을 왜 하는가” 그걸 제일 먼저 생각하곤 해요. 얼마 전에도 카프카를 쓴다고 했던 조직이 있었는데 어떻게 적용을 해야 할지 고민을 하고 계셨어요.

한 몇 주를 고민하고 계시길래 회의 때 그 얘기를 했어요.

카프카를 왜 쓰려고 하시는지, 목적이 분명히 있을 거니까 쓰시려고 할 거고 아니면 누가 가이드를 해줘서 쓰고자 할 건데 당신이 최종적으로 그리는 그림이 무엇인지.

그랬더니 앞으로 비즈니스 로직에 트래픽이 많아질 걸 대비하기 위함이라고 답하셨어요.

그렇다면 목적은 성능이니 카프카의 구조를 어떤 식으로 준비를 하셔야 한다고 가이드를 드렸어요.

그렇게 다시 고민을 하시고 지금은 어느 정도 의미있는 프로토 타입을 만드시게 되었어요.

그러니까 업무 효율이나 몰입도는 내가 왜 일을 해야 되는가, 우리가 왜 이런 기술을 적용해야 되는가가 가장 중요한 것 같아요.

그 답이 나와야 집중이 되고 어떻게 그림이 그려질지 미래가 보이는데, 이런 과정없이 진행을 하면 결국 우왕좌왕하다가 끝나게 되는거죠.

결국엔 Why가 중요한 것 같아요.

Q: 개발자라는 직업의 가장 큰 매력은 무엇인가요?

정년이 없다는 것이 장점인 것 같아요.

하지만 배워야할 기술이 계속 나오고, 이제 나보다 후배들이 많은 것을 알고 있기 때문에,

나이 먹어서까지 개발일을 하기 위해서는 공부를 계속 해야한다는 단점이 함께 수반되는 것 같아요.

Q: 본인만의 강점은 무엇이라고 생각하시나요?

국가 프로젝트도 경험해보고 많은 IT 회사(naver, coupang, skt)들을 거치다 보니 일하는 노하우가 많이 쌓였어요.

다양한 문제를 마주해봤고 해결해봤기 때문에, 문제 해결방법이 다양한 것이 나의 강점인 것 같아요. 또 ~~(이빨을 잘까고)~~언변이 화려하고,

사회성이 좋고 공부가 취미인게 강점이라고 생각해요.

Q: 학생들에게 이런 경험은 꼭 해봐라! 하는게 있다면 무엇이 있을까요?

팀원들과 많은 토론을 하면서 프로젝트를 진행했으면 좋겠어요. 혼자서만 뚝딱 뚝딱 프로젝트를 쭉 해버리면 나중에 큰 문제로 돌아오게 돼요.

같이 토론하면서 프로젝트를 진행해보는 경험을 겪어보길 바래요.

Q: 기도님의 최종목표가 있다면 무엇인가요?

65세까지 SKT에 남아 있기. SKT는 배우고 싶은게 있다면 적극적으로 지원해줘서 정말 좋은 것 같아요.

Q: 기도님께 데보션이란?

단비같아요. 데보션이 생기기 전 T hub 커뮤니티가 있었는데, Tmap택시를 개발하고 나서 매너리즘에 빠져 공부가 제미없던 시절,

제가 가진 기술들을 올려 공유하니 상품권같은 것을 주었어요.

상품권을 주니 다른 것도 올려보고 싶어 다시 공부를 시작하게 되었어요.

알고 있는 것을 그냥 적어보기 보다는 조금씩 퀄리티를 올려서 글을 남기게 되었고 글을 남기고 받은 상품권으로 책을 사고 책으로 공부를 했어요.

T hub는 지루하던 삶에 재밌는 순환을 만들어 주었던 것 같아요.

Q: 데보션은 어떤 방향성을 가지고 나아가야 한다고 생각하시나요?

interactive하게 지금처럼, 상호작용하며 나아가야한다고 생각해요.

인터뷰 소감

채상엽 : 학생 신분에서 현직자를 직접 만나뵙고, 현업에 대한 이야기를 자세하게 들어볼 수 있는 기회가 흔치 않은데 데보션영 1기 활동을 통해 인터뷰 기회를 얻게 되어서 정말 유익한 시간이었다고 생각해요.

질문을 드리다보니, 기도님께서 너무 친절하게 답변을 잘해주셔서 원래 준비했던 질문들보다 더 많은 즉석 질문들도 드리게 되었는데, 바쁘신 와중에도 끝까지 인터뷰에 응해주신 기도님께 정말 감사하다는 말씀을 전합니다!

김현지 : 현직자와 이렇게 가까운 위치에서 이야기를 할 수 있는 기회가 생겨 좋았다. 기도님께서 편안하게 인터뷰에 답변해주셔서 우리도 편한 마음으로 인터뷰를 진행할 수 있었다.

현직에서 느끼시는 것들부터 퇴근후 여가활동 등 사적인 질문까지 여쭤보고 나니 개발자가 된 내 자신을 상상하게 되었다. (미래 개발자가 된 내가 퇴근후 새로운 스터디에 들어가 go언어를 배우고 있는...? 그런..?)

나도 저런 현직자가 되어 후배들에게 귀감을 주고 싶다는 생각이 들게한 인터뷰였다!

박민아 : 졸업이 코 앞이다. 이것저것 생각이 많아지는 시기라는 뜻이다. 마음이 조급해질 수록 여기저기서 주워 듣는 이야기는 제법 많아졌지만 정작 현업에서 뛰고 있는 실무자와 직접 대화할 기회는 그렇지 많지 않았던 것 같다.

친구들과 대화하거나, 학부 공부를 열심히 하거나, 교수님과 상담하거나 인터넷에서 정보를 찾아보는 것만으로는 전해 들을 수 없는 선대의 지식이라는 것이 있지 않은가.

그런 의미에서 이번 인터뷰는 정말 값진 경험이었다고 할 수 있다. 평소 관심이 있던 데이터 베이스 쪽의 이야기를 그 분야 전문가를 통해 정말 생생하게 전해 듣고, 또 그 미래 전망까지 공유하고 나니 앞으로 어떤 노력을 통해 어떤 길로 나아가야 할 지도 그간 뜬구름처럼 막연하던 기대와 달리 조금 뚜렷한 윤곽이 잡힌 기분이다. 정말 흔치 않은 기회였고, 감사한 마음으로 인터뷰를 듣던 한 시간은 진짜 쏜살같이 지나갔던 것 같다.

앞으로도 이런 기회가 자주 온다면 좋을 텐데. 그런 생각을 하지 않을 수 없을 만큼 아쉬움과 만족감이 교차하는 경험이었다.

구민정 : 누군가를 인터뷰해서 콘텐츠를 작성하는 게 처음이었다. 내가 조언을 얻어가는 자리이기도 했지만, 데보션 페이지에 올라갈 글인만큼 다른 사람들에게도 도움이 될만한 질문을 팀원들과 열심히 골라내보았다.

개인적으로 인터뷰를 마치고 기도님과 가볍게 대화를 나눈 게 평소 갖고있던 불안을 덜어내는 데에 도움이 된 것 같다. 한 가지만 파라(Go로 go하세요!)고 조언해주셨던 것도 생각난다.

왜 이 일을 하는지는 잊고 그냥 남들을 따라서 달리고 있는 건 아닌지 이 인터뷰를 보며 모두 스스로를 돌아보는 기회를 가질 수 있다면 좋겠다. 기술자에겐 더더욱 필요한 고민인 것 같다.