주니어 XX의 2023 회고록
12월 31일 15시 22분 장소는 신림역 할리스 지하 1층, 나는 연말회고를 해보기 위해서 여느 때와 다름없이 할리스에 왔다. 지금 내가 듣고 있는 곡은 주호의 ‘잘 가요’라는 곡인데 노래가 적당히 우울해서 여러 감정과 기억을 떠올리게 해 준다. 그리고 이러한 감정과 기억은 연말 회고를 조금 더 풍성하게 해주는 것 같아 나쁘지 않은 선곡이라 생각한다.
조금 더 TMI를 말하면, 신림역 할리스 지하 1층은 여느 때와 다름없이 20대들이 (아마도) 하나 둘 모여 각자의 미래를 그려나가고 있다. (연말임에도 말이다) 그래서 이 들의 모습을 보고 있으면 동기부여가 되기도 하고 참 세상 살기 어렵다는 복잡한 생각도 든다. 그렇지만 그들의 생동감을 생생하게 느낄 수 있고 그 생동감이 좋아 종종 이들과 함께 카페에서 작업을 하곤 한다.
2023년 개인적으로 가장 집중했던 것은 나만의 ‘기준’과 ‘정의’를 만들고자 했던 것이다. 2022년 첫 직장을 퇴사할 때만 해도 ‘기준’과 ‘정의’가 많이 부족하여, 눈앞의 코너만 돌면 내가 보고 싶은 광경이 나타날까?라는 의문이 지속적으로 들었고 코너를 돌았을 때도 항상 후회가 더 많았었던 것 같다. 이러한 감정과 경험들은 '불안’이라는 불씨로 커지게 되어 ‘자기 확신’을 점점 연소시키기 시작했고, 그렇게 ‘자기 확신’이 다 타들어갈 때쯤 몸과 마음이 지친 상태로 퇴사를 했다.
하지만 이때의 경험으로 한 가지 확실히 얻은 것은 개발자란 직업이 하는 일이 매력적이다라는 확신은 얻을 수 있었고 "내가 원하는 경험이 무엇이고 내가 가야 할 곳이 어딘지만 알 수 있다면 더 잘할 수 있을 것"이라는 생각이 들었다. 그래서 다시 ‘기준’과 ‘정의’를 바로 잡는 것부터 시작하고자 했다.
가장 좋았던 경험
1년간 프로덕트 팀에 속해 BE 개발자로서 프로덕트 발전에 기여하며, 고객들의 좋은 피드백을 전해 들었을 때, 그리고 세일즈 팀에서 “이번 계약에 XX 기능이 많은 어필이 되었습니다!!”라는 피드백을 들었을 때,
개발의 본질을 어느 정도 깨달은 것 같았고, 조금 더 책임감과 프로 의식을 고조시킬 수 있었으며 나아가 나라는 사람도 성장했던 것 같다. 그리고 나는 이 과정에 매료되었다.
왜 기준가 정의가 중요한가요?라는 질문을 한다면 나의 대답은 다음과 같다.
자기 확신을 가지고 방향을 잃지 않기 위해
선택의 기로에서 기준이 있을 때 방향을 명확히 할 수 있다 생각한다. 제자리에 머무르지 않고 한 발이라도 나아가며 그 과정에서 무언가를 배우는 것을 중요시하는 나에게 기준은 등대처럼 어디로 가야 할지 지속적으로 알려준다.
즉, 기준은 나의 정체성으로서 등대 역할을 하며 나아가야 할 길을 밝혀준다.
기준을 가지고 목표로 나아갈 때 “이 길이 맞을까?”라는 불안은 필연적으로 따라오는데, 나는 이러한 불안을 선택에 따르는 책임이 가져오는 무게감이라 정의한다, 따라서 불안을 이겨내기 위해선 무게를 지탱할 수 있는 견고한 지탱목이 필요한데, 내가 만든 ‘정의’가 책임이라는 무게를 견뎌줄 견고한 지탱목이라 생각한다.
조금 더 디테일하게 말해보면 ‘정의’를 내리기 위해선 무언가를 자세히 아는 과정이 필연적으로 필요한데, 겉으로만 보고 배운 것으론 본인만의 정의를 만들지 못한다. 예를 들어 ‘객체’ (객체지향에서 객체)란 무엇인가요?라는 질문은 사전적인 의미가 넘어 본인 만의 정의를 물어보는 질문이라 생각한다. 이렇게 본인만의 정의를 내리기 위해선 스스로 많은 고민을 해야 하고, 고민 과정에서 꼬리는 무는 질문이 생기게 되고 질문을 해결하며 지식은 쌓인다. 그렇게 쌓인 지식의 최종 형태는 '나만의 정의'가 되며, 이 과정이 견고한 지탱목이 만들어지는 과정이라 생각한다.
선택을 위해선 기준이 필요하고 기준을 세우기 위해선 정의가 필요하며 정의를 내리기 위해선 일련의 '과정'필요하고 이 과정들이 모여 버팀목이 된다.
개발자의 본질은?
컴퓨터를 이용해 비즈니스 영역의 문제를 해결하여, “가치”를 제공하는 직군
즉, 문제의 본질을 고민하고 본질을 해결하여 가치를 만들고자 노력하는 사람들
나의 직업 정체성
나는 자바 스프링 개발자 아닌, 서버 개발자이다. 기술에 종속되지 않고 어떠한 문제든 본질을 파악하고 그에 맞는 해결책을 가지고 가치를 만들어내는 것이 나의 가치를 입증하는 것이다.
기술이란?
기술은 가치를 만들어내는 수단으로, 기술이 가치를 만드는 것이 아니라 가치를 만들기 위해 기술은 사용되는 것이다. 따라서 선택지를 넓히는 것은 아주 중요하다. 그러니 특정 기술에 종속되지 않고 여러 기술에 관심을 가지는 것이 가치를 전달하는 개발자에겐 중요한 역량이라 생각한다.
좋은 개발자란?
비즈니스 관점에서 문제의 본질을 정의하고, 이를 해결하여 고객에게 ‘가치’를 전달할 수 있는 개발자이다.
뛰어난 개발자란?
‘가치 전달’ 사이클이 적게 동작할수록 뛰어나다 생각한다. 사이클은 다음과 같다.
문제 정의 → 가설 설정 → 근거/이유 제시 → 임팩트 측정
가치전달 사이클 횟수가 적을수록 적은 비용으로 고객이 원하는 가치를 제공할 수 있다 생각하는데, 이를 위해 문제를 잘 정의하는 것이 선행조건이라 생각한다. 따라서 ‘문제 정의’가 뛰어난 개발자가 뛰어난 개발자라 생각한다
객체지향이란?
객체는 우리가 직관적으로 아는 것에 더해 관념적으로 이해하고 표현할 수 있는 것이면 그 어떤 것이든 객체라 할 수 있다. 예를 들어 ‘책상’이라는 직관적인 것도 ‘객체’이며 ‘사랑’이라는 관념적인 것들도 객체이다.
객체지향이란 실세계의 투영이며, 객체란 현실 세계에 존재하는 사물에 대한 추상화라는 것이다.
- 객체지향 사실과 오해 -
오해하지 말자
객체지향의 목표는 실세계를 모방하는 것이 아니다. 오히려 새로운 세계를 창조하는 것이다. 소프트웨어 개발자의 역할은 단순히 실세계를 소프트웨어 안으로 옮겨 담는 것이 아니라 고객과 사용자를 만족시킬 수 있는 신세계를 창조하는 것이다.
- 객체지향 사실과 오해 -
내가 생각하는 좋은 팀원이 되는 기준은?
문제와 해결 방법을 공유하는 사람
고집이 있지만 의견을 꺾을 줄 아는 사람
오너쉽이 있는 사람
상대방을 배려하는 사람
스타트 업에서 ‘좋은 코드’의 기준은?
MVP 가치를 제공할 수 있는 코드이면서 동시에 변화에 유연한 코드가 ‘좋은 코드’이다.
개발을 다 했다는 기준은?
Client 관점: 고객이 원하는 데로 동작하는 서비스
개발 관점: 내가 의도한 대로 동작하는 코드
여기까지가 지금 내가 생각하는 정의와 기준들이다. 이것이 정답이라고 생각하지도 않고 앞으로 변하지 않는다 생각하지도 않는다. 그냥 2023년 나의 정의와 기준들이고 이것들을 바탕으로 나는 2023년도를 선택했다.
퇴사 후 위에서 언급한 것들 외에도 많은 부분에서 나만의 기준을 세우고자 노력했다. 하지만 번번이 실패하는 주제들이 많았는데, 이유를 생각해 보면 ‘경험 부족이 가장 큰 원인이 아닐까?’라는 생각이 들었다. 그래서 23년 2월 즈음부턴 난 어떤 기업에서, 어떤 경험을 하고 싶은지에 집중했고 그렇게 정해진 경험들은 다음과 같다.
스스로 문제를 정의하고 해결하는 경험
스스로 문제를 정의하고 해결하는 과정에서 얻는 인사이트로부터 성장하는 경험
개발뿐 아니라 다양한 부분을 경험할 수 있는 회사
이렇게 내가 경험하고픈 경험들을 정리하고 나니, 회사 규모는 크지 않는 것이 유리하겠다는 생각이 들었고, 그 결과 현재 직장은 Pre A 단계의 작은 스타트업으로, 상당히 작은 규모의 회사이다. 합류하고 느낀 점은 체계가 많이 부족하다는 점인데 온보딩 과정도 없었고, 개발 히스토리들도 관리되어 있지 않아 사람의 기억에 의존적인 형태로 유지되고 있었다. 나아가 서비스 운영 관점에서 보면 고가용성도 마련되지 않은 상태라 아마추어 프로덕트에 가까운 모습이었다.
하지만 이게 싫거나 큰일 났다는 느낌은 없었고 오히려 설렘이 컸던 것 같다. 다양한 경험을 하고 싶어, 작은 스타트업을 선택했기에 어느 정도 예상은 했던 부분이기도 했고 동료들과 이야기했을 때 좋은 사람들이고 충분히 진취적인 사람들이라 개선 여지가 충분해 보였기 때문이다.
어지럽고 이쁘지 않은 것들을 깨끗하고 이쁘게 정리하는 능력이 실력이다. 더러운 것을 깨끗하고 이쁘게 탈바꿈시키는 것이 가능한 사람은 깨끗하고 이쁜 환경에서는 한층 더 높은 퀄리티의 프로덕트 (코드 + 인프라 + 업무 프로세스)를 만들어낼 수 있다 생각한다.
- 멘토링 중 -
첫 번째로 개선하고자 한 것은 문서화이다. 처음 합류 했을 때 대부분의 히스토리는 기억으로만 남아있었기에 무언가를 파악하기 위해선 휴먼 리소스가 꼭 투입되어야만 하는 구조였다. 사람은 부족하고 해야 할 Task는 많던 우리 입장에서는 큰 문제가 생각했다. 따라서 온보딩 기간에 파악한 것들을 문서화하여 다음 입사자들의 업무 파악 비용을 낮추고자 노력했고, 나아가 ‘테크 스펙’ 이란 문서화 방법을 도입하여 작업 히스토리를 남기고자 했다.
그 결과는 반 성공이라 판단한다. 아직까지 완벽하게 성공적으로 도입되었다. 보기는 어렵지만 점차 팀원들이 필요성을 깨닫고 있으며, 더 잘 쓰기 위해 노력하고 있다는 점이 절반의 성공이라 판단할 수 있는 요소라 생각한다. 24년도에는 테크 스펙도 리뷰하고 더 완성도 높은 결과물을 만들어내는 단계까지 발전시키는 것이 목표이다.
두 번째는 노력한 것은 서비스 운영 관점에서 개선이다. 운영 관점에서 기술적으로 부족한 부분들이 많았는데, 특히 로깅 및 알람 시스템이 잘되지 않아 문제가 발생해도 문제를 인지하는 것과 문제를 파악하는데 시간이 많이 들었다. 따라서 로깅 전락을 설계하는 것부터 시작하여, 운영 포인트들을 개선하기 시작했다.
일단 로그를 검색 가능한 구조로 만들기 위해 request_id를 추가했고 쌓이는 로그를 보며 무의미하다 판단되는 로그들은 없애고 최대한 운영시점에 필요한 로그만 남기는 방향성으로 개선했다. 나아가 파편화되어 있는 예외처리 로직을 최대한 하나로 관리할 수 있도록 코드도 많이 개선했다.
이러한 시점에 팀장님이 새롭게 합류하셔서 전체적인 운영 방향성에 대해 다시금 검토가 이루어졌고, 그 결과 k8s 환경으로 마이그레이션 하여 k8s가 주는 이점을 조금 더 활용하고 고가용성을 확보하여 모니터링 + 로깅 + 알람 시스템을 개선하여 장애 대응 시스템과 고가용성을 갖춘 서비스로 나아가기로 했다. 따라서 24년 상반기는 k8s로 전체적인 마이그레이션과 여러 운영 포인트를 개선하는 것에 많은 리소스가 할당될 예정이다.
세 번째는 코드 리뷰 환경 구축이다. 어설픈 코드 리뷰가 무슨 의미가 있을까 할 수 있지만 어설픈 코드 리뷰라도 큰 이점이 있다 생각한다. 첫 번째, 코드 리뷰는 공유 가장 기본 형태이다. 개발자가 자신의 코드를 공유하고 피드백받고 본인의 생각을 전달하는 것은 개발자들이 할 수 있는 공유의 가장 기본적인 형태라 생각하며, 공유하는 것은 성장을 위한 필수요소라 생각한다.
지식은 어떤 형태로든 더 성장하기 위해선 공유되어야 하며, 프로덕트 그리고 동료들과 함께 호흡해야 한다. 사용되지 않는 지식은 크게 의미가 없다.
- 내 생각 -
이전의 회사의 경험 + 여러 회사들의 코드 리뷰 문화를 읽어보고 우리에게 맞는 코드 리뷰 환경을 어느 정도 구축한 상태이다. 하지만 아직은 절반의 성공이라 판단하기도 어렵지만 모두가 공감은 해주고 있기 때문에 조금 더 실용적으로 도입될 수 있도록 더 디벨롭시켜야 할 것이다.
현재 코드 리뷰의 문제점
시간을 할애하기 힘들다.
히스토리를 모르는 업무의 Code Review가 올 경우 비용이 비싸다.
면접에 들어가다
지금 회사는 규모가 많이 작았기 때문에 주니어들로 이루어진 회사였고 그 결과 운이 좋게도 나에게도 면접에 참여할 기회가 주어졌다. 면접관으로 면접 자리에 참석하니 지금까지 보지 못했던 관점이 보이기 시작했고, 내가 다시 면접자가 된다면 어떻게 준비해야 할지 새로운 인사이트를 얻은 것 같다. 이때 느낀 점들이 너무 많아 여기서 회고하는 것보단 따로 글을 작성해보고자 한다. 한 가지 확실한 것은 다음과 같다.
함께 일하고 싶은 사람은 기술보다 애티튜드에 있다. 즉, 사람대사람 관계에서 감정은 이성을 앞지른다. (연애랑 비슷한 듯…)
나를 채우는 방법을 잘 모른다는 것
인간적인 부분에서 선호를 만들지 못한 것
사람으로서 내가 줄 수 있는 것은 무엇일까? 명확하지 않다는 것 즉, 나의 강점이 뭘까? 뭘 줄 수 있을까?
공감과 함께 문제를 해결할 수 있도록 도움과 인사이트를 주고 싶다.
문제 해결에 도움을 주고 싶다면 선행되는 것은 이야기를 잘 듣는 것이 중요하다 생각한다.
하지만 현재 자신의 문제를 이야기하기 어려워하는 사람이 있다. (아마 대부분??) 이러한 사람들은 어떻게 다가가서 어떻게 도움을 줄 수 있을까?
나의 사례를 먼저 말하고 상대방의 답변을 유도해 본다.
그 사람에게 신뢰를 준다
그 사람에게 정서적인 지지를 보낸다.
갑자기 치고 들어오는 업무의 우선순위 및 Task 분배가 명확히 되지 않다. 하고자 했던 것들을 못하게 되는 경우 많다.
소통이 어렵다. 대표님의 의중을 명확히 파악해야 하는데 시작이 명확하지 않아 이를 내가 더 디벨롭해야 하는데 쉽지 않았다.
모니터링의 부재로 서버가 죽어도 명확한 Action Item 산정이 어려웠다.
2024년에는 조금 더 인간적으로 성장할 수 있다면 좋을 것 같다. 어떻게 보면 지금까지 나는 한 명의 사회 구성원으로서 내가 무엇을 할 수 있고 어떻게 해야 할까?라는 고민이 주를 이루었다. 그러다 보니 ‘나라는 사람’에 대해 많이 파악하지 못했던 것 같은데 내년엔 이 부분을 조금 더 포커싱 해보려 한다.
1. 내가 좋아하는 것들 잘 알기
2. 내가 줄 수 있는 것들 잘 알고 더 디벨롭하기
3. 개발 외의 장기를 하나 만들기
1. 조금 더 리소스 분배를 잘하는 것 -> 잘하는 것의 기준을 세우기
2. 작업의 완성도를 높이는 방법 알기
3. 업무 속도를 조금 더 높이기
브런치를 통해 꾸준히 글쓰기 해보기
지금처럼 꾸준히 하기
CKAD 자격증 따기
저는 ‘거침없는 개발자’입니다. 스스로 한계와 제약을 두지 않고 어떤 일이든 거침없이 해결할 수 있는 개발자입니다.
내가 개발이라는 업무를 할 때의 근간을 이루는 핵심 가치관이다. 물론 누군가는 그러면 깊이를 챙기지 못하지 않냐라고 할 수 있지만 이 과정에서도 충분히 깊이를 얻는 것이 가능하다 생각하며 오히려 깊이 없이는 거침없이 무언가를 해결할 수 없다 생각한다.
아직 이 부분은 이야기하기 어려운데 24년 회고록에는 이 부분을 꼭 채울 수 있으면 한다. 그렇기 때문에 24년도는 '나는 어떤 사람인가?'를 고민해 보는 해로 보내보려 한다. 그럼에도 지금의 나를 간단하게 소개한다면
저는 무엇이든 꾸준하게 하는 것을 최고의 덕몫이라 생각하며 내 분야에서 프로가 되고 싶은 사람이며, 문화와 예술을 통해 다양한 시선에서 세상을 바라보는 것을 좋아하는 사람입니다!!