시작하기 전에

올해는 내 인생에서 가장 빠르게 지나간 한 해인 것 같다.

스타트업에 왔다보니 확실히 이전보다 개인의 책임과 권한이 많아져 주도적으로 개발할 수 있는 일거리들이 많아서 바쁜만큼 즐겁게 개발할 수 있는 한 해 였던 것 같다.

업무를 떠나서도 개인적으로 시간을 내어 모교 캡스톤 멘토링 및 TSBM 밋업, AI SUMMIT, RAG 개발자 패널토크 등의 커뮤니티 활동과 TSBM 커뮤니티에서 알게된 Node.js 스터디에도 참여했다보니 더욱 시간이 빨리 가지 않았나 싶다.

그리고 올해 3월, 지인의 소개로 4년만에 다시 연애를 시작하게 되어 더 소중한 1년을 보낼 수 있었다. Shout out to MJ !

시간이 가는지도 모르고 어느새 2년차 개발자가 되었지만, 이제야 첫 회고를 작성하게 되었다.

이런저런 핑계를 대자면.. 하룻밤새 전 직장과 그룹사가 뉴스에 나오더니 월급이 밀리게 되었고.. 우리 가족 사정 상 내 월급이 없으면 안되기에 이직을 무조건 해야만 했다.

운이 좋게도 바로 플로우에 합격하여 이직을 할 수 있었고, 다사다난 했던 작년 이맘 때쯤엔 회사에 적응하기 바빠 다른 곳에 눈을 돌리지 못했던 것 같다.

사실 올해 지금은 작년보다도 더 바쁘고 정신없는 상황이지만, 현재 우리 팀의 리더인 유민호 실장님께서 과거에 분기마다 회고글을 작성하신 것을 보고 올해부터는 꼭 회고를 작성해보며 나를 돌아보기로 혼자만의 약속을 했다.

내 삶은 정해져 있는 트랙이 아니기 때문에, 속도만 올려 앞만보고 달려서는 내가 원하는 목적지에 도착할 수 있을지 모른다. 그래서 Sub Destination 을 나누어 그 끝마다 내가 달려온 길을 돌아보며 올바른 방향과 속도로 가고 있는지 회고를 통해 평가하고 다음 목적지로 출발하고자 Road to Carefree Life 회고 시리즈를 작성해나가려 한다.

2025년 - 나는 어떤 사람이었는가 ?

나는 어떤 아들이었는가 ?

나는 듬직한 아들이자 가장이다. 2023년 가을, 대학을 졸업하기도 전에 너무나도 갑자기 우리 가족을 먹여 살려야하는 책임이 생겼다. 올해도 마찬가지로 나는 부모님께 받아온 무조건적인 사랑에 무조건적인 사랑으로 답하고 있는 듬직한 아들로서 우리 가족을 지키고 있다.

나는 어떤 동료인가 ?

이건 평가를 받아야 할 것 같은데.. 부끄러우니 그냥 지극히 주관적인 내용과 평가를 기반으로 작성해봐야겠다. 올해는 정말 다양한 분들과 다양한 프로젝트에서 협업을 했다. 스타트업이라는 특수한 회사의 상황과 분위기도 있지만, 내가 잘 할 수 있는 분야에서 내 역량을 최대한 발휘하고 싶어 기회가 생길때마다 잡으려 했던 시도들 때문이기도 하다. 결과적으로는 여러 프로젝트에서 내 역할을 잘 수행했지만, 이를 동시에 진행하는 과정에서 한 동료분을 설득하지 못한 것 같다. 한 프로젝트를 진행하던 중 또 다른 프로젝트가 시작되었다. 사내 타 개발자 리소스가 없는 상황에서 나는 내 여가시간을 투자하여 해당 프로젝트도 병행하겠다고 리더분들께 제안했고, 흔쾌히 승낙되어 기존 프로젝트 수행에 차질이 없다고 생각되는 선에서 프로젝트를 병행하게 되었다. 하지만 나는 리더분들께 허가를 받아야 한다는 생각만 하고 이를 기존에 함께 프로젝트를 수행하던 동료분께 정확하게 인지시켜드리지 못했다. 개발이 재밌어서, 주말이나 퇴근 후에 사이드 프로젝트를 하며 힐링을 하곤 하는데 그냥 이 시간에 신규 프로젝트를 진행하면 일거양득이라고 생각하고 진행했으나, 이 내용을 충분히 동료분에게 인지시킨 후에 진행했었으면 어땠을까 하는 아쉬움이 다시 한번 남는다. 그 외의 아쉬움은 없는 것 같다. 플로우에서 다양한 분들과 친분을 쌓았고, 회사 밖에서는 형, 동생 할 만큼 공적으로나 사적으로나 친해진 분들도 이제 꽤 있다. 협업 과정에서 배울 수 있는 것들을 많이 배우려고 노력했고, 반대로 내가 도움을 줄 수 있는 부분에서 대신 업무 처리도 하고 의사결정해야 하는 상황에서 충분한 근거를 들어 설득해내곤 했다. 평소 어떤 것을 질문하기 전에 충분히 찾아본 후에 질문하는 것은 예의라고 생각하는데 이 태도 또한 좋은 평가 중 하나였던 것 같다. 동료 평가에서 "커뮤니케이션에 비용이 들지 않는 유일한 동료" 라는 평가도 기억에 남는 것 같다.

