2021년, 개발 3년차 회고

개발을 시작했다고 볼만한 시점부터 2022년 01월 01일 기준으로 3년이 채워졌다. 시작도 2019년 01월 01일부터 했기 때문에 3년을 딱 맞게 채웠다. 조금 늦은 감이 있지만 생일 기념으로, 그리고 매년 하는 일인 만큼 지난해 무슨 일들이 가장 유의미했는지 정리해봤다.

다른 개발자의 회고 내용에 기대하듯, 이 주니어 개발자는 무엇을 하며 1년을 보냈을까? 를 기대하며 이 글을 읽는다면 조금 실망하실 수 있습니다. 개발자보다는 개인적인 회고에 가깝습니다. 그러나 저는 개발자입니다.

졸업 전 창업 해보기

예전부터 만들어보고 싶었던 서비스가 있었다. 프로젝트 관리 SaaS를 만들어보고 싶었다. 간단히 설명하자면 지금 Jira가 충분히 만족스럽지 않고, 태스크 사이의 관계들을 더 잘 파악하도록 바뀌었으면 좋겠다는 생각을 자주 해왔다. 나는 그 방법이 트리 구조에 있으리라 생각했고, 뭐 비슷한 방법으로 문제를 풀어보려고 노력했다.

결과적으로는 실패를 경험했고, 그 과정은 이전에 “4개월간 서비스 개발 후기 (사업화 실패하는 데 성공)“ 이라는 글에 배운 점과 느낀 점을 나름 디테일하게 서술했다.

과정에서 많은 것들을 배우고 얻었지만, 사람들을 많이 얻은 것 같아서 좋다. 팀원들을 포함해서 내가 만들고자 하는 것을 응원해주고 같이 고민해준 사람들도 있고… 일단 교수님하고 친해져서 좋았다. 교수님은 서비스 자체에 대해서는 잘 모르셨지만, 공간을 빌려주시고 최대한 도움을 주시려고 많이 노력해주셨다. 수업 중에 나서지도 않는 학생이어서 이름도 잘 기억 못하실 법한데 이렇게 도움을 주셔서 정말 감사했다.

구체적인 내용들은 이미 다른 회고에서 작성했으니 이 정도로 마무리…

취준

사실 취준 과정이 엄청 고통스럽거나 힘들지는 않았다. 취업할 자신도 있었고 취업 준비 과정이 딱히 그전 생활과 다르지도 않았다. 물론 CS에 집중해서 공부했다든지, 포트폴리오 정리하고 자기소개서를 쓴다든지 하는 것들은 있었지만, 그전에도 개발 공부하고 자유시간 갖고 반복하던 삶을 살았기 때문에 특별히 다르다는 느낌은 없었다.

CS 스터디, 멘토링

스터디를 2개 열어서 진행했는데, 하나는 CS 전반적인 내용에 대한 스터디였고 하나는 시스템 프로그래밍을 주제로 한 멘토링이었다.

CS 스터디

과거에 취업 준비를 한다고 생각하면 Github에 올라가 있는 CS 토막 상식 같은 링크를 보곤 했다. 물론 훌륭한 레포지토리들이라 보면서 끄덕끄덕 기억을 살려내곤 했는데, 뭔가 CS에 대해 잘 알게 되었다는 느낌을 받지는 못했다. 그래서 학교에서 사용했던 교과서를 다시 보면서 CS를 정리하기로 했다.

교과서 스터디는 워낙 양이 많아서 취준을 하던 다른 개발자 친구, 이미 개발하는 친구와 함께 스터디를 진행했다. Notion에 정리하기로 하고, 학부에서 배운 수준의 교과서 레벨을 커버한다는 느낌으로 OS와 네트워크까지 잘 정리했다. DB, 자료구조까지 정리했으면 좋았을 것 같은데, 친구들이 바빠지고 취업도 되고 하면서 흐지부지 정리됐다. DB는 따로 학습하긴 했으나 정리되지는 않았고 조금 깊숙한 얘기들에 관해 공부해볼 계획이다.

