« 2024/12 »
일	월	화	수	목	금	토
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

0. Intro

2022 연말에 갑자기 회고를 쓰고 싶어서 헐레벌떡 이틀만에 쓴 이후로 내년에는 좀 더 진득히 시간을 가지고 쓰리라 다짐했는데, 올해도 30일이 다 되어서야 회고록을 쓰기 시작합니다. 사람은 쉽게 변하지 않는다는 말을 이럴 때에 쓰는 것 같습니다.

2022년 회고 제목은 다시 학생이 되다 였습니다. 이는 2년간의 군휴학을 마치고 다시 학생으로서 살아가는 제 모습에 대한 표현입니다. 그리고 올해, 저는 복학 1년만에 다시 휴학을 하게 되었습니다. 올해 초만 하더라도 제가 다시 휴학을 하게 될 줄은 꿈에도 몰랐습니다. 이런 의미에서 2023 회고 제목은 다시 (휴)학생이 되다로 결정했습니다.

1. UMC 활동 종료

썩 만족스럽진 않았던 앱 프로젝트와 UMC 수료

2월에 최종 프로젝트를 끝내며 UMC 3기 활동을 마쳤습니다. 1월부터 약 한 달이 넘는 시간 동안 프로젝트를 위해 전념했던 시간이었습니다.

저희 팀은 교내/외의 각종 스터디, 프로젝트, 동아리 등의 매칭을 지원하는 애플리케이션을 만들고자 했습니다. 이 애플리케이션을 개발하면서 스프링에 한 층 더 익숙해졌던 것 같습니다. 처음으로 profile이라는것을 사용하여 환경을 분리해보기도 했습니다.

하지만 프로젝트 운영 자체는 순탄하지 않았습니다. 4명의 서버 개발자 중 2명은 사실상 참여하지 않았고, Android 파트 분들은 프로젝트 경험이 없어서 개발하는데에 많은 애를 먹으셨고, iOS 파트 분들은 도중 하차하셨습니다. 당연한 수순으로 앱을 실제로 배포하는데에는 실패했지만, 저는 스스로 많이 배웠다고 생각해서 크게 안타깝지만은 않았습니다.

1년 전에 누가 이 바보 같은 프로그램을 만들었는지 보자

사실 이때 쯤 했던 일들은 잘 기억이 나지 않아 다시 찾아볼 겸 그때 개발했던 레포지토리를 찾아보았습니다. 지금 다시 보니 당시 작성했던 코드 상태가 생각보다 심각했음이 느껴집니다.

지금도 잘 아는 것은 아니지만, 당시에는 JPA의 양방향 연관관계 매핑에 대해서 잘 몰랐기 때문에 양방향 매핑을 하는데에 두려움이 있었습니다. 다른 팀원들도 JPA를 처음 사용하는 것이었기 때문에 저희 팀은 조금 불편하더라도 단방향만 사용하자고 약속했었습니다. 그렇게 만들어진 코드를 지금 보니 참 불편하게 개발했었구나 라는 생각이 듦니다.

위 코드도 눈에 띄었습니다. 여러 조건을 통해 팀을 조회하기 위해 파라미터에 값들을 다 때려박은 모습입니다. Swagger 애노테이션이 들어있어서 더욱 빽빽하게 보이는 것 같습니다.

2. 쉬어가는 학기 3-1

이번만 쉬어가자

UMC를 마치고 얼마 되지 않아 새학기를 맞이했습니다. 작년에 팀플이 너무 많아서 데였기 때문에, 이번 학기는 조금 쉬어가고자 했습니다. 어차피 3-2 이후로부터는 열심히 살지 않으면 안될 것 같아서 3-1이 쉬엄쉬엄할 수 있는 마지막 학기라는 생각이 들었습니다. 그냥 특별히 다른 활동 안하고 학교 공부만 하면서 틈틈이 프로젝트 하나 할 생각이었습니다. 그런데 . .

지옥의 스프링부트

https://sbslc.notion.site/7b977756d3744a148d1e2190f748f329?pvs=4

백엔드에 대해 배우고 싶어하는 친구가 있어 일대일 과외를 계획했다가 판을 더 키워서 3명의 스터디원을 더 받게 되었습니다. 저도 많이 부족한지라 여러 내용들을 전달하기 위해서는 많은 시간을 학습과 자료작성에 할애해야 했습니다. 스터디는 주 마다 진행했기에, 매번 주말에 편의점 알바를 하는 도중 글을 쓰고 PPT를 만들었던 기억이 납니다.

스터디는 백엔드 입문자를 대상으로 듣기 좋게 만들기 위해 노력했으며, 웹과 관련된 전반적인 내용부터 Spring 아키텍처, DB, AWS 등 다양한 분야를 다루었습니다. 스터디원 분들도 열심히 들어주셔서 되게 재밌게 했던 것 같습니다.

