월간 지앤선

인터뷰 및 편집 : 아델라 월간지앤선 편집장

 

2021년 새해 릴레이 인터뷰 첫 번째 주자는 소프트웨어 엔지니어 김지현 님입니다. 지현 님은 다양한 도메인의 프로그래밍을 깊게 다루는 분이고, Rust라는 프로그래밍 언어의 매력에 빠져 한국 러스트 사용자 그룹의 운영진으로 활동하고 있습니다. 또 여러 가지 기술을 개선해나가면서 활기차게 오픈소스 활동도 하세요. 지현 님은 어떤 분야에 관심이 있고 어떤 방식으로 기술 발전에 기여하고 있는지 인터뷰로 여쭤보았습니다.

 

지현님의 시그니쳐 프로필인 리락쿠마

 

Q. 안녕하세요 지현님, 자기소개 부탁드립니다.

김지현입니다. 가리지 않고 다양한 주제에 관심을 가지는 프로그래머입니다.

 

Q. 풀 스택(Full Stack) 개발자이신가요?

풀 스택 개발자(Full Stack)라고 하면 보통은 웹서비스에 한정된 개념이고 컴퓨터 보안, 게임 개발 같은 다양한 분야를 모두 아우르는 용어는 아닌 것 같습니다. 저의 경우에는 우선 시스템 프로그래밍, 운영체제(OS), 보안에 관심이 많습니다. 해킹을 제외하면 모든 분야를 거치고 있다고 보셔도 무방할 것 같습니다.

그동안 아직까지 건드리지 않은 분야가 있다면 Machine Learning(ML)과 해킹 정도인 것 같아요. ML은 2017년에 잠깐 열심히 공부하다 최근에 다시 열심히 하고 있습니다. 해마다 많이 바뀌어서 업데이트가 필요하더라고요. 해킹 분야도 exploit을 짜거나 포너블을 푸는 것을 안 할 뿐이지 취약점을 막는 방법이나 시큐어 코딩 같은 분야는 공부하고 있습니다.

 

Q. 여러 가지 분야를 아우르는 이유가 따로 있으신가요?

다양한 분야에 이해관계가 생기면 어쩔 수 없이 다른 분야의 지식이 필요한 경우가 있습니다. Dev-Ops 업무를 할 때 Java 서버나 Ruby on Rails 서버가 어떤 식으로 짜여 있는지 파악을 해야 할 때가 있었고요. 마찬가지로 Front-End 파트에서 일하는 게 아니어도 모종의 이유로 Front-End가 어떻게 짜여 있는지 파악을 해야 할 때가 있는데, 그 경우에도 도움이 되었습니다. 이렇게 다양한 분야에 대한 지식을 갖고 있으면 새로운 종류의 코드나 일이 나타나도 익히는 게 쉬운 편입니다.

여러 분야의 기술을 다루는 가장 큰 이유는 다양한 분야의 일을 하는 게 재밌기 때문입니다. ‘다양한 분야의 일을 해야겠다’ 마음을 먹고 따로 공부한 적은 없고 모르는 부분을 조금씩 공부하다 보니까 이렇게 된 것 같습니다.

 

Q. 시스템 프로그래밍, 운영체제, 보안에 관심을 가지게 된 이유가 있으신가요?

처음에는 학문적 호기심으로 공부를 시작하였습니다. 최근에는 그 분야에서 할 수 있는 게 많이 보여 관심을 더 많이 갖게 되는 것 같습니다.

 

Q. 시스템 프로그래밍으로는 어떤 것을 할 수 있나요?

시스템 프로그래밍에는 다양한 정의가 있지만 쉽게 풀어 말씀드리자면 운영체제를 직접 사용해서 소프트웨어를 최적화하는 것입니다. 다른 프로그래밍을 하기 위해 기반이 되는 작업을 하는 분야라고 생각하시면 좋을 것 같습니다.

지금의 시스템 프로그래밍은 중요도에 비해 대중의 관심도가 떨어지는 편입니다. 관심은 적지만 시스템 프로그래밍이 사람들에 끼치는 영향력은 상당하죠. 최근에는 퍼징(Fuzzing)이 재발견되거나, 러스트 프로그래밍(Rust Programming), 정적 프로그램 분석(Static Program Analysis) 같은 여러 가지 기술이 발전되었습니다. 아쉽게도 사람들의 기여가 부족한 분야이기도 합니다.

 

