들어가기 전에

안녕하세요. 2019 카카오 겨울 인턴십의 인턴으로 시작해 정직원으로 근무한 지 2달이 되어가는 파트너서비스개발 파트의 로빈입니다. 저는 이번 겨울 인턴십을 진행하며 기술을 익히고, 문제에 맞닥뜨렸을 때 해결해나간 과정과 카카오에서 일하는 방식을 경험하고 배운 과정에 대해서 소개하고자 글을 쓰게 되었습니다.

이제 막 새로운 곳에서 새로운 출발을 준비하시는 새싹 개발자분들이 가지고 계신 불안감은 조금이라도 덜어 드리고, 이미 그 시기가 지나가신 개발자분들에겐 나도 그땐 그랬지 하는 공감을 불러 일으키는 글이 되었으면 좋겠습니다.

경력 0년, 인턴 경험 0회, 공모전 0회

소위 말하는 ‘스펙’이 될 법한 경험이 전무했던 저는 겨울 인턴십에 합격하고 나서도 여러 고민에 휩싸였습니다.

‘한 번도 안 해본 것을 시키면 어떡하지?’

‘나는 깃으로 협업해 본 경험도 없는데 잘못 건드려서 큰일 나면 어떡하지?’

‘회사생활과 업무는 어떻게 하는거지?’

‘과연 내가 시간 내에 과제를 다 해낼 수 있을까?’

지금 저에게 누군가 저런 질문을 한다면 이렇게 대답해줄 겁니다.

’일단 하면, 된다! (대신 미친 듯이 해라)'

물론 당시에도 특유의 능청스러움과 긍정적 마인드를 발휘해서 당차게 인턴십을 시작하긴 했습니다. 맨땅에 헤딩할지언정 잃을 것보단 얻을 게 많을 것이란 걸 알고 있었거든요. 실제로 노트북과 공책과 펜을 들고 이리저리 다니며 어떻게든, 뭐라도 배우기 위해 많은 분들을 꽤 귀찮게 굴었습니다. 파트 내 크루분들은 물론이고 인턴 동기들에게도 말이죠. (제 버디(멘토)는 저에게 배우고자 애쓰는 모습이 보여서 열심히 알려주는 거라고 말씀하셨던 적도 있습니다.)

그리고 정말로 그 기간 동안 저는 많은 것들을 가져올 수 있었습니다. 누군가에게 제대로 된 피드백을 받아본 적이 없던 저였기에 그간 개발을 하며 옳다고 여겨왔던 것들이 그렇지 않았음을 깨달을 수 있었죠. 뿐만 아니라 코드를 짜고 시스템을 돌아가게 하는 것만이 전부가 아니며 결과만 보고 달리다 보면 나에게 남는 것이 과연 무엇일지 고민할 기회가 되어주었습니다. 이러한 과정이 있었기에 금새 잊어버리는 단발적인 경험을 넘어 성장으로 나아갈 수 있었다 생각합니다.

그렇게 난생 처음 보는 라이브러리를 접하곤 코드 한 줄을 짜는데도 몇 시간이 걸리고, 매일의 스크럼 시간에 일주일치 목표를 쏟아내던(❗️스크럼은 당일 할 일과 이슈만 이야기하면 됩니다.) 어리숙한 인턴은 어느새 2개월 차 카카오 크루가 되었습니다.

그럼 두 달간의 인턴십 동안 당근과 채찍 속에서 성장한 저의 이야기를 진행해보도록 하겠습니다.

한 단계씩 올라가기

1. 기술에게도 역사가 있다.

(내가 받은 인턴십 과제 기획서) 진짜 안 해본 일을 시키셨다.

안타깝게도 해 본 것보다 안 해본 것이 더 많은 건 저와 같은 주니어에겐 당연한 사실이며, 내가 해봤던 걸 시킬 거란 기대가 매주 로또를 사며 5등이라도 될 거라고 기대하는 것과 같다는 것을 그때는 몰랐습니다. 그래서 버디가 친절한 미소를 머금고 기획서를 보여주시자마자 저는 속으로 이렇게 외칠 수밖에 없었습니다. ‘왜 하필 캘린더야?’. 인턴십에 합격한 뒤 입사까지 여유가 있던 기간 동안 공부를 했는데 게시판을 만들까, 캘린더로 to-do 리스트를 만들까 고민하다가 결국 게시판을 만들었었거든요.

하지만 곧 받아본 ‘교육 과정’에 써보긴 한 것, 어디서 들어는 본 것, 태어나서 처음 보는 것이 다 섞여 있는 것을 보고 캘린더는 시작에 불과했단 것을 깨달았습니다. 그래도 불행 중 다행이었던 것은 버디가 오전 업무 중 일부를 다양한 기술의 개요를 알려주는 교육 시간으로 사용하셨다는 것입니다!

교육 시간마다 버디는 열정적으로 여러 기술의 역사를 이야기해 주셨고, ‘왜 그 기술이 생겨났는지 알면 언제, 어떻게 써야 할지 예측 할 수 있다.’는 가르침은 기능을 중점적으로 공부해온 제게 새로운 공부 방향을 제시해주었습니다.

(좌측: wiki에 정리한 선행학습 목록, 우측: web의 역사에 대해 정리한 내용의 일부)