나는 어떤 남자친구인가?

올해도, 내년도, 앞으로도 배울 수 있는, 좋은 영향을 줄 수 있는 사람이 되고 싶다.

올해 나는 어떤 개발자였는가?

올해 나는 신규 서비스 개발과 기존 프로젝트의 고도화를 병행하며, 여러 개의 크고 작은 프로젝트를 동시에 수행했다. 대부분의 프로젝트는 누군가에게 배정받은 일이 아니라, 내가 직접 맡겠다고 요청해 시작된 작업이었다. 정답이 정해지지 않은 초기 단계의 문제를 마주하는 일이 부담스럽기보다는, 오히려 그 안에서 구조를 만들어가는 과정 자체를 즐겨왔기 때문이다. 신규 서비스를 여러 프로젝트 및 TFT 를 통해서라도 빠르게 출시하여 결과를 내야하는 상황에서, 회사가 나에게 요구한 역할 또한 그것이라고 생각된다.

기능을 구현할 때 나는 항상 “이 기능은 왜 지금 이 형태여야 하는가” 를 먼저 고민한다. 단순히 요구사항을 충족하는 구현보다, 이 선택이 이후의 확장과 변경에 어떤 영향을 미칠지를 더 중요하게 본다. 그래서 하나의 기능을 설계할 때도 여러 대안 구조를 비교하고, 각 선택이 가져올 트레이드오프를 충분히 검토한 뒤 결정을 내린다. 이런 방식으로 구현된 코드에 대해서는, 동료들로부터 “그 구현에는 분명한 이유가 있을 것” 이라는 신뢰를 받고 있다.

나는 전체 구조를 먼저 그린 뒤 세부 구현으로 내려오는 방식을 선호한다.
파일과 모듈의 역할을 명확히 나누고, 함수와 상수는 재사용 가능한 단위로 분리하며, 확장성과 유연성을 해치지 않는 방향으로 코드를 구성하려고 노력한다. 클린 코드, 헥사고날 아키텍처, FSD와 같은 설계 방식에 관심을 갖는 것도 결국 “지금의 편의보다, 이후의 변화에 강한 구조를 만들고 싶은 욕심” 때문이다.

또한 본격적인 개발에 앞서, 기술적 가능성을 빠르게 검증하기 위한 프로토타입을 만드는 방식을 자주 사용했다. 짧은 시간 안에 실제로 동작하는 형태를 만들어보고, “된다 / 안 된다”를 명확히 판단한 뒤에야 본 개발에 들어갔다. 여가 시간에 진행한 실험이나 R&D 결과가 실제 서비스 기능으로 이어진 경험도 여러 번 있었고, 이를 통해 기술적 상상과 제품 현실 사이의 간극을 줄이는 역할을 해왔다.

최근에는 AI를 단순한 코드 생성 도구가 아니라,
사고를 정리하고 설계를 검증하는 협업 파트너로 활용하고 있다.
구현 전에 코드베이스를 기준으로 직접 전체 계획을 먼저 설계하고, 이를 명확한 텍스트로 정리해 AI와 검증한다. 이를 통해 개발 건에 대한 컨텍스트를 AI 와 공유 및 유지하려고 노력한다. 하나의 커밋을 만들기 전에도 코드 규약, 컨벤션, 포맷팅을 점검하고, 구조적 관점에서 다시 한 번 냉정한 평가를 거친 뒤 반영한다. (Claude Code 사용할 때 "냉정하게 평가해줘" 라고 하면 확실히 날카롭게 변경사항과 코드베이스를 분석하고 더 정밀한 평가를 해주는 것 같아 요즘 자주 사용하고 있다.)

올해 나는 특정 기술 하나를 깊게 파는 전문가라기보다는, 백엔드 / 프론트엔드를 넘나들며 여러 신규 서비스의 구조와 흐름을 책임지는 역할을 반복했다.

