사이드 프로젝트와 돌아보는 개발자의 가치

:::info 들어가기 전에

이 글은 편의상 반말로 작성되었습니다.

:::

25년 10월의 긴 연휴 동안 나는 두 가지에 집중했다.
첫째는 4 ~ 5일 간 진행한 사이드 프로젝트의 대규모 리팩토링이었고,
둘째는 지금까지의 프로젝트를 정리하고 문서화하는 작업이었다.

7월 정도부터 무언가를 만들고 싶다는 욕구가 조금씩 다시 생겼다.
그리고 9월 ~ 10월을 기점으로 가속이 붙으면서 사이드 프로젝트 작업이 다시 늘어났고, 이를 갈무리하는 시간도 가지고 있다. 관련된 내용은 여기에서 확인할 수 있다.

이렇게 최근 적지 않은 시간을 투자했지만, 그만큼 사이드 프로젝트, 더 나아가 개발자로서의 가치와 관련해 고민한 시간도 많았다. 고민의 내용은 앞으로도 곳곳에 들어가겠지만, 이 글에서도 한 번 더 정리하고 나 스스로 다짐하는 계기를 마련하려고 한다.

나는 어떤 개발자가 되고 싶은가?

기술: T자형 개발자

지금까지 나는 대부분의 사이드 프로젝트를 개인으로 진행해 왔고, 배포하여 외부에 공개하는 것까지를 목표로 하고 있다. 자연스럽게 모든 분야를 다루어야 했지만 싫지 않았고 오히려 내가 원하는 대로 조율할 수 있는 부분이 많아 좋았던 적이 많다.

각 분야에 대한 우선순위는 분명히 다르다. DevOps와 백엔드는 내가 대외적으로 맡은 업무기도 하고,
관심도 상대적으로 많이 가는 편이다. 반면에 프론트엔드와 디자인은 상대적으로 비중이 낮은 편이다.

하지만 그렇다고 이를 대충 구현할 것인가 하면, 나의 답변은 아니오다.
프론트엔드에서도 기본적인 폴더 구조나 리렌더링 등의 성능 최적화는 잡고 싶었고, 디자인도 AI를 사용해도 정확히 원하는 결과가 나오지 않아서 최근 Figma 서적을 사서 사용법을 익혔다. 너무 이것저것 다루다가 방향성을 잃는 것이 아니라면, 다양한 분야를 접하고 일정 수준의 개념과 깊이를 가지는 것은 큰 그림을 보는 데 도움이 된다고 생각한다.

결과적으로 나는 주력 기술이 있지만 제너럴리스트에 가까운, 두꺼운 T자형 개발자를 추구한다고 정리할 수 있을 것 같다.

서비스 개발 vs 코어 개발

한 가지 더 중요한 선택이 있다. 코어 개발, 즉 Low-level 로직을 깊게 다루는 것과 서비스 개발, 즉 결과물을 보는 것 중 어느 것을 택할 것인가이다.

과거를 돌아보면 나는 항상 눈에 보이는 것을 좋아했다. 대학 시절 전공은 화학이었는데, 그때도 실험 과목은 가장 즐거웠던 시간이었다. 전공이 맞지 않아 다른 진로를 알아볼 때, 프로그래밍을 선택한 이유도 결과물이 바로 눈에 보이기 때문이었다.

코어 개발에 대한 중요성은 충분히 인지하고 있다. 아니, 오히려 몇 번을 강조해도 지나치지 않다. 최근에도 블록체인 스터디를 진행하면서 이 쪽 도메인도 코어 개발이 매우 중요하겠다는 생각을 했고, 다른 곳에서도 이를 느낀 적이 많다. 하지만 실제로 나에게 코어 개발 기회가 주어진다고 가정하면 아직은 망설이게 되는 것도 사실이다. 기술적인 문제도 있을 수 있지만, 무엇보다 추상적이고 와닿지 않는 부분이 있어서가 큰 이유를 차지하는 것 같다. 반면 서비스 개발은 직관적이고 눈에 잘 보인다.