일단 그래도 OS와 네트워크에 대해서는 배운 내용들이 잘 정리된 느낌이었고, 실제로 면접에 큰 도움이 되었다. 구멍들이 느껴지긴 하지만, 차차 해결해가면 되겠지.

멘토링

학교에 연이 깊은 듯 얕은 듯 한 개발 동아리가 있다. 이 개발 동아리에서는 매 학기 멘토를 모집한다. 멘토는 주제를 선정하고 멘티들이 이 주제에 투표하는 구조이다. 평소에 리눅스 시스템을 조금 잘 써보고 싶다는 생각을 항상 하고 있어서 파일 시스템을 다루거나 소켓을 다루는 등의 프로그래밍에 대해 알아본 적이 있었다. 이런 걸 학습하는 주제가 Unix 시스템 프로그래밍이라는 것을 알게 되었고, 그 당시 Go에 흥미가 많아서 Go를 가지고 시스템 프로그래밍하는 내용으로 수업을 준비했다.

해당 동아리는 비전공자 또는 초보인 분들이 많은 특성이 있어서 관심을 끌기에는 조금 어려운 주제가 아닐까 하는 생각이 들었다. 다행히도 조금 고인물 분들이 나타나 스터디를 재밌게 끌어주셨다.

일단 교재는 Go System Programming이라는 책을 사용했다. 시스템 프로그래밍의 이론적인 이야기라든지, 유닉스 시스템이 파일시스템을 구성하고 있는지 등 자세한 설명이 부족한 책이었다. 다만 Go를 가지고 시스템 프로그래밍을 어떻게 할 수 있는지 등 조금 실전적인 이야기가 많이 담긴 책이었다.

조금 이론적인 이야기도 궁금해서 Advanced Programming in the Unix Environment 책을 같이 참조하면서 공부했다. 꼼꼼히 읽어보면 좋을 것 같은데, 스터디 진행이 꽤 빨라서 꼼꼼하게 읽어보지는 못했다.

스터디 진행은 멘토가 Go언어 자체에 대한, 또는 Go를 통해 어떻게 시스템 프로그래밍을 할 수 있는지 설명해주는 시간과 멘토가 정해준 주제에 대해 멘티들이 특정 주제에 대한 발표를 준비해오고 이를 세션 형식으로 발표하는 형태로 진행되었다. 준비 과정이 진짜 어려웠는데, 사람들이 잘 따라와 주고 발표 준비도 잘 해주셔서 재밌게 마무리 지을 수 있었다.

취준을 위해 했다고 할 수는 없어서 분류가 조금 애매하긴 한데, 아무튼 시스템 프로그래밍도 CS의 한 부분이기 때문에 취업에 도움이 안 되었다고 볼 수도 없을 것 같다.

알고리즘

개발 공부 중에 추가된 것이라고 하면 알고리즘이 있을 것 같다. 알고리즘을 잘하는 편도 아니고, 경험이 많이 있는 편도 아니었다. 알고리즘 자체에 대한 경험을 쌓으려고 하루에 2, 3문제씩 풀었던 것 같다.

대충 200문제 넘어가고 나니까 알고리즘은 어떻게 푸는 거구나 느낌이 생겼던 것 같다. 물론 지금도 골드 1, 2만 만나면 좌절을 맛보고 있다. 그래도 어느 정도 코딩 테스트라고 하는 부분에서 막히던 걸 많이 해결해줬다.

알고리즘을 처음 공부할 때는 카테고리별로 공부했던 것 같다. 예를 들어서 Brute Force 문제, Greedy 문제, 이분 탐색, DP 이런 식으로 정해진 카테고리 문제들을 풀면서 이런 경우는 이 알고리즘이 도입되는 거구나? 이런 느낌으로 알고리즘을 풀었던 것 같다. 이 부분이 어느 정도 진행되고 나서부터는 그냥 프로그래머스 연습문제 2, 3단계에 있는 걸 쭉 풀었다.