그리고 이 과정에서, 불확실한 문제를 외면하지 않고 끝까지 파고들며 “지금 가장 합리적인 구조는 무엇인가” 를 고민하는 개발자로 성장하게 된 올해인 것 같다.

2025 년도의 나는: "불확실한 문제를 구조로 정의하고, 그 구조를 실제 코드로 증명하는 개발자"

2025년 - 나는 어떤 문제를, 어떤 방식으로, 어떤 수준에서 해결해 왔을까 ?

올해를 관통하는 핵심 테마 3가지

1. 정답이 없는 문제를 구조화하여 정의하다

올해 내가 가장 많이 맡아온 역할은, 요구사항이 완전히 정리되지 않은 상태에서 “무엇을 만들어야 하는지”부터 함께 정의하는 일이었다. 기획이 충분하지 않거나 정답이 정해지지 않은 상황에서 요구사항을 그대로 구현하기보다는,
이 문제가 어떤 구조와 흐름을 가져야 하는지를 먼저 고민했다.

여러 신규 서비스 개발을 진행하며, 나는 0에서 1을 만드는 과정에 반복적으로 참여했다. 이 과정에서 요구사항은 종종 불완전했고, 구현보다 먼저 문제의 경계를 나누고 책임을 정의하는 일이 필요했다.
어떤 기능이 핵심이고, 어떤 변화가 구조 안에서 흡수되어야 하는지, 그리고 지금은 구현하지 않더라도 구조 설계를 통해 대비해 두어야 할 지점이 무엇인지에 집중했다.

기능 하나를 설계할 때도 “이 방식이 왜 지금 상황에서 가장 합리적인가” 를 설명할 수 있어야 한다고 생각했다.
그래서 단순히 동작하는 코드를 만드는 데서 멈추지 않고, 대안 구조와의 차이, 선택하지 않은 이유까지 정리하며 구현을 진행했다. 이런 과정 덕분에, 내가 구현하거나 리팩토링한 기능에 대해서 구현 방식 자체에 대한 신뢰가 자연스럽게 형성되었다.

이 경험을 통해 나는 주어진 요구사항을 빠르게 처리하는 개발자에서, 문제의 구조를 정의하고 그 선택에 책임을 지는 개발자로 역할이 바뀌고 있음을 느꼈다.
기술 스택이나 특정 구현 방식보다, 문제를 어떻게 정의하느냐가 결과의 품질을 좌우한다는 것을 올해의 경험을 통해 분명히 체감하게 되었다.

2. 빠르게 검증하고, 확신이 생긴 뒤 깊게 들어간다

팀 내에서 새로운 방향이나 문제 정의를 두고 오랜 고민과 논의를 이어가도 명확한 결론에 이르지 못하는 상황이 자주 있었다. 그럴 때마다 리더가 나에게 했던 요청은 늘 비슷했다. “실제로 동작하는 형태를 빠르게 만들어 올 수 있겠는가. 그걸 보고 한 번 결론을 내보자.”

이 경험을 반복하며, 나는 가능성을 말로 설명하거나 논쟁하기보다 짧은 시간 안에 실제로 동작하는 결과물을 통해 판단의 근거를 만드는 역할을 맡게 되었다. 완벽한 설계를 충분히 고민한 뒤 움직이는 것도 좋지만, 때론 빠른 검증을 통해 방향성을 좁혀가는 방식이 조직과 프로젝트에 더 효과적이라는 것을 몸으로 익히게 되었다.

새로운 기능이나 기술을 도입할 때도 곧바로 본 구현에 들어가기보다는, 최소한의 형태로 프로토타입을 먼저 만들었다. 이를 통해 기술적 제약이나 예상치 못한 병목을 조기에 드러내고, “된다 / 안 된다”를 빠르게 판별했다.
이 과정은 불필요한 구현을 줄이고, 팀의 시간과 리소스를 아끼는 데 중요한 역할을 했다.

여가 시간에 진행한 개인적인 R&D 역시 단순한 실험에 그치지 않고, 실제 서비스에 적용 가능한 수준까지 발전시키는 데 집중했다. 직접 구현한 결과를 팀에 공유하고 시연하면서, 아이디어의 가능성을 말이 아닌 코드로 설명했고, 그중 일부는 실제 프로덕트의 기능으로 이어졌다.

여러 프로젝트를 동시에 병행해야 했던 환경에서도 이 방식은 특히 효과적이었다. 모든 것을 완벽히 이해한 뒤 움직이려 하기보다, 작게 만들고 빠르게 검증하면서 방향을 좁혀나갔기 때문에
속도를 잃지 않으면서도 판단의 정확도를 유지할 수 있었다.

