2024년 회고 (1)

들어가며

1월

• 작년에 벌려놓았던 일들이 마무리되기도 전에 새로운 일들이 들이닥쳤다. 어어 하다 보니 순식간에 1월이 지나갔다. 올해에는 맺고 끊음을 확실히 할 시간이 있어서 다행이라고 느낀다. 다음 연말엔 바쁘더라도 이런 시기를 꼭 가져야겠다.

• 1월 10일자로 지금 다니고 있는 회사에 입사했다. 일단 3-2를 마치고 1년 휴학을 할 생각이었다. 휴학을 하지 않는다면 4-1에는 취준을 해야 하는데 아직 그럴 자신이 없었다. 우테코에도 떨어져서 고민하던 차에 23년 여름 인턴을 했던 회사에서 연락이 와서 복귀하게 되었다.

• 연말 약속, 디프만 활동, GDSC 개발팀 기획, 회사 입사 등이 겹치면서 정말 바쁜 시기를 보냈다. 지금처럼 부지런하게 사는 것에 익숙치 않은 시기였다. 처음 1~2주는 퇴근하고 디프만 코어타임을 들어갔다가 바로 침대에 누워서 쉬다가 자는 생활이 계속되었다.

• 며칠 그러다 보니 미안한 마음이 들었고 조금 더 나중에는 부끄러웠다. W나 S나 A 모두 직장을 다니는 사람들이다. 그중에서도 내가 다니는 회사보다 몇 배는 바쁜 곳에서 일한다. 그런 사람들도 얼마 안되는 여유 시간을 쪼개서 디프만에 투자하고 있다- 힘든 내색 하나 없이 말이다. 내가 정말로 바쁘고 힘들다 한들 그들 앞에서 그런 말을 할 자격이 없다고 생각했다. 집 근처 괜찮은 24시간 카페를 찾았고, 퇴근 후 카페에 가서 12시까지 작업하는 루틴을 처음으로 시작했다.

• GDSC KR 연합 해커톤인 ‘눈꽃톤’ 백엔드 멘토로 참여했다.

2월

• 디프만 런칭데이, 최종발표를 거쳐 14기를 수료했다. 우리 팀은 최우수상(2위)를 수상했다. 나는 솔직히 1등도 할 만하다고 생각했는데, 깔끔하게 인정하고 더 원대한 목표를 향해 달리기로 했다. 팀 차원에서 2주 간 리프레시 휴가를 가진 후, 서비스를 계속 이어나갈지, (만약 그런다면) 방향성은 어떻게 설정할지 등에 대해 논의하기로 했다. 자세한 이야기는 뒤에서 다룰 것이다.

• 개발자란 무엇인가? 나아가 좋은 개발자란 무엇인가? 사용자들이 그들의 시간을 내어 우리 서비스를 사용하고, 우리가 만든 서비스가 그들에게 모종의 가치를 제공함을 알았을 때, 나는 개발을 시작한 지 1년 반이 넘어서야 (디프만에서의 경험을 통해) 비로소 개발자가 되었음을 느꼈다. 2월 3일 썼던 ‘개발자가 된다는 것’ 편에서 이 생각을 다루었다.

• 디프만은 내가 여태껏 경험했던 개발 환경 중에서 가장 최고였다. 먼저 최고의 팀원들이 있었다. 평소 가지고 있던 가치관을 타협하고 이력서 몇 줄을 위한 프로덕트를 만들지 않아도 되었다. 이런 내 생각에 대해서도 백엔드 내부적으로 충분한 공감대가 있었다. 백엔드 역시 사용자 경험에 대해 고민할 지점이 있다는 걸 깨달았다. 이때가 디프만 활동에서의 최고점을 찍었을 시기였기에, 자연스래 회사에서의 환경과 비교할 수밖에 없었다.

• 디프만에서 좋은 경험을 쌓을수록 회사에서는 늘 불안했고 짙은 아쉬움을 느꼈다. 개발팀이 축소되고 난 후 백엔드 개발자는 나 혼자였다. 조언해줄 사수도 없었고, 같이 고민할 동료도 없었다. 심지어 그 어떤 의사결정권도 나에게 없었기 때문에 프로덕트 측면에서도 의미있는 시도를 해보기 어려웠다. 전임자들이 망가트리고 간 코드베이스를 수습하는 데 급급했다.

