지난 프로그래머스 데브코스(FE)에서 나는 무엇을 얻었을까

현재 프로그래머스 데브코스를 수료한지 2개월 하고도 반절 정도가 지난 시점, 저는 6개월간의 프로그래머스 데브코스 과정에서 무엇을 배웠을까요?

저는 데브코스를 처음 시작했을 때, 막연하게 아래 사진과 같은 목표가 있었습니다. 아래 사진은 데브코스 자기소개란에 적어두었던 저의 목표입니다 ㅋㅋㅋ 부끄럽네요 ㅎ

데브코스 자기소개에 적어두었던 나의 목표

 

시간이 지나 다시 되돌아보니 어떤 기술을 얼마만큼 알았고, 어떤 기술을 사용해보았고, 코딩테스트 실력이 어떻고 이런것 보다 저는 개발자로서 커리어를 이어나가는 데에 중요하다고 생각되는 부분을 배운 것 같습니다.

 

문제가 아니어도 문제로 삼는 법(스스로 성장하는 법)

우리는 늘 삶 속에서 문제를 마주하지만, 누군가는 문제를 마주하지 않을 수 있습니다. 하지만 문제가 되지 않을 것을 문제를 삼는다면, 그것은 문제가되죠. 저는 데브코스 내에서 문제가 되지 않을 수 있는 것을 문제로 삼는 방법을 배웠습니다. 음.. 이게 무슨 말일까요?

 

우선 저는 문제에 대해 깊에 고민하는 사람이 아니었습니다. 이를 코드에 빗대어 생각해봤을때, 내가 작성한 코드가 정상적으로 돌아간다면 크게 문제삼지 않고 다음 작업을 이어나가는 사람이었죠.

 

하지만 데브코스 팀 동료들과 멘토님들은 달랐습니다. 이 또한 코드에 빗대어 생각해봤을때, 본인이 작성한 코드가 잘 돌아가더라도 이 코드의 네이밍은 적절한지, 이 코드가 효율적인지, 성능상에 문제점은 없는지, 의존성 분리는 적절하게 되어있는지, UX 측면에서 바라봤을 때 효과적일지 등 계속해서 A와 B를 비교하며 다양한 방면으로 계속 문제를 스스로 만들어내셨습니다.

 

간단한 예시로 최근 작성했던 prefetching에 관한 내용에 작성해 놓은 상황을 생각해볼 수 있겠죠.

대박사건 프로젝트의 페이지 일부분

 

간단히 말씀을 드리자면, 위 사진은 2차 프로젝트에서 진행했었던 `대박사건`이라는 익명/기명 편지서비스입니다. 위 페이지에서는 박을 클릭하면 박속에 들어있던 편지들이 나타나게 됩니다. 박을 클릭했을 때, 박속에 들어있던 편지들이 문제없이 잘 나타나고 있고요.

 

여기서부터가 핵심입니다. 누군가는 박속의 편지가 나타나는 기능이 문제없이 잘 나타난다고 생각할 수 있습니다. 하지만 다른 누군가는 아래처럼 이 부분에서도 문제를 삼을 수 있죠.

'음.. 이 페이지 내에서 작성된 편지들을 보려면 무조건 저 박을 클릭해야 하는데, 저 박을 클릭하기 전에 마우스만 갖다대도 미리 데이터를 불러올 수 있는 방법이 없을까? 이렇게만 된다면 UX 측면에서도 더 개선이 될 것 같은데.. ➡️ 아 이럴땐 prefetching을 사용할 수 있지! 우리는 현재 TanStack Query를 사용하고 있으니 해당 기술내에 존재하는 prefetching을 사용해보자"

 

누군가에겐 당연하게 저 페이지 내에서 박을 무조건 클릭해야만 편지들을 볼 수 있는거라면, 당연히 프리페칭 해야하는거 아니야? 라고 생각할 수도 있습니다. 해당 문제를 경험했던 사람이라면 당연하게 위 문제를 고민하고 진행했었을겁니다. 하지만 프리페칭이라는 개념을 모르는 사람은 해당 부분에 대한 문제의식을 느끼지 못하고 넘어갈 확률이 높습니다. 그렇다면, 꼭 경험을 해야만 문제를 삼는 능력을 기를 수가 있는건가? 라고 물으신다면 저는 X 인 것 같습니다.

 

우리는 경험을 하지 못해도 문제를 삼을 수 있어야합니다. 다시 한번 위의 예시로 프리페칭이라는 개념을 몰랐을때 고민의 과정을 살펴보겠습니다.

'음.. 이 페이지 내에서 작성된 편지들을 보려면 무조건 저 박을 클릭해야 하는데, 현재는 박을 클릭해야만 데이터를 불러오고있지. 근데 저 박을 클릭하기 전에 마우스만 갖다대도 미리 데이터를 불러올 수 있는 방법이 없을까? 이런 기술이 존재는 하나? 그냥 hover 이벤트가 발생했을때만 api를 요청하도록 작성할까? 일단 해당 사례가 있는지 구글링해보자'

 