알고리즘을 공부하면서 느낀 점은 알고리즘이 코딩하는 것과 크게 다른가? 라는 점이다. 이 부분은 아주 갑론을박 말이 많다. “알고리즘을 잘 못 한다고 개발을 못 하는 건 아니다.” 라든지 “사실 개발하면서 알고리즘을 제대로 써본 적이 없다.”든지…

본인은 알고리즘이 개발과 아주 유관하다고 생각하는 편이다. 그전에는 알고리즘은 아주 다른 영역이라고 생각했지만, 사실 기본적인 문제들을 해결하는 능력은 논리적 사고 능력일 뿐이다. 물론 굉장히 스킬을 가미하며 알고리즘을 해결해야 하는 경우는 조금 현실성 없다고 느낄 수도 있지만, 논리적 사고 연습이라는 측면에서 알고리즘을 연습하는 것이 개발을 더 잘하게 만들어준다는 느낌을 받는다. 따라서 취업하고도 알고리즘을 푸는 걸 취미 삼아 하나씩 하는 것도 좋을 것 같다는 생각이 들었다.

프로젝트

프로젝트는 취준 목적으로 했다기보다는 개발을 안 하는 삶이 조금 무료한 감이 있어서 시작했다. 프로젝트를 하는 사회인 동아리? 라고 해야 할지… 아무튼 그런 곳에서 프로젝트를 진행했다. 초반에 프로젝트 진행이 많이 루즈해졌다. 이유는 진짜 창업 아이템을 고르듯 아이템에 대해 조사도 하고 기능 명세도 문서화하고 기본적인 컴포넌트들에 대한 합의 과정이 진짜 길어서 그랬다. 사실 이런 단계를 모두 거치는 사이드 프로젝트는 해본 적이 없지만, PO 역할을 해주시는 분이 요런 저런 걸 해보고 싶어 하시는 것 같기도 하고 나름 재밌어서 쭉 같이 진행했던 것 같다. 루즈한 출발 자체는 아쉽지만, 그 사이 과정에서 배운 점들이 많이 있어서 그래도 이 부분은 긍정적이었다.

개발에서는 아쉬운 점이 있었다. 개발 스택을 정하는 과정에서 같이 개발하는 팀원에게 많은 부분을 양보해드렸다. 팀원분도 취준 중이신데 목표하시던 회사 스택을 사용해보고 싶다고 하셔서 최근까지 더 이상 잡고 있지 않던 타입스크립트와 NestJS를 사용했고 MySQL을 사용했다. 사실 개발 스택은 별로 신경 쓰지 않기 때문에 상관은 없었지만 배울 수 있는 포인트가 줄었다는 점이 사이드 프로젝트의 매력을 조금 반감되게 했다.

심지어 서버 코드에 거의 기여한 바가 없으시다. 스켈레톤을 작성하는 것 외 서비스 로직이 머지된 적이 없었다. 이 부분은 좀 많이 아쉬웠다.

그러나 진짜 문제는… 사이드 프로젝트가 더 이상 진행되지 않는다는 것이었다. 물론 사이드 프로젝트는 그야말로 사이드니까 원래 하던 일이 있다면 우선순위가 뒤로 밀리는 경우가 허다하다. 그래도 뭔가 우리 팀이 흐지부지 프로젝트를 정지한 이유를 생각해봤는데 다음과 같은 이유가 있었던 것 같다.

• 주기적인 회의를 안 함: 주기적인 회의를 해도 했던 작업이 많이 없으니 회의 시간이 짧고 그걸 위해 약속을 취소해야 하는 등 부담이 좀 있다는 이유로 주기적 회의를 없앴다. 사실 이게 가장 큰 실패 원인이 아닐까 싶은데, 회의 주기가 뭔가 개발 기능을 마무리 짓는 주기로 동작했기 때문에 이 부분이 없어지면서 더 안 하게 된 것 같다. 그리고 애초에 이 정도의 강제성조차 안 가지고 사이드 프로젝트를 진행할 수가 없다.

