유하 신입 개발자들의 이야기

유하에서는 분기별로 각자 기술에 대한 하나의 주제를 정하여 글을 작성하기로 했습니다. 입사한 지 대략 한달이 지난, 세 명의 개발자는 아직 배우는 과정으로 글의 소재를 정하기가 어려웠습니다. 이를 고민하던 중, 함께 모여 각자의 ‘이야기’를 하나의 글로 작성해 보자는 의견으로 시작되었습니다.

누구나 어떤 일에 대해서 ‘처음'이라는 것이 있었을 것입니다. 이번 글에서는 Ticketplace에 입사한 지 대략 한 달이 지난, 세 개발자가 ‘입사 전 이야기’, ‘입사 후 알게 된 점', ‘업무 적응 이야기' 총 세 개의 파트로 나누어 이야기를 하고자 합니다.

 (김해린) : 한창 IT 열풍이 있었을 때, 고등학교를 소프트웨어 쪽으로 진학하기로 했었습니다. 그렇게 자연스럽게 소프트웨어를 접하게 되면서 개발자라는 직업이 매력적으로 느껴졌고, 만들고자 하는 것을 마음대로 제어할 수 있는 게 재미있어서 프론트엔드를 택하게 된 것 같아요.

 (이지헌) : 학부 1학년때 계열교양으로 파이썬 과목을 수강하게 되었습니다. 당시 교수님께서 강의 도중에 “세상은 빠르게 발전하고 있다. 컴퓨터에 대한 기초적인 지식과 사용법은 알아야 한다. 여러분들 또한 빠르게 발전하는 세상의 속도에 맞춰 발전해야 한다.” 라고 하셨던 말씀이 기억에 남습니다. 이는 제 자신을 돌아보는 계기가 되었고, 이때 진로의 터닝포인트가 찾아왔습니다. 이후로 IT 관련 과목에 흥미를 가지기 시작했고, 개발자가 되어야 겠다는 다짐을 했습니다.

 (장용희) : 어릴 적부터 컴퓨터를 좋아했습니다. 제가 초등학생일 때, 부모님께서 컴퓨터를 사주셨는데, 계속 이것저것 건드리다가 한 주 걸러서 한 번씩 꼭 컴퓨터 수리 기사님의 얼굴을 뵈었던 기억이 있네요. 그렇게 컴퓨터와 친하게 지내다 보니, 자연스럽게 장래희망은 컴퓨터와 함께 일할 수 있는 쪽으로 향하게 되었습니다.

