개요
사실 회사에서 다양한 시도를 하기란 쉽지 않다.
보통 대부분의 프로젝트는 기술 리딩을 누군가 하게 되어있고, 기술 리더가 기술 스택과 코드의 전반적인 구조를 결정짓게 된다.
프로젝트 구조와 규칙에서 중요한 것은, 낮은 학습 코스트로 문제 없는 코드를 생산하기 쉽게 하는 것. 가능하다면 강제, 정적 코드 분석 등을 통해서 실수를 미연에 방지하는 것이다. (코드 리뷰는 따지고 보면 수동적인 검증 과정이라고 볼 수 있지만, 검증 범위가 더 넓어지고 다양해질 수 있는 장점이 있다)
이렇게 구조가 정립 되고 나면, 보통 리더가 아닌 일반 팀원들은 새로운 시도를 하기 어려워진다.
이미 규칙이 있는데 새 규칙이 도입되게 설득하려면, 기존 규칙보다 배 이상의 장점이 있다는 것을 증명해야만 한다.
또, 양립 가능한 규칙이라해도, 복잡도를 높이는 것 이상의 가치가 있음을 증명해야만 설득이 가능해진다.
그럼 어디서 실패하라구요??
사실 프로젝트가 빌드업 단계일 때, 같이 논의해가며 시도하는 것이 가장 좋기는 하다.
이런 시기가 속도전인 경우도 분명히 있지만, 그렇지 않고 다양한 시도의 코스트를 쓸 수 있는 경우도 적지 않다.
이미 프로젝트가 일정 궤도 이상에 올라 규칙이 마련되어 있다면, 설득 밖에는 답이 없긴하다.
그렇담 어떻게 실패 하는가?
절대 다수의 프로젝트는 레거시 코드를 품게 되어있다. 이런 코드를 개선하기 위한 시도와 노력을 통해 마음껏 실패할 기회를 받는 것이 좋다.
물론 가능한한 실패 확률을 줄이고, 실패로부터 배울 수 있도록 투명하게 진행하고 공유하는 것도 필수라고 할 수 있겠다.
하지만 그런 기회를 보통 대놓고 부여해주는 경우는 흔치 않다.
대부분의 조직에서 최우선 가치는 정해져 있기 마련이고, 데드라인도 정해져 있다.
데드라인 까지의 시간이 얼마나 더 많이 주어지는가 차이랄까?
현실적으로 우리의 실패는, 업무 시간을 쪼개거나, 개인 시간을 할애해서 하는 것이 차선일 것이다.
그렇게 시간을 들여서 한 시도가 100% 받아들여 지지는 않겠지만, 훌륭한 리더라면 대부분 이러한 시도에 대해 감탄하고, 지지해주려 노력한다.
마치며
사실 마음껏 실패하기로 글의 제목은 써있지만, 마음껏 실패하기란 쉽지 않다.
실패하는 것은 결국엔 비용이며, 실패하는 과정을 성장으로 승화시키기란 저항감이 만만치 않다. 결과가 성과로 이어지지 않는 시간은 무의미하다고 보는 분들도 적지는 않다.
그럼에도 우리는 실패로부터 배워야 하고, 결과만이 아닌 과정에서도 배워야 한다.
다양한 시도, 경험을 위해 Dev Toy, Toy Project를 통한 다양한 경험을 해보고 준비를 한다면, 그 시도들을 실무에서 더 나은 가치로 녹여낼 수 있는 기회도 분명히 올 것이다.