위처럼 우리는 계속해서 고민해야합니다. 개발자는 문제를 코드로 해결하는 사람이고, 모든 문제를 100% 해결할 수는 없어도, 어떠한 방식으로든 해결할 수 있습니다. 하지만 문제를 발견하지 못한다면 해결조차 하지못하죠. 방금 얘기한 prefetching 또한 처음부터 있던 개념은 아닐겁니다. 누군가가 문제라고 느꼈고, 이러한 방식을 해결하려면 어떻게 하는게 좋을까? 라는 고민속에서 prefetching이라는게 탄생했을겁니다. 이어서 우리 또한 방금 전 예시처럼, 프리페칭의 개념을 모르더라도 계속해서 고민해야합니다. 유저의 경험 향상을 위해 무언가를 클릭해야만 데이터를 가져오는것이 아닌, 데이터를 미리 불러올 수 있는 방법은 없나? 그러면 어떤 방법이 있는지 찾아보자! 라는 방향으로 계속해서 고민해야합니다. 이는 곧 상상력 싸움이죠.

 

꼭 prefetching 만을 생각하고 적용해봐라 이런 얘기는 아닙니다. 위 얘기는 세상에 존재하는 모든 문제중 0.000000000000001%에 불과합니다. 항상 모든 가능성을 열어두고 고민하는 것이 중요하다고 생각합니다.

 

또한, 멘토님들께서도 멘티들이 하는 질문에 답을 떠멱여주시는게 아닌, 이게 왜 답인지, 이 답이 맞기는 한건지, 이 답이 나오기까지의 과정  등 계속 피드백 해주시며 멘티들로 하여금 한 번더 생각할 수 있는 기회를 주셨습니다.

 

위 내용의 결론으로 저는 데브코스 팀 동료들과 멘토님, 강사님을 통해 문제를 삼는 방법을 배웠습니다. 이는 곧 스스로 성장하는 법을 뜻합니다. 우리 개발자는 항상 문제를 해결합니다. 그러려면 문제가 아니어도, 문제로 삼을 줄 알아야합니다. 이는 곧 상상력 싸움이고, 모든 기술은 상상력을 통해 탄생하였습니다. 저는 이번 데브코스를 통해 이런 개발자의 모습이 참 개발자의 모습이라고 생각하였고 현재는 계속 문제를 삼기 위해 노력하고 있습니다. 문제를 삼는다고 그 문제가 100% 해결되리라 생각하지는 않습니다. 하지만 최소한 문제를 삼기위한 노력을 해야하고 문제로 삼은 문제를 해결하기 위해 노력해야한다고 생각합니다. 앞으로저는 계속 문제를 삼고 100% 문제를 해결하기 위해 나아갈 것입니다.

 

함께 성장의 힘

저는 데브코스 내에서 총 3번의 팀 활동을 진행하였습니다. 그 중 2, 3번째 팀은 팀 프로젝트를 진행했기에 팀장이 필요했고 저는 두 번의 프로젝트에서 모두 팀장을 맡았습니다. 팀장을 맡으며 팀장이 필요한 이유는 무엇일까에 대한 자세한 이야기는 팀장은 무엇을 위해 존재할까라는 글에 포스팅 해놓았습니다.

 

여기서는 제가 팀장을 함으로써 얻은 또 다른 경험에 대한 이야기를 하려합니다.

 

결론부터 말하자면 저는 팀장을 맡으면서 저는 '함께 성장하자' 라는 모토로 팀 프로젝트를 이끌었고, 자연스레 함께 성장의 힘을 경험하였습니다.

 

제가 생각하기에 사람은 혼자 무언가를 하기에는 쉽게 지칩니다. 비교 대상이 없고, 피드백을 받을 수 없기에 내가 잘 하고 있는건지 쉽게 딜레마에 빠집니다. 하지만 '함께'라면 다릅니다.

 

하기 어려운 일, 습득하기 어려운 지식도 함께라면 피드백을 통해 쉽게 부족한 점을 채울 수 있고, 비교 대상이라는 단어가 적절할지 모르겠지만 함께 학습하고 있는 동료(비교 대상)이 있기에 조금 더 동기부여를 얻을 수 있습니다. 여기서 말하는 동기부여는 사람은 각기 장점이 모두 다르고 다른 사람의 장점을 바라보며 그 장점을 가지기 위해 노력할 수 있고, 내가 조금 지치더라도 다른 사람이 계속 나아가고 있다면 여기서 동기부여를 얻어 다시 힘을 낼겁니다.

 

데브코스에서 저는 두 번의 팀장과 여러 스터디를 통해 팀 프로젝트에서는 코드리뷰와 회의(토론), 스터디에서도 학습한 내용에 대한 토론 등 내가 알고 있는 지식을 직접 입 밖으로 꺼내며 동료들과 이야기하면서 부족한 점을 채울 수 있었고, 내가 모르는 지식, 동료가 더 잘 아는 지식에 대해 자주 질문하며 '함께 성장'의 힘을 느꼈습니다.