Q. 러스또랑스시군요.

네. 러스트가 시스템 프로그래밍에만 쓰이는 것은 아니기 때문에 다양하게 사용하려 노력하고 있습니다.

 

Q. Rust로는 어떤 일을 할 수 있나요?

다른 언어로 하지 못하는 것 중에 Rust만 할 수 있는 일을 말씀드리자면, 시스템 프로그래밍에 대한 깊은 이해가 없는 상태에서도 쉽고 안전하고 재사용이 가능한 시스템 프로그래밍을 할 수 있도록 해줍니다.

 

Q. Rust의 어떤 점이 시스템 프로그래밍을 쉽게 만드나요?

Memory Safety를 강제하는 점 때문입니다. 충분히 숙달되지 않은 상태의 프로그래머는 프로그래밍 중에 메모리 오류를 종종 발생시킬 수 있습니다. 이 메모리 오류는 보안 취약점을 발생시켜 위험하게 만들기도 합니다. Rust는 Memory Safety를 강제한다는 특징 때문에 프로그래밍에 충분히 숙달되지 않은 사람도 효율적이면서 안전하게 시스템 프로그래밍을 할 수 있게 된다는 장점이 있습니다.

 

Q. 운영체제에 대해선 어떤 부분에 관심이 많으신가요? 그리고 앞으로 발전시키고 싶은 것이 있나요?

운영체제라는 학문 자체에 관심이 있습니다. 운영체제는 할 수 있는 게 엄청 많은 분야기도 합니다. 운영체제의 특정 부분에만 관심이 있다기보다는 운영체제의 전체적인 방향성에 관심이 많습니다.

현 운영체제 기술은 미진한 부분이 많고 발전시킬 여지가 많아 그 부분을 개선하고 싶어요. 예를 들어 리눅스 같은 경우 입출력에 개선할 여지가 많습니다. 지금까지는 HDD나 SSD가 느려서 운영체제가 I/O(Input/Output)에서 차지하는 시간 비중이 낮았기 때문에, I/O를 위해 운영체제를 크게 최적화할 필요가 없었기 때문입니다. 코드 유지보수성을 위해 성능을 포기한 부분도 많고요. 물론 성능 최적화를 하면 리눅스 팀에서 곧바로 패치를 받아들이는 것만은 아닙니다. 사람들과 합의하면서 천천히 개선해 나가야 하는 구조입니다.

 

Q. 오픈소스로 기여를 할 때, 기술을 발전시키는 코드를 PR로 올리는 것 외에도 사람들과 토론해야 하는 부분이 많은가 봐요.

네. 그래서 사람을 대하는 스킬이 중요하다고 생각합니다. 수백, 수천 명의 이해관계가 걸쳐 있는 리눅스 프로젝트 같은 경우에는 참여자들 간에 마찰도 잦은 편입니다.

 

Q. 오픈소스 기여 중에는 주로 어떤 식으로 토론하나요?

프로젝트 분위기에 따라 다릅니다. 하지만 핵심은 오픈소스 메인테이너 마음에 드는 패치를 만드는 것입니다. 이외에도 발언의 무게 또한 사람마다 다릅니다. 오픈소스 활동이란 돈을 받지 않고 진행하는 프로젝트이기 때문에, 프로젝트 주인이 아니더라도 프로젝트에 도움이 되는 기여를 더 많이 하는 사람의 눈치를 볼 수밖에 없습니다. 따라서 노동력을 많이 제공할수록 발언권이 세진다는 특징이 있습니다.

