글을 작성하면서..
오늘은 다시는 돌아오지 않을 24년의 마지막 날이다. 지난 24년의 개인적인 부분과 업무적인 부분에 대한 회고를 작성하였으나, 생각보다 많은(?)양에 요약이 필요하다는 생각을 하게 되어 "24년을 지나며, N개의 깨달음" 이라는 글을 통해 나를 다시한번 정리해보고자 한다.
그리고 이 글은 주기적으로 나 스스로 앞으로 반복하여 볼 생각이다. 그래서 이 글의 독자는 미래의 나 가 핵심으로 생각하며 작성한다.
과거부터 지금까지 나는 회고를 좋아하는 사람이다. 주의해야 할 것이 후회가 아니라 회고이다. 내가 생각하는 회고는 과거를 돌이켜보며, 더 나은 결과를 기대할 수 있지만, 후회는 과거에 사로잡혀 미래를 그리지 못하고 더 안 좋은 결과를 기대하게 된다.
나는 호기심이 많은 사람이다. 특히 개발(커리어)적으로는 현재 굉장한 호기심과 관심이 많다. 그래서 다양한 경험과 지식을 쌓기 위해 책과 강의를 통해 많은 호기심을 해소해오고 있다. 하지만 이것만으로는 나의 욕구를 충족시키지 못하였다.
그러던 중, 나는 현재 회사(미션드리븐)에 지난 4월 말 입사하게 되었다. 미션드리븐은 작년 창업한 극 초기의 스타트업으로, 무에서 유를 만드는 과정 중의 회사이다.(진행 중..) 그리고 나는 이 부분에서 많은 끌림을 느꼈다. 어디서도 경험하지 못한 굉장히 비싼 경험과 시간을 매우 직접적으로 부딪쳐볼 수 있을 것이라 생각했기 때문이다.
그리고 실제로 이는 내 예상과 같았다. 하지만, 내 예상(각오)보다 더 큰 일과 깨달음을 얻을 수 있었다. 지난 약 9개월의 기간은 커리어 적인 부분을 넘어, 인생에 대한 부분도 스스로 많이 고민하고 생각할 수 있는 시간이었다. 그리고 나는 이번 24년이 나에게 큰 성장(with 성장통)을 이끌어준 한 해였다고 생각한다.
나는 24년에 깨달은 내용이 미래에 어떻게 작용할지 기대도 되고, 걱정도 된다. 그러나 왜 기대도 되면서 걱정이 되는지 내 스스로 분명하게 이유를 설명하지 못하겠다. 하지만.. 미래의 나는 내가 왜 이런 생각을 갖게 되었는지 답을 알것이라고 믿는다. 언제가 될지 모르지만, 분명하게 지금 작성하는 이 글이 힌트가 되어 내 스스로 답을 내릴 수 있을 것이라고 확신한다.
과거에 내가 미래의 나에게 도움이 되길 기대하며.. 24년 마지막 글을 작성한다.
1. 나는 개발을 생각보다(?) 좋아하는 사람이다.
개발에 입문한 21년 12월 부터 지금(글을 작성하는 시점)까지 나는 개발을 좋아한다. 개발을 좋아하는 이유는 개발에는 정답이 없으나, 오답은 존재하기 때문이다. 그리고 우리(나)는 정답이 오답이 되지 않도록 계속해서 개선해 나가는 과정을 즐긴다. 나는 개발이 좋고 개발하는 과정이 즐겁다.
2. 개발에서 중요한 것은 기술보다는 비용이다.
개발을 좋아하면서, 다양한 기술에 흥미가 생긴 나는 다양한기술을 접하게 되었다. 좋은 기술을 사용하면 좋다. 하지만 좋은 기술 모두가 나에게 좋은 기술이 되지 않는다. 비용이 많이 든다면..!
개발에서는 기술보다는 현재 상황에 맞는 기술을 사용하는 것이 중요하다. 그리고 현재 상황에서 가장 큰 영향을 주는 것은 비용(시간과 실제 돈을 포함한 모든 리소스)이다.
생각보다 초기 서비스에서 내가 공부한 심화(?)의 기술은 오버엔지니어링에 가까운 경우가 많았다. 그리고 오버 엔지니어링은 불필요한 비용이 많이 들었다.
3. 개발 비용에 많은 영향을 주는 것은 새로운 코드(기술)보다는 기존의 코드(기술)의 영향이 크다.
개발에 있어서 새로운 코드를 작성하는 일은 생각보다 많지 않다.(새로운 서비스를 개발하지 않는 이상..) 이에 더해 새로운 코드를 작성하는 경우, 기존의 코드 작성 스타일(컨벤션 및 기술스택)을 활용하여 작성하기에 새로운 기술을 사용하는 일은 흔하지 않다. 그리고 생각보다 새로운 기술을 도입하는 것은 굉장히 어렵다.
하지만 매일 우리는 기존의 코드를 수정하고 수정한다. 그리고 수정을 하면서 가장 큰 비용이 발생되는 부분은 코드를 이해하는데 발생한다. 기존의 코드의 의도를 파악하는데 비용이 발생하고, 작성된 코드들의 다르게 작성된 코드 컨벤션, 방식, 설계에서 오는 고민에서 발생한다.
기존의 코드의 일관성은 비용(aka. 유지보수)에 큰 영향을 주며, 레버리지가 굉장히 높다.
4. 기존 코드를 유지보수 하면서 생각보다 큰 비용을 차지하는 것은 예측 가능성이다.
코드를 작성하면서 의도가 드러나지 않는(예측 불가한)코드는 예상보다 거대한 기술 부채로 다가오는 경우가 많다. 덧붙여 예측 가능성이 떨어지는 코드는 사용의 오용과 남용의 가능성이 커지게 된다. 그리고 잘못 이해한 코드는 문제가 발생했을 때, 굉장히 오싹하다.
그리고 이런 예측 가능성을 높일 수 있는 가장 좋은 방법은 표준(컨벤션)에 대한 약속이었다. 나는 컨벤션을 함께 만들어 가면서 실제로 코드의 예측 가능성을 높일 수 있었다. 뿐만 아니라 불필요한 코드이해 시간도 줄일 수 있었다.
5. 우리 중심 기능 개발이 아닌 사용자 중심의 기능 개발이 중요하다.
개발이 핵심이 되어 움직이는 경우, 기술 중심적이 되고 합리적이지 못한 리소스를 사용하게 되는 경우가 많았다. 돌이켜볼 때, "왜 이 기능이 사용되지 않는거지?" 생각이 들 때면, 이 기능은 사용자의 목소리에서 기반된 것인가? 아니면 우리가 있으면 좋겠다.(하고싶다)하는 기능이었는가? 에서 답을 얻을 수 있었다. 즉, 우리가 만들고 싶은(하고싶은) 기능을 개발하면, 사용자가 잘 사용할 확률이 현저하게 줄어들었다.
6. 생각보다 기술적인 챌린지(최적화)는 많지 않다.
내가 생각하는 기술적인 챌린지는 최적화다. 내가 생각하는 최적화에는 코드 최적화, 구조 최적화 등이 있다.
입사 이전 관심이 많았던 다양한 패턴과 아키텍처는 생각보다 실무에서 사용될 일이 적었다.(거의 없었다.) 기술적으로 문제가 되고 한계에 부딪히는 일이 거의 없었다.
개인적으로 생각해본 기술적인 챌린지가 없었던 이유는, 현재 일반적인 서비스 아키텍처(MVC, 수평확장 패턴)만으로도 가용가능한 수준의 서비스였기 때문이지 않았나 싶다. 하지만 기술적인 챌린지가 없다하여 다양한 패턴과 아키텍처에 대하여 흥미를 잃은 것은 아니다. 여전히 관심이 많고 언젠가는 나도 이런 기술을 실제 서비스에 적용해볼 수 있는 날을 상상하며 공부하고 있다.
7. 개발자에게 가장 중요한 것은 개발이 아니다. 현재의 상황에 따라 개발보다 더 중요한 우선순위의 일이 발생할 수 있다.
나는 개발자라면 개발이 가장 중요한 일이라는 생각을 갖고 있었다. 아무래도 첫 회사의 영향이 크지 않았나 싶은데, 첫 회사에서는 개발팀이 존재하여 개발 부분에 대하여 한정하여 생각과 업무만 진행했었다.
그러나 지금 초기 스타트업의 특성 상, 개발도 굉장히 중요한 것은 맞으나 개발보다 더 중요한 일들이 발생하는 경우가 많았다. 예를 들어 고객의 인터뷰를 진행하여 정성 데이터를 취합하고 고객의 진정한 문제를 파악하는 것이 있었다. 만약 내가 코드 작성(개발)만 중요하게 생각했다면 나는 고객의 목소리를 듣지 못하고, 필요한 기능이 아닌, 있으면 좋을 기능을 개발하고 있었을 지 모른다.
마무리하며: 24년의 깨달음을 25년의 성장으로
지난 24년은 나에게 '개발자로서의 정체성'을 다시 한번 정립하는 시간이었다. 단순히 코드를 작성하는 사람이 아닌, 사용자의 문제를 해결하고 비즈니스 가치를 만들어내는 개발자로 성장할 수 있었다. 특히 초기 스타트업에서의 경험은 '기술을 위한 기술'이 아닌 '목적을 위한 기술'이라는 관점을 갖게 해주었다. 하지만, 아직 부족하다.
지난 24년은 주변의 영향을 받아 주변 사람들을 닮아 갔던 것 같다.(이게 싫지 않다.) 나는 해당 부분을 더 성장시키고 싶고 성장하고자 한다. 이러한 깨달음을 바탕으로, 25년에는 다음과 같은 기준과 목표를 설정했다.
1. 기술적 깊이와 비즈니스적 관점의 균형
나는 여전히 개발적 지식 및 기술에 관심이 많다. 지금 상황에 도움이 될 수 없는 기술이 될 수 있지만, 지금과 같은 공부와 호기심을 유지하고자 한다. 다만, 비즈니스 임팩트를 고려한 기술 선택과 적용을 할 수 있는 개발자가 되고자 한다.
이 코드(기술)이 작성되었는지, 보다 분명한 의도를 갖고 설명할 수 있는 개발자가 될 것이다. 계속해서 연습하고 있는 부분이나 아직 많이 미흡하다. 올 한 해 이 목표를 매 순간 잊지 않고 적용하여 올해 말에는 보다 효율적인 기술 선택과 코드 작성을 통해 비즈니스적 효율적인 코드 작성을 할 수 있는 개발자가 되어보겠다!
2. 지속 가능한(클린) 코드 작성
과거부터 지속된 클린 코드에 대한 관심과 공부의 내용을 바탕으로 내가 생각하는 클린코드의 기준을 적용하여 서비스 코드에 적용해보고자 한다. 코드 작성에 있어 클린코드는 상황에 따라 모두 다르다는 것을 알고 있다. 하지만 클린 코드를 작성하는 것은 지속 가능한 개발을 위해 필수적이다. 그래서 나는 현재 상황에 맞는 나만의 클린 코드 규칙을 만들고 작성해보고자 한다.
아마도 클린 코드에 대한 생각은 계속해서 변화할 것이다. 그러나 핵심적인 내용은 변화하지 않을 것이다. 그리고 내가 생각하는 핵심은 "코드에 의도가 분명하게 표현되고, 경계가 명확한 코드"라고 생각한다. 핵심 가치를 달성하기 위해 다방면으로 공부하고 시도해 보아야 겠다.
3. 사용자 중심의 문제 해결
나는 올 한 해에는 보다 더 기술적 관점 보다는 문제 해결에 집중해보고자 한다. 물론 개발을 진행하면서 기술적인 고려가 이뤄지지 않을 순 없다. 그러나 기술에 사로잡혀 섣부른 최적화, 오버 엔지니어링을 가장 경계해보고자 한다. 작성하는 코드(기능)은 사용자의 문제 해결이 최우선이라는 것을 잊지 않고 개발하여, 효율적인 코드 작성 및 기능 개발을 할 수 있는 개발자로 성장할 것이다.
이제 24년의 깨달음은 25년의 밑거름이 될 것이다. 미래의 내가 이 글을 다시 읽을 때, 이러한 다짐들이 얼마나 실현되었는지 되돌아볼 수 있기를 바란다. 그리고 그때는 또 다른 새로운 깨달음으로 더 성장한 내가 되어있기를 기대한다.
'회고' 카테고리의 다른 글
| 3개월 스타트업 개발자 인턴을 마무리하며, 느낀점 (4) | 2024.02.27 |
|---|
