스타트업 나쁜 개발 리더 종특
스타트업 창업가가 알고 있어야 할 좋은 개발 리더 나쁜 개발 리더
나는 내 경력의 대부분을 개발자, 기획자, 경영진, 창업가, 창업 멤버로 주로 살아왔고, 이 중 내 심장을 가장 뛰게 하는 순간은 좋은 프로덕트 개발팀과 가치를 만드는 일을 쿵작쿵작 해갈 때가 아닌가 싶다.
아무튼 수많은 사람들을 채용도 해보고, 해고도 해보고 성장도 시켜본 사람으로서 절대 채용하면 안 되는 또는 더 이상 우리와 같이 갈 수 없습니다를 시전 해야만 하는 개발자 혹은 개발 리더에 대해서 써보고자 한다. 뭐 좋은 개발 리더는 그 반대편 극단에!
특히 스타트업 창업가들 중에는 내가 개발을 할 수 없기 때문에 마우스와 키보드로 아무 코드나 끄적일 수 있다면 일단 모셔오자는 마인드인 분들, 이 글을 읽고 다시 한번 생각하는 계기가 되시길.
Copy & paste로 코딩하는 친구들
스택 오버플로우, 인터넷이 없으면 코딩 못하는 분들은 위험하다. 뭔가 개발을 할 때는 설계라는 걸 해야 한다. 설계할 때 인터넷 검색은 필요없다.
믿을만한 시니어가 있다면 설계 후 일을 배분해서 하도록 가이드하는 게 맞겠다.
개발 설계는 서비스 기획이 아니다. 간혹 개발 설계를 하라고 하면 UI 시나리오를 그려오는 사람들이 있는데 참 막막하다.
언어마다 다르지만 쉐도 코드로 스토리 얼개를 구상 작성하고, 그 다음 구글링이나 스택 오버 플로우를 디깅 해야 한다. 알고리즘 시나리오는 선정해야 하고 코더 AI 도 있다지만 플로우에 대한 define은 구글링 스택오버플로우 검색보다 먼저 해야 한다.
나로서는 아래 플로우와 설계가 이상적
- business 문제의 정의. 주로 문제정의와 솔루션. 이때 nice to have 빼기. must have 아이템만 구현하기. 뭘 푸는지는 알아야 할 것 아닌가?
- ui flow & data flow : 우리가 하는 일의 대다수는 input을 받아서 output을 만드는 일. user에서 출발 비즈니스 로직 해결을 위한 플로우 설계
- argorithm design with pseudo code : flow chart 보다 oop 개념이 나오면서 오브젝트 정의 그리고 그 과정 알고리즘 구상. 어떤 데이터 타입에 뭘 저장하고 어떻게 처리할 것인가? 알고리즘은 어떻게 구현할 것인가?
이걸 꼭 근사한 툴이 아니라 난 아직도 손으로 그리는 게, 화이트보드에 쓰는 게 제일 편하다. 손으로 그리고 찍고, 의사소통하자!
코딩은 설계하고, 시작하는 거다. 짜다가 문법이나 기대한 결과가 안 나올 때 찾아봐야 하는 게 스택오버플오우고 구글이고, 검색 결과는 참조일 뿐, 검색으로 copy & paste 가 주인 개발자는 조심해야 한다.
Legacy 탓하기형
1년 이상 리더를 해왔으면서 워낙 후진 리거시 때문에 아무것도 못했다는 수동적인 리더들을 보면 난 일단 스타트업에서는 해고해야 한다고 조언한다.
또, 리거시는 후졌기 때문에 다 전면 새로 개발해야 한다는 리더들도 있는데 이 경우는 그 사람이 그 변화를 리드할 수 있는지 주의 깊게 살펴본다. 대부분은 전면 재개발 능력이 없거나 어설픈 시도로 운영 중인 서비스에 피해를 입히는 경우가 대부분이기 때문이다.
아주 신생 스타트업이 아니라면 리거시는 늘 존재하기 마련이다. 기존에 제작했던 코드로 현재 구동 중인 서비스 또는 플랫폼을 리거시라고 하는데 리거시를 개편하는 건 정말 새로운 서비스를 만들지 않는 한 더 어려운 일임에는 틀림이 없다. 리거시를 들어내고 전면 재개발을 해야겠다는 리더가 있다면 그 사람이 그런 역량이 있는지 다시 한번 체크해보자. 아니라면 역량 있는 전문가 도움을 받는 게 맞겠다.
우선 내가 하는 테크닉은 아래가 테크트리다.
- backend와 frontend를 분리한다.
authorized request, RESTFul api로, 채용 여력이나 팀 capacity에 따라서 유지보수 개편 속도를 확실히 개선할 수 있다. 프론트엔드와 백엔드 개발이 병렬 진행이 가능해지기 때문이다.
요즈음 프론트엔드 스택이 상당히 빠르게 진화하고 있고 복잡도도 높기 때문에 클라이언트부와 서버 연산을 분리하는 게 첫 번째 단계이다.
- Legacy는 유지 가능해야 한다.
문제 발생 시 근본 해결을 상황에 맞춰서 진행한다. 버그 픽스나 리팩토링을 하다 보면 뜯어내서 마이크로 서비스 단위로 분리할게 나오게 마련이다. 예를 들어 배치 처리라거나 async api call 단위, 통계, 검색 등. 그런 아이템들이 나올 때마다 새 틀로 덜어내면 된다.
- 시스템 아키텍처, 데이터 모델링은 전문가의 도움을 받자.
코드는 어떤 언어건 어떤 서비스건 어떻게든 고치면 되겠는데, 서비스 구조와 데이터 모델링이 엉망인 서비스들은 참 난감하다. 마이그레이션이 돼야 하기 때문이다.
특히 데이터는 RDB를 쓰면서 오브젝트 DB처럼 무분별한 반정규화를 남발해 두었거나, index를 남발해두었거나, 데이터 구조 자체를 잘 못 설계해 둔 경우가 참 난감하다. read, write i/o에 대해서 생각하고 모델링을 하지 않으면 데이터는 급속도로 쌓일 수 있고, 위험해질 수 있다.
데이터가 아직 적을 때, 전문가를 섭외해서 고쳐두는 게 낫다. 나중에 하려면 비용과 시간, 리스크가 몇 배 수로 늘어나기 때문이다.
- 백엔드, 프론트 엔드 새 부대 마련
위 단계가 끝났다면 좀 더 유지보수 가능하고 핸들링이 유연한 틀로 하나씩 퍼오기를 한다. 테스트 코드와 로깅은 필수. 새 술을 담을 부대를 깨끗하게 꼭 써야 하는 디펜던시로 만들어온다.
- 옮기기
서비스 중이라면 약간의 게이트웨이 마련 공수가 들더라도 병행시킬 수 있다. 프론트엔드는 아직 솔루션을 못 찾았지만 예를 들면 프론트엔드는 1도 안 바꾸고 기존 프로토콜 그대로 새 부대에 담은 백엔드 엔드포인트를 만든다. 게이트웨이를 중간에 둬서 Reverse Proxy 형태로 구성한다.
- 100% 옮기고 나서 기존 모델을 중단한다.
내부 경쟁 유발자형
성향 자체가 남에게 군림하고 bossy 한 사람들이 있기 마련이다. 나는 스타트업에서 일하려면 아닌 건 아니라고 직설적으로 말하기는 해야 하지만, 다른 사람 의견이 더 좋을 때는 쿨하게 수용할 수 있는 사람이어야 한다고 생각한다.
- 일 독점욕 : 일을 분담 없이 혼자서만 하려고 하거나, 내부에서 다른 멤버보다 더 두각을 나타내려고 하는 친구들은 동료들이 당연히 싫어할 것이고, 팀워크를 위해 옳지 않다.
간혹 시니어 중에 주니어가 제안한 걸 무조건 안 받아들이거나 주니어가 처리한 걸 자기가 한 것처럼 포장하는 경우들도 있는데 그 팀은 열정적으로 팀원들이 일해 줄리가 없다.
- 책임회피형 : 솔직히 말해서 실수는 내 책임이다. 재발 방지하려면 이렇게 하겠다. 잘한 건, ***님이 만드셨잖아요. ***님이 제일 잘 아시고 잘하시죠! 이런 사람이 멋지지 않은가? 주니어들이 따르기 마련이다.
간혹 리더가 실수가 터지면 남 탓하고 결과가 안 좋을 때 동료 탓하는 모습을 보게 될 경우가 있다. 나도 그런 사람과 일하기 싫은데 어떤 멋진 사람들이 그런 리더와 일하려 하겠는가?
- 나만 알아야 해 형 : 주니어들 중에서도 개인 톡으로만 상급자에게 질문을 하고, 알아낸 정보를 절대 공유하지 않고 내 코드는 공개하지 않는 친구들이 있다. 일을 잘 못 배운 친구들이 주로 그런데, 경쟁자는 외부에 있다는 점을 명확히 하고, 그래도 그러면 역시 바이 바이 하는 게 낫다. 빠르게 변화하는 환경에서 지식과 노하우의 공유는 개발 조직의 핵심 경쟁력일 수 있기 때문이다.
입코딩, 말코딩
개발 작업이란 코딩. - 빌드(테스트) - 배포 과정을 거쳐 실제 사용이 가능하게 만드는 과정이라는 생각이다.
간혹 유행하는 워딩이나 키워드, jargon 으로 입코딩하는 친구들이 있다.
자기가 스터디한 자료를 정리하고 싶고 나누고 싶은 선한 블로거 유튜버들도 있지만 단편적인 지식들을 짜깁기해서 컨텐츠는 잘 작성하고 올리는데 실제 일해보면 실행력이 떨어지는 유형이다.
특히 SNS에서 유명하거나 파워블로거인 경우 주의해 볼 필요가 있다. 폄하하려는 게 아니라 남 가르치기를 잘하는 유형, 지식을 잘 전달하는 유형이 꼭 실제 업무를 잘하리라는 보장은 없기 때문이다.
이런 유형은 작은 팀이건 큰 팀이건 들어와서 회의 때 목소리는 크고 각종 업무에 오지랖을 펼치며 간섭 의견 개진은 잘 하지만 정작 자기 업무는 기한 내 마치지 못하거나 동료들이 같이 일하라고 하면 동료들이 기피하는 유형이다.
내가 익숙한 건 죽어도 못 보내 형
한번 자기가 익숙해진 프레임워크나 방식을 절대 바꾸기 싫어하는 유형의 리더이다. 자고 일어나면 새로운 개발툴, 플러그인, 유력 모델 논문이나 아티클들이 쏟아지는데 자기가 오래 해본 방식만을 고집하는 형태이다.
간단히 말해 변화를 싫어하면 도태하기 쉬우니까. 하지만 이럴 때 현실감각은 매우 중요하다.
얼마 전 실제 있었던 사례인데, 배치 처리해야 할 일들을 크론 잡을 걸어서 서비스단 백엔드에서 타임아웃, 로깅없이 처리하는 문제 리거시가 있었다.
Java 개발자라면 개선안을 스크래치 리서치해오라고 하면 코드 분석, 스프링 배치 구조 차용, 스프링단에서 스케쥴링 또는 Quartz 등 스케쥴링 방식 구현 등을 고려해 올 수 있다. 그런데 내가 의논해보고 내린 결정은 스프링 배치를 활용해서 효과적으로 테스트 수행부를 설계하고 재개발, 스케쥴링 및 트리거링은 aws를 쓰니까 cloudwatch event로 하자고 결론을 내렸다. 이유는 해당 작업에 투입할 수 있는 시간이 얼마 없었고(당장 추가해야 할 배치 잡 대기 중). Quartz 등 도입을 리서치만 했지 도입해서 셋팅하려면 시행착오가 있을 수 있고 팀 내 시니어가 부족해서 가져다가 계속 유지 보수하기가 까다로워 보였다. 클라우드의 심플 이벤트는 99.99 이상 안정성은 나오니 이편이 적합해서다.
반면 다른 회사는 기술 자문하는 회사가 있었는데 동일 환경에서는 예전 같이 일했던 경험 많은 동료가 상당히 훌륭하게 안정감 있게 Quartz를 사용해서 코드를 완료한 경우다. 그. 팀에는 그 방식 도입을 적극 찬성했다. 유지보수가 된다면 그 편이 메리트가 있어서다. 현실감각은 있어야겠으나 새로운 방식은 늘 검토하고 메리트를 따져서 결정해야 한다.
공부하기도 싫고 안 하는 유형.
20년 이상 한 업종에서 일해 온 남편과 공감했던 얘기가 있다. 공부 안 하고 어떻게 이렇게 빠르게 변하는 환경에서 좋은 소프트웨어 프로그래밍을 하냐고.
나는 열심히 책도 보고 좋은 오픈소스가 있다면 해당 리파지토리를 모두 둘러보는 편이다. (안 그러면 따라가기 어려워서다). 새로운 클라우드 플랫폼 제품이나 프레임워크가 나오면 관련 문서를 숙독하는 건 기본이다.
다른 직능은 모르겠는데 개발 쪽은 확실히 리더가 너무 모르면 그 팀이, 그 팀이 만드는 소프트웨어를 탑재한 하드웨어가, 그 팀이 만드는 소프트웨어를 이용하는 이용자들이 고생한다.
내 철밥그릇 사수형
간혹 비개발자 출신 리더가 창업한 기업에 약간의 경력으로 조인한 기술 리더 중에 자신만 할 수 있는 일들을 끌어안고, 회사야 망하거나 말거나 내 존재감과 철밥 그룻 사수에 좀 더 열중하는 리더들이 있었다.
모 코워킹 스페이스에서 들은 얘기다.
"아 우리 대표가 어디서 듣고 와서 cs 운영툴을 없애고 젠데스크 등 몇 개 서비스를 검토해서 넣자는데 난 반대야. 그거 간단히 위젯 버튼 스크립트로만 넣으면 된다는데, 그럼 우리가 할 일이 없어지는 거 아냐? 좀 익숙해질 만 한데 다른 일 하기도 싫고"
"vuejs를 리액트로 갈아탄다는데, 그거 좀 어렵지 않아? 나 리액트 안 써봐서.. 머리 아파 꼭 써야 해?"
"사진 분류 모델에 트랜스포머 모델이 더 정확도가 높다는데.. 꼭 그걸 해야 해? 대충 기존 모델 튜닝해서 보여주고 말면 될 것 같아서 일단 테스트도 안 해보려고"
공무원만 철밥그릇이 있는 게 아니다. 개발 스택으로, 리거시로, 내가 익숙한 환경으로 나만 할 수 있어를 시전 하는 개발자들을 주의해야 한다. 새로운 플랫폼이나 스택은 실험하고 도입 시기나 전환시기를 고려할 수 있는 리더가 좋은 개발 리더다.
개발이 아니더라도, 경영 101 에서 배우지 않는가? 훌륭한 리더는 내가 없더라도 시스템이 조직이 움직이도록 하는 리더라고.
맺으며
이런 종특 성향 리더를 만났다면 좋은 이별을 준비하는 게 맞는 일 같다.
개발 리더가 필요하다면 우선 후보자들을 찾아야겠지만 찾았다면 선택 시 이런 성향이 아닌지 살펴봐야 한다.
창업가들이 걸어야 할 길은 많은 고난과 장애물들이 펼쳐지기 마련인데, 이 길을 같이 걸어갈 개발 리더들은 이런 성향이 아니어야(반대 성향일수록 유리) 하지 않을까?