그런데, 개발자가 아니어도, 과거부터 현재까지 사무, 그래픽, 영상 등등 거의 대부분의 업무는 컴퓨터로 이루어지고 있습니다. 하지만, 저는 컴퓨터를 사용만 하는 것이 아니라, 컴퓨터를 저의 뜻대로 움직이게, 컴퓨터가 내가 원하는 형태대로 동작할 수 있도록 하고 싶었습니다. 이에 생각 끝에 개발자가 되기로 마음먹었습니다.

 (김해린) : 학교 수업으로 C언어, 컴퓨터 구조, 운영체제, 알고리즘 등 기초적인 개념들을 학습했고, 수업과 별개로 전공 동아리에서 프로젝트를 진행하며 경험을 쌓았습니다. 디자인을 해보기도 하고 프론트 리더를 맡기도 하며 다양한 서비스를 접하면서 실무와 익숙해지기 위해 노력했습니다. 한번이 아니라 여러 차례 프로젝트를 하며 개발을 하다보니 이슈와 오류를 접하면서 어떻게 대응해야 하고 어떤 방식으로 관리를 해야 하는지 깨달았습니다. 이런 경험들을 토대로 서류 준비를 하였고 면접을 위해 웹이나 프론트에 대한 기초 개념들을 한번 더 상기시켰습니다.

 (이지헌) : 학부 때 IT 관련 과목을 수강하는 것으로는 턱없이 부족할 것이라고 생각하였고, 이를 고민하고 있었습니다. 때마침 교내 연구실 TEAMLAB의 지원 공고를 보고, “개발자로 성장하는데에 큰 도움을 받을 수 있을 것 같다.” 라는 생각이 들어 지원하였고, 코딩테스트 및 과제를 통과하여 마침내 학부생 연구원으로 참여했습니다. 이후 ‘창의성 계발을 위한 AI 서술형 평가 지원’ 프로젝트에 참여하여 기획/개발/운영/배포 그리고 팀원들과의 협업 방법들을 배우면서 개발자의 역량을 쌓아왔습니다.

 (장용희): 먼저, 컴퓨터와 의사소통할 수 있는 언어를 알지 못하면 아무것도 되지 않습니다. 중학생 때, 어떠한 계기가 있어서 C언어를 배운 것을 시작으로 여러가지 언어를 배우기 시작했습니다. 이후 고등학생이 되어, 앱 개발 동아리에 들어가게 되었습니다. 해당 동아리에서, ‘스쿨맘'이라는 가정통신문 및 알림장 앱 제작에 참여했었습니다. 비록 제가 해당 어플에 많은 기여를 하진 못하였지만, 해당 어플이 성장해나가는 것을 보며 자신이 개발한 작업물이 세상에 퍼져나가는 것이 개발자로써 얼마나 뿌듯한 순간인지 새삼 깨닫게 되었습니다.

이후, 대학에 진학하고 취업을 하게 되었습니다. 처음엔 대표님 한 명뿐인 회사에 제가 들어가 회사 규모가 점점 커져, 나올 때 즈음엔 총 직원이 5명인 회사로 성장해 있었습니다. 현재는 Ticketplace로 이직했으며, 동창인 친구들과 게임 개발에 참여하는 등, 계속해서 개발자로써의 역량을 쌓기 위해 노력하고 있습니다.

 (김해린) : 막막하고 두려움이 먼저였던 것 같아요. 알려주는 사람도 없었고, 이렇게 해야 된다는 정답도 없었기 때문에 무작정 뛰어들었습니다. 어떤 회사들이 있는지, 어떤 언어가 트렌드인지 취업 사이트에서 보았을 때 되게 다양하고 많은 회사들이 있다는 걸 느꼈습니다. 회사마다 장단점도 다양했고, 서비스도 제각각이어서 어느 곳이 나와 잘 맞을까 하는 생각에 좀 혼란스러웠어요. 회사 선택하는 것도 조금 걸렸었고, 서류 준비에도 시간을 쏟았습니다. 그동안 프로젝트를 했던 기억은 있는데 그 안에 세부적인 내용들을 나열하기까지가 어려웠던 것 같아요. 하지만 이루고자하는 목표가 있었기 때문에 재빠르게 알아보고 준비도 했었습니다.

 (이지헌) : “나는 여러 경험과 학습을 통해 개발자로서 일할 준비가 충분히 되어있다.” 라고 생각했지만 실제로는 그렇지 않았습니다. 이력서부터 코딩테스트 및 과제 그리고 면접까지 모두 엉망진창이였습니다. 여러 회사를 지원하고 불합격을 반복하면서 자존감이 매우 떨어지기도 했습니다. 이렇게 계속 좌절하고 있을수는 없다고 판단하여, 나의 부족한 점을 찾아 이를 개선하는 과정을 통해 조금씩 성장하는 모습을 볼 수 있었습니다. 마침내 Ticketplace와 좋은 인연으로 함께할 수 있게 되었습니다.

 (장용희): 누구나가 그렇듯이, 처음에는 막막하다는 생각 뿐이었습니다. 그러나 지금까지 차근차근 준비해온 사실과, 준비해온 것들에 대한 자신감만을 가지고 취업에 임했습니다. 물론, 모든 일이 생각했던 것만큼 순조롭지는 않았으나, 계속하여 도전하다 보면 결국 취업에 성공할 수 밖에 없다고, 긍정적으로 생각하며 굴하지 않고 노력하였습니다.

