2024년 개발자 회고 - 회사편
오랜만에 회고를 시작하며
항상 1년의 시간은 각별하다. 1년이 지나면 절대 바뀌지 않을 것 같은 바위 같은 생각들도 풍파를 맞아 작은 조약돌이 된다. 나는 이 조약돌들이 쌓이는 것을 보며 스스로의 성장을 판가름하곤 하는데, 모나지 않으면서도 충분히 정제되어 단단하기 때문이다. 나에게 회고는 이 조약돌들을 골라내고 사라지지 않게 유리병에 저장하는 일이다.
2024년 회고를 작성하기 위해 책상에 앉아 지난 1년을 돌이켜보니, 이번 년도는 정말 색다른 1년이었던 것 같다. 나는 학생에서 회사원이 되었고, 집을 나와 자취를 시작했으며, 처음으로 스타를 받은 프로젝트도 생겼다. 그 밖에도 많은 변화가 있었지만, 이 회고에선 직장인이자 개발자로서의 1년을 회고해보고자 한다.
스타트업에서 커리어를 시작했다
인턴을 하며 이 기업 저 기업 돌아다니길 3번 반복했다. 대기업의 인턴 생활을 할 땐 그 복지가 참 좋으면서도 나에게 뭘 기대하는 건지 막막한 면도 있었다. 그러고 정적이고 변화가 없는 기업의 인턴도 했는데, 썩 마음에 들지 않으면서도 시장이 좋지 않아 여기 정착해야 하나 생각했다. 다행히(?) 떨어졌다. 그렇게 3곳의 기업을 거치며 깨달은 것은 나에게 정적인 것은 죽음이라는 것이다.
나는 켄트 백이 이야기한 XP와 애자일에 많은 영향을 받았고 실리콘밸리의 너드들 이야기는 나의 동심을 찾아주었다. 어느새 나는 스타트업의 개발자를 모방하고 있었고, 대기업이나 정적인 중소기업은 나와 핏이 맞지 않는다는 것을 깨달았다.
그렇게 나는 방향을 틀어 스타트업에 지원하기 시작했고 결국 AI 스타트업에서 커리어를 시작하게 되었다.
스타트업에서의 1년, 무엇을 배웠는가?
스타트업이라는 환경과 사고방식은 꽤 낯설면서도 퍽 마음에 들었다. 성장 아니면 죽음뿐이라는 극한의 레이스는 휘청휘청하면서도 조금씩 나아가는 것이 꽤나 스릴 있다. 이 과정에서 스타트업의 유연한 사고방식을 많이 배울 수 있었는데, 그중 가장 인상 깊었던 점 2가지를 적어보겠다.
작은 조직에서 효율적으로 일하는 방법
어린왕자 사투리버전
우리 팀엔 그렇다 할 컨벤션이 없는데, 나는 처음엔 이게 걱정이 됐다. 컨벤션이 없다면 코드를 읽기 어렵기 때문이다. 마치 책에 경상도 사투리, 전라도 사투리, 표준어가 막 섞여 있는 느낌이다.
처음엔 컨벤션을 만들어보려고도 하고 꼼꼼한 코드 리뷰를 해보려 하기도 했는데, 오히려 이게 팀원들의 발목을 잡는 일이라는 것을 깨달았다.
스타트업의 서비스는 충분히 성숙하지 않았기에 기능이 주기적으로 추가되고 변경된다. 때문에 변경될 코드에 컨벤션을 왈가왈부하는 것은 상당히 비효율적이었다. 컨벤션이 좀 달라도 코드를 읽고 이해하는 데 전혀 문제가 되지 않았고, 의미 전달만 잘 된다면 개개인이 가장 효율을 낼 수 있는 방법으로 코드를 작성하는 것이 궁극적으로 더 좋았다.
하지만 자유로운 코드 속에도 꼭 지키는 것이 있었는데, 나의 능률을 우선해 동료의 능률이 떨어지지 않게 한다는 것이다. 내가 더 읽기 편한 스타일이 있어도 동료가 작성한 코드는 함부로 수정하지 않는다. 내 작업을 위해 동료의 코드를 수정해야 한다면 그때 리뷰어로 추가해 “네 코드를 좀 건드렸어, 너의 작업에 문제 될 게 있는지 확인해줘” 같은 방식으로 소통한다. 이런 방식은 불필요한 소통을 줄여 개개인이 일에 집중할 수 있게 도와준다.
물론 이는 작은 조직과 성숙도가 낮은 프로덕트를 개발하기에 가능한 일이다. 큰 조직은 큰 조직에 맞는 규칙이 있어야 혼란스럽지 않다. 하지만 조직이 충분히 작음에도 너무 많은 규칙과 룰을 세우고 있다면 과감하게 룰을 없애고 그 혼돈을 즐겨보는게 어떨까?
파괴를 생각하고 작성하기
위 글은 올해 읽었던 글 중 가장 좋았던 글 중 하나이다. 내용을 짧게 요약하자면 다음과 같다.
비지니스의 복잡도는 시간이 흘러도 줄어들지 않는다.
따라서 정성스레 설계한 코드가 비지니스의 변화에 따라 기술부채가 되기도 한다.
그러니 반대로 제거하기 좋은 코드를 만들어 보는건 어떨까?
글의 뒷내용은 이미 SOLID 등의 거인들이 이미 이야기한 개발 원칙들에 부합하고 있어 매우 놀라운 건 아니다. 하지만 파괴를 지향하자는 주장이 꽤 좋았는데 내가 잘 지키지 못하고 있던 점들이기 때문에 그렇다.
새 코드를 기우고 새 코드로 기우고
7년 된 회사의 레거시 코드는 누더기에 가까웠고 새 프로젝트를 할 때는 마찬가지로 누더기가 되지 않기 위해 좋은 구조를 잡으려고 노력했다. 이 폴더는 무슨 역할이고 저 폴더는 무슨 역할이고… 디자인 시스템을 도입할 땐 의존성을 없애기 위해 UI를 별도의 패키지로 분리하고 네임스페이스로 감싸는 등 갖은 노력을 했다. 결론적으로 그 노력들은 하나도 유의미한 결실을 맺지 못했고 되레 복잡한 구조가 되어 반대로 어떻게 제거할지 궁리해야 하는 골치덩이가 되었다.
문서화에서도 비슷한 경험을 했는데, 당시의 기준으로 문서를 열심히 작성했지만 볼 사람도 없었고, 곧 명세가 바뀌어 의미 없는 문서가 되었다. 물론 문서화가 나쁘다는 말은 아니다. 하지만 지금 이 문서가 필요한지 고민하는 과정이 생략되어 결과적으로 나는 시간만 내다 버린 사람이 되었다.
스타트업의 비즈니스 요구사항은 말 그대로 생물처럼 빠르게 변한다. 오늘 작성한 코드가 내일 레거시가 될 수 있다. 따라서 섣부른 리팩터링과 구조화는 독이다. 비즈니스 요구사항이 빠르게 변하는 기능을 구현할 땐 제거하기 쉽게 짜자. 단순히 중복이 생긴다고 리팩터링 혹은 추상화를 하면 코드 내에 의존성이 생기면서 끈적이게 달라붙어 변화에 대응하기 어렵다.
-2024년 개발자 회고 - 프로젝트편 에서 이어집니다-
