KILLPO를 회고하며

포텐업에서 좋은 동료들과 함께 첫 프로젝트 KILLPO를 하게 되어 많이 배우고 성장했습니다. 오랜만에 감정과 열정을 제대로 쏟아 행복했어요. (서정님, 성훈님 감사합니다)

여러 직무에서 각자의 경험을 가진 동료들과 협업하며 실무적인 태도와 소프트 스킬의 중요성을 몸으로 익혔습니다.

다시 한 번, 개발은 혼자 하는 일이 아니라 함께 만드는 일임을 선명하게 느꼈고, 끝까지 책임을 지고 마무리해 더 뿌듯했습니다.

운이 좋게도 저는 늘 좋은 동료들과 함께했습니다. 그 덕분에 “어떻게 하면 협업을 잘할 수 있는지”에 대한 배움과 경험을 이번 킴조이 팀에서도 적용할 수 있었습니다.

---

챌린지 포인트

"꼭 해야만 하는 가장 중요한 일을 파악하고, 그 일에 시간을 확보하라." 라는 원칙은 의식하고 있는 것과 아닌 것의 차이가 큰 듯 합니다.

프레임워크/라이브러리 의존성 탈피하기

여러 프로젝트를 해왔지만, HTML·CSS·Vanilla JS만으로 웹서비스를 구현한 건 처음이었습니다.

학습해 온 브라우저 렌더링 과정을 실제로 부딪히며 이해했고, 왜 최적화가 중요한지 체감했습니다.

• 왜 </body> 직전에 <script>를 두는지(파서 차단·로드 순서)
• 이벤트 핸들러를 어디에 붙이고 언제/왜 해제해야 하는지
• 캡처링/버블링 흐름과 이벤트 위임 전략
• DOMContentLoaded 이후 DOM 조작의 안정성
• 비동기 처리와 모듈화(의존성 최소화)
• 리플로우/리페인트 최소화를 위한 구조 설계
• 반복 UI의 컴포넌트화와 디자인 패턴

“정적 페이지를 더 빠르게 렌더링하려면 무엇을 줄일까?”를 기준으로 비동기 로드·모듈화·이벤트 위임을 신중히 적용했습니다.

머릿속에 떠 있던 지식들이 하나하나 맞물리며, 설계한 대로 동작하는 짜릿함을 느꼈습니다.

좋은 동료가 되는 법, 실천으로 증명하기

항상 저는 "함께하고 싶은 동료"가 되고 싶었습니다. 제가 생각하는 기준은 세 가지였습니다.

• 커뮤니케이션 부담이 적은 동료 (상태/이슈를 투명하게 공유)
• 믿고 의지할 수 있는 동료 (말한 일정을 지키는 실행력)
• 정보를 잘 공유하는 동료 (내가 겪은 문제를 팀의 지식으로)

위의 기준들을 지키고, 팀에 “할 수 있다”는 기운을 퍼뜨리려 노력했습니다.

"제한된 시간" 안에서 "최대의 임팩트" 만들기

이번 프로젝트는 7일이라는 짧은 기간 내에서 진행되었습니다.

개발자는 문제를 해결하는 일을 하기에, 코드 외에도 해야 할 일이 참 많습니다. (모든 직무가 이 부분은 다 마찬가지인 듯합니다..)

그래서 커뮤니케이션 비용을 낮추고 개발 시간을 지키는 구조가 중요합니다.

커뮤니케이션 비용은 issue/PR 템플릿·커밋 컨벤션·회의록·데일리 스크럼으로 낮추고, 자투리 시간은 문서화·정리에 집중해 개발 시간 자체를 확보했습니다. (AI 덕분에 리서치/문서화 시간이 줄었지만, 절대적인 개발 시간은 최대한 내가 확보해야 한다는 것도 다시 느꼈습니다.)

또한 제가 설명하는 것도 시간이지만, 그걸 듣는 것도 동료의 시간입니다.
그렇기에 설명은 짧고 명확하게 하려고 했습니다. 어려운 내용을 쉽게 설명하는 역량을 의식적으로 훈련했습니다.

'pre'의 습관화

결국 협업을 잘하기 위해서는 'pre'라는 단어가 중요한 것 같습니다.

초반에 피어 프로그래밍으로 폴더 구조를 함께 잡고, 데이터 구조를 미리 설계해 소통 비용을 줄였습니다.

필요할 때 한 발 앞서 가이드·결정·정리를 했고, 경험을 팀에 적극 공유했습니다. 항상 동료들의 상황을 미리 체킹하며 팔로우할 수 있도록 하였습니다.

데일리 스크럼을 통해 매일 진행/이슈/도움 필요한 점을 빠르게 공유하고, 필요한 결정은 그 자리에서 내렸습니다.

