필자가 처음 사이드 프로젝트 모집 공고를 올린 게 아마 작년 크리스마스 즈음일 것이다. 그로부터 근 6개월이 지났는데, 현재 프로젝트는 100% 잘 진행되는 건 아닐지라도 나름 안정적으로 진행되고 있다. 이제는 메인 페이지를 비롯하여 코어 페이지도 디자인이 나오고 있고, 프론트엔드도 디자인 구현이 한창이다. 백엔드는 올해 3월부터 백로그 과업 작업을 쉰적이 없으니 알만하지 않겠나 싶다.
오늘은 그런 과정에서 겪은 바를 통해 얻은 깨달음을 일목요연하게 정리하는 시간을 가져 보고자 한다. 예비 혹은 현재 사이드 프로젝트 팀장에게 조금이나마 도움이 됐으면 한다.
팀원 관련
1. 나갈 것 같은데? 싶은 사람은 반드시 나간다.
나가는 사람을 잡는다고 해도 결국은 나간다.
중요한 건 애초부터 안 나가고 싶다는 마음이 들게 하는 것이다.
2. 팀원을 모집하는 기준을 정할 때는, 실력보다 소통 방식이 훨씬 중요하다.
실력은 없어도 같이 성장하면서 키워나가면 될 일이지만, 소통이 잘 안 되면 그 팀은 흔한 말로 “삐걱”거리게 되어 있다.
또한 팀원을 1대 1로 마주할 기회는 처음 모집할 때가 아니면 잘 없다. 첫 대면은 그만큼 중요하다.
3. 큰 문제 없이 주어진 과업을 기한 내에 잘 수행할 수 있다면, 그 팀원은 팀에 꼭 필요한 인재일 것이다.
취미, 견해, 취향, 선호 따위의 개인과 관련한 특징은 모두 부차적일 따름이다.
4. 구성원 수가 적은 만큼, 유별난 팀원 1명이 팀의 분위기를 좋은쪽으로든 나쁜쪽으로든 이끌 수 있다.
장기적으로 갈수록 개별적인 팀원보다도 팀 그 자체가 중요해지는 만큼,
그게 무엇이든 어차피 해야 할 결단이라면 그냥 빠르게 해버리자.
5. 프론트엔드 팀원은 천천히 모집해도 된다.
백엔드와 디자인 과업이 잘 진행되어 있지 않다면, 그들은 팀에 크게 기여할 수 있는 게 없을 것이다.
팀장 관련
6. 팀장이 쉬면 팀은 으레 방향을 잃는다.
반대로, 팀장이 일하면 없던 길도 생길 때가 있다.
중요한 건 팀장이 그 길을 과감히 걸어가 보는 것이다.
7. 팀장은 직무를 막론하고 그게 무엇이든 알면 알수록 좋다.
특히, (예비) 개발자라고 해도 기획을 할 수 있을 정도의 디자인 지식이 없다면 디자이너가 상당히 힘들어 할 것이다.
8. 팀원이 의견을 줄 수는 있겠지만, 팀의 장기적인 비전을 제공하는 건 결국 팀장의 역할이다.
멀리 보고, 과업을 판단하고, 기간을 따지고, 팀원에게 명확히 전달하자.
9. 기획 문서를 길게 작성해봐야 팀원이 읽지 않으면 아무 소용이 없다.
중요한 건 팀원이 팀장이 의도하는 바를 얼마나 정확하게 알고 있느냐 하는 것이다.
이러한 본질에 집중하자.
10. 의견 수용력 내지는 포용력이 높은 것과 휘둘리는 건 다르다.
스스로 부족하다고 여겨서 '많이 아는' 팀원의 말을 빠짐없이 이행할 필요도 없다(정답은 존재하지 않는다).
굳이 팀의 주인을 꼽으라면 당연히 팀장이 그러한 사람일 것이다. 소신을 가지고, 주도적으로 행동하자.
끝으로, 물론 여러 개 하는 것도 도움이 될 수 있겠지만, 사이드 프로젝트를 여러 개 하는 것보다는 하나에 집중하는 것도 꽤 좋은 방법이 될 수 있으리라는 점을 언급하고자 한다. 짧게 여러 번 하면 같은 작업을 더 빨리 할 수 있을 수도 있겠지만, 한 프로젝트를 진행하며 장기적으로 작업물이 쌓인다면 그 결과는 단기적으로는 이뤄낼 수 없는 경지에 오를 수 있을 것이다.
'웹 개발 (Spring Boot)' 카테고리의 다른 글
| 레이어 아키텍처에서 클린 아키텍처 + DDD로 리팩토링하기 (2) (1) | 2025.12.10 |
|---|---|
| 레이어 아키텍처에서 클린 아키텍처 + DDD로 리팩토링하기 (1) (0) | 2025.12.04 |
| 리플렉션(Reflection)으로 Enum 관련 유틸리티 정적 메소드 만들어 보기 (0) | 2024.10.27 |
| @TestPropertySource를 활용해서 테스트 DB 분리하기 (0) | 2024.09.27 |
| 상수를 관리할 때 중요하게 고려할 점 (3) | 2024.09.17 |