3차 프로젝트의 코드리뷰 일부분

 

이후 현재도 뛰어난 데브코스 동료들을 섭외하여 함께 자체 코어타임을 가지며 학습을 진행하고 있습니다(참여해주시는 분들 너무나 감사합니다). 해당 코어타임에서 Todo 스크럼(마무리 스크럼)을 통해 한분 한분에게 본인이 오늘 무엇을 했고 어떤 성과가 있었는지를 질문하며 몰랐던 키워드도 새로 알게되고 메타인지 영역을 점차 늘릴수 있게 되었습니다.

 

함께 성장은 개발자를 막론하고 모든 분야에서 중요하다고 생각합니다. 혼자 공부해도 잘 하시는 분들에게는 해당 사항이 없겠지만, 제가 느낀 경험으로는 함께 성장하는 것이 혼자 성장하는 것보다 5배는 더욱 빠르게 성장할 수 있다고 느꼈습니다.

 

이러한 경험을 바탕으로 앞으로도 혼자 공부하며 딜레마에 빠지는 것이 아닌 함께 성장이라는 키워드에 초점을 맞추고 개발자 인생을 걸어갈 것 같습니다 ㅎㅎ 

 

기록의 힘

데브코스 기간 동안 그저 아쉬움으로 남는 '기록'입니다. 저는 블로그를 시작한 지 그리 오래되지 않았습니다. 기록이라는 것이 내가 배운 것을 리마인드 하는 역할을 해준다는 것을 알았지만 내가 충분히 이해했으면 됐지, 굳이 글로 써야하나라는 생각이 있었습니다.

 

하지만 저를 가장 잘 드러낼 수 있는것이 블로그임을 멘토님들의 블로그를 보며 알았습니다.

문동욱 멘토님의 블로그

 

위 블로그는 제 멘토님이셨던 동욱 멘토님의 블로그입니다. 기술 관련 포스팅 뿐만이 아닌, 멘토님 본인의 주관과 가치관이 들어간 포스팅을 볼 수 있습니다. 기술 관련 포스팅에도 사실을 기반한 멘토님 본인의 주관이 들어가있는 것을 볼 수 있습니다.

 

위처럼 블로그를 통해 내가 공부했던 것을 리마인드 할 수도 있지만, 나라는 사람이 무엇을 공부했고 무엇을 공부해보니 이건 별로고 이건 좋더라 등 나 자신을 나타내는 블로그가 정말 좋은 블로그이고, 블로그는 나라는 사람을 나타내기 정말 좋다는 걸 조금 늦게 깨달았습니다.

 

늦게 깨달은 만큼 블로그로 하여금 나라는 사람을 잘 드러낼 수 있도록 내 생각을 담은 블로그를 작성하려 노력중에 있습니다.

 

그럼 앞으로 나는?

위와 같은 경험을 통해 저는 저 스스로 그리고 함께 성장하는 법을 배웠습니다. 이 방법을 토대로 저만의 강점을 구축하는데에 노력을 쏟을 것 같습니다.

 

개발자 커리어를 어떠한 방법으로 성장하여 얻어나갈지 힌트를 얻었지만 아직 학습이 완료되지 않은 부분들이 정말 많습니다. 6개월이라는 시간이 길다면 길지만 짧다면 짧게도 느껴질 수 있는 시간이었던 것 같습니다. 강의와 과제, 프로젝트에 치여 깊에 파보지 못한 기술들이 많아요.

 

아직 깊게 파보지 못한 기술들을 서적과 공식문서, 오픈소스 코드를 직접 까보며 깊이 이해하는 시간을 가지고, 이전에 진행하던 3차 프로젝트 "짤뮤니티"의 서버를 이관하고 다시 운영하여 유저 경험을 쌓아보고 싶은 생각입니다.

 

추가로, 현재 채용 공고에 보면 TDD에 관련한 내용이 많은데, 왜 TDD를 중요하게 생각하는지 직접 공부하고 프로젝트에 적용해보며 TDD의 장단점을 직접 몸으로 느껴볼 예정입니다.

 

데브코스는 제 개발 인생에 있어서 큰 전환점이 되어 주었습니다. 아직은 실력이 부족한 신입(예비) FE 개발자이지만, 데브코스에서 얻은 경험을 통해 꾸준히 나아갈 일만 남았습니다.

 

제가 고민해본 부분들이 누구나 생각해보고 느낄 수 있는 부분이지만 내가 어떻게 성장할지 고민해보는 것은 내 커리어에 있어서 가장 처음으로 고민해봐야 할 부분인 것 같습니다. 이 글을 보게될 예비 개발자, 신입 개발자 분들도 기술에만 치중하는 것이 아닌, 나 스스로가 어떠한 방법으로 성장하여 개발자 커리어를 이어나갈 것인지 한번씩 고민해보면 좋을 것 같습니다.