그때부터 버디의 교육과 더불어 책과 웹, 때때로 크루들에게서 얻은 지식을 파트 내 wiki에 정리해 나갔습니다. 특정 기술이 나타날 때까지의 발전 과정과 여기서 생기는 문제점들, 그로 인해 또 새롭게 생겨난 기술들을 비교하며 흐름을 이해하기 위해 노력했습니다. 이를 통해 자연스럽게 각 기술의 장단점을 깨달을 수 있었고 추후에 선택지가 생겼을 때 이를 기반으로 ‘제 나름’의 합리적인 선택을 수행할 수 있었습니다.

앞으로 누군가가 ‘왜 이 프로젝트에 A를 쓸 생각을 했지?’라고 물을 때, ‘이게 요즘 뜨는 기술이니까, 다들 이걸 쓰니까~’라는 말로 뭉뚱그리던 과거의 제가 아닌, ‘A는 이런 이유로 B보다 여기에 적합해’라고 자신 있게 대답할 수 있는 사람이 되기위해 지금도 이 학습법을 이어가고 있습니다.

2. 치트키는 없다.

치트 코드(영어: cheat code) 또는 치트키(영어: cheat key)는 비디오 게임 진행 중에 더이상 진행이 불가능할 때 일종의 속임수로 사용하는 방법이다. (출처: wikipedia)

이 글을 읽고 계신 독자분들께서는 구글링에 대해 어떤 견해를 가지고 계신가요?

저에게는 구글은 제가 원하는 모든 것을 뚝딱 가져다주는 마법의 검색 엔진이라는 생각이 있었습니다. 하지만 인턴십을 진행하면서 제 생각이 완전히 틀렸다는 것을 깨달았습니다. 오히려 정리되어 있지 않은 아주 큰 도서관 같은 느낌을 받았죠. 필요한 것을 찾아내는 것 또한 제 능력이었거든요.

이따금 질문을 하면 파트원 분들은 한참 설명을 해주신 뒤에 그럼 그다음은 검색하면 나오겠죠? 라고 끝을 맺곤 하셨습니다. 그리고 전 꽤 많은 시간을 구글링에 투자했음에도 번번이 실패했습니다?. 혹은 정답을 찾는 데까지 너~무 많은 시간을 들였거나요.

검색에 실패하면 저는 이런 결론에 이르기도 했습니다.

?? : 아! 내가 지금 필요로 하는 이건 아무도 안 해본 거고(?) 내가 만들어야겠구나!

그렇게 열심히 짠 코드를 보곤 버디는 이렇게 말씀하셨습니다.

??‍ : 너는 문제를 해결하기 위해 문제를 만들고 있구나

분명히 문제를 해결하기 위해 적절히 사용할 수 있는 API들이 존재했을 것이지만 이를 알아내지 못하는 것이 일차적인 문제였습니다. 우선, 제가 사용하고 있는 많은 라이브러리와 프레임워크 중 어떤 것을 이용해야 할지도 파악하기 힘들었고, 해당 기술의 API를 검색하기 위한 핵심적인 키워드를 뽑아내는 것도 서툴렀기 때문이었죠.

이와 관련된 일례를 가져와 보았습니다.

TimeZone 관련 문제를 해결한 과정

요약하자면 배포 후 사용자 화면에 나타나는 날짜가 데이터베이스에 저장된 날짜와 다르게 보이는 이슈가 생겼고, 사용한 프레임워크와 라이브러리는 FE, server를 통틀어 6개나 되었습니다.

전 고민에 빠졌습니다. 대체 뭘 기준으로 검색해야 할지 모르겠더라고요. 대책 없이 LocalDateTime 변환이나 캘린더 날짜 변환 오류라던가 하면서 아주 광범위하게 검색하기 시작했습니다. 다행히 이번에는 옆에서 지켜보시던 버디가 무턱대고 해결하려고 할 게 아니라 우선 문제 발생지점을 정확히 찾아야 함을 지적해 주셨기에 산으로 가지 않을 수 있었습니다.

그리고 문제 발생지점을 찾는 방법이 왜 중요한지에 대한 설명을 들으면서 해결 방안의 핵심을 빠르게 찾지 못했던 이유와 해결 방법에 대해 생각할 수 있었습니다.

원인 : 문제가 어디서 시작됐는지 파악하는 방법을 몰랐다. (혹은 시도하지 않았다.) 결과 : 사용 중인 다양한 라이브러리와 프레임 워크 중 어떤 것을 선택해 해결법을 찾을지 알 수 없다. 해결 방법 : 데이터의 흐름을 따라 순차적으로 문제의 시작 지점을 파악한다.
원인 : 특정 기술들이 지원하는 기능에 대한 이해가 부족했다. 결과 : API를 검색하기 위한 핵심적인 키워드를 뽑아내기 힘들다. 해결 방법 : 도큐먼트를 통해 이해의 폭을 넓히도록 한다.