이슈 관리는 필수적으로 해야 하는 것 중 하나라고 생각합니다. 프로젝트나 서비스를 배포하기로 마음 먹었을 때, 또는 배포 이후이면 더더욱 이슈 관리는 중요하게 다가옵니다.

즉, 프로젝트가 어떠한 상태에 있다고 하더라도 이슈가 발생하면 해당 이슈를 추적하고, 확인할 수 있어야 합니다.

Ticketplace는 이렇게 하고 있습니다:

Ticketplace의 입사 과제에는 의도적으로 질문을 유도하는 듯한 내용이 있었습니다. 예를 들어, 내용이 명확하지 않다던가, 틀린 내용이 적혀저 있다던가 하는 것들 말이죠.

Ticketplace에서는 애자일 소프트웨어 개발을 지향하고 있는데, 애자일 4대 선언에서는

와 같이 선언하고 있습니다. 해당 선언에서는, 왼쪽에 있는 것들도 가치가 있지만, 오른쪽에 있는 것에 더 높은 가치를 둔다고 이야기하고 있습니다.

개인과 상호작용을 부분에 주목해 보면 왜 그러한 과제가 주어졌는지 명확해집니다. ‘질문’을 통해, 자연스럽게 해당 방법론을 채득할 수 있도록 도와주신 것이죠.

질문을 던질 수 있도록 도와주심으로써, 질문이 협업에서 얼마나 중요한 것인지를 배울 수 있었습니다.

혼자서 해결하기 어려운 주제에 대하여 질문을 망설이는 것은, 질문을 통해 문제를 해결할 때보다 시간이 지체될 가능성이 높고, 그렇게 되면 결론적으로 일정을 지키지 못하게 되는 경우도 발생하게 됩니다. “고민은 배송만 늦출 뿐!” 이라는 말이 있듯이 고민은 해결만 늦출 뿐입니다.

대부분의 신입분들은 질문을 하면 “이런 것도 몰라?” 라고 생각하실까봐 걱정하고, 결국 질문을 고민하고 있을 겁니다. 신입은 모르는게 당연하고, 이를 배워서 성장하면 됩니다. 그리고 옆에는 도와주실 팀원분들이 존재합니다.

개발자는 코드를 작성하는 것이 다라고 생각할 수 있지만 개발자는 ‘코드만 작성하는 사람'이 아닙니다. 코드 작성하여 제품을 만들고 서비스가 돌아간다고 해서 일이 끝나는 게 아닙니다. 만든 제품을 누군가에게 설명해야 하고, 작업에 대해 기록을 남겨야 하는 상황이 생길 수 있습니다. 또한 작업 도중에 이슈가 생겨 공유하는 일이 있을 수도 있습니다.

제품을 만드는 일에 있어서 문서화는 필수입니다. 작업을 하기 전, 작업 중일 때, 작업이 끝나고 나서 문서가 필요한 상황은 반드시 발생합니다.

또한 나중에 일어날 수도 있는 일에 대한 대처방안이 되기도 합니다. 잘 기록된, 정리가 잘 되어있는 문서는 새로운 개발자가 팀에 합류할 수도 있는 상황에서 굉장히 유용한 키가 됩니다.

이것은 신입 개발자 중 한 명의 경험담인데요, 어떠한 프로그램의 Add-In을 작성해야 하는 일이 있었습니다. 해당 프로그램은 .NET Framework로 제작되어 있었는데, CodeDOM 패키지를 이용하여 사용자가 직접 해당 애플리케이션 내에 필요한 기능을 스크립팅 할 수 있도록 되어 있었습니다.

