2024년 회고 - 개발자로서 쓰는 첫 회고

들어가며

좀 주저리 주저리가 많습니다. 요즘 굉장히 많은 생각을 하는 시기를 보내고 있어서 그렇기도 하고, 회고 자체를 이렇게 작정하고 써보는게 처음이라서 그렇기도 합니다. 그 전에는 회고의 필요성도 딱히 못 느꼈습니다. 하지만 지금은 어떤 이정표, 체크포인트 같은 것이 있었으면 좋겠다싶어 여기에 이렇게 써봅니다. 글이 조금 정신 없더라도 양해부탁드립니다.

어디서부터 시작하면 좋을까요?

이제 졸업을 앞 둔 저는, 2학년에 패션디자인학과에서 컴퓨터공학과로 전과를 와서 얼마전까지, "별 생각없이" 개발을 해왔습니다. 대충한 것은 절대 아니지만, 나름 공부도 최선을 다하고 필요하면 밤도 자주 새고 그랬지만 "그냥 열심히" 했던 것 같습니다. 또 그게 잘못했다고도 생각하지 않습니다. 효율적이었냐고 물어보면 그렇지 않지만, 나름 까맣게 태웠고 정말 재밌었습니다. 무엇보다 이런 과정이 없었다면 지금 드는 이런 여러가지 고민들도 없었을 것이라고 생각합니다.

왜 컴퓨터공학과로 왔을까? 지금 다시 생각을 해봅니다. 일단 패션디자인학과에서 어딘가 잘 안 맞는 구석이 있다는 생각이 들었습니다. 어디서 그렇게 느꼈을까 계속 고민을 해봤는데, 아무래도 특별히 "욕심"이 안 났던 부분인 것 같습니다. 오해를 하시면 안 되는 것은 "욕심"이 안 생긴다고 적성에 안 맞는 일이라고 주장하는 것은 아닙니다. 사람마다 다르다고 생각합니다. 그런데도 이걸 꼽은 이유는 제 성격이 원래 욕심이 많은 사람이라 그렇습니다. 무얼하든 대단하고 싶고, 멋진 일을 하고 싶다는 상상을 많이 합니다. 패션디자인학과를 다니면서는 그런 이미지가 잘 안 그려졌습니다. 이전에 그림이 즐거워 열심히 그리다가 직업으로까지 이어지지 않은 것이 비슷한 이유에서라고, 이제와 생각이 듭니다.

그래서 전과를 해야겠다는 생각을 했습니다. 고민하던 중 친구가 컴퓨터공학과가 잘 어울린다고 추천을 해줬습니다. 코딩을 해본 적은 없었고, 해본 거라곤 1학년때 Scratch로 고양이 그림이 뛰어다니고 인사하는 거 만들어본게 다였습니다. 그런데 별 큰 고민없이 컴공 좋겠다 선택을 했습니다. 덧붙이려면 얼마든지 할 수 있겠지만 무엇보다 직감이었던 것 같습니다. 저거 배워서 나도 뭔가 만들어보고 싶다하고 생각했습니다. 잘한 선택이라는 걸 컴공으로 전과 온 첫 학기 때 알았습니다. 전공 수업도 과제도 어려웠지만, 그걸 결국 해냈을 때의 쾌감이 아주 중독적이었습니다. 많은 개발자들이 이 늪에 빠져 나오지 못하고 있는게 아닐까 싶습니다.

올 한 해를 함께한 제 베이비입니다

간단하게 설명드리자면, 채팅 혹은 오픈 채팅에 참여한 사람들이 원하는 음악의 유튜브 링크를 올리면 해당 음악을 다 같이 들을 수 있는 서비스입니다. 기존 뮤직 플레이어를 여럿이서 함께 쓸 수 있게 만들고 싶었기 때문에 음악 추가/삭제/재생/정지/이동 등 모두 동기화되어 동작하도록 구현하였습니다.