• 이제 한 달이 지났고, 앞으로 11개월이 더 남아있는데, 과연 내가 여기서 성장할 수 있을까? 신입은 첫 스타트가 중요하다고, 이상한 곳에서 시작하면 물경력 개발자가 되기 쉬우니 조심해야 한다고 경고하던 C의 말이 귓가에 맴돌았다. 더 나은 환경이었으면 이것보다 더 나은 결과물을 낼 수 있었을텐데.

• 디프만 런칭데이 때 이 고민을 털어놓았다. 말을 하다 보니 생각이 정리되긴 하더라. 비정상을 평범함으로 돌려놓았다면 평범함을 비범함으로 바꾸는 것 역시 가능할 것이다. 환경에 낮은 종속성을 가지기 위해 더 이상 환경 탓을 하지 않기로 했다. 환경에 종속되지 않는 문제해결능력을 키우는 것에 집중하기로 했다. 사소하다고 생각했던 피쳐들에 의미를 부여하기로 했다. 평소 내리는 일상적인 의사결정들에 무게를 두기로 했다. 이와 관련하여 2월 3일에 ‘바라는 것들의 실상’ 이라는 글을 썼다.

• 좋은 기회로 F사의 대표님과 커피챗을 할 기회를 얻게 되었다. 현재 상황을 진단받고, 이 시기의 고민들에 대해 조언받을 수 있는 귀중한 시간이었다. 최근의 어려운 채용 시장에서도 결국 누군가는 취업을 한다는 이야기를 했고, 그 극소수에 들기 위한 조건에 대해 이야기했다. 필살기를 만드는 것도 중요하지만 그 전에 기본 스탯을 다 채우는 과정이 선행되어야 한다. 오히려 필살기의 존재에 매몰되는 것이 더 위험하다. 정확하게 같은 이야기를 24년 9월 2일 향로님이 ‘과락하지 않기’ 라는 글로 적어주셨다. 7개월이라는 간극이 있지만 이때의 인사이트가 틀리지 않았다는 걸 증명받은 느낌이었다. 그 외에도 이런 이야기를 했다.
• 기본 스탯을 채우기 → 기본기에 대한 이야기였다. 무엇을 하든 탄탄한 CS가 뒷받침되어야 한다. CS 딥디깅 스터디를 추진해야겠다는 생각을 했지만, 결국 올해에는 어떤 액션도 취하지 못했다. 25년으로 이월될 예정이다.
• 필살기 찾기 → 어떤 필살기가 잘 먹히냐? 그건 기업마다 다 다르다. 어떤 곳은 테스트가 중요할 수도 있지만 어떤 곳은 덜 중요하다고 생각할 수도 있다. 몇몇 큰 조직은 의외로 테스트를 잘 작성하지 않는 곳도 있다고 한다. 클린코드도 마찬가지다. 생각하는 것보다는 현업에서 그렇게 중요하지 않다 (이제는 이 말을 이해할 수 있다). 모든 영역의 필살기를 다 찾을 수 없다면 결국 가슴이 시키는 걸 해야 한다.
• 그 외 → 성장하기 위해서는 주변의 도움을 잘 받는 것도 정말 중요하다.
• 예전에 GDSC 23-24 리드 온보딩 데이 연사로 참여한 적이 있다. 발표 준비를 하면서 마지막에 으레 하는 ‘뭔가 궁금한 점이 있으면 여기로 연락을 주시면 된다’는 이야기가 형식적으로 비춰지는 것이 싫었다. 그래서 ‘이렇게 말하면 당연히 연락을 안 주실 것 같고, 저도 단체 대표 경험 없이 처음 1기를 시작한 입장에서 첫 운영이 얼마나 힘든지 알고 있다. 정말 힘든 시간이었고 그때를 생각해보면 더 적극적으로 도움을 요청했을 걸 하는 생각이 들더라. 여러분들도 요청하는 것에 부담을 느끼지 말고, 저 개인 외에도 알럼나이 채널 등을 통해서 도움을 구하셨으면 한다’ 라는 말을 했다. 그 일을 계기로 인하대 리드님이 커피챗 요청을 주셔서 이야기할 기회가 있었다. 또 알럼나이 채널에 질문이 여럿 올라와서, 마지막 이야기하길 잘했다는 생각이다.
• 그런데 정작 그 말을 한 나는 누군가에게 도움을 요청한 적이 많이 없었던 것 같다. 나도 모르게 나약한 행위라고 생각해서가 아닌가. 도움을 요청하는 것에서 나아가, 다른 사람들의 이야기 그리고 생각을 자주 들어야겠다는 생각을 했다. 이 이야기는 뒤에서 다시 다뤄보겠다.