그런데, 문제는 스크립팅에서 사용해야 하는 컴포넌트들의 구조에 대한 문서가 전혀 제공되지 않았습니다. 어떠한 class에 어떤 function들이 있는지를 아는 방법은 내장 Editor에서 제공해주는 자동완성 기능에서 하나씩 찾아나가는 방법 뿐이었습니다.

절망 속에서도 한 줄기 빛은 있었습니다. JetBrains에서 무료로 제공하는 DotPeek라는 프로그램이 있었는데, .NET Framework로 제작되어 컴파일 된 컴포넌트를 디컴파일하여 코드를 확인할 수 있는 프로그램이었습니다. 이후의 일은 상상에 맡기겠습니다.

하지만 이 프로그램은 비유하자면 손전등 정도의 빛 정도밖에 비춰주지 못했습니다. 만일 문서화가 되어 있었다면, 문서는 태양과 같이 필요한 모든 부분을 비추어주었을 것입니다.

극단적인 예시였지만, 문서화가 왜 필요하며, 문서화가 되어 있지 않았을 때 일어날 수 있는 일에 대해 생각해보게 되는 계기가 되었으면 합니다.

 (김해린) : 지금은 리팩토링 되었지만 작업을 하면서 컴포넌트들을 세세하게 봤을 때 하나의 컴포넌트에 props가 너무 몰린다거나, 제 역할을 하지 못했던 부분을 봤던 기억이 있습니다.

 (이지헌) : 해당 이슈에 대한 분석을 끝냈을 때 개발 팀원분들 모두가 함께 Story Point 지정하는 것 즉, 이 일이 얼마나 걸릴지 추정하는게 신기했습니다. “프로젝트 매니저와 담당 엔지니어 둘이서 정하면 되는 거 아닌가? 왜 다른분들도 참여를 하는거지?” 라는 의문점이 생겨났습니다. 대부분은 대략 얼마나 걸릴지 추정하고 이에 따라 진행할 것 입니다. 하지만 진행 도중에 “시간이 너무 부족한데?”, “시간이 너무 남는데?” 라는 경험이 있지 않으신가요? 사실 정확하게 추정하고, 이를 따르는 것은 쉽지 않습니다. 그래서 담당 엔지니어가 일의 내용을 공유하고, 팀원분들과 함께 Story Point를 지정함으로써 시간이 부족하지 않도록 그리고 시간이 남아서 담당 엔지니어가 나태해지지 않도록 적절하게 추정할 수 있습니다.

 (장용희) : 입사 후 신입 개발자들에게는 3개월 동안 읽어야 할 책 6권이 주어집니다. 처음에는 ‘일도 바쁠텐데 책까지 읽으라고?!’라고 생각하였으나, 책 1권을 거의 다 읽을 때 즈음엔, 생각이 바뀌었습니다. 개발자는 끊임없이 성장해나가야 하는 존재이며, 어떠한 방향으로 성장해나가야 하는지 가장 집약적으로 담겨 있는것은 ‘책'이었습니다. 지금까지는 1년에 책을 한 권 읽을까 말까 할 정도로 책과 거리를 두고 살고 있었으나, 읽기 시작하니 보이는 것이 있었습니다.

 (김해린) : 코드 파악하기 전에 아키텍처 문서를 우선적으로 읽었는데요, 코드 구조가 어떻게 이루어져있는지 아키텍처에 담겨 있기 때문에 세부적인 코드들을 훑기 전에 전체적인 아키텍처를 파악하는 게 중요하다고 생각해서 문서 먼저 들추어보았습니다. 큰 흐름과 구조를 익히고 나서 코드를 읽었을 때 빠르게 읽혔고 파악하기 수월하였습니다.

 (이지헌) : 티켓플레이스의 기본적인 설계는 clean architecture를 따르고 있었습니다. 이를 토대로 구현하고 있었기 때문에, 먼저 clean architecture에 대하여 학습해야 했습니다. 하지만 이를 학습한다고 해서 실제로 프로젝트에 어떻게 적용했는 지는 알 수 없었기에 무작정 코드를 읽었던 것 같습니다. 결국 혼자 이해하는데에 한계를 느끼고, 작성되어 있는 여러 문서(youha architecture, RESTful API 구현 가이드 및 설계 등)를 모두 읽으면서 이해할 수 있었습니다. 이때, 문서화의 중요성을 크게 느꼈던 것 같습니다.

 (장용희) : 지금까지의 경험대로, 처음에는 코드만을 보고 문맥을 파악하려고 하였습니다. 지금까지는 아키텍처 문서가 현 상황에 맞도록 제대로 구성되어 있는 사례를 본 적이 손에 꼽을 정도였는데, Ticketplace는 해당 부분이 제대로 되어 있음을 알았습니다. 아키텍처 문서와 함께 코드를 분석하니, 한결 손쉽게 느껴졌습니다. 이 일을 통해, 문서화의 중요성을 자연스럽게 채득하게 되었습니다.

 (김해린) : 입사하고 3일째 되던 날에 작은 작업 두개를 할당받은 게 있었어요. 먼저 어떤 걸 작업해야 맞는지 파악하는 게 우선이라 이 업무에 대해 분석하고 이리저리 둘러보았습니다. 작업에 대해 어떤 부분을 어떻게 작업할 것인지 지라에 정리한 후에 업무를 처리했었어요. 이전에는 막히던 게 있으면 마냥 머릿속으로 고민해서 시간이 좀 걸렸다면 입사 후에는 티켓플레이스 방식에 맞게 고민하고 있는 내용까지 다 기록하여서 막히는 부분을 다른 분들에게 쉽게 공유할 수 있어서 문제 해결에 많은 도움이 되었습니다.

 (이지헌) : 저에게 할당된 첫 이슈는 기존 API의 문제점을 해결하여 개선하는 업무였습니다. JIRA에 보고된 이슈의 설명을 보고 의도는 파악했지만 코드를 이해할 수 없어서 진행이 어려웠습니다. 이때 어디선가 들었던 “개발자는 코드를 작성하는 시간보다 읽는 시간이 더 많다.” 라는 말이 이해될 정도로 며칠은 코드만 읽었던 것 같습니다. 혼자만의 힘으로는 부족하다고 판단하여 팀원분들께 도움을 요청하였고, 마침내 문제점과 진행 방향성을 찾을 수 있었습니다. 이후 자연스럽게 진행해야 하는 일들이 정해짐과 동시에 JIRA 이슈 문서내에 과정을 기록하였고, 이를 토대로 진행하면서 코드 리뷰를 통해 이슈를 해결할 수 있었습니다.

 (장용희) : 코드 분석에서 이어지는 내용이 될 것 같네요. 새로운 API를 추가하는 작업이었는데, 기존 코드와의 일관성에 위배되지 않는 코드 작성이 중요하다고 생각되었습니다. 그렇게 하려면 먼저 API가 어떤 식으로 구현되어 있는지 면밀히 확인하여야 했습니다. 시행착오를 거쳐 (적어도 작업해야 하는 범위 내에서의) 코드 분석이 완료되었고, 작업도 어느정도 일단락 되었습니다. 이후 막힌 부분은 테스트를 작성하는 부분이었습니다.

TDD (Test Driven Development)에 대해 들어도 보았고, 중요성도 알고는 있었으나, 어떤 식으로 테스트를 진행해야 하는지는 모르고 있었습니다. 지금까지는 개인 프로젝트 등 프로젝트를 진행할 때, ‘돌아만 가면 된다'라는 생각으로 마무리한 경험이 대부분이었습니다. “한 번이 어렵지 두 번은 쉽다”라는 말이 있습니다. 이슈를 해결하는 과정에서 테스트 코드를 작성해보고 나니, 앞으로 프로젝트 진행에 있어서 중요하게 될 스킬을 배울 수 있었습니다.