총 12주차로 만들어서 학기 중에 끝낼 계획이었는데, 중간의 몇몇 주제들은 하루로 끝내기 어려웠고 일부 주차는 쉬었기 때문에 학기 중에 못끝내고 방학에도 4차례 학교에 가서 결국 마무리 했습니다.

알고리즘, 운영체제, 소프트웨어공학

3-1학기에는 알고리즘, 운영체제와 소프트웨어 공학 강의를 들었습니다. 모두 서로 다른 분야에서 굉장히 매력적인 강의였습니다.

셋 중 가장 재미있게 들었던 강의를 뽑자면 저는 운영체제를 고를 것입니다. 강의를 듣기 전에는 어렴풋이만 알고 있었던 프로세스와 쓰레드, 가상메모리 등의 개념을 깊이있게 이해할 수 있어서 좋았습니다. 이때 쯤에 공부할 때에는 전공서 2개를 가지고 모두 읽어가면서 공부했는데 도움이 많이 되었던 것 같습니다.

이번 학기는 아이묭의 학기

작년 2학기에는 등하교마다 잔나비 노래를 들었다면, 3-1학기에는 아이묭의 노래를 잔뜩 들었습니다. 아이묭 노래의 밝지만 어딘가 쓸쓸한 감성 너무 좋습니다.

3. 나는 구르미 플레이어

부트캠프 지원

3-1 학기가 끝날 무렵부터 휴학을 하고 싶다는 생각이 강하게 들었습니다. 학교 다니는게 힘들어서라는 이유는 아니었고, 저 스스로가 무언가 외부 활동을 통해 경험을 쌓고 나서 학교에 복귀했을 때 더 많은 것을 배울수 있을 것이라고 생각했기 때문입니다. 이쯤부터 여러 부트캠프에 지원하고 면접을 봤습니다. 몇 군데는 떨어지고나서 최종적으로 붙은 곳은 구름톤 트레이닝입니다.

구름톤 트레이닝 합격!

전부터 구름IDE를 여러 차례 사용해보았기 때문에 구름은 저에게 굉장히 친숙한 기업이었습니다. 예전에 군대에서 업무에 사용할 웹 기반 프로그램을 만들고 싶었는데, 업무용 PC는 망 자체가 다르므로 그곳에서 개발환경을 구축하고 작업을 하는 것은 불가능했습니다. 따라서 당시에는 “싸지방”에서 구름IDE를 통해 개발하고 그 내용들을 인쇄해서 업무용 PC에 옮기는 작업들을 했습니다. 제가 한동안 몰두한 프로젝트인 만큼 구름IDE에 대한 이미지도 좋았는데, 합격하여 이곳에서 공부하게 될 생각에 아주 들떠있었던 시기도 있었습니다.

끝없는 스터디

구름톤 트레이닝 과정은 1차 스터디 - 2차 스터디 - 1차 프로젝트 - 2차 프로젝트 순으로 진행됩니다.

각 스터디는 형식부터 인원 모집까지 굉장히 자유롭게 진행할 수 있었습니다. 저는 1차 스터디 팀장으로서 발표 기반 스터디를 구성해서 진행했습니다. 50개가 넘는 주제들에 대해서 약 5주간 다뤘고, 팀원들과 거의 매일 ZEP에서 모여 발표 시간을 가졌습니다. 다른 플레이어분들도 이 점을 좋게 봐주셨는지 저희 팀은 약 10개 팀 중 2등으로 1차 스터디를 마치고 치킨 기프티콘 🍗을 받았습니다~

구름톤 트레이닝 내에 스터디 매칭에 도움을 주고자 9oorp이라는 웹 프로젝트를 진행한 스터디 팀이 있었습니다. 저는 2차 스터디에 이 팀으로 이동해서 프로젝트 리팩토링을 도왔습니다. 남이 작성한 코드를 보고 익히고 문제점을 파악하고 개선하는 작업은 또 새로운 경험이어서 좋았습니다.

직접 여는 세미나

세미나 혹은 발표를 연다는 것은 제 개인에 있어서도, 듣는이에게 있어서도 도움이 많이 되는 활동 같습니다. 제가 컴퓨터 공학과 개발자라는 직업에 처음 매력을 느낀 것도 이러한 문화 때문입니다. 따라서 아무도 시키지 않았지만 구름톤 플레이어분들을 대상으로 주기적으로 세미나를 진행했습니다. 처음에는 3명 정도로 시작했지만 이후에는 감사하게도 열 분이 넘는 분들이 오셔서 세미나를 들어주셨습니다.

가끔은 저에게 찾아오셔서 다음 세미나는 언제하냐, 할 때 꼭 불러줘라 라고 이야기해주신 분들도 계셨습니다. 립서비스일 수도 있겠지만 정말정말 감사해서 더 좋은 발표를 구상하기 위해 더욱 노력했던 것 같습니다.

Web IDE를 만들어보자

이후 12월부터 본격적인 프로젝트 과정에 돌입했습니다. 첫 프로젝트는 Web IDE를 만드는 것이었습니다. 감사하게도 좋은 팀원들을 만나 매일 같이 회의하고 밤새 개발하며 몸은 피곤하지만 즐겁게 프로그래밍하는 시간을 가졌습니다.