그래서 지금의 나는 코어 개발보다는 서비스 개발, 무언가를 처음부터 만들어내기보다는, 그것을 발전시키고 그 위의 기술을 응용하는 것을 선호하는 것 같다.

물론 조건은 항상 바뀔 수 있다고 생각한다. 나는 지금 DevOps 엔지니어로 일하고 있는데, 초기에 Kubernetes라는 개념은 나에게 너무 멀게 느껴졌다.
그런데 직접 다루고 경험할 기회가 생기니 흥미가 생겼다. 이런 경험이 주어졌을 때 첫 번째로 내가 충분히 변할 수 있다는 것을 알게 되었다. 두 번째로 상황이 변할 수 있다. 어떠한 방식으로든 코어 개발의 근간이 되는 CS 지식은 모든 개발의 기초가 되고, 코어 개발이 매우 중요한 상황이 왔을 때 이를 피하지 않을 준비는 해야 한다.

방향: 나를 고객으로 하는 서비스

그렇다면 나는 누구를 위해, 어떤 방향성을 가지고 개발을 하는 걸까?

첫 번째는 꽤나 명확한데, 확실하게 나를 위해라고 할 수 있다.
사이드 프로젝트를 통해 주도적인 역할을 수행하고 기술을 사용해 보며 실제 성장을 이루고 싶다. 또한 서비스 자체도 실제로 나에게 도움이 되거나 의미가 있도록 하고 싶다. 내가 만드는 서비스인데 내가 고객이 되지 못한다면, 그것은 오래갈 수 없다고 생각한다. 그래서 나에게 주도권이 있는 사이드 프로젝트는 관심사 위주의 주제, 주변 사람들 또는 관심사가 같은 사람들을 대상으로 진행하고 있다.

예를 들어 게임을 즐겼기 때문에 게임 정보 사이트를 3개 만들었고 2개를 아직 유지하고 있다.
최근에 시작한 사이드 프로젝트인 Tiny Clover도 이러한 맥락이다. MCP가 등장했을 때 이것을 개인화하여 AI를 적용한 서비스를 만들면 재미있을 것 같다는 생각이 들었다. 또한 기존에 만들었던 사이드 프로젝트를 개선하고 구조를 통일하여 유지보수와 확장을 쉽게 하고자 하는 목적도 있다. 처음부터 너무 큰 그림을 그리기보다는, 핵심 기능 위주로 2026년 초까지 Production-ready 제품을 만드는 것이 목표이다.

또한 피드백도 중요하게 생각하는 편이다. 피드백에서 전혀 생각하지 못한 요소가 나오는 경우도 많고, 결과적으로 그런 과정을 거쳐 내 서비스를 의미 있게 사용하는 것을 보면 힘이 난다.

결국 나는 먼저 내가 쓸 서비스를 만들고, 겸사겸사 공통분모를 가진 사람들에게 공유하는 것을 방향성으로 잡고 있다.

속도, 완성도, 그리고 멀티태스킹

최근에 한 학생 분에게 사이드 프로젝트 제안을 받아 백엔드 개발자로 참여 중이다. 보상은 기대할 수 없지만 아이템에 대한 진정성이 느껴져서 참여하게 되었다.
합류했을 때 개발 진행이 거의 되지 않은 상태여서 빠른 기능 구현에 초점을 맞추고 진행했는데, 내가 직장인이 아니고 프론트엔드 개발자 1명 정도가 더 있었다면 1~2주 정도에 MVP를 뽑을 수 있을 정도의 속도였다. 실제로 생각보다 엄청나게 빠르다는 피드백도 들었다.

이런 것을 보면, 나는 속도를 내려면 빠르게 낼 수 있는 능력은 있다. 하지만 지금까지 사이드 프로젝트의 속도가 빨랐나 하면 그것은 아니었다. 오히려 느렸던 적도 많았다.
이는 완성도를 계속 올리려고 하다 보니 끝이 없기 때문이다. 실제로 완벽주의 성향이 꽤 강한 편이다. 속도를 챙기게 되면 필연적으로 다른 것을 희생하게 되는데, 이를 포기하지 않고 모두 잡고 가려는 것이다. 그런 과정에서 스피드가 늦어지거나 고민이 깊어지고, 결국에는 흐지부지되는 경우도 있고, 속도가 급격히 느려졌다가 마음을 다잡고 다시 빠르게 나가는 경우도 있다.