• 작업에 정해진 시간이 없음: 언제까지는 해요! 라는 작업 시간이 없어서 무기한으로 미뤄진다. 정말 미친 듯이 바쁜 사람은 애초에 사이드를 할 생각을 안 한다는 가정하에, 일상 업무에 일반적인 시간 소비를 하는 사람들 기준으로 일주일 내내 일정 시간을 할애하도록 스케줄링하는 것이 불가능하지 않다. 강제적으로 3시간! 이런 식으로 정할 수 있는데, 각자 정한 이 시간을 기준으로 어떤 작업은 언제까지 마무리되어야 한다는 약속이 필요했던 것 같다.

원래 사이드 프로젝트 완성하기란 정말 어렵다는 것을 알고 있다. 그렇지만 이번 프로젝트는 진짜 사이드 팀 프로젝트에 대해 굉장한 회의를 느끼게 했다. 그냥 혼자 하는 것보다 못한 경험을 했다고 느꼈다. 앞으로 사이드 프로젝트는 진짜 친해서 강제성을 좀 더 부여할 수 있거나, 사이드 프로젝트에 진~심인 디자이너 + 프론트 개발자와 하거나 혼자 하거나 해야겠다고 생각했다.

인턴

길다면 길고 짧다면 짧은 듯한 취준 시간을 보내고 평소에 정말 가서 일해보고 싶던 기업의 플랫폼 개발 인턴으로 들어가게 됐다. 회사에서 크게 두 가지를 했던 것 같은데, 하나는 인턴 과제와 같은 서비스를 개발하고 이를 배포하는 과정이었고, 다른 하나는 팀에서 사용하고 있는 기술을 학습하는 과정이었다. 두 가지 모두 본인에게 큰 의미가 있었고 개발자로서는 굉장한 퀀텀 점프를 했던 경험이었다.

기술 학습에 대해

회사에서 사용하고 있던 기술들을 내가 잘 알고 있지는 않았다. gRPC, Go를 공통으로 사용하고 있던 조직이었기 때문에 위 기술들을 학습하고, 전반적으로 팀이 사용하고 있던 NoSQL, RDB에 대해 학습했다. 이 학습의 가장 큰 포인트는 “깊숙한 이해“ 였다. 단순히 특징을 검색해서 나오는 얘기들 말고, 예를 들어서 “Go는 동시성 프로그래밍에 특화된 언어 구조를 가지고 있습니다.”라는 문구는 쉽게 찾아볼 수 있다. 그렇다면 “왜 특화되었다고 표현되어있지?”라는 질문이 나온다. 어느 겉핥는 학습을 해보면 그 질문에 대한 답변은 “go, channel 키워드와 여러 sync 패키지 등으로 개발자들이 동시성을 구성하면서 고민해야 하는 여러 부분을 해결해주고 있기 때문이다”라는 것을 알 수 있다. 그렇다면 그 고민이 구체적으로 무엇이고 어떻게 해결해주고 있는 것일지 구현체 레벨까지의 궁금증(코드 레벨까지는 아니고, 보다 추상적인 레벨에서)을 갖게 된다. 완전히 어떠한 특징에 대해 깊게 이해한 다음, 그렇다면 우리는 이 기술을 어떻게 활용할 수 있을까? 어떤 옵션들이 우리 상황에 더 잘 맞는지, 그리고 그 이유는 무엇일지? 를 고민하는 순서로 여러 기술들을 학습했던 것 같다.

사실 과거에 상당히 많은 부분이 경험을 통해 얻을 수 있는 영역이라고 생각하던 부분이 있었다. 어느 정도 학습하고 나면, “여기부터는 경험을 통해 알 수 있는 영역”이라고 생각하는 부분들을 마주한다. 물론 그 부분이 없다는 것은 아닌데, 이 과정을 거치면서 상당 부분은 이런 깊숙한 이해를 통해 많이 해결할 수 있다고 생각하게 되었다.