오픈소스 활동을 할 때 추가적인 팁이 있다면 메인테이너에게 맡겨놓은 듯이 행동하는 게 아니라, 적극적으로 문제 해결을 위해 노력하면 패치를 머지시키는 사람에게도 도움이 많이 됩니다. 예를 들어 이슈트래커에 이슈를 올리면 메인테이너가 나를 위해 버그를 고쳐주는 것이 당연하다고 생각하시는 분들이 많습니다. 그런데 오픈소스 프로젝트 메인테이너들은 선의만으로 일하는 무급 자원봉사자가 아니라 본인의 필요와 동기에 의해 프로젝트를 관리하는 사람들이기 때문에, 사실 다른 사람들의 버그를 적극적으로 고쳐줄 의무는 없습니다. 실제로 얻는 것보다 잃는 것이 많을 경우 특정 문제는 일부러 방치하는 경우도 흔합니다. 그래서 오픈소스 프로젝트에서 해결하고 싶은 문제가 있다면, 이런 점을 잘 숙지하고 본인이 적극적으로 문제 해결을 위해 노력하는 자세를 보여주면 메인테이너뿐만 아니라 버그 리포터 본인에게도 도움이 될 가능성이 큽니다.

 

Q. 인상 깊었던 오픈소스 활동은 어떤 것인가요?

Rust 프로젝트에 머지시켰던 패치가 떠오르네요. SIMD(Single Instruction, Multiple Data) 관련 버그를 패치한 적이 있습니다. 엄청 시급한 패치는 아니었고 쓰는 사람들 사이에서나 쓰는 기능이어서 처리가 늦을 법도 했는데, 버그를 리포팅하고 패치하기까지의 과정이 활발하게 진행되었습니다. 모든 오픈소스가 그렇지는 않거든요. 패치를 날려놓고 며칠씩 기다리는 경우도 흔한데, 그곳 메인테이너 분들은 활기차고 친절하게 대했던 게 인상 깊었습니다.

또 다른 활동으로는.. 대단한 패치는 아니지만 Infinity Large Napkin이라는 수학 교재에 오타를 제보하기도 했었네요. 교재에 사소한 오타가 많은데 배우는 사람 입장에서 이 오타가 내용적으로 헷갈리더라고요. 오타를 발견하면 바로바로 수정해서 PR을 올립니다. 그렇게 되면 새 판본을 기다릴 필요 없이 인터넷에 필요한 최신 버전이 바로 뜨게 됩니다. 오픈소스의 장점을 수학책에도 적용할 수 있어서 인상 깊습니다.

 

Q. 개발은 언제부터 시작하신 건가요?

초등학교 3, 4학년 때 PHP와 HTML을 잠깐 했었고 그 뒤로 홈페이지를 만들어본 적은 있습니다. 잘 이해를 한 상태는 아니었고요. 본격적으로 개발을 시작한 것은 고등학교 수업 시간에 C언어를 배운 이후네요.

 

Q. C언어를 공부하고 나서 왜 더 공부하고 싶단 생각이 들었나요?

1학년 1학기 말에 오델로 게임을 만들었습니다. 처음에는 2인 플레이 게임을 만들었는데 1인 플레이 게임으로 바꿔 보고 싶었어요. 그러려면 상대편 플레이어 AI(인공지능)가 필요해서, 여름 방학 때에 아무 생각 없이 만드는 방법을 검색했는데 생각보다 쉽지는 않았습니다. 어떻게든 만들긴 했지만요. 그렇게 혼자 공부하는 게 습관이 되어서 혼자 꾸준히 공부를 할 수 있게 되었던 것 같습니다. 아쉽게도 프로그래밍을 가르쳐줄 교수자는 따로 없었습니다. 학교에서 수업으로 들은 건 C언어 기본 문법 정도였고, C++의 메모리 할당 같은 복잡한 내용은 혼자 힘으로 배울 수밖에 없었어요.

 

Q. 처음에 혼자 공부하시면서 힘들었던 게 있었나요?

디버깅하는 걸 하나도 할 줄 몰랐는데, 도와줄 수 있는 사람이 없어서 막막했어요. 지금이야 어떻게 디버깅 해야 할지 알지만, 당시에 프로그래밍은 원래 이렇게 하는 건 줄 알고 힘든 줄 모르고 했었습니다. 또 아무래도 학교에서 짬 내어하던 거라, 자습 시간에만 공부를 했어야 되어서 힘들었었네요. 컴퓨터를 마음대로 쓸 수 있는 시간이 많지 않았거든요.

 

Q. 대학교에 와서 접한 프로그래밍의 세계는 어떻게 다른가요?

