심심해서 만든 토이프로젝트가 회사에서 공식 채택됨
퇴근 후에 심심해서 만든 내부용 배포 스크립트가 그만 회사 공식 배포 파이프라인으로 채택됐습니다.
처음엔 그냥 Jenkins 대안으로 가볍게 만들어본 거였는데, 어느 날 팀장님이 "이거 실제로 써봤는데 괜찮네, 다른 팀에도 써도 되냐"는 메일 보내시더라구요. 그러면서 갑자기 코드 리뷰 받고, 보안 점검 받고, 문서화 작업까지... 그냥 사이드 프로젝트가 회사 일이 되어버렸네요.
추가로 느낀 점
- 사내 서비스는 문서화가 80%다. 아무리 코드가 좋아도 main 브랜치 전략 하나 설명 못 하면 적용 불가다.
- 회사 도구와의 호환성을 미리 확인하자. 우리는 LDAP 연동 때 고생함.
- 만들어놓고 가만히 있으면 아무도 안 쓴다. 데모 한 번 보여주는 게 100번 메일 보내는 것보다 효과적이다.
다음 주에 같은 주제로 기술 공유회 하라고 해서 PPT 만들고 있는데, 발표가 더 떨리네요. 혹시 사내에서 토이프로젝트 공식 채택된 케이스 있으면 썰 풀어주세요 ㅋㅋ
7 개의 답변
ㅇㅈ 문서화 80%는 진짜 팩트 ㅋㅋ
발표 화이팅하세요 ㅋㅋ
저도 비슷하게 사내 툴 만들어서 채택된 적 있는데, 진짜 문서화보다도 옆 팀에 데모 한 번 해주는 게 10배 효과 좋더라고요. 근데 한번 정식 채택되면 유지보수까지 다 책임져야 해서... 축하드리면서도 고생 좀 하시게 됐네요 ㅋㅋ
글쎄, 이 정도면 토이프로젝트가 아니라 이미 업무 시간에 만든 거 아니에요? 퇴근 후에만 그 정도 퀄리티가 나올 수 있나
사내 도구 호환성은 진짜 중요하죠. 저희는 SSO 연동 안 되는 거 모르고 만들어서 나중에 다 갈아엎은 적 있는데... LDAP도 그런 케이스겠네요. 그래도 공식 채택이면 회사에서 시간 내서 문서화하고 리뷰할 수 있으니 오히려 좋은 기회예요. 발표는 PT 구조만 잘 짜면 됩니다!
LDAP에서 고생한 거 저도 공감요 ㅋㅋ
Jenkins 대안이라면서 결국 문서화에 보안 점검에... 기존 Jenkins 쓰는 거랑 차이가 있나? 차라리 Jenkins 플러그인으로 만드는 게 낫지 않았을까요. 장기적으로 유지보수 생각하면