UX 디테일 챙기기

아무리 시간이 부족하더라도, UX적인 디테일을 놓치지 않았습니다. (DX를 개선해야 하는 이유라고도 생각합니다.)

QA 당일과 데모 전까지 개선할 점을 동료들과 리스트화한 뒤 바로 적용했습니다.

UX가 서비스의 완성도와 직결이 된다고 생각합니다.

---

프로젝트 매니징과 개발을 리드해보니

리더십과 팔로워십은 한 끗 차이입니다.

주어진 상황에 맞는 정확하고 빠른 의사결정

정답은 없고 프로젝트 핏이 있을 뿐. 중요한 건 결정을 미루지 않는 것이었습니다.

제한된 시간과 한정된 스택 안에서 제거할 건 과감히 제거하고, 수용할 건 즉시 수용했습니다.

Pre-mortem

시작 단계에서 실패 시나리오를 먼저 적어 두고 리스크를 선제적으로 제거했습니다.

배포 구조와 상대경로, 아이콘·이미지 로드, 환경변수 주입 타이밍 같은 이슈를 초기에 제거해 각자 작업 시 생길 충돌 가능성을 낮췄습니다.

각자 작업하면서 충돌할 만한 데이터 구조도 미리 설계해 소통 비용을 줄였고, 개발 시간을 확보할 수 있었습니다.

디자인·HTML 골격과 컴포넌트 스켈레톤을 먼저 확정해 기준점을 만들고, mock 데이터를 합의해 병렬 개발과 로컬 독립 테스트가 가능하도록 했습니다.

팀 내 사이클 만들기

팀 루틴은 ‘코드 리뷰 → 본인 개발(기한 준수) → 남는 시간 문서화’,
기능 우선순위는 ‘MVP 기한 준수 → UX 개선 → 리팩토링’으로 통일했습니다.

각자의 역할과 권한

각자 맡은 일에 의사결정권을 부여하되 책임은 명확히 했습니다.

개인 리스트업 → 팀 컨펌 → 실행 사이클로 합의 시간과 커뮤니케이션을 줄였습니다.

지속할 수 있는 계획과 개발 사이클 수립

최소 규모라도 확실히 실행하는 계획을 세웠습니다. QA 라운드는 2회로 잡고, 개발 여유 시간을 확보했습니다.

기능 개발–코드 리뷰–문서화의 리듬을 고정해 팀 페이스를 일정하게 유지했습니다.

---

다음 프로젝트에서는 어떻게 나아가야 할까

AI를 더 잘 쓰고, 일상과 개발 시간을 따로 보지 않기

AI를 잘 활용하기

이제는 AI 없이 살아갈 수 없는 시대입니다.
이번 프로젝트도 그랬지만, 개발 외 문서화/정리 같은 영역에서도 불필요한 시간을 줄이기 위해 더욱 적극 활용하려 합니다.

장기적인 프로젝트를 대처하고 설계

이번 프로젝트는 기간이 7일이었지만, 실제 서비스는 훨씬 길게 이어집니다.
장기적인 프로젝트의 일정을 더 잘 다뤄보는 능력을 기르고 싶습니다.

일정한 컨디션 관리

시간 관리를 포함하여, 컨디션 관리를 잘해야겠다고 느꼈습니다. (압박감으로 밥을 많이 걸렀더니 머리가 많이 어지러워서 힘들었네요..)
프로젝트 끝나고 다시 일상으로 돌아오는 것도 필수적인 능력이라고 생각합니다.

말로 설득하는 힘 키우기

문서화를 넘어, 이걸 저만의 언어로 소리로 표출하는 것 또한 잘하고 싶습니다.
(남에게 설득력 있게 생각을 표현하는 법은 또 다른 영역의 일 같습니다.)

또한, 덜어내서 표현하는 법도 중요하다고 생각이 듭니다.

단축키로 모든 일을 다 끝내버릴 수 있도록

macOS 단축키, VS Code 단축키, Emmet 문법을 더 익혀 불필요한 시간 소모도 아껴야겠습니다.

---

마치며

제 주변의 동료들이 저에게 좋은 평가를 내려 주셔서 부끄럽기도 했지만, “함께하고 싶은 동료에 더 가까워지고 있구나”를 느끼게 된 경험이었습니다.

나아가 동료들에게 좋은 인사이트를 주기 위해 더욱 노력해야겠다고 생각했습니다.

좋은 동료들과 함께해서 가능했던 프로젝트였고, 여기서 멈추지 않고 남은 UX 개선과 React → Next.js 마이그레이션도 차근차근 진행해 보겠습니다.

읽어주셔서 감사합니다.