검색 엔진에 대한 믿음과 의존이 저를 위와 같은 원인까지 도달하게 했음을 알게 되었습니다. 즉, 저는 ‘빨리 고치고 보자’는 생각(오히려 빠르게 해결할 수 없었지만요??)에만 사로잡혀 검색에 의존하고, 그 이전에 제가 먼저 해야 할 것들을 그냥 넘겨버리고 있었음을 깨달았습니다. 첫 번째 문제는 착실하고 순차적인 디버깅을 통해 해결할 수 있었기에 큰 무리가 없었습니다. 진짜 문제는 두 번째 문제였습니다.

도큐먼트를 읽는 것은 아주 기본 중의 기본이라고 많은 분들이 말씀하시겠지만 영어 울렁증을 겪고 있는 저에게 그건 알면서도 피하고 싶은 숙제 중 하나였습니다. ‘요즘 잘 정리된 블로그도 많은데’ 하면서 제쳐두고 있던 일이었죠. 그리고 결국 그 숙제를 펼쳐봐야 할 타이밍이 온 것이었습니다. 핵심만 골라 읽어야겠다는 생각이 들긴 했지만 초급자인 저에겐 마땅한 기준을 세울 경험과 지식 또한 많이 부족했습니다.

결국 제가 선택할 선택지는 모 아니면 도였습니다.

도큐먼트 읽기를 포기하고 이전처럼 누군가가 정리한 글을 본다.
혹은, 중간에 그만두더라도 처음부터 차례대로 읽어나 본다.

당연히 저는 후자를 택했고 이해가 잘 안 가는 부분에 대해서는 다른 글을 참고하기도 했습니다. 그렇게 처음 읽게 된 것이 도큐먼트의 서론(혹은 요약이라 표현된 것)이었습니다. 다행히 어느 정도의 역사는 알고 있었고, 자세한 이야기는 이 구간에서 다뤄지지 않았기에 상대적으로 짧은 시간 내에 읽어낼 수 있었습니다. 또한, 대게 서론에는 핵심 용어나 기능을 언급하기 때문에 어느 부분을 조금 더 깊게 공부해야 할지 파악할 수 있었죠.

처음으로 읽은 것은 Querydsl이었는데, 양이 많은 편이 아니라 지하철로 출퇴근하며 읽을 수 있었다.

물론 제가 사용한 모든 프레임워크와 라이브러리의 도큐먼트를 독파한 것은 결코 아닙니다. 몇 가지의 기술에 대해 가능한 최소한의 독해로 컨셉과 핵심 API를 파악하는 것이 목표였거든요.

결과적으로 그 선택은 나쁘지 않았습니다. 도큐먼트 번역에 너무 많은 시간을 투자하지 않으면서, 검색 범위를 좁히기 위한 지식을 가져가자는 저의 최초의 목표는 달성할 수 있었기 때문입니다. 어림잡은 추측으로 엉뚱한 데에서 삽질하기보다 문제가 생긴 곳을 파악하고, 그 지점에서 사용된 기술 중 문제를 해결하는데 쓸만한 API를 제공할 법한 것을 추측할 수 있게 되었습니다. 백발백중은 아니었지만 적어도 선택지를 몇 가지 추려내는 것만으로도 많은 시간을 아낄 수 있었죠.

지금 생각해보면 저는 구글링이라는 치트키를 이용해 부족한 경험을 메꿔줄 요령을 찾아 헤맸지만 결국은 확실한 디버깅과 기술에 대한 근본적인 이해라는 기본에 충실해야 함이 키포인트가 아니었나 싶습니다. 너무 식상한 이야기인가요? 하지만 저는 덕분에 검색 엔진에 대한 의존성을 많이 낮출 수 있었을 뿐만 아니라, 도큐먼트의 중요성을 느낄 수 있었기에 최근에는 이를 해석하는 데에 다시 한번 노력을 기울이고 있습니다.

지난 3월에 번역한 Redux 도큐먼트

3. 시행착오는 시간 낭비가 아니다.

당연히 최소한의 배경 지식이 추가됐다고 앞날이 꽃길로 바뀌지는 않았습니다. 완전히 이상한 곳에서 헤매고 있지는 않았을 뿐이지 삽질은 늘 저와 함께했습니다.

그도 그럴것이 위에 언급한 내용들은 기술적 문제를 해결하는 과정에 도움을 주는 부가적인 요소이고 적절하게 활용하는 것은 온전히 저의 몫이었으니까요. 장인은 도구를 가리지 않는다지만, 초심자는 최고의 도구를 가져다줘도 어떻게 써야할지 수십개의 물음표가 머리에 떠오릅니다.

(출처 : 구글 이미지 검색) 코딩을 하는 우리네 모습

모르는 것은 당연하니 그 다음 고민은 ‘이걸 혼자서 얼마나 시도해 본 뒤 물어봐야할까?’ 였습니다. 그래서 저는 문제에 맞닥들이면 다음 스탭을 밟기 전 두 가지를 생각하기 시작했습니다.

하나. 지금 내가 집중해야할 핵심 요소인가 이를 서포팅 해주는 부가적인 요소인가
둘. 일정을 생각했을 때 이 문제에 얼만큼의 시간을 투자할 수 있을만큼의 여유가 있는가

결론적으로 제가 처한 문제에 꽤 많은 시간을 투자하는 것이 합당할 때가 많았습니다. 즉, 많은 시간을 삽질에 투자할 여유가 있었죠.