아이디어가 이것저것 많았지만, 그 중에서도 개인적으로 이거다 싶었던 아이디어를 올 한 해 캡스톤디자인 프로젝트로 진행을 했습니다. 이 전에 한이음 ICT 멘토링에 참여하면서 웹개발 프로젝트를 경험한 적이 있긴 했지만, 해당 팀 모두 경험이 적다보니 흐지부지해져 많은 개발 경험을 얻지는 못했습니다. 그래서 사실 리액트만 어느 정도 경험이 있고, 스프링은 아무것도 모르는 상태로 프로젝트를 시작했습니다.

이마저도 야생형도 아닌 우가부가형으로, 제대로 알아보지도 않고 무작정 여러 튜토리얼들에서 본 것들을 호문쿨루스 만드는 것 마냥 덕지덕지 붙여가면서, 맨땅에 피칠갑 박치기 해가며 만들었습니다. 그래도 저의 아이디어가 정말로 실제 프로덕트가 되어가는 모습은 정말 뿌듯했습니다. 하지만 다 만들고 나서야 느낄 수 있었던 배운 점 몇 가지를 적어봅니다.

1장(편)부터 보세요

개발 공부 스타일에 대해 이야기할 때 야생형과 학자형 이야기가 유명합니다. 저는 야생형이 효과적이라고 해서, 또 얼른 만들어야겠다는 욕심이 너무 앞선던 터라, 나는 야생형이야! 생각하고 덤벼들었습니다만, 제가 야생형의 의미를 조금 오해하고 있었던 것 같습니다. 저는 야생형이 아닌 그냥 무지성형(앞서도 말한 우가부가형)이었습니다.

필요한 기술 혹은 지식이 있을 때, 해당하는 무언가를 찾게 된다면, 부디 1장부터(강의라면 1편부터) 보시길 바랍니다. 왜냐면,

• 첫째, 두꺼운 책을 훑으며 필요한 정보만 취할 수 있는 사람은, 보통 본인이 뭘 읽고 계시는지에 대한 이해가 있으신 분입니다.

• 둘째, 결국 돌고 돌아 1장으로 돌아오게 되어있습니다. 그러고 다시 읽어야됩니다. 시간만 두 배 넘게 걸리고 답답합니다.

공부를 제대로 해오신 분들이라면 너무 당연한 소리라고 생각하실 수도 있고, 아예 동의하지 않는 분도 계실 수 있습니다. 하지만 어떤 조언이라기 보단 저 자신에게 하는 당부라고 생각해주시면 좋을 것 같습니다. 1년 공부하며 개인적으로 가장 좋았던 순간이 저 위에 사실들을 몸소 깨달았을 때입니다.

작게 한 것 같아도 아직 너무 큽니다

얼마나 단순한 서비스를 생각하든, 그걸 얼마나 더 줄이든, 거의 99퍼센트 확률로 아직 너무 큽니다. 멀쩡히 동작하는 서비스를 완성할 수 있을 거란 생각도 버리는 게 좋습니다. 더 중요한 것은 빠르게 실패(Fail Fast)하는 것입니다. 될 아이디어와 안 될 아이디어를 가능한 한 빠르게 확인하기 위해 최소한의 프로토타입을 만들어야 합니다. 이것도 몇 가지 이유가 있습니다.

• 첫째, 직접 써보기 전까지 절대 모릅니다. 좋다고 생각한게 안 좋을 수도 있고, 안 좋다고 생각한게 오히려 좋을 수 있습니다. 울고불고 해도 판단은 유저가 합니다.

• 둘째, 금방할 것 같아도 금방 안 됩니다. 몇 주, 몇 달 정말 순식간에 가버립니다.

위의 부분들은 어느정도 제가 아직 경험이 부족해서일 수도 있겠습니다만, 실제로 많은 성공적인 스타트업 CEO와 엔지니어들이 공통적으로 얘기하는 부분이 바로 Fail Fast의 부분입니다. 이렇게 많은 분들이 입을 모아 이야기하는 데에는 이유가 있다고 확신합니다.