3월

• 와우디벨로퍼스(GDSC Hongik 개발팀)에서 ‘와우온보딩 (당시 기준 GDSC Hongik 온보딩’) 을 런칭했다. PM 겸 백엔드 파트로 참여했다. 사실상 첫 PM 역할이었지만, 그동안의 디프만 활동을 통해 많은 것들-주로 문제를 뾰족하게 정의하는 방법-을 배워왔기에, 내가 해당 포지션을 충분히 수행할 수 있을 것이라는 확신이 있었다. 물론 예상했던 것만큼 잘 풀리지는 않았다. 예상치 못한 이슈들이 계속 발생했다. 런칭이 무산될뻔한 위기도 있었다.

• 그래서 매니징에 대한 고민이 많은 시기였다. 회사의 환경과 디프만의 환경을 비교했던 것처럼 디프만의 환경과 GDSC 개발팀의 환경을 비교하게 되더라. 당연하지만, 디프만의 환경이 더 좋았고, 한창 좋은 기억을 가지고 있던 시기이다 보니, 개발팀의 환경에도 아쉬움이 많았다. 한계를 많이 느꼈던 것 같다- 예전에 리드 시절처럼. 그럼 그때처럼 기대를 낮춰야 하나? 그때와 마찬가지로 실망과 좌절을 반복하고 싶지는 않았다. 얼라인을 맞춰간다는 좋은 표현이 있지 않은가. 둘 사이에는 ‘현실을 인정하기’ 라는 큰 차이가 있었다. 팀에서 쓸 수 있는 리소스가 다를 수밖에 없고, 우리가 낼 수 있는 퍼포먼스도 다를 수밖에 없다. 그걸 인정하기로 했다.

• 배기홍님의 ‘개발자도 회사의 조직원이다’ 라는 글을 인상깊게 읽었다. 이 글은 8월에 정말 유명해지는데, 날 선 댓글들을 보면 전부 이 시기에 달린 것들이다. 개발자의 입장에서는 매우 불편하게 느껴질만한 글이고, 그래서 유달리 몇몇 사람들이 화내는 것도 이해할 수 있지만, 그럼에도 나는 이 글의 견해에 전적으로 동의한다.

• 하지만, 이 글이 아무리 옳은 말을 담고 있다 한들 개발 조직의 매니저가 이러한 입장만을 가진 채 조직원들에게 프로덕트를 위해 희생할 것을 강요한다면, 그것이 올바른 형태의 매니징이라고 볼 수는 없을 것이다.

• 그렇다면 좋은 매니징이란 무엇인가? 디프만에 비해 환경이 아쉬운 것과 별개로, 내가 좋은 매니징을 못 하고 있다는 생각을 했다. 나의 매니징 역량 부족을 환경의 탓으로 돌리고 있는 것은 아닐까. Y의 매니징을 관찰하고 벤치마킹하기 위해 노력했다. 환경이 다른 것을 인정하기로 했고, 우리 팀에 맞는 매니징에 대해 고민했다. 프로덕트 중심적 사고가 중요하지만 매니징을 위해서는 마냥 프로덕트만을 생각할 수 없으며 메이커의 모티베이션을 위한 기술적 챌린지 역시 중요함을 알았다. 가용 가능한 리소스를 잘 파악하고 프로덕트와 메이커 사이의 간극을 적절히 조율하는 것이 좋은 매니징이다.

• 3월 13일 쓴 ‘두 번째는 항상’에서 위에서 언급한 매니징에 대한 고민들을 다뤘다.

• 3월 23일 ‘임팩트 만들기’에서는 비즈니스 가치 그리고 ‘개발자도 회사의 조직원이다’에 대한 글을 썼다. 앞에서 기술 조직의 매니저가 이런 입장을 온전히 지지할 수는 없다는 이야기를 했지만 ‘개인적으로는’ 전적으로 동의한다고 말했었다.