그렇게 저는 자정이 넘도록 디버깅을 하고도 해결하지 못한 버그가 다음날 파트원의 도움으로 불과 몇 분만에 깔끔하게 풀리는 것을 본다거나, 겨우 해결했다 싶으면 또 다른 문제가 터지는 상황들을 꾸준히 겪게 됩니다. 어느 순간부터 버디의 아침인사가 ‘어제는 무슨 삽질했어?’ 가 될 정도로 말입니다.

직접 그려본 삽질의 뫼비우스

그 과정 동안 제 자신이 너무 부족하다고 생각되기도 하고, 답답함에 머리를 (말 그대로) 쥐어짜기도 했습니다. 하지만 어느 순간부터 왠지 모르게 ‘이렇게 하면 될 거 같은데?’ 라던가 ‘이걸 쓰면 될 거 같은데?’ 같은 생각들이 떠올랐고, 단숨에 문제들이 해결되는 것은 아니었지만 이전보다 빠르게 해결책에 도달할 수 있었습니다. 이는 한 가지 문제를 해결하기 위해 온갖 방법을 시도해 보면서 알게 모르게 얕은 지식이 쌓였기 때문이라고 생각합니다.

실제로 그 과정에서 처음 보는 라이브러리나 API를 많이 접할 수 있었기에 저의 부족한 경험이란 큰 공백이 이런 시행착오를 통해 채워지고 있었을지도 모르겠습니다. 단순히 하나의 목표 지점을 향해 앞만 보고 학습하고 있던 시기였다면 지금 굳이 알아야 할 필요가 없을 거란 생각에 눈으로 쓱 보고 지나쳤을지도 모르겠습니다. 하지만 당장 문제를 풀어야 하는 상황에서는 이 시도해볼 만한 것을 그냥 지나칠 수는 없는 일이었죠.

아래에 첨부된 이미지에서 트랜잭션 이벤트 리스너도 결과적으론 문제를 해결하는 정답은 아니었지만 저렇게 삽질을 해댄 덕에 이를 처음으로 공부하고 사용해 볼 수 있었습니다. 꼭 트랜잭션이 아니더라도 언젠간 유사한 문제가 발생했을 때 저는 이벤트 리스너를 하나의 해결책으로 떠올리지 않을까요?

눈물없인 볼 수 없는 JPA 삽질기의 일부

이런저런 시행착오를 겪고, 다양한 코드를 접해보면서 모든 문제의 해답이 늘 하나만 존재하는 것은 아니다라는 시사점을 또한 얻을 수 있었는데요. 덕분에 하나의 방식이 대체 불가한 1등 공식이라는 편견을 가지는 것에 대해 경계할 수 있었습니다.

다시 저의 삽질에 대해 논해보면, 모든 시행착오와 그 과정에서 배운 것들이 깔끔하게 머릿속에 정리되는 것은 당연히 아니었습니다. 너무 많은 정보를 단편적으로 접하다 보니 이내 복잡해질 수밖에 없었죠. 그래서 이 문제 해결 과정을 wiki에 기록하기로 마음먹게 됐습니다. 익힌 것들과 새롭게 익힐 것들을 잘 정리하고 잊지 말자는 목적으로 말입니다.

그렇게 client에서 server로의 데이터 전달 문제, LocalDate설정 등 사소한 것들부터 코드 리팩토링 과정이나 배포 문제 해결, 가장 많이 고생했던 JPA까지 많은 시간을 투자했거나 누군가의 도움을 받았던 이슈를 위주로 글을 쓰기 시작했습니다. 결과적으로 처음 목표했던 것 이상으로 많은 것을 얻었고 이 기간에 가장 많이 성장할 수 있었습니다.

왜 잘못된 방향으로 진행되었는가에 대한 언급

우선, 문제를 풀어나갔던 과정을 복기하면서 왜 그때 그렇게 생각했고 어느 포인트에서 잘못 짚게 됐는지 스스로 피드백할 수 있었습니다. 그리고 문제를 해결하는 과정에서 급하게 보고 넘어갔던 부분은 포인트를 잘 체크해 둠으로써 잊지 않고 다음에 다시 한번 공부할 수 있었죠. 어디서 본 거 같긴 한데 뭔지 모르겠는? 이슈들이 생겼을 때는 때때로 그 기록이 빠르게 해결책을 찾는 노다지가 되기도 했습니다.

그뿐만 아니라 이런 시도는 해봤나요? 라는 질문이 나오기 전에 제가 시도해 본 것들을 이야기할 수 있었는데요.

제가 이러이러한 시도를 해보았는데 A라는 결과가 나오며 여전히 해결이 안 됐습니다. 그래서 B라는 부분이 문제라고 생각하는데 해결할 방안이 생각나지가 않네요

라는 설명은 저의 선택에 대한 문제점을 함축하고 있다고 생각합니다. 따라서 저의 접근방식이 근본적으로 잘못되었다면 그 원인을, 혹은 해결하는 과정이나 코드에 문제가 있었다면 어느 부분인지 구체적으로 들을 수 있었죠.

맨 마지막에는 항상 코멘트를 작성했다.