문제는 그래서 작게 할려고 해도, 그게 분명 더 작아질 수 있다는 것입니다. 개발에 들어가버리면 사이즈를 가늠하기 쉽지 않습니다. 설계 단계에서 더 작게, 더 유연하게 할 수 있는지 깊이 고민해봐야 합니다.

기록하면 언젠간 봅니다

프로젝트가 길어지면 반드시 뭘 하나씩 까먹습니다. 정말 귀찮지만, 대충이라도 기록을 생활화해놓으면 언젠가 덕을 봅니다. 프로젝트 내내 "와 이거 적어놔서 다행이다"와 "아니 이거 왜 안 적어놨지?"의 무한 반복이었습니다. 열심히 기록하고, 더 잘 기록하는 방법을 고민해야겠다는 생각을 많이 하게 되었습니다.

이렇게 프로젝트를 진행하며 많은 생각이 들었지만, 그 중에서도 가장 크게 느낀, 저에게 큰 영향을 준 것들에 대해 정리를 해보았습니다. 결론적으로는 "음악"과 YouTube API라는 외부 API에 기대는 서비스가 가지는 종속성과 저작권 관련 복잡한 문제들을 설계 단계에 충분히 생각하지 못해 적극적인 홍보를 하지 못해 아쉽지만, 제한적이지만 테스트를 위해 가까운 사람들을 동원하여 겪은 사용자 경험은 서비스에 대해 생각하는 시야를 정말 많이 넓혀주었습니다. 또 덕분에 앞으로 어떻게 하면 좋을지에 대해 많은 생각을 갖게 해준 큰 부분 중 하나이기도 합니다.

어쩌다보니 면접을 봤습니다

여지껏 별 생각없이 그냥 "개발자"가 되야지 하고만 생각해왔습니다. 솔직히 백엔드라는 분야만 정해두었지 특별히 가고 싶은 회사가 기업의 종류가 있는 것도 아니었습니다. 그런데 올해 하반기가 되고, 대기업 공고들이 올라와서 경험삼아 한 번 넣어나 보자 하는 마음에 부랴부랴 지원을 했습니다. 총 16군데 대기업과 은행에 지원을 했고, 그 중 4군데 서류가 운 좋게 통과되었습니다. 서류야 열심히 썼지만 넣을 때까지만 해도 사실 아무 기대도 안 하고 있었습니다. 그런데 서류 통과가 몇 군데 되고나자 패닉에 빠졌습니다. 내새울만한 유일한 프로젝트인 캡디도 완성이 안 된 상태였고, 자격증도 없었고, 코딩 테스트 준비도 안 되어있었습니다. 그래서 9월, 10월, 11월은 제가 뭐 어떻게 살았는지 기억도 잘 나지 않습니다ㅋㅋㅋ. 4군데 서류 통과된 곳 중 1군데는 코딩 테스트를 떨어져 3군데에 면접을 보러가게 되었습니다. 난생 처음 판교에 가봤는데 와 건물도 크고 정말 넓었습니다.

정말 사시나무처럼 떨면서 면접을 봤습니다. 무엇보다 제가 스스로 준비가 되지 않았다는 생각이 저를 제일 힘들게 했던 것 같습니다. 도전을 좋아한다고 말하면서도 도전에 결과가 없었고, 발전에 관심이 많다면서도 얼마나 발전했는지 보여줄게 없었습니다. 결과적으로 2군데 1차 면접에서 탈락하고, 1군데 최종 면접에서 탈락했습니다. 뭐 다들 비슷한 처지일 수도 있겠지만, 스스로 확신이 없으니 더 그랬던 것 같습니다. 하지만 면접 준비를 하고, 나 자신을 어필하기 위해 노력하다보니 피할 수 없는 의문이 들었습니다.

도대체 어떤 개발자가 되고 싶은가?