고등학생 때는 혼자서 공부하다 보니 공부를 비효율적으로 했었습니다. 고등학생 때 Java, C#을 알긴 했지만 거의 C++ 만 익혔었어요. 프로그래밍 기본기를 단단히 익힐 수 있는 기회였으나 좀 더 효율적으로 공부할 수 있었을 것 같아 참 아쉽습니다.

대학교에 오고 나서는 다양한 사람들과 교류함으로써 한 단계 더 성장할 수 있었던 것 같습니다. 예를 들어 고등학생 때는 Linux와 Vim을 아주 조금만 썼었고, 거의 모든 프로그래밍을 Windows와 Visual Studio라는 IDE에서 개발했었어요. 그런데 대학에서는 어셈블리를 배우기도 하고 리눅스 서버도 만들어보면서 정통적인 커리큘럼을 차근히 밟아나갈 수 있었습니다. 학교 수업에서는 기초지식을 쌓고 다양한 개발자 커뮤니티에 들어가서는 학교 교육 과정 외에 하고 싶은 것을 따로 익혔어요.

 

Q. 어떤 곳에서 다른 개발자들과 교류하며 실력을 키워나갔나요?

고등학교가 기숙사라 고등학생 때는 이동이 제한적이어서 개발자 모임에 참석하는 게 자유롭지 않았습니다. 그렇다고 온라인 모임이 언제 어떻게 이뤄지는지와 같은 정보를 잘 알았던 것도 아니에요. 알았다고 하더라도 입시 때문에 참석이 한정적일 수밖에 없었습니다. 대학에 오고 나서는 자유로움과 능력을 얻게 되면서 실력이 폭발적으로 늘어날 수 있었던 것 같습니다.

 

Q. 아직 졸업을 안 하셨다고요. 학부 생활 중 회사를 들어가게 된 계기가 있었나요?

대학교 1학년 때 학교 생활이 재미없어서 자퇴를 고민할 정도로 학교에 적응하는 게 힘들었습니다. 드디어 과학고등학교를 졸업해서 기뻤는데, 1학년 때 구성되는 수업이 과학고등학교 커리큘럼의 연장선 같아서 재미가 없었거든요. 그리고 대학교 1학년이 되면 독학 없이 누군가로부터 친절하게 도움을 받아가면서 개발 공부를 할 수 있을 거라는 기대가 있었는데, 오히려 과고 때보다 더 독학을 열심히 했어야 했습니다. 그러던 중 한 선배를 도와드리다가 스타트업에 합류를 하게 되었습니다. 스타트업 때문에 미국도 다녀왔고요. 지금 생각해보면 회사를 좀 덜 다녔어도 될 거 같아요. 하지만 당시에는 생활비를 충당해야 했어서 열심히 다닌 것도 있네요.

 

Q. 저도 그랬고 주위에 학교 생활을 하면서 일을 병행하는 학생들이 많습니다. 지현 님이 회사를 다니던 때로 다시 돌아가게 된다면 어떤 결정을 내릴 것 같나요?

지금 제가 알고 있는 것과 이 기억을 그대로 갖고 돌아간다면 당연히 회사를 가지 않겠지요. 하지만 기억도 되돌려진 채로 돌아간다면 똑같은 선택을 할거 같습니다. 그때는 그게 최선의 선택이라고 생각하고 한 거니까요.

 

Q. 협업을 할 때는 어떤 태도가 필요한가요? 소위 소프트 스킬이라고 칭하는데, 지현 님이 중요하게 생각하는 소프트 스킬은 무엇인지 궁금합니다.

짚고 넘어갈게 소프트 스킬이라고 하면 ‘원만하고 효율적으로 일하는 능력’을 통칭하는데 오픈소스 활동을 할 때 필요한 소프트 스킬과 회사에서 활동할 때 필요한 소프트 스킬은 서로 다릅니다. 오픈소스 활동은 오픈소스 메인테이너나 오픈소스 기여자 모두 풀타임으로 그 일만 하는 게 아니어서 대부분이 비동기적으로 일하고 실시간으로 채팅하지 않습니다. 오픈소스 소프트 스킬은 개발자와만 소통하면 되는 것이기도 하고요. 반면 회사에서는 풀타임으로 집중해서 업무를 임할 뿐만 아니라, 개발자 외의 다양한 파트의 사람들과 소통하다는 차이점이 있을 것 같네요.