• 예전에 23년 소위 ‘연합동아리’라고 하는 단체에서 내놓는 프로덕트들이 정작 사용자의 문제를 풀 생각은 없고, 이력서에 몇 자 채워넣기 위해 실제로는 없는 문제를 기술적으로 푼 ‘척’ 하기 급급한 세태를 비판하는 글을 썼었다. 배기홍님의 글도 그렇고 이때의 글도 그렇고 결국 같은 맥락에 있으며, 핵심은 ‘가짜 문제’가 아닌 ‘진짜 문제’를 풀어야 한다는 것이다 (물론 무엇이 ‘진짜 문제’인지에 대해서는 조금 입장 차가 있긴 하다).

어떻게 생각해 보면 너무나 당연한데, 우리 주변, 또는 우리 회사의 많은 개발자들이 그냥 본인들이 풀고 싶은 문제를 풀고, 본인들이 개발하고 싶은 기능을 개발하고, 단순히 기술적으로 어려운 문제를 코드로 미화하고 싶어 한다.

• 꽤 오래 전부터 이런 생각을 막연하게나마 가지고 있었다. 그래서 교내 연합동아리는 왠지 들어가기 싫었고 기술보다는 실용적인 무언가를- 지금의 말로는 ‘진짜 문제’를 풀 수 있는- 곳에서 처음 프로젝트를 해보고 싶었다. 다행히 이런 니즈를 디프만에서 (그중에서도 우리 팀에서) 충족시킬 수 있었다. 정말 운이 좋았다.

• 궁극적으로 프로덕트가 성장하기 위해서는 프로덕트를 만드는 메이커들 역시 무시할 수 없기에(그들은 부품이 아니다) 그들의 동기부여를 위한 요소 역시 적절히 고려되어야 한다는 것이다. 만약 정말로 프로덕트’만’이 중요했다면, 왜 유수의 빅테크 기업에서 기술 컨퍼런스를 열고 밋업을 진행하는가? 왜 데브렐 조직을 두고 운영하는가? 그 리소스를 프로덕트 기능 개발에 전부 투자하면 더 나을 텐데.

• 디프만 시절에서는 정말 프로덕트에 미쳐있었고, 그래서 기술보다는 당연히 사용자들에게 가치를 전달하는 것이 중요하며 그에 반하는 모든 행위는 지양해야 한다고 생각했었다. 디프만 서버 팀원들 그리고 다른 개발자 분들과 생각을 나누면서, 그리고 PM 역할을 수행하면서 (중요하다) 흔히 말하는 ‘기술적 챌린지’에 대해 더 온건하게 생각할 수 있게 되었다. 단순히 공감대가 있었다-가 아니라, 나름 합리적인 근거를 가지고 이해할 수 있게 되었다.

4월

• 글또 9기 커피챗이 있었다. 솔직히 말해서 9기 활동은 열심히 참여하지 못했다. 제출은 꼬박꼬박 했지만 만족스러운 퀄리티는 아니었고 (그래서 이때 쓴 글은 전부 지웠다), 처음에 글또에 참여할 때 목표했던 것들을 대부분 이루지 못했다. 회사에 출근하면서 가장 먼저 리소스를 줄일만한 일이 글또 말고 없었다는 핑계 아닌 핑계를 대본다 (…)

• 커피챗 날짜가 일본여행 전날이라 고민도 많이 됐었는데, 카페 마감 시간이 빠른 것이 아쉬울 정도로 즐거운 시간이었다. 이때 10기 참여하실 거냐고, 나중에 10기 하면 꼭 다시 보자는 이야기를 했는데 이 말이 생각나서 10기에 다시 참여하게 되었다 (물론 다시 뵙지는 못했다).