여기에 대한 답을 제가 가지고 있지 않다는 것을 깨달았습니다. 뭐 꼭 있어야 하나 생각할 수도 있지만, 그런 것도 고민으로부터 나올 수 있는 답이라고 생각합니다. 고민을 해본적이 없으니, 자기소개고 장단점이고 뭘 말해야 좋을지 몰랐습니다. 면접도 면접이지만, 나에 대해 아는 게 너무 없는게 아닌가 하고 충격에 빠졌던 것 같습니다. 그러다 보니 자연스럽게 주변 다른 개발자 분들에게 눈이 갔습니다. 동아리나 이런 저런 행사, 온/오프라인에서 발표하시는 분들을 보니 전에 못 느꼈던 자극을 느꼈습니다. 이렇게 열심히 하는 사람들이 가까이 혹은 멀리에 가득하고, 모두 너무 멋있어 보였습니다. 거의 학부생 내내 혼자 조용히 코딩해왔던 터라 몰랐는데, 남들로부터 영감을 받고 서로 교류한다는 게, 개발 자체만 매달리는 것보다 훨씬 풍부한 경험을 준다는 것을 깨달았습니다. 이런 분들을 보니 저도 욕심이 났습니다. 나도 멋진 개발자가 되야지하고 그 어느 때보다 강하게 욕심내고 있습니다.

누군가에게 도움이 되는 개발자가 되고 싶습니다

이 문장을 쓰기까지 몇 일 고민을 했습니다. 정말 이게 맞을까? 다른 무언가 또 없을까? 하고. 그런데 결국 쓰게 되었습니다. 물론, 앞으로 언제 어떻게 바뀔지 잘 모르겠지만 지금으로써는 저 문장에 걸맞는 목표를 잡고 노력해보려 합니다. 당장 취업도 해야하고, 공부할 것도 많고 하지만, 궁극적으로 저에게 직간접적으로, 프로젝트로, 강의로, 블로그로, 혹은 그냥 말 혹은 존재 그 자체로 도움을 주었던 개발자들처럼 저도 누군가에게 도움을 줄 수 있는 개발자가 되고자 합니다. 아직 많이 부족해 직접 도움이 된 경우가 많지는 않지만, 몇 안 되었던 그 작은 경험이 정말 뿌듯했던 것 같습니다. 그래서 앞으로 저는 제가 받은 도움만큼 다른 누군가도 돕기 위해 노력하는 개발자가 되기 위해 노력하겠습니다.

성공과 실패를 빠르고 정확하게 하자

이전까지 저의 프로젝트 및 활동의 가장 큰 문제점 중 하나는 바로, 성과를 측정할 만큼 구체적인 목표가 없었다는 것, 그리고 성과 측정을 위한 지표 수집을 고려하지 않았다는 것이고 생각했습니다. 캡스톤 디자인 프로젝트의 목표는 "잘 돌아가는 웹 서비스의 완성"이었고, 그 외 다른 것도 마찬가지였습니다. "적당히 괜찮은 프로덕트 개발하기" 같은 식으로 접근해 왔다는 걸 깨달았습니다.

예를 들어, 먼저 두리뭉술하게 완성도 못하고 끝냈던 한이음 ICT 멘토링 프로젝트로 진행한 "ChatGPT API를 이용한 번역/작문 웹서비스" 같은 경우. 주제부터가 어마어마하게 두리뭉술합니다. 결국 프로젝트 끝까지 팀원 전원이 무엇을 만들고 있는지 합의하지 못했고, 때문에 엉성하게 저장 기능, 빠른 번역 기능, 파파고와 비슷한 UI 등 명확한 목적 없이 이것저것 기능만 추가하다가 제대로 완성하지 못하고 끝이 났습니다. 가장 큰 문제는 성과를 평가할 지표가 없었으므로, 해당 프로젝트가 실패했는지, 실패했다면 원인이 무엇인지 조차 말할 수가 없다는 것입니다. 만약 다시할 수 있다면 저는 "ChatGPT에 단일 질문하는 것보다 높은 질의 번역 제공"이라는 목표를 가지고, 기존 ChatGPT API를 이용한 번역 결과와 저희가 제공하는 번역 결과(프롬프팅 혹은 자체적으로 에이전트를 구성한 결과)를 함께 보여주고 더 나은 번역 결과에 투표할 수 있는 MVP를 만들었을 것 같습니다. 그렇게 해서 저희 서비스가 제공하는 번역 결과에 대한 사용자 선호도를 일정 퍼센트(예를 들어 60%) 이상 찍는 것을 목표로 노력했을 것 같습니다. 이렇게 해야 추가적으로 외부 LLM을 패키징하여 제공하는 번역 서비스의 가능성을 평가할 수 있고, 유의미한 결과가 안 나오는 경우 프로젝트의 방향을 빠르게 피벗할 수도 있었을 것입니다.