당시에 써둔 글들을 다시 읽어보니 정말 말도 안 되는 곳에서 시간을 낭비한 것 같기도 하고, 왜 이상한 곳에 꽂혀서 파고들고 있지? 하는 생각이 들긴 하더라고요(ㅋㅋ). 하지만 그런 과정이 없었다면 많은 경험은 고사하고, 당장 필요한 부분만 보고는 이후에 또 비슷한 삽질을 반복할 수도 있었을 겁니다. 제가 삽질로 괴로워할 때 마다 ‘지금 이것저것 많이 해봐, 그래야 나중에 안 하지’ 라며 다독이던 버디의 이야기가 이제서야 공감이 되네요.

실제 업무에선 정해진 기한 내에 주어진 일을 해결하기 위해 혼자 고민하는 시간을 줄여야 할 수도 있고, 무언가를 엉망으로 만드는 일은 없어야 할 것이라 생각합니다. 너무 바빠 기록을 남기는 것은 더욱 힘들 수도 있겠죠. 이렇게 생각하니 지난 두 달 동안 잘 모르는 것을 고민하고 피드백 받은 내용을 기록하며 시행착오란 경험을 충분히 겪은 것이 얼마나 값진 시간이었는지 다시 한번 깨닫게 됩니다.

여기서 끝이 아니라, 앞으로도 저만의 토이 프로젝트를 통해 또 다른 삽질을 하면서 더 많은 것을 경험하고 배워나가야 할 것입니다. 하지만 이전만큼 막막하거나 답답하지는 않으리라 생각합니다! 지금은 그 과정이 있어야 제가 한 단계 더 성장할 수 있음을 알고 있으니까요.?

일하는 방식 알아가기

(출처: 카카오 영입)

인턴십을 진행하는 동안 프로젝트를 개발하며 얻은 개발자로서의 기술적 성장과 깨달음 외에도 ‘일’하는 방식을 익힐 수 있었습니다. 물론 제 프로젝트는 개인 프로젝트였기에 협업의 과정은 없었지만, 2달 동안 어떻게 일하는지 파악하기에 적절한 경험을 했다고 생각합니다. 회의에 참석하고, Jira를 관리하고, 스크럼을 진행하고, 마지막으로 회고를 하기까지의 일련의 과정을 통해서 말입니다.

다음의 이야기들은 제가 소속해있는 파트에서의 경험을 기반으로 썼기 때문에 팀 마다 상이할 수가 있음을 염두에 두고 읽어주세요.

1. 회의에 참석하다.

회의하는데 같이 들어가자는 버디를 따라 회의실에 도착한 저는 살짝 당황했었습니다. 파트 내 회의인 줄 알았는데 처음 뵙는 분들이 자리에 앉아 계셨거든요??. 당시 저는 파트에서 정확히 어떤 업무를 하는지 전혀 모르는 상태였고, 함께 들어오신 분들이 기획팀 분들과 FE 개발자분들이셨단 것도 회의가 진행되면서 눈치챘습니다. 회의에 참석하신 분들이 언급하시는 단어에 대해서도 이해 못할 것들이 많아 회의실을 나오면서 크루에게 물어보곤 했죠. 그만큼 회사 업무가 어떻게 돌아가는지에 무지한 때였습니다.

하지만 그런 저도 회의에 참석하면서 몇 가지를 깨달을 수 있었습니다!

스프린트가 한 과제를 수행하는 단위가 된다.
스프린트가 종료되는 날에 회의를 진행한다.
기본적으로 업무는 기획서를 바탕으로 진행한다.
회의에서 각 과제에 대한 우선순위와 일정 조율이 이뤄진다.

저도 인턴십 과제를 통해 기획서를 살짝 맛본 적이 있었지만, 굉장히 간소화된 형태였고 실제 파트 업무를 위해 전달받는 기획서는 훨씬 복잡하고 많은 기능이 포함돼있었습니다. 그 기획서를 분석하고 업무 산정을 하는 것도 개발자의 몫이란 것 또한 회의를 통해서 알게 되었죠.

그리고 이 과정이 제 인턴 프로젝트에서도 유사하게 이뤄지고 있었습니다. 물론 체계적인 스프린트를 기준으로 이뤄지진 않는다는 점만 뺀다면요.

요구사항을 달성하면 추가할 기능에 대해 논의한다.
모든 업무는 요구 사항에 맞춰 진행한다.
논의를 통해 구현할 기능에 대한 우선순위를 정한다.

제 프로젝트는 프로토타입으로 점진적 개발을 수행하고 있었기에 며칠 간격으로 요구사항이 바뀌었습니다. 따라서 계속해서 변화하는 요구사항에 맞춰 작업해야 할 것들을 정리하고 진행해나가는 과정을 반복하고 있었고요. 이런 개발 요청이 기획서가 아닌 구두로 전달되었을 뿐이지 비슷한 맥락으로 진행되었기 때문에 실제로 일하는 것과 비슷한 경험을 하는 기회가 되지 않았나 생각합니다.

뿐만 아니라 저는 프로젝트에 새로 추가할 기능이나 수정이 필요한 요구사항에 대해 제가 가지고 있던 의견들을 조심스럽지만 나름 적극적으로 펼치고자 노력했었는데요. 이를 통해 버디와 앞으로의 일정에 대해 만족스럽게 조율해 나갈 수 있었습니다. 실제 회의에서도 각 분야의 크루들의 대화를 통해 개발 일정을 맞추고 우선순위를 정하는 모습을 보면서 전체적인 맥락은 크게 다를 것 없음을 느낄 수 있었죠.