최근에는 속도 면에서도 변화가 생기고 있다. AI가 발전하면서 멀티태스킹으로 많은 일을 할 수 있게 되었다.
나도 최근에는 여러 일을 동시에 하고, 반복 작업을 자동화하는 방식을 회사 안에서도, 밖에서도 계속 시행착오를 거치는 중이다. 하지만 나는 개인적으로 멀티태스킹보다는 하나의 일에 집중하는 것을 더 선호한다. 그리고 아직까지는 멀티태스킹을 하더라도 AI가 완벽하게 처리하지 못하면 결국 사람이 보아야 할 부분이 남는다. 과부하가 올 가능성이 좀 있다고 보는 편이다.

개인적으로 이러한 점을 경계하는 편이다. 완벽주의를 지나치게 추구하고 나를 몰아붙이기 시작하면 번아웃이 쉽게 오기 때문이다. 실제로 대학 시절에 번아웃을 겪은 적이 있기 때문에 무서움을 잘 알고 있다.

그래서 어느 정도 흐름에 편승은 해야 하지만, 나의 페이스를 찾아나가는 것이 중요하다고 생각한다.
지금은 다음과 같은 생각으로 개발을 진행하고 있다.

1. 초기에는 최소한의 구조만 잡아 두고 빠르게 기능을 구현한 다음, 이후에 완성도를 높이는 방향으로 나가려고 한다. 속도는 중요한 요소가 맞고, 어느 정도 시행착오를 거치면서 너무 복잡한 코드가 아니라면 직접 리팩토링할 능력이 있기 때문에, 수습이 가능할 거라 생각한다.
2. AI가 발전하면서 좋아진 점은 업무의 일부를 위임할 수 있다는 것이다. Destructive한 작업이나 통일성을 깨는 행위만 잘 제외하면 위임 가능한 부분이 생각보다 많다. 이를 잘 사용하는 것 또한 개발자의 역량이다. 계속 작업을 자동화할 방법을 찾고, 불필요한 요소를 줄이고, 정리하고 통일하면서 균형을 맞추어야 할 것 같다.
3. 강박을 가지지 않고 충분한 휴식을 취해야 한다. 큰 틀에서 루틴이 완전히 깨지는 것이 아니라면, 이것이 오히려 개발을 오래 지속하는 일인 것 같다.

물론 말은 쉽지만 잘 되지는 않아서, 이 균형을 어떻게 맞추어야 할지를 고민하고 있다.

정리하며

그래도 최근 프로젝트를 정리하고 여러 고민을 하면서, 내가 추구하는 개발자의 모습이 조금씩 보이는 듯하다.

나는 DevOps와 백엔드를 중심으로 하면서도, 다른 분야도 경험하며 큰 그림을 볼 수 있는 “두꺼운 T자형 개발자”를 지향한다. 코어 개발자들을 존경하고 중요성에 대해서 인정하지만, 아직은 눈에 보이는 서비스를 만드는 것이 더 즐겁다. 항상 대비를 하며 내실을 다져 나가는 것이 중요할 것 같다.

나는 결국 자신을 위해 개발을 하면서, 이를 기반으로 작은 가치부터 시작하여 의미를 공유하는 것이 나의 정체성이다.

속도와 완성도 사이에서는 아직 균형을 찾고 있다. 하지만 꾸준히 나만의 페이스를 찾기 위해 노력하고 있다.

아직 모든 답을 찾았다고 할 수는 없다. 하지만 적어도 내가 어떤 방향으로 가고 있고 무엇을 중요하게 여기는지는 명확해지고 있다.
앞으로도 이렇게 천천히 한 걸음씩 나아가며 나만의 답을 찾아 나가고, 주변 사람들에게 긍정적인 영향을 주는 사람이 되고 싶다.