4. 블로그는 어떻게 변했나

새로운 이름

블로그 이름을 ‘공부하자범석아’에서 ‘세상에 나쁜 코드는 없다’로 바꿨습니다.

물론 나쁜 코드는 있습니다. 시스템에 장애를 낳거나 많은 비용이 들거나 알아보기 어렵게 작성된 코드는 안 좋은 코드임이 분명할 것입니다.

하지만 한 사람의 개발자 인생 속에서 나쁜 코드는 있을 수 밖에 없으며, 나쁜 코드를 항상 나쁘다고만 볼 수는 없을 것 같습니다. 나쁜 코드를 써내려가는 것은 결국 성장의 발판이자 좋은 코드의 밑거름이 될 것이기 때문입니다.

이러한 맥락을 통해 ‘세상에 나쁜 코드는 없다’라는 문장으로 블로그 이름을 변경하게 되었습니다. 이는 저에게 보내는 일종의 격려이자 위로이기도 합니다.

다작보다는 퀄리티를

가끔은 공부를 하다보면 ‘이 내용을 블로그에 담으면 좋겠다’라는 생각이 들곤 합니다. 주로 새로운 내용에 대해 배우고 나서 이것이 공유할 만한 가치가 있다 싶은 내용일 때 그런 생각을 하게 되는 것 같습니다.

하지만 위와 같은 동기로 작성된 글의 퀄리티가 항상 좋다는 것을 보장하지는 못할 것 같습니다. 주로 새롭게 배운 기술에 대해 이를 기록하기 위한 목적으로 작성되기 때문에, 작성자 본인도 그 내용에 대해 깊이있게 알고 있다고 말하기 어렵기 때문입니다. 또한 이런 주제로 작성된 글은 이미 다른 블로그 혹은 기술문서에서 더 좋은 내용을 담고 있을 가능성이 높습니다.

올해 제 블로그에는 단순한 정보전달이 아닌 최대한 제 고민이 들어간 창작물을 남기기 위해 노력했습니다. ‘이 기술은 되게 좋네. 블로그에 남기고 싶다’ 라는 생각들은 다 쳐내고, 제가 수행한 일들과 제 고민 및 재해석이 담긴 글들 위주로 작성하였습니다.

실제로 제가 다른 블로그의 글을 볼 때에도 가장 다가왔던 포스팅은 단순히 기술을 설명하는 글보다는 작성자가 말하고자하는 스토리가 들어간 포스팅이었던 것 같습니다. 이러한 글들은 읽기엔 어렵지만, 그 글에 대해 공감하고 이해한다면 어떠한 다른 글보다 도움이 됩니다. 제가 작성하는 블로그도 그들의 글처럼 사람들에게 도움이 되었으면 좋겠습니다.

5. 돌아보면 아쉬움만 남는

나는 열심히 사는 사람인가?

종종 자기전에 오늘 하루 열심히 살았나 스스로에게 물어보곤 합니다. 저는 그 질문에 항상 같은 대답을 합니다. - NO.

매일 하루를 되돌아보면 그날 열심히 살지 않았던 순간만이 떠오릅니다. 유튜브를 보면서 무의미한 시간을 쓰기도 하고, 그날 하려고 한 일들을 다음으로 미루는 일도 많습니다. 한 때는 이런 것들에 대해 하루하루 반성하며 내일은 열심히 살리라, 시간을 허투루 쓰지 않으리라 다짐하기도 했습니다.

Everyone has a personal time zone

어느 순간 이러한 반성과 다짐이 큰 의미가 있나라는 생각이 들기 시작했습니다. 저는 하루하루는 좀 나태하게 살더라도 장기적으로 보면 열심히 사는 사람이라고는 생각합니다. 지인분들이 그렇게 봐주시기도 하고, 연 단위로 봤을 때 공부를 완전히 쉰 날은 손에 꼽을 정도이기도 합니다. 돌아보면 이것이 제 장점이라는 생각이 듦니다.

그래서 이제는 하루하루 자책하고 다짐하고를 반복하기 보다는 이게 나의 페이스임을 인정하고 꾸준하게 하자는 마인으로 바꾸게 되었습니다. 모두는 각자의 시간대에서 각자의 방법으로 각자의 길을 나아가는 중인거고, 저 또한 제 길을 나아간다는 생각으로 하루하루 살아가고 있습니다.

그럼에도 불구하고

그럼에도 불구하고 아쉬움은 남을 수 밖에 없는 것 같습니다. 이러한 아쉬움은 비단 학습과 관련된 것 뿐만 아니라 제가 올해를 보내면서 할 수 있었던 선택을 과감히 하지 못하고 흘려보낸 것 때문이 아닌가 싶습니다. 올해를 통해 느낀것을 통해 다가오는 해에는 후회 없이 아쉬움 없이 보낼 수 있었으면 좋겠습니다.