두 번째로 상기한 Groovith의 경우, 솔루션보다는 소셜 네트워크의 성향이 훨씬 강하다고 생각합니다. 애초에 기획의 의도 중 큰 부분이 음악 취향이 맞는 사람들끼리의 커뮤니티 활성화였습니다. 따라서 정확한 양의 유저 수를 목표로 단일 채팅 서버 + 음악 동시 청취 라는 MVP를 만들어 한 달 안에 유저 100명 모으기와 같은 목표를 설정했다면 좋았을 것 같습니다. 또한, 이를 위해 유저의 유입 경로, 유저가 이탈하는 이유, 각 기능에 의해 유저가 서비스에 얼마나 오래 머물러 있는지를 측정할 수 있도록 지표를 마련하고 해당 지표에서의 성과를 기준으로 기능 확장 방향을 선택하는 것이 맞는 전략이지 않았을까 생각이 듭니다. 유저의 지속적인 활동이 주 목적인 만큼 1순위 기능 확장은 유저로부터 나왔어야 했다고 생각합니다.

성과를 측정할 수 있도록 하는 것은 비단 개발 프로젝트에서 뿐만 아니라 일상에서도 중요하다고 생각이 듭니다. 목표를 항상 두리뭉실하고 크게 잡고 살았는데, 좀 바꿔야겠다는 생각을 했습니다. 처음에도 언급했듯 체크포인트의 중요성을 많이 느끼고 있기 때문입니다. 그래서 이제부터 목표는 작고 성패 구별이 확실하게 세울 것입니다. 하지만 아직 그 방법이 정리되지 않은 목표가 있어 나누어 적어봅니다.

명확한 목표

1. 일주일 안에 MVP 프로덕트를 하나 배포해서 10명에게 피드백 받기.

올해 서비스 만들고 제대로 홍보 못한 게 한이라, 해당 아키텍처를 살려 실시간 기반의 다른 외부 기술에 기대지 않는 서비스를 꼭 하나 만들어 홍보를 해보려 합니다. 현재 아이디어가 있어 하나 만들고 있습니다. 이번에는 꼭 빠르게 실패하려고 합니다. 인디 게임들처럼 사용자와 소통하며 성장하는 서비스를 만들어보는 게 장기 목표입니다.

2. 매주 배운 내용 발표하고 영상으로 만들어 유튜브 올리기.

이거는 저번 주부터 진행 중인 스터디 입니다. 제대로 배웠는지 확인하는 가장 좋은 방법은 가르쳐보는 것이다라는 이야기가 있죠? 그걸 한 번 해볼까 합니다. 과정에 누구한테든 도움이 되면 좋을 것 같습니다. 스터디 인원들 모두 관심 갖고 참여해주어 감사합니다.

3. 매주 배운 내용 관련 Stack Overflow 답변 1개 달기.

이거는 그저께부터 시작을 했습니다. 아직 모르는게 너무 많아 좌절스럽기도 했지만, 실제로 따봉 하나 받으니 너무 기분 좋더군요. 계속해보려고 합니다.

4. 매일 LeetCode 문제 2개 풀기.

전날 풀었던 문제 1개, 새 문제 1개 총 2개씩 매일 풀려고 합니다. 오늘 놀러간다고 안 했습니다. 죄송합니다.

아직 좀 두루뭉술한 목표

