에개모는 EDU 스쿼드 개발자들이 스프린트마다 모여 기술 로드맵, 코드 리뷰 문화, 지식 공유, 운영 프로세스를 함께 다룬 정기 개발자 모임입니다. 빠른 비즈니스 일정 속에서 개인에게 흩어지던 시행착오와 판단 기준을, 팀이 함께 쓰는 자산으로 바꾸기 위해 만들고 조정해온 모임입니다.

프로젝트 한눈에 보기

항목	내용
문제	급격히 커진 스쿼드와 빠른 일정 속에서 기술 로드맵을 챙길 여력이 없고, 전문성·시행착오·운영 개선 아이디어가 특정 인원과 개인 대화에 흩어지던 상태
역할	정기 모임 운영, 회의 템플릿 정착, 기술 논의·지식 공유 장 마련, 기술 백로그 축적, 코드 리뷰·프로세스 캠페인 진행, Wiki 기반 기록 체계 구축
핵심 성과	스프린트 단위 정기 운영, 개발자가 자발적으로 기술을 공유·논의하는 장(스크럼 문서 DB) 정착, Good Review 캠페인·랜덤 PR 리뷰어·오전 리뷰 문화·에개모 Wiki 등 리뷰·운영 자산 정착
핵심 포인트	개인의 시행착오가 다음 사람의 판단 기준으로 이어지도록 공유 루프를 만든 것

1. 배경

EDU 스쿼드는 큰 비즈니스 일정에 맞춰 빠르게 움직여야 했습니다. 그 과정에서 기술 로드맵을 차분히 세우거나, 각자 겪은 시행착오를 팀 전체의 기준으로 바꾸는 시간은 쉽게 밀렸습니다. 회의록과 논의는 있었지만, 기술 의제와 운영 개선 아이디어가 회차를 넘어 이어지고 실제 행동으로 돌아오는 구조는 약했습니다.

팀이 작을 때는 옆자리 대화와 자연스러운 리뷰만으로도 맥락이 전달됐습니다. 하지만 스쿼드가 급격히 커지고 유닛이 나뉘면서 같은 문제가 쉽게 반복됐습니다. 그 시기에 제가 마주한 문제는 구체적으로 이런 것들이었습니다.

• 기술 로드맵을 챙길 여력이 없는 상태. 당장의 비즈니스 일정에 밀려, 팀이 어디로 가야 하는지에 대한 기술적 그림을 그릴 시간이 없었습니다.
• 공유가 특정 인원에게만 쏠림. 지식과 아이디어를 전파하려 해도 바쁜 일정 탓에, 결국 가까운 몇 사람에게만 전파되곤 했습니다.
• 소통과 피드백 감소. 바쁜 일정 속에서 팀 안의 소통이 줄었고, 업무 코칭도, 먼저 주고받는 피드백도 함께 줄어들었습니다.

기술 부채처럼 보이는 문제 중 상당수는 실제로는 경험과 기준이 충분히 공유되지 않는 운영 구조의 문제였습니다.

에개모는 이 문제들을 풀기 위해 시작한 정기 개발자 모임입니다. 그해 제가 세운 개발자 문화 목표 — "본인의 경험을 쉽게 공유할 수 있는 문화" — 를 실제로 굴러가게 만드는 실행 장치이기도 했습니다. 빠르게 결론을 내는 회의를 늘리려는 게 목적은 아니었습니다. 개발자들이 한 스프린트 동안 겪은 문제, 배운 점, 개선하고 싶은 프로세스를 꺼내놓고, 그중 팀에 남길 만한 것을 캠페인과 기록으로 바꾸는 것이 핵심이었습니다.

2. 핵심 판단

에개모는 결정을 내리는 회의보다 공유와 회고를 반복하는 자리에 가까웠습니다. 매번 같은 목적과 템플릿을 반복해 모임의 색을 유지했고, 논의한 내용은 다음 액션과 Wiki 기록으로 이었습니다. 한 번에 많은 안건을 처리하기보다, 누군가의 경험이 다음 사람이 참고할 기준으로 남는 것을 더 중요하게 봤습니다.

3. 접근

에개모는 결정 회의가 아니라 공유와 회고를 반복하는 자리로 설계했고, 다음 원리로 운영했습니다.