저 뿐만이 아니라 많은 사회 초년생분들이 첫 직장을 생각했을 때 가장 먼저 회의나 토론같은 것에 대한 막연한 두려움을 떠올리시지 않을까 생각합니다. 하지만 저는 인턴 기간에 짧게라도 이를 경험해 봄으로써 그런 두려움을 차츰 지워버릴 수 있었습니다! 물론 언젠가 여러 사람들 앞에서 제 주장을 펼치고 부딪혀야 하는 날이 올 것을 생각하면 조금 떨리기는 하지만 적당한 긴장감을 유지하되 굳이 두려워하지 않아도 되겠다는 생각을 할 수 있게 되었죠.

2. Jira를 통해 업무를 관리하다.

지라(JIRA)는 아틀라시안이 개발한 사유(proprietary software, 독점 소프트웨어) 이슈 추적 제품이다. 버그 추적, 이슈 추적, 프로젝트 관리 기능을 제공하는 소프트웨어이다.

인터넷으로 ‘신입 사원 준비물’을 검색하면 뜨는 것 중 하나가 바로 다이어리였습니다. 본인의 업무 일정을 기록하기 위해서 반드시 준비해야 한다고 쓰여 있었는데요. 안타깝게도 첫날 가져간 다이어리는 그대로 구석에서 먼지만 쌓이게 됐습니다. Jira를 이용해서 온라인으로 모든 개발 일정을 관리하였거든요. (물론 회의 등의 개발 외 업무는 아닙니다.)

처음 Jira를 접했을 땐 뭐가 뭔지 1도 모르겠다는 말이 가장 적절할 것입니다.

처음에는 너무 익숙하지 않은 탓에 티켓 이름은 어떻게 지어야할지, 종류는 뭐로 선택해야 할지, 체크리스트는 어떻게 선정해야 할지 한참을 고민하기도 하였습니다. 심지어 개발을 진행하다가 티켓을 생성하지 않았음을 깨닫고 뒤늦게 티켓을 생성한 적도 있었습니다. 버디가 미리 만들어 둔 티켓이 몇 개 있었는데 비슷하게나마 따라 해보려고 노력했던 기억이 나네요.

저에게 한 줄기 빛이었던 것은 버디가 Jira 사용법에 대해 발표까지 하신 분이셨던 거죠.? 덕분에 영상과 발표자료를 얻어 이를 정리하고 열심히 컨닝(ㅋㅋ)하면서 익혀나갔습니다.

Jira에 익숙해지자 출근 후 처음 할 일은 자연스레 Jira에 들어가 오늘 해야 할 일을 체크하고, 미처 생성하지 못한 티켓을 생성하는 것이었습니다. 개발 기간은 한 달이 조금 넘었기 때문에 저는 한 주를 스프린트로 잡았었는데요, 처음에는 버디가 이 스프린트를 관리해 주시다가 제가 Jira에 익숙해진 것 같으니 권한을 넘겨 주신다고 했을 땐 그래도 잘하고 있구나하는 생각이 들어 꽤 뿌듯했었답니다.

(좌: 생성한 티켓들, 우: 개발 기간 동안의 티켓 진행 그래프)

이를 사용하면서 가장 좋았던 점은 매일 아침 내가 오늘 할 일을 다시 한번 체크할 수 있게 하고, 그날 해야 할 일들을 산정하면서 일정을 간편하게 관리할 수 있었다는 것입니다. 그리고 start date와 due date 설정을 통해 딜레이되고 있는 업무를 확인하고, 어떤 일부터 진행할지 우선순위를 재조정 할 수 있었습니다. 솔직히 Jira 홍보대사 아니냐 할 정도로 좋았던 점들을 구구절절 나열할 수도 있을 거 같아요.

또한 Jira가 제 개인적인 업무 일정을 관리하고 체크하는 것에 큰 이점이 있는 것도 사실이지만, 협업에서 더 빛을 발함을 알게 됐는데요. Jira 내 같은 프로젝트에 포함된 크루라면 누구든지 지금 무슨 일을 하고 있고 얼마나 진행했는지, 혹은 앞으로 어떤 일을 할 예정인지에 대해서 한 눈에 볼 수 있기 때문입니다. 이는 투명한 업무공유라는 카카오의 일하는 방식에도 일맥상통하죠. 특히 다음에 나올 스크럼에서는 이 Jira 스프린트 보드를 통해 일과와 이슈에 대해서 얘기하기 때문에 단순히 업무 관리를 넘어서 의사소통에도 유용한 도구로 사용됨을 알 수 있었습니다.

전환 후 팀 프로젝트에 초대된 후 추가로 알게 된 걸 말씀드리자면, Jira 프로젝트를 저희 서버 개발팀뿐만 아니라 FE와 기획팀 분들도 함께 공유하고 있었습니다. 따라서 일정을 공유하고 요구사항을 티켓으로 발행함으로써 더 투명하고 효율적인 관리가 이루어짐을 느낄 수 있었습니다. 충분한 내용을 포함하여 티켓을 만들기 때문에 티켓 이름이나 링크를 공유하며 의사소통에도 도움이 되고 있었고요.