• 4월 초에 일본 도쿄로 여행을 다녀왔다. 디프만 활동은 조금 더 일찍 끝났지만, 디프만 최종발표 이후 바로 와우온보딩 런칭이 잡혀있어서, 실제로는 4월 여행이 나에겐 리프레시 휴가같은 느낌이었다. 여행 목적으로 가는 첫 해외여행이었다. 현지인 가이드 C의 도움으로 편안하게 다녀올 수 있었다. 평소에 여행에 대해 큰 욕심이 없기도 하고, (이 시기에는 아직) 나다니는 걸 그닥 선호하지 않았던 터라 굳이? 싶었는데, 이때를 기점으로 정기적으로 다녀봐도 괜찮겠다는 생각을 했다. 이후에는 부산 여행도 다녀왔고, 또 당일치기로 춘천 여행도 다녀오면서 생후 최다 연간 여행 기록을 갱신했다.

• 별개로 여행을 다녀오기 전에는 ‘에너지를 회복해서 돌아오는’ 걸 생각했는데, 실제로는 에너지를 펑펑 쓰고 왔다. 정말 오랫동안 걸었고 또 걸었다. I에게 ‘에너지 충전 여행’ 따위는 환상이라고. 모순 형용이라니까? 가령 ‘뜨거운 얼음’ 같은 말인거다.

• 집 근처 카페 대신 파이브스팟(일종의 공유오피스다)으로 퇴근 후 작업 루틴을 바꿨다. 24시간 카페는 너무 불편했고, 좋은 카페는 너무 비싸며 영업시간도 길지 않았다. 듀얼 모니터용 아이패드를 들고 다니는 것도 고역이었다. 작업이 더 몰입할 수 있는 공간이 있으면 좋겠다는 생각을 했다. 집 앞 카페보다 접근성은 떨어지긴 했지만 그래도 메리트가 더 크다고 생각했다.

• 회고 모임 이후, 10MM 오프라인 회의가 있었다. 팀 상황은 그닥 좋진 않았다. 방향성을 상실하고 있었고, 다들 디프만 활동 때보다 리소스를 투자하기 어려운 상황이었다. 예전만큼 모티베이션이 이루어지고 있지 않았다. 그래도 좋은 인사이트가 담긴 이야기들이 오갔고, 단기적인 방향성은 잡을 수 있었다.
• 초기 레벨에서는 수치보다 직관이 힘을 발휘한다. 그래서 흔히 말하는 data-driven의 함정에 빠지기 쉽다 (내심 이 말에 찔렸다. 이 시기엔 정량화할 수 있는 가치들에 매몰되었던 것 같다).
• fail-fast. 빠르게 실패해야 한다. 직관으로 의사결정을 내리는 것이 위험할 수 있지만, 차라리 그렇게 실패하는 게 낫다. 수치를 선호하는 것은 괜찮다. 하지만, 그러한 수치를 얻는 데 너무 오랜 비용이 든다면, 그래서 성공과 실패 중 어떤 것도 정해지지 않는다면, 차라리 실패하니만도 못한 결과를 얻게 될 것이다.
• 일단 뭐든 찔러보자. 잘못된 상자를 찔러도 다시 하면 된다. 지금 우리 팀은 무엇이라도 해야 한다. L이 내가 의사결정권을 가지는 게 어떻겠냐고 말했다. 나는 차라리, 내가 아니더라도, D가 하든, C가 하든, 하물며 원숭이를 데려다놓고 제비를 뽑게 시켜도 지금보다는 낫지 않겠냐는 말을 했다. 누가 의사결정을 하느냐가 중요한 것이 아니다. 누구라도 뭐든 하는 게 중요하다. 그런 말을 했었다.
• 피드와 리액션 기능 역시 정밀한 수치를 근거로 하는 의사결정은 아니었다. 런칭데이 이후 최종발표 사이에 무엇을 할까 고민하다가, ‘이거 나중에 하기로 했는데, 그래도 있으면 재밌지 않을까?’ 라는 다소 엉성한 직관에 의해 만들어진 기능이었다. 아이러니하게도 이 덕분에 실사용자를 상당수 받을 수 있었고, 우리 프로젝트가 디프만 이후에도 이어질 수 있게 해준 원동력이 되었다.
• 그래서, 좋아하는 걸 하자. 즐거운 걸 하자. 이 말도 희미하게 기억난다. 이게 돈 받고 하는 일도 아니고, 우리가 시간과 노력을 투자해서 즐겁지 않은 일을 할 이유가 무엇인가? 즐거움에서 원동력을 찾아야 한다.