이 경험을 통해 나는 완벽한 설계에 집착하던 개발자에서, 검증을 통해 의사결정을 가능하게 만드는 개발자로 사고 방식이 확장되었다. 확신 없는 상태에서 시간을 쌓는 것보다, 작은 시도를 통해 빠르게 근거를 만들고 그 위에서 깊이를 더하는 것이 때론 실무에서 훨씬 강력한 전략임을 올해의 경험을 통해 체득했다.

3. 코드를 기능이 아니라 ‘자산’으로 만들다

여러 프로젝트를 동시에 진행하고, 신규 서비스 개발과 고도화를 반복하면서
나는 코드가 단순히 “지금 동작하는 결과물”로 남아서는 안 된다는 생각을 점점 더 강하게 하게 되었다.
당장의 요구사항을 빠르게 충족하는 것은 당연한 전제였고, 그 과정에서 이 코드가 이후의 변화와 확장을 얼마나 견딜 수 있는지까지 함께 고민했느냐에 따라 프로젝트 전체의 속도와 안정성이 달라진다고 느꼈기 때문이다.

그래서 기능을 구현할 때도 개별 로직을 빠르게 추가하는 방식보다는, 확장 가능성을 고려해 구조를 먼저 정리하는 데 많은 시간을 썼다. 역할과 책임이 명확하게 드러나도록 파일과 모듈을 나누고, 공통으로 사용될 가능성이 있는 로직은 의도적으로 분리했다. 이 선택은 당장은 구현 속도를 늦추는 것처럼 보일 수 있었지만, 요구사항이 늘어날수록 오히려 전체 수정 비용을 낮추는 결과로 이어졌다.

또한 코드의 품질을 개인의 취향으로 남기지 않기 위해 컨벤션과 포맷, 커밋 단위까지 신경 쓰는 습관을 유지했다.
코드는 혼자만 이해하면 되는 결과물이 아니라, 팀이 함께 읽고 수정하며 오래 가져가야 할 자산이라고 생각했기 때문이다. 클린 코드나 헥사고날 아키텍처, FSD와 같은 설계 방식에 관심을 가져온 것도 특정 방법론을 따르기 위해서라기보다, 역할과 경계를 명확히 드러내는 구조를 만들기 위한 고민의 연장선이었다.

이 과정에서 AI 역시 단순히 코드를 대신 작성해주는 도구가 아니라, 내가 세운 설계와 구조를 검증하는 파트너로 활용했다.
구현에 들어가기 전에 계획을 명확히 정리하고, 코드 규약과 구조적 관점에서 다시 한 번 점검한 뒤 반영함으로써
한 번 만들어진 코드가 쉽게 무너지지 않도록 관리했다.

이 과정을 통해 나는 “작동하는 코드”를 만드는 개발자에서, 시간이 지나도 유지되고 축적되는 시스템을 만드는 개발자로 사고가 확장되었다.
코드 품질은 개인의 만족이나 취향의 문제가 아니라, 팀의 생산성과 서비스의 지속성을 결정짓는 중요한 자산이라는 인식을 올해의 경험을 통해 분명히 갖게 되었다.

올해 수행한 프로젝트

FLOKR - 대기업 보험사의 OKR 성과 관리 시스템

올해 가장 오래, 그리고 가장 깊게 몰입했던 프로젝트다. 대기업 보험사에서 기존 엑셀 기반의 OKR 관리를 벗어나, 수만 명 직원의 부문/부서별 성과를 한눈에 시각화하고 싶다는 요구가 있었다.

나는 이 프로젝트에서 백엔드 전체 설계/구현과 프론트엔드 전체, 특히 OKR Map 시각화를 담당했다. "사람의 업무 흐름을 코드로 표현한다"는 관점에서 접근해야 했던 프로젝트였는데, 추상적인 OKR 개념(목표-핵심결과)을 과제(Task) - 액션플랜(ActionPlan) - KPI라는 계층 구조로 모델링하고, 이를 d3.js 기반의 인터랙티브한 트리 다이어그램으로 시각화하는 것이 핵심 도전이었다.

기술적으로 가장 기억에 남는 부분은 트리 구조 생성 시 N+1 쿼리 문제 해결이다. 부문별로 수백 개의 노드를 처리해야 했는데, 각 Task마다 하위 ActionPlan과 KPI를 개별 조회하면 성능이 급격히 저하되었다. 이를 In() 연산자를 활용한 배치 쿼리 패턴으로 해결하고, Redis 캐싱 인터셉터까지 도입해 응답 속도를 크게 개선했다.