• 고정된 목적과 템플릿으로 모임의 정체성 유지매 회의록 상단에 기술 로드맵, 지식 공유 및 아이디어 공유 문화, 팀원 간 친밀도라는 목적을 반복해서 게시하고, 이전 액션 아이템 결과 공유 → 공유하고 싶어요! → 이야기해보고 싶어요! → 앞으로 해결할 것은? → 다음 모임까지 액션 아이템 흐름을 고정했습니다. 이 구조 덕분에 모임은 단발성 대화로 끝나지 않고, 지난 모임에서 정한 일을 다음 모임에서 확인하고 이어가는 흐름이 됐습니다.
• 결정이 아니라 회의 사이에 굴러가는 캠페인으로에개모에서 남은 것은 회의록보다 회의 사이에 굴러간 캠페인이었습니다. 의제를 한 스프린트 동안 돌려보고 다음 에개모에서 회고하는 방식으로 검증해, 해볼 만한 시도가 팀의 기준으로 자리 잡도록 했습니다.
• 개발자가 스스로 기술을 꺼내놓는 공유의 장 마련모임에서의 논의에 그치지 않고, 개발자들이 평소의 기술 탐구와 시행착오를 직접 기록하는 자리를 만들었습니다. 개발자 스크럼 문서에는 새로 파본 기술 주제, 막혔다가 풀어낸 오답노트, Deep Dive 글이 자발적으로 올라왔고, 서로 댓글로 질문하고 답하며 논의가 이어졌습니다. 회차·노트 타입·카테고리(Browser, AI, Turbo, Monorepo, CDC, Docker, MongoDB 등) 태그를 붙여, 한 사람이 파본 내용이 다음 사람이 검색해 찾는 지식 베이스로 쌓이게 했습니다.
• 운영 방식 자체도 함께 회고하고 조정운영 방식은 고정된 규칙을 일방적으로 적용하지 않고, 모임을 해보며 나온 회고를 바탕으로 계속 조정했습니다. "0에서 바로 논의하면 비효율적"이라는 회고 이후에는 스쿼드 안에서 먼저 논의한 안을 가져오게 했고, 다른 조직과 합의가 필요한 의제는 에개모 안에서 끝내기보다 별도 논의로 넘겼습니다. 시간, 주기, 의제 경계 같은 운영 원칙도 모임을 지속하기 위해 함께 맞춰갔습니다.

4. 결과

• Good Review 라벨로 좋은 코드 리뷰 사례를 누적했고, 칭찬과 학습, 리뷰 방식 전파가 함께 일어나는 캠페인으로 자리 잡았습니다.
• 랜덤 PR 리뷰어 그룹과 오전 리뷰 문화를 도입해, 유닛 안에서만 리뷰가 도는 문제와 바쁜 일정 속 리뷰 누락 문제를 팀 단위로 다뤘습니다.
• 신규 테크스펙 템플릿, PR/Task Card 템플릿, 셀프 체크리스트, dev/beta QA 단계 분리, API 응답 컨벤션, CS 당번 순환, 강좌 복사 Tool 제공 같은 프로세스·컨벤션 논의가 실제 운영 개선으로 이어졌습니다.
• 개발자들이 평소의 기술 탐구와 오답노트를 스크럼 문서 DB에 자발적으로 올리고 서로 댓글로 논의하면서, 한 사람의 시행착오가 검색 가능한 지식 베이스로 쌓였습니다.
• 에개모 Wiki에 회의록, 기술 로드맵, 아이디어, CS 가이드, 온보딩 자료를 모아, 개발자 모임이 조직의 기억을 쌓는 허브가 됐습니다.
• 개발자들이 같은 자리에서 의제를 꺼내고 서로의 작업을 인정하게 되면서, 바쁜 일정 속에 줄어들었던 팀 내 소통과 피드백이 다시 도는 통로가 됐습니다.

5. 회고

에개모는 제가 중요하게 여기는 자율과 공유의 실제 사례입니다. "공유하자"는 선언보다 중요한 것은 공유가 자연스럽게 일어나는 시간, 템플릿, 캠페인, 기록 장소, 다음 액션의 구조를 만드는 일이었습니다. 각자의 시행착오가 그냥 지나가지 않고 다음 사람이 참고할 기준으로 남을 때, 팀은 같은 문제를 반복하지 않고 더 자율적으로 판단할 수 있습니다.

좋은 개발 문화는 누군가 혼자 설계해서 완성되지 않고, 함께 운영하고 회고하며 유지됩니다. 운영 방식 자체도 규칙으로 고정하기보다 회고를 통해 계속 조정해야 오래간다는 것을 에개모를 지속하며 배웠습니다. 그 과정에서 구성원들의 작은 시도와 회고가 사라지지 않도록 반복 가능한 장치를 남기는 일이 핵심이었습니다.