---

위에서는 조금 비중 있게 쓰진 않았지만, 사실 “깊숙한 이해”의 근본적인 목표는 “우리는 어떻게 사용할지”이다. 그래서 우리는 “어떻게 쓸 수 있을까?”를 조금 더 중요하게 본다. 식사를 기다리면서 시니어분에게 “대규모 서비스를 구성해본 경험이 없어서 ‘어떻게 쓸 수 있을까?’에 대한 정보는 떠올리기 어려운 것 같다”라고 말씀드린 적 있는데, 시니어분이 “기술적으로 까다로운 특정 상황에서 경험으로 어떤 기술을 사용하려는 사람은 사실 오히려 더 소수이다. 어떻게 쓰지?를 알기 위해서 깊숙한 이해가 요구되는 것”이라고 말씀하셨다. 깊숙한 이해가 기술을 대하는 핵심이지만, 그것이 핵심인 이유는 근본적으로 어떻게 쓸지를 보다 잘 알기 위해서이다.

잘 정리해서 쓴지 모르겠지만, 아무튼 이 공부 과정을 통해서 기술을 바라보고 대하는 태도, 학습 방법, 문제를 해결하기 위해 지나가야 하는 기술적 탐구 과정에 대한 에티튜드가 바람직한 방향으로 박힌 것 같아, 인턴이 끝나고 나서도 참 기분이 좋았다.

회사에서 학습했던 기술들은 조금 더 포괄적이거나 깊게 다시 학습해 정리하고 있다.

프로젝트에 대해

회사에서 했던 프로젝트는 이 링크에서 구체적으로 확인할 수 있다. 과정은 위 링크에서 잘 정리되어있기 때문에 위 과정으로 뭘 배웠나에 대해서 간단하게 정리해보려고 한다.

일단 위 프로젝트에서 경험한 핵심은 “예측 가능한 애플리케이션”이다. 예측 가능하다는 것은 내가 만든 서비스가 얼마만큼의 성능을 낼 수 있는 앱인지를 말한다. 서비스에 어떤 부분에 노출이 되는지 또는 어떤 서비스 뒤에서 돌아가는 플랫폼 서비스인지, 그래서 얼마만큼의 TPS가 나올지를 알 수 있다면 약간의 버퍼를 두고 그만큼을 해결할 수 있는 TPS가 뽑히도록 앱을 설계하거나, 그것이 현실적으로 불가능하다면 지금 만든 앱이 몇 개의 서버로 부하를 분산해야 하는지를 아는 것이 예측 가능한 애플리케이션이라고 생각한다.

일단 위에서 말한 것처럼 어느 정도 규모가 있는 애플리케이션에서는 이런 작업이 필수적이기 때문에 서비스를 개발하는 일련의 과정을 학습했다는 것 자체를 배웠다. 그리고 최대한의 성능을 위해서 애플리케이션의 성능 테스트를 진행하고 병목 지점을 찾아서 고쳐서 다시 배포하는 과정에서 숫자적인 감각이 조금 생겼던 것 같다. 예를 들어서 어떤 서비스인지, 하드웨어 성능이 어떤지에 차이가 있지만 I/O 작업이 추가될 때와 아닐 때 어느 정도의 성능이 나오는 게 일반적인지라든지, 어떤 수치를 보고 어디서 생기는 병목인지 예측하는 감이 생겼던 것 같다. 일시적이지 않으려면 뭐 추가적인 경험을 해봐야 할 것 같은데, 일단은 이러한 경험을 한차례 했다.

졸업

학교를 참 열심히 다녔는데, 학교 수업을 열심히 들었다기 보다는 해보고 싶었던 건 거의다 한 것 같다.