아키텍처 측면에서는 흥미로운 전환이 있었다. 초기에 헥사고날 아키텍처(CQRS 패턴)로 시작했지만, 프로젝트 규모 대비 과도한 복잡성과 팀원들의 러닝커브 문제로 레이어드 아키텍처로 전환했다. "적정 기술"의 중요성을 몸소 체감한 경험이었다. 완벽한 설계보다 동작하는 시스템, 그리고 팀이 함께 유지보수할 수 있는 구조가 더 중요하다는 것을 배웠다.

프론트엔드는 퍼블리싱 팀과의 협업 제약으로 VanillaJS를 사용해야 했다. React가 아닌 환경에서 d3.js의 foreignObject를 활용해 복잡한 카드 UI를 SVG 안에 삽입하고, 미니맵 네비게이션과 줌/팬 인터랙션까지 구현하는 과정은 쉽지 않았지만, 그만큼 성장할 수 있었다.

현재 스테이징 배포가 완료되어 운영계 반영을 대기 중이며, AI TFT 수행을 위해 인수인계를 완료한 상태다.

상세 개발 기록은 FLOKR 프로젝트 상세에서 확인할 수 있다.

FLOWIKI - 사내 위키 및 실시간 협업 문서 시스템

이 프로젝트는 FLOKR을 진행하던 중 시작된 신규 프로젝트였다. 앞서 "동료를 설득하지 못했다"고 언급했던 그 프로젝트가 바로 FLOWIKI다. 사내 개발자 리소스가 부족한 상황에서 내 여가시간을 투자해 병행하겠다고 제안했고, 약 2개월간 초기 개발을 담당했다.

FLOWIKI는 Notion이나 Confluence 같은 외부 도구 의존도를 줄이고, 사내 지식을 체계적으로 관리할 수 있는 실시간 협업 문서 시스템이다. 나는 프론트엔드 초기 아키텍처 설계와 Full Text Search 백엔드를 담당했다.

이 프로젝트에서 가장 의미 있었던 경험은 초기 개발만 담당했음에도 실제 엔터프라이즈 고객사에서 운영되는 서비스의 기반을 설계했다는 점이다. Next.js App Router, TipTap 에디터, Zustand 상태 관리 등 기술 스택을 직접 선택하고, 이후 확장을 고려한 구조를 설계했다.

기술적으로는 PostgreSQL Full Text Search 한글 처리가 가장 도전적이었다. 한글은 영어와 달리 형태소 분석이 필요하고, 조사와 어미 처리가 복잡하다. to_tsvector('korean', ...) 과 to_tsquery('korean', ...) 를 활용해 한글과 영어를 동시에 검색할 수 있도록 구현했고, 파라미터 바인딩을 통해 SQL Injection 방어도 철저히 했다.

또한 계층형 사이드바의 재귀적 트리 렌더링 성능 최적화, Zustand persist 미들웨어를 활용한 탭 상태 유지 등 실제 사용자 경험을 고려한 세부 구현들을 직접 해결해나갔다.

현재 FLOWIKI는 SK 쉴더스, 매그나칩 반도체 등 엔터프라이즈 고객사와 플로우 SaaS에서 운영 중이다. 초기 개발만 담당하고 운영은 다른 분께 인수인계했지만, 내가 설계한 구조 위에서 서비스가 확장되어 실제 고객들이 사용하고 있다는 사실이 뿌듯하다.

상세 개발 기록은 FLOWIKI 프로젝트 상세에서 확인할 수 있다.

두 프로젝트를 통해 배운 것

FLOKR과 FLOWIKI, 성격이 전혀 다른 두 프로젝트를 동시에 진행하면서 나는 **"문제의 본질을 파악하고 구조로 정의하는 능력"**이 가장 중요하다는 것을 깨달았다.

FLOKR에서는 "사람의 업무 흐름을 어떻게 코드로 표현할 것인가"를, FLOWIKI에서는 "사용자가 정보를 어떻게 찾고 정리하는가"를 고민해야 했다. 기술 스택은 달랐지만, 결국 도메인을 깊이 이해하고 그에 맞는 구조를 설계하는 과정은 동일했다.

또한 두 프로젝트 모두 **"적정 기술"**의 중요성을 가르쳐줬다. FLOKR에서의 헥사고날 → 레이어드 전환, FLOWIKI에서의 RediSearch 대신 PostgreSQL FTS 선택 등 화려한 기술보다 상황에 맞는 합리적인 선택이 프로젝트의 성공을 좌우한다는 것을 체감했다.