1. 취업(준비) 하기.

부트캠프 참여나 취업을 위해서 계속 이력서를 쓸 예정입니다. 매일 정해진 시간에 취업을 위한 정보를 확인하고, 이력서와 포트폴리오를 가다듬습니다.

2. 더 잘 기록하기.

단순히 무작정 많이 기록하는 것이 아닌, 이후 나에게 최대한 도움이 될 수 있도록, 기록 방법과 계획을 체계화하기 위해 시도하고 수정해갑니다. 계획법을 학습하고 적용하고 나에게 최선인 것을 찾습니다. 매일 내가 해낸 일과 그 세부사항을 기록합니다. 내 삶도 에자일하게 이슈와 현재 상태를 트래킹합니다. 1주~한 달 간격으로 회고를 합니다. 기록을 통계화/수치화 할 수 있도록 노션이나 무언가로 시스템을 마련합니다.

3. 네트워킹 도전하기.

더 많은 사람을 만나고, 질문하고, 내가 줄 수 있는 도움이 없나 탐색합니다. 기술 컨퍼런스 등의 행사를 최대한 많이 참여합니다. 네트워킹은 경험이 아직 적어서 무작정 어디든 많이 참여해보는 식으로 배워나가려고 합니다. 해당 과정에서 네트워킹에 대한 조언을 모읍니다.

4. 협업을 경험하고 더 나은 동료(리더, 매니저)가 되는 법 고민하기.

여태 내 한몫하면 좋은 동료, 남의 몫까지 해줄 수 있으면 좋은 리더라고 생각했습니다. 몇 차례 협업 경험이 있고 어째선지 매번 리더를 하게 되었지만, 저의 전략(?)은 항상 피할 수 있는 충돌은 피하고, 모두 각자 알아서 잘 할 수 있도록 하며, 부족한 것은 제가 좀 더 희생하는 것이었습니다. 하지만 여러 다른 개발자 분들의 이야기를 접하면서 제가 정말 좋은 동료 혹은 리더가 되는게 무엇인지는 고민하지 않고 그저 제가 편한 것만 골라왔다는 사실을 깨달았습니다. 그렇기 때문에 가능한한 빨리 협업 기회를 다시 얻고 싶고, 그때는 정말 팀원들을 사람으로서 알고, 그들이 가진 문제와 상황을 이해하기 위해 적극적으로 대화해보려고 합니다. 단순히 프로젝트만을 위한 것이 아닌 사람으로서 성장하는데 필요하다고 생각이 듭니다. 개발도 결국 사람이 사람이랑 하는 일이고, 그게 가장 중요한 부분일 것입니다. 좀 더 자세히 적어놓자면, 다음에 제가 리더를 맡는다면 매주 각 인원들과 따로 커피챗을 요청하여 그들이 생각하는 것, 필요한 것에 대해 알아보고, 저도 제가 어떻게 하면 그들에게 더 나은 리더십(혹은 협업 경험)을 줄 수 있을지 조언을 구하려고 합니다. 한 마디로 정말 열심히 귀찮게 하겠다는 건데, 미래의 동료들에게 미리 사과의 말을 올립니다.

마무리

경험할 수록 모르는 것 투성이구나 깨달은 한 해였습니다. 하지만 그만큼 다양한 경험이 중요하다는 것을 알 수 있었습니다. 사실 제 한 해는 개발과 취준만으로 정리하기는 그 외에도 정말 많은 일, 감사한 사람들로 가득했지만, 여기는 블로그 특성상 그 부분만 좀 글로 담아보았습니다. 모르는 부분, 부족한 부분을 알아 그것을 이렇게 정리해놓을 수 있어 너무 좋았다고 생각합니다. 따로 궁금하신 점이 있으시다면 댓글로 얼마든지 남겨주시기 바랍니다.

이거 쓰는 동안 12월 31일에서 1월 1일이 되어버렸습니다. 혹시라도 이 글을 읽게 된 모든 분들 모두 건강하시기 바랍니다.