• 4월 23일, 위의 인사이트와 매니징에 대한 고민에 대해 언급한 ‘그러나 그 또한’ 이라는 글을 썼다.

• 4월 26일, '무위(無爲)’ 라는 글을 썼다. 세 가지 이야기를 했다.
• 비즈니스 가치란 무엇일까? 빅테크 기업과 스타트업, 각각의 조직에서 개발자가 만드는 비즈니스 가치에는 수직적이냐 수평적이느냐의 차이가 있다. 수평적 가치만이 비즈니스 가치가 아니며, 수직적 가치 역시 비즈니스 가치가 될 수 있다는 점을 간과했던 것 같았다. 서로 조직과 목적에 어울리는 방식으로 각자의 문제를 풀고 있을 것이라는 가정을 깔고 보니 더 균형있는 인사이트를 얻을 수 있었다.
• 회사에서 밥을 먹으면서 지금 환경에 대해 감사함을 가져야 한다는 생각을 했다. 뜬금없이 감사하세요-가 아니라, 그러한 감사함을 리마인드하는 것이 일종의 동기부여가 된다.
• 장기적 성장에 있어 의식적 노력 없이 자연스럽게 행하는 것- 즉 ‘무위’가 중요함을 언급했다. 번외로, 재밌는 사실 하나가 있다. 성장하기 위해서는 ‘의식적 노력’이 필요하다고 조언하는 분들도 많다는 것이다. 사실 둘 다 맞는 말이다.
• 3월 말 한빛미디어 세미나에서 B 그리고 새로 만난 T님과 함께 이야기를 나눴다. 헤어지기 전 연락처를 교환하면서 내친 김에 다음 커피챗 일정까지 잡아버렸고, 4월 말에 뵙게 되었다. 그냥 스쳐지나갔을 수도 있는 관계이지만 아래에서 언급할 ‘아주 약간만 더 용기 내기’가 좋은 기회를 만들어주었다. 이 날 꽤 오랜 시간동안 쉴새없이 이야기를 나눴다.
• 집에 돌아와서 개발자로서의 항상성, 즉 지속 가능한 성장에 대해 고민했다. 누군가는 질색할지도 모르지만 나는 사실 개발 얘기를 하는 것이 즐겁고 나를 가슴뛰게 하는데 (처음부터 이랬던 건 아니다), 오히려 빅테크 기술 조직에 속한 중니어들을 뵈었을 땐 그런 말을 안 좋아하는 분들도 정말 많더라는 신기한 이야기를 했다. 그분들이 이상하다는 건 아니고 회사-개인 모드 스위칭을 철저히 하려는 목적도 있겠지만, 그게 발단이 되어 항상성에 대한 이야기로 이어졌다.
• 또 어디선가 그런 이야기도 봤다. 좋은 글이 올라오는 기술 블로그들은 정말 많은데, 그중에서도 수 년 동안 꾸준히 운영하는 블로그는 많지 않더라. 나도 그런 블로그들을 여럿 봤다. 취업 소식과 함께 수년 전에 멈춰버린 블로그들.
• 그래서 비슷한 두려움이 있다. 좋은 기업을 가놓고도 그 환경을 잘 써먹지 못하고 안주해버리는 것. 롱런할 수 있는 원동력을 잃어서 고작 5-6년 일하고 지쳐버리는 것. 지속 가능성을 가지기 위해서는 어떠한 뚜렷한 의식 없이 자연스럽게 행하는 ‘무위’가 중요하며, 고통스러울수록 더 자주 해야 하며 그러한 일에 익숙해져야 한다고 생각했다. 결국 익숙해지면 컴포트 존이 될 것이고, 그러면 다음 구역으로 나아갈 수 있을 것이다.

• 4월 28일, ‘루틴 만들기’ 를 썼다.
• 1 ~ 3월에 비해 4월은 많이 널널한 편이었다. 몸이 편해질수록 더 불안했다. 몇 달만 지나면 24년의 절반이 지나가고, 또 절반이 지나가면 24년이 끝난다. 그러면 이제 취준시장으로 던져진다. 낭비되는 시간을 트래킹해보았고, 꽤 많은 가용 시간이 있다는 걸 깨달았다. 이를 활용하기 위한 루틴을 만들고 실험해보기 시작했다.