DND에 지원하게 된 계기는, 지금까지 해온 개발 경험의 한계를 넘고 싶다는 생각에서 시작됐습니다.
멋쟁이사자 부트캠프와 UMC를 거치며 팀 프로젝트 경험을 쌓았고, 최근에는 AI 여행 플래닝 서비스 Sofly의 백엔드를 처음부터 설계하고 실제 운영까지 해봤습니다. 그 과정에서 "기술적으로 잘 만든 서비스"와 "사용자가 원하는 서비스"가 얼마나 다른지 체감했습니다. Kafka와 Redis로 이벤트 아키텍처를 고도화하고 Blue-Green 무중단 배포까지 구성하면서도, 정작 사용자 흐름을 설계하는 디자이너의 시각이 없으면 그 모든 것이 반쪽짜리 결과물이 될 수 있다는 것을 느꼈습니다.
DND는 개발자와 디자이너가 처음부터 함께 실제 서비스를 만든다는 점이 가장 끌렸습니다. 단기 과제 중심이 아닌 실제 배포를 목표로 하고, 다양한 직군이 한 팀으로 움직이는 구조가 제가 부족하다고 느끼는 부분을 채워줄 수 있다고 생각했습니다. 지금까지는 "어떻게 구현할까"를 고민하는 시간이 대부분이었다면, DND에서는 "무엇을 왜 만드는가"를 다직군과 함께 고민하는 경험을 쌓고 싶습니다.
활동을 통해 이루고 싶은 목표는 두 가지입니다. 하나는 비개발 직군과 실질적으로 소통하는 역량입니다. 기술적 결정을 팀원 모두가 이해할 수 있는 언어로 설명하고, 디자이너와 PM의 요구사항을 시스템 관점에서 구체화하는 능력을 키우고 싶습니다. 다른 하나는 내가 내린 설계 결정이 팀 전체 작업에 어떤 영향을 미치는지 피드백을 직접 받아보는 것입니다. 그 경험이 기술만 쌓는 것과는 다른 차원의 성장이 될 것이라 확신합니다.
현재 가장 관심 있는 AI는 LLM 기반 코딩 어시스턴트입니다. Claude Code를 매일 개발 작업에 활용하고 있는데, 단순한 코드 생성을 넘어 아키텍처 결정 시 의견을 구하거나, 복잡한 쿼리의 성능 문제를 같이 분석하거나, 내가 놓친 엣지 케이스를 짚어주는 방식으로 씁니다. "왜 이 설계가 문제인지"를 설명해주는 점이 가장 유용하고, 주니어 개발자 입장에서 시니어 개발자와 페어프로그래밍을 하는 것에 가장 가깝다고 느낍니다.
AI를 서비스에 직접 통합한 경험도 있습니다. Sofly 백엔드에서 Spring AI와 Google Gemini 2.5 Flash를 연동해 AI 여행 플래너 채팅 기능을 구현했습니다. 단순 API 호출을 넘어, 대화 기록을 PostgreSQL에 저장하고 Redis로 24시간 캐싱하는 하이브리드 메모리 구조를 직접 설계했습니다. 또한 사용자가 일정 확정 의사를 밝히기 전까지는 자연어로만 응답하고, 확정 시점에만 JSON 구조를 출력하도록 3단계 시스템 프롬프트를 설계했습니다. AI 모델의 동작 방식을 이해하고 프롬프트 설계로 제어하는 경험이 특히 인상 깊었습니다.
현재 주목하는 방향은 코드베이스 전체를 이해하고 맥락을 유지하며 협업하는 AI Native 개발 환경입니다. AI가 단순 도구가 아닌 개발 흐름 자체를 바꾸고 있다고 느끼고, 이를 잘 활용하는 개발자가 더 좋은 서비스를 더 빠르게 만들 수 있다고 생각합니다. 앞으로도 AI를 적극적으로 실험하면서 활용 방식을 계속 발전시켜 나가고 싶습니다.
협업에서 가장 중요하게 생각하는 것은 "팀원 모두가 같은 것을 보고 있는가"입니다. 이 원칙을 중심으로 여러 팀 프로젝트에서 구체적인 방법을 시도해왔습니다.
멋쟁이사자 부트캠프에서 두 번의 팀 프로젝트를 진행했고, 그 중 한 프로젝트에서 수상했습니다. 첫 번째 프로젝트에서는 Git 브랜치 전략과 커밋 컨벤션이 없어 충돌이 반복되고 서로 다른 버전을 작업하는 혼란이 생겼습니다. 이 경험을 바탕으로 두 번째 프로젝트에서는 브랜치 네이밍, 커밋 메시지 포맷, PR 리뷰 기준을 직접 제안하고 팀 전체가 합의한 문서로 정리했습니다. 결과적으로 충돌이 눈에 띄게 줄었고, 코드 리뷰 사이클도 빨라졌습니다. 협업 구조를 미리 잡는 것이 개발 속도와 코드 품질 모두에 직접적인 영향을 준다는 것을 그때 처음 실감했습니다.
UMC 활동에서는 팀원 간 개발 속도 차이로 인한 병목 문제를 겪었습니다. 주간 작업 범위를 GitHub Issues로 잘게 쪼개 관리하고, 막히는 부분을 혼자 끌어안지 않고 팀 채널에 빠르게 공유하는 문화를 제안했습니다. 블로킹 상황이 줄고 전체 일정이 안정적으로 유지되는 효과가 있었습니다.
Sofly 백엔드 2인 개발에서는 설계 변경이 생길 때마다 ADR(Architecture Decision Record)을 문서로 남겼습니다. "왜 이렇게 바꿨는가"를 기록해두니 팀원이 맥락을 파악하는 시간이 줄고, 이후 설계를 재검토할 때도 근거가 명확하게 남아 있어 불필요한 재논의를 줄일 수 있었습니다.
Sofly 백엔드를 자신 있게 소개하는 이유는 단순히 기능을 구현했다는 것이 아니라, 설계 결정의 과정과 이유가 문서로 남아 있기 때문입니다.
개발 과정에서 총 9번의 설계 변경이 있었고, 대부분 초기 설계의 한계를 실제로 부딪히며 발견한 것들입니다. 정복 지도의 DB 풀스캔 문제를 Kafka + Redis ZSet 이벤트 아키텍처로 전환하고, 캐싱 전략을 입력 길이 조건부로 세분화하고, JPA N+1과 Cartesian Product 문제를 직접 찾아 수정한 것 모두 문제를 먼저 파악하고 트레이드오프를 따져 해결책을 선택한 경험입니다. 단순히 동작하는 코드가 아니라 왜 그 방식을 선택했는지 설명할 수 있다는 점이 자신감의 근거입니다.