처음으로 팀 프로젝트에 만든 티켓

물론 실제 업무에선 훨씬 규격화된 규칙을 바탕으로 지라 티켓이 관리되고 있었으므로 다시 한번 사용 가이드를 숙지할 필요가 다분했습니다. 하지만 미리 경험해 보았기 때문에 낯설지 않았다는 것이 큰 위로가 됐죠! 사용 중인 IDE에 이를 연동하여 새 브랜치를 생성한다거나, 티켓 담당자를 할당하고 업무 진행에 맞춰 어떤 것들을 설정해야 하는지 같은 것들을 포함해서 말입니다. 인턴 기간 동안 이를 규격대로 완벽하게 해낸 것은 아니었지만 익숙함이 있었기에 빠르게 익힐 수 있었다고 생각합니다.

3. 스크럼과 스프린트 회고

스크럼

스크럼(Scrum)은 프로젝트관리를 위한 상호,점진적 개발방법론이며, 애자일 소프트웨어 공학 중의 하나이다. 스크럼(Scrum)은 소프트웨어 개발 프로젝트를 위하여 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있다.

스프린트마다 바뀌는 스크럼 마스터가 스크럼을 진행한다.

처음 회의하러 가자는 이야기를 들었을 때 ‘회의요?’라며 놀랐던 이유는 저는 저희 팀 업무와는 별개인 저만의 인턴 과제를 수행하고 있었기 때문이었습니다. 그래서 팀 업무를 위한 회의에 저를 초대해주셨을 때 비록 다른 일을 하는 인턴일지라도 팀이 일하는 방식에 대해서 경험할 기회를 준단 것이 너무 좋으면서도 놀랍기도 했습니다. 같은 맥락에서 ‘스크럼 하러 가야지’ 라는 이야기를 들었을 때도 (늘 그렇듯 1초 만에 알겠다고 대답했지만) 이런저런 생각이 들었습니다.

?? : 네! (근데 스크럼이 뭔가요…)

눈치껏 버디를 따라간 곳은 몇 발자국 안 떨어진 크루의 자리였습니다. 알고 보니 스크럼은 Jira의 스프린트 보드를 보며 각자 하고 있는 업무와 이슈에 관해서 이야기하는 시간이었습니다. 위에서 잠깐 언급했듯이 Jira 티켓 제목에는 업무 내용이 무엇인지 함축적으로 드러나 있었으므로 스크럼 시간에 활용하기에도 좋구나 하는 생각이 들었죠. 뿐만 아니라 보드는 티켓 상태에 따라 순차적으로 나뉘어있고 크루 이름으로 필터링할 수 있었기 때문에 설명을 들으면서 동시에 한눈에 업무를 파악할 수 있었습니다.

저는 파트 프로젝트가 아닌 개인 프로젝트 보드에 포함되어 있었기 때문에 파트원분들의 스크럼이 끝나면 제 프로젝트로 들어가 일정을 공유하였습니다.

처음 스크럼에 참여하고 며칠 동안은 앞서 다른 크루들이 진행하시는 것을 보고 들으면서 눈치껏 따라 하려고 했으나 투 머치 토커인 저는

?? : 지난주에 뭘 하려 했는데 일정이 밀려서 이번 주까지는 어쩌고… 어제는 어쩌고저쩌고…

하며 구구절절 이야기하다가 버디에게 ‘스크럼은 오늘 할 일과 이슈만 간단하게 이야기하면 된다’ 는 조언을 듣고 그 후에는 착실하게 오늘의 업무만 얘기하게 된 머쓱했던 경험도 있습니다.

이뿐만 아니라 스크럼 시간에 이슈를 알리기도 한다고 말씀드렸는데요. 이를 통해 일정이 빠듯하면 티켓 담당자를 조정하거나, 스크럼이 끝나고 코드를 보며 간단하게 리뷰를 하고 의견을 공유하기도 하였습니다. 저는 이따금 프로젝트를 진행하는 데 겪고 있는 문제점에 대해 도움을 요청하거나 누군가의 도움을 받아 해결한 것이 있다면 이를 언급하곤 하였답니다.

스프린트 회고

(팀 위키) 처음으로 작성한 회고

드디어 마지막! 스프린트 회고입니다.

회고도 스크럼 마스터가 진행하였는데요. 스크럼이 매일 스크럼 마스터의 자리에서 간단하게 진행되는 것과는 다르게 회고는 따로 회의실을 잡아서 진행하였습니다. 팀마다 이런 사소한 부분에 대해서는 상이하리라 생각됩니다.?

스프린트 회고는 말 그대로 이번 스프린트를 지내면서 느낀 점들에 대해서 솔직하게 공유하는 시간이었습니다. 저는 주기적으로 지난 일을 되돌아보고 그간 있었던 일들을 반성하거나 미래를 계획해 본 적이 없었기 때문에 꽤 신선한 경험이었습니다. 실제로 2주간 제가 했던 일들과 생각했던 것들에 대해서 돌아볼 기회가 되었거든요.