사실 학교 그 자체에 대해서는 좀 회의적이기도 하고 쓸 말도 없다. 졸업 당일에는 아쉬운 감정이 생길 줄 알았는데 그런 거 없고 그냥 행복하게 졸업했다. 지금 약 2, 3개월 지나고 나니까 실감이 나는듯하다. 그러나 여전히 아쉽지는 않다.

졸업식에는 다행히 친구 몇 명과 같이 사진 찍고 즐겁게 졸업식을 보낼 수 있었다. 굿.

회고 모임

2021년 초 “왕각코”라는 왕십리에서 각자 코딩 모임을 했다. 친한 동생 한 명하고 같이 모여서 각자 코딩하거나, 책을 읽거나 그냥 만나서 할 거 하는 모임이었다. 둘이서 하니까 모임이라고 부르기 뭐하긴 했는데, 꾸준히 이 모임에 누군가를 초대해왔었다. 공통으로 알고 있는 여러 명을 초대했는데, 그중 한 분이 정기적으로 이 모임에 나오게 되었고 이 모임의 아이덴티티를 재설정했다.

재설정된 아이덴티티는 회고 모임이었고, 이름도 “우린 남이니까”라는 이름으로 바꾸었다. 우린 남이니까라는 말은 파카라는 방송인이 과거에 자주 하던 소리였는데, 모두 파카 방송을 재밌게 보는 사람들이기도 하고, 회고 후 피드백이나 조언을 가감 없이 전달할 수 있는 사람들이라는 의미를 붙여서 이름을 정했다.

이 회고 모임은 지금은 4명이 되었고 꽤 유쾌한 회고 모임이 되었다. 회고 모임에는 아주 각자 영역에서 열심히 살고 계시는 분들이 함께하고 있는데, 조금씩 좋아하는 것이나 생각하는 방향이 차이가 있으면서도 남들의 의견을 폭넓게 수용하고 자신들의 것으로 만드시는 모습을 보면 본인도 아주 삶의 동기부여가 된다. 또 일주일마다 무엇을 했는지 어떤 것이 아쉬웠고 어떤 것이 좋았는지, 다음 주는 어떤 것을 할지를 계획하는 것들이 인생을 막사는 것으로부터 어느 정도 방지턱 역할을 해준다.

막 사는 것을 막을 수는 없다. 그건 행복하다. 그리고 지금만 누릴 수 있는 것 같다. 그런데 그렇게 살고 난 주에 회고를 읽으면 자괴감도 들고 다른 분들이 훌륭하게 일주일을 마무리 지은 것을 보면서 반성하게 되는 효과가 있다.

말이 잘 통하고, 자신의 가치관에 대해 굳이 남을 동의하게 만들려는 분들이 아닌 사람들과 이런 회고 활동을 하는 것은 정말 추천할만하다. 최근 좀 아쉬운 점이 생겼는데, 세 분이 모두 같은 회사에 다니게 되었다는 점이다. 아직 그에 대한 피부에 와닿는 단점은 없지만, 그 전보다 다양한 얘기들을 듣기 힘들고 회사 욕을 하기도 어렵다는 점(예상)이 아쉽다. 그래도 원래 하던 기능은 온전히 잘하고 있어서 피부로 와닿지는 않는듯하다.

---

회고 전에는 뭔가 반성할 점이 많은 일 년이구나 싶었는데, 꽤 알찼던 것 같기도 하고? 이번 해에 개발자로서 한 단계 점프한 것 같다는 생각도 들었다. 벌써 상반기가 거의 다 지나가고 졸업 이후 첫 회사도 결정하는 단계가 되었고 고민 중이다. 다음 페이즈가 열리고 있다는 생각도 들고 커리어 골과 마일스톤 사이에 간극에 대한 고민도 많아진다. 이 글은 뇌에서 거의 바로 꺼내 쓴 글이라 두서가 없을 것 같은데 퇴고 과정 없이 올렸다. 회고는 참 어려운 것