오픈소스 활동을 할 때 필요한 소프트 스킬은 위의 질문에 대한 답변으로 갈음할 수 있을 것 같고요. 제가 감히 회사에서 일할 때 필요한 소프트 스킬을 조언 드릴 만한 위치에 있는지는 모르겠습니다. 그럼에도 말씀드려보자면, 제가 생각하는 회사에서 원만하게 일하는 스킬은 다른 사람을 존중하면서 사람들을 이해하려고 하는 것이고, 그게 제일 중요한 것 같다고 생각합니다. 바쁘게 회사 생활을 하다 보면 무언가 안 되는 경우도 있고, 일이 복잡하다 보면 일이 어려울 수도 있습니다. 그럴 때일수록 함께 일하는 동료들을 이해하려는 노력이 중요한 것 같습니다. 물론 회사 안 본인의 위치에 따라서도 소프트 스킬이 다르게 필요할 것 같습니다.

 

Q. 좋아하는 동료상은 어떤가요?

한 가지로 정의되지는 않습니다. 특정 분야에 전문성을 가진 분들과 일하는 게 즐겁기도 하고요. 또  프로그래밍에 전문성이 뛰어나지 않아도 같이 일하는 맛이 있는 분들이 계십니다. 다른 팀 / 사람과의 갈등을 효과적으로 봉합한다거나, 프로젝트의 맥락을 짚고 적절하게 기여하는 분들이 바로 그런 분들이죠. 다양한 분들과의 협업을 즐겨서 딱 어떤 분을 제일 좋아한다라고 말씀드리긴 어려울 것 같아요.

 

Q. 같이 일하기 싫은 분은 어떤 분인가요?

많이 만나보진 못했습니다. 대화를 거절하고 자기 입장이나 주장만 펼치는 사람과는 일하는 게 어렵지 않을까요. 아니면 다른 사람들의 의견이나 피드백, 조율 혹은 다른 사람과의 협업 자체를 무시하고 거절하는 분들과는 같이 일하는 게 어려웠습니다.

 

Q. 앞으로 김지현 님이 이루고자 하는 목표가 있으신가요?

세상에 도움이 되는 개발자가 되고 싶습니다. 세상이 도움이 되는 방향은 다양할 것 같은데.. 방향에 대해서는 아직 고민 중입니다. 생각하는 목표가 있다면 돈이 많은 사람에게만 도움이 되는 사람이 되기보다, 돈이 없는 사람들이나 다양한 취약계층에도 도움이 되고 싶어요. 그걸 이룩하는 수단은 아직까지 구체적으로 정하진 않았습니다. 제가 프로그래머가 되기로 한 건 고등학생 때였지만, 훨씬 이전인 초등학생 때부터 공학자가 되기로 마음을 먹었어요. ‘엔지니어링’이 뭐냐는 질문을 하면 다양한 대답이 돌아오겠지만, 초등학생 때 가장 처음 배운 엔지니어링의 정의는 ‘기술을 사용하여 사람들을 이롭게 하는 것’이었습니다. 전 그냥 그 꿈을 실현하고 있는 것이고, 돈이 많은 사람에게만 도움이 되면 임팩트가 협소한 엔지니어가 되는 것이라고 할 수 있을 테니까, 다양한 사람들에게 도움이 되는 엔지니어가 되려고 노력하고 있습니다.

 

Q. 지앤선 독자분들께 하고 싶은 말이 있으신가요?

많은 분들이 다양한 동기를 가지고 프로그래머가 되어 일을 하고 계십니다. 별거 아닌 것처럼 보여도 자기가 하는 일이 의외로 사회에 끼치는 영향이 크다는 점을 항상 생각하고 맡은 바를 임하셨으면 좋겠습니다.

 

✨김지현 님의 블로그 주소: https://hyeon.me

 

Hyeon Kim

Natural Born Developer

hyeon.me

✨ 김지현 님의 깃헙 주소: https://github.com/simnalamburt

 

simnalamburt - Overview

Natural Born Developer. simnalamburt has 241 repositories available. Follow their code on GitHub.

github.com

 

Comment +0