위키 내 회고 페이지의 제 자리에 빈칸을 채우기 위해서 곰곰히 생각하다 보면 부족했던 점이 가장 먼저 떠올랐습니다. 그리고 마냥 제가 대책 없이 있는 것이 아니라 앞으로 어떻게 개선해 나갈지에 대한 (추상적일지라도) 계획이 있음을 공개적으로 얘기함으로써 한 번 더 이를 다짐할 수 있었습니다. 그래서 저는 꼭 그다음 회고 때는 이전에 개선할 점으로 이야기한 것을 어떻게 실천했는지, 결과는 어떤지 얘기하도록 하였답니다.

처음 온보딩 때 들은 카카오의 일하는 방식 중 100:0 법칙과 신충헌(신뢰, 충돌, 헌신)이 가장 기억에 남는 이유는 이를 몸소 체험할 수 있었기 때문이라 생각합니다. 업무를 투명하게 공유하고, 필요한 것이 있다면 도움을 요청하고 이에 응하며, 의견을 나누고 대화하는 방법들이 모두 그 안에 녹여져 있었습니다. 당시 인턴 신분이었던 저에게도 동등하게 말이죠.

이런 모든 것들이 회사 경험이 전무했던 저에게 미지의 세계였던 회사 업무가 어떻게 진행되는 것인지, 그 안에서 나의 역할은 무엇인지, 일을 하면서 어떤 마음가짐과 태도를 가져야 할지에 대한 적절한 답을 찾도록 도와주는 너무나도 값진 경험이 되어주었습니다. 물론 100퍼센트 회사 생활만으로 혼자 깨닫고 혼자 습득한 것은 결코 아닙니다. 그 바탕엔 함께 카카오에서 생활하며 저에게 많은 조언은 아끼지 않으신 버디를 비롯한 파트원분들이 있었기 때문이겠죠.

2달이라는 기간 동안 나름의 노력을 기울여 따라 해본 것들도 있는 반면에 곁에서 지켜본 것이 다인 것도 있습니다. 아직 경험하지 못한 것도 많을 수밖에요. 하지만 실제 업무에 투입되었을 때는 그때의 기억을 되살려, 미숙할지언정 인턴 시절처럼 땀을 삐질삐질 흘리지 않을 수는 있을 것이라 믿습니다.

글을 끝맺으며

2달간의 경험이 단순히 ‘기술’을 배우는 것과 ‘업무수행 방식’을 익히는 것뿐만이 아니었다고 확신합니다. 제가 가지고 있던 나쁜 습관을 고치고, 기술을 대하는 태도와 책임 의식도 배울 수 있었죠. 바로 이것이 제 성장이었고 앞으로의 또 다른 성장을 위한 좋은 밑거름이 되어주리라 생각합니다.

그간의 제 성장을 한마디로 정의하자면 0에서 1로일 것입니다. 회사 경험도 프로젝트 경험도 너무나도 부족했던 제가 2달 동안의 겨울 인턴이라는 짧다면 짧고 길다면 긴 기간을 통해 이제 한 발짝 앞으로 나아갔다고 생각하거든요. 앞에서 잠깐 1도 모르겠다는 말을 사용했는데, 이제 1은 아는 사람이 되었기를 기대합니다.

인턴 합격 메일을 받았을 때의 순간을 아직 잊지 않고 있습니다. 너무 좋아서 동네방네 소문내곤 무조건 정규직으로 전환될 거야! 라며 허세 섞인 카톡을 지인들과 주고받았던 기억이 납니다. 인턴 동기들과 저녁 도시락(무료랍니다?)을 시켜 먹으며 이정도 밥이면 맨날 야근해도 되겠다고 농담을 하고 긴장을 풀던 것과 주말에도 쉬지 않고 프로젝트에 매진했을 때의 열정도요.

인턴 합격 메일을 받은 순간부터 정규직 합격 메일을 받은 순간까지, 두려움과 설렘이 공존하던 그때를 항상 기억하면서 1이 아니라 2는 아는 사람이 되기 위해서, 그다음엔 3은 아는 사람이 되기 위해 카카오에서 한 단계씩 나아가기를 다짐합니다.

비단 무언가의 시작점에 서 있는 분들이 느끼는 걱정이나 답답함이 혼자만 느끼는 감정이 아님을 기억해주셨으면 좋겠습니다. 제가 인턴 기간을 지내면서 자주 망치고 틀릴 때, 가장 위로가 됐던 한마디는 ‘괜찮아, 나도 그땐 그랬어’ 라는 말이었습니다. 뻔한 이야기일 수도 있겠지만, 누구에게나 처음은 있고 처음부터 완벽할 수는 없음을 인정하는 것이 성장의 시작점이라고 생각합니다. 그러니 너무 두려워하거나 자신을 탓하는 대신 본인이 미약하게라도 나아가고 있음을 믿고 다독여주길 바랍니다.

마지막으로, 이 글을 읽는 당신이 취업을 위해 날마다 치열하게 살아가는 취준생이거나, 이제 막 개발에 첫발을 내딛는 분이라면 다시 한번 이 마법의 문장을 기억해주세요!

일단 하면, 된다! (대신 미친듯이 해라)

긴 글 읽어 주신 모든 분들께 감사드립니다.

2020 여름 인턴십 절찬 모집중! 지원하러 가기

서버 개발 인턴 robin의 성장기