쌩 스타트업 에서의 두 달 차 : 끝 없는 논의 , IR, 애자일과 컬쳐핏

조금은 익숙해진 두 달 차 

 

?

 

확실히 인간은 적응의 동물이다. 조직에 따라 자기의 역량이 나오기까지 몇달 정도 걸린다는 이야기를 어느 개발 관련 유튜브 영상에서 봤는데 그래도 쌩 스타트업에 조직 구성도 적어서 그런가 한달 정도 하니 꽤나 익숙해진 상태로 두 달 차를 들어가지 않았나 싶다.

 

취준할땐 그닥 고민하지않았던 협업에서의 '생산성' 에 대한고민이 이어져 '애자일' 에 대한 고민으로 이어지기도 했다.

 

그런 고민은 함께 자라기 라는 책을 같이 일하는 동료가 추천 해줘서 생각하게 된 것도있다. 

책을 읽지는 않았고 제목만 보고 그냥 이런저런 생각을 했다는게 옳은 것 같다. 

 

사실 동료가 말해주기 전에도 이미 알고있던 책이긴하다.  분위기를 형성해야된다는 그런 내용으로 기억하는데 책 내용은 사실 안 읽어서 잘 모르고  개인적으로 분위기에 기여 할 때 내가 추구하는 태도는 '은근히 알게 그러나 쉽게는 알지 못하게'인데 다 알게 해야되나 싶기도하다. 

 

뭐 아무튼 결론적으로 추려보자면 같이 일하는 사람과 조직 문화라는 것이 어떤 것인지 다시 한번 생각하고 느끼게 됬다.

 

좀 더 풀어서 말해보자면 취준할때는 공고에 적혀있는 컬쳐핏 을 본다는게 뭘 본다는거지? 그냥 소프트스킬을 보는게 아닌가 했는데 확실히 애자일에 대한 고민이나 팀 문화같은것을 형성하는 입장이 되다보니 우리가 이런 분위기를 만드는 것과 별개로  새로 입사하게 되는 분이 이런 생각을 나누고 조직에 맞는 사람인가 하는 컬쳐핏을 확인하는게 중요하겠구나 하는 생각이 들었다. 

 

두 달 밖에 되진 않았다만 확실히 코드치는 시간보다 확실히 비즈니스, 도메인에 대해서 더욱 이해하고 설계하고 논의하는 일이 훨씬 많다는 것을 다시 한번 느꼈다. 

 

 

 

1주차 

 

 

1-1)  데브옵스 관련 미팅 

 

클라우드 서비스 정확히는 인프라 구축에 대한  회사와의 미팅이 있었다. 프론트 엔드 리더 라는 명목으로 껴서 참여하게 되었으며 

 

평소에도AWS 공부는 주말마다 하고있었어서 뭐 끼면 좋고 어짜피 내입장에선 전부 레거시이고 백엔드 개발자님이 데브옵스도 적용해놓은 상태라서 명시적 담당자는 아니였던지라 안부르면  말고 하는 생각으로 별 생각없이 앉아 있다가 각 팀 리더는 대표로 참여해달라는 말에 참여하게 되었는데

 

이런 미팅에선 보통 뭘 물어봐야 하나? 하고 고민하고 생각해보니

 

1. CI CD 구축은 어떻게 해주는 것인지 

2. 롤백 이나  장애 대처가 가능한지 

 

이 두 가지 정도 밖에 없었는데. 백엔드 겸 인프라 구축 까지 해주신 팀원 분께서 이미 다  개략적으로 물어봐서 사실상 앉아서 분위기 탐색 같은 자리 였다. 

 

처음에 전달 받기론 완전히 만들어져있는 인프라 아키텍쳐 에 대한 점검을 해주는 자리인가 했는데 그냥 본인들 사업에 대한 소개 홍보 미팅 자리 같은 분위기였다 오신분도 기술자가 아니라 사업관련 영업사원 이신듯했다. 

 

그러나 나는 이 자리가 굉장히 재미있었다.  아주 오래전 내가  서버 모니터링 관제 및 대처 오퍼레이터로 일했던 것이 데브옵스 쪽 장애관련 처리와 연관되어있었던 것이였어서 그럴 수 도있다. 

 

그러고보니 aws를 배우고 나서는 별 신경을 안쓰지만 예전에 호스팅 업체에서 일했을때에는 트래픽에 동적으로 대처하는게 아니라 일일이 바꿔줬던 기억도 났어서 여러모로 과거를 돌아볼 수 있는 자리이기도 했다.

 

사실  개인적으로는 어떻게 보면 신입이 참여할 자리는 아니지만 참여하게 되어 좋았다.

 

작은회사의 장점은 이런 게 아닐까? 깜냥이 안되도 전부다 참여할 수 있는거 어디까지나  좋게 생각하면 이지만. 

 

 

 

 

1-2)  기초 컨벤션 개선 회의 

 

기존 레거시 같은 방향으로 가지않고 앞으로의 코드에서 좋은 코드 품질 퀄리티를 유지할려면 컨벤션에 대한 회의는 필수적이였다.

 

사실 그동안 산발적으로 조금 씩 컨벤션 관련 업무가 진행되긴 했었는데. 

 

내 의지로 산발적인 업무가 되었다기보다. 팀원의 의견에 귀 기울이다보면 워터풀 혹은 콜백지옥같이 업무가 진행되는 경우 가 많았는데 나는 이게 죽도밥도 안되고 결국 휘발되어 일하는 느 낌만 내는 부류의 업무 방식이라고 생각한 적도 있었기 때문에

 

산발적으로 업무가 마치 브레인 스토밍 하듯이  퍼질려고 하면  그자리에서 컷해버리고 내 노트를 백로그로 활용했다. (당시만 해도 팀 내에 업무 관리에서 백로그 개념이 모호했음)

 

mvp도래 등으로 시간이 충분하지는 않았던 관계로 기초적인 부분만 진행하기로했다.

 

그래서 코드 컨벤션, 린트, 프리티어,  커밋 컨벤션, 깃플로우, 디렉토리,  브랜치, 라이브러리 전략 등을 새로 명시적으로 정했다. 

 

 

 

1-3)  기술 점검 

 

mvp 도래가 얼마 남지 않았다.  그렇게 표면적으로 인지하고 있었다 

 

나온 유저 스토리를 토대로 기술 점검을 하는 시간을 가졌는데 

 

여기서 다시 한 번 또 느꼈다. 프로덕트 관점에서 생각해보는 것이 얼마나 의미 있고 이게 현업이 가지는 다채로운 고민이구나 하는 것들을. 

 

비밀 번호 찾기 하나 생각하는데도 생각만 4시간 걸렸으며 심지어 끝나지도 않았다.

 

아, 참고로 어떻게 만드는지는 듣자마자 쿠키나 url 구성으로 처리하면 되겠거니 하고 답이 나온지는 오래였는데 

 

문제는 그게 아니라 보안이나 도메인 로직에서 오는 여러가지 문제에 있었다.  

 

비밀번호 찾기를 누르면 이메일이 날라가고. 이메일에는 재설정을 할 수 있는 url 이 있다. 그걸 누르면 재설정 페이지로 간다. 

 

나는 만드는 방법은 머릿속에 이미 나온채로 메일이 털리는건 네이버 나 구글 같은곳에서의 문제고 고객의 문제인거지 그런 악의 적인 사용을 굳이 머릿속에 넣어놓지 않았다면 

 

다른 팀원은 만드는 방법은 몰라도 그런 악의 적인 사용이 된다면 이라는 고민을 갖고있는 분이여서 그런 의미에서 계속된 기술논의 가 있었다. 

 

여기서 왜 다른 곳에서는 비밀번호찾기를 할때 몇 분의 제안시간을 주고 핀번호를 입력시키는 방식을 쓰는지.  생각 끝에 도달 할 수 있었다. 

 

 

 

2주차 

 

 

2-1)   데브옵스 2차 외부 미팅 

1주차에 했던 외부 업체랑은 다른 업체와 2차 외부 미팅을 진행했다. 참고로 그 이전주에 내 업무는 아니였지만 AWS 컨퍼런스가 있었고 거기에 참여하면서 우리 한테도 담당 AWS 매니저가 있는 상태였는데 이번 미팅은 매니저님이 추천해주신 업체와의 미팅이였다.

 

첫 번째 미팅은 기술에 대한 점검은 거의 받지 못했다면 이번에는 기술자 분도 같이 참여해서 사용하고 있는 기술에 대한 점검도 받고 장애 세팅 보다는 자체 기술을 내제화 하게끔 본인들이 도와드리면서 진행할 것이라는  말에 기술자로써도 굉장히 매력적으로 느껴졌다.

 

이 미팅에서 데브옵스에도 어떤 비즈니스냐에 따라 전문 영역이 있다는 것을 설명을 듣고 세세하게 이해했다. 

 

몇 가지 옵션이 다르긴 했지만 . 심히 비즈니스 적인 것은  블로그에 적지않는게 맞다고 생각해서 따로 적진 않겠다. 

 

 

2-2)    전체 MVP플로우 

내가 입사하고 첫 달차에도 의견을 물어오셔서 전체 MVP 플로우와 프론트 개발팀의 개발 플로우 에 대한 피드백을 간단히 했었지만. 막상 하나하나 단계를 밟아가면서 진행하게 되니 그제서야 눈에 밝히는 것들도 있었다.

 

2차 mvp 까지는 디자이너가 계셨지만 지금은 디자이너가 없었던 관계로 신경안썼던 디자이너와의 협업에 관한 명시 같은게 없었다. 정확히는 원래는 그냥 디자인 완성되면 온거 토대로 논의 없이 그냥 퍼블리싱 기간 공수만하고 만드는 것이였는데 내 생각에 프론트 개발자가 하는 일중에 가장 중요한 일 중 하나는 

디자이너와 논의해서 시각적인 표현을 확립하고 UX,UI를 고려한 기술을 적용한다. 

 

라고 생각한다. 그래서 원래는 만들어진 디자인을 가지고 SI 처럼 워터풀로 내려오는 의뢰를 받아 처리하듯 진행되는 플로우 에서 디자이너와 UX,UI 논의 항목이 필요할 것 같다고 팀원들에게 말해 추가했으며

 

손 보는 김에 다른 분들에게도 말해야되기도 하고 기획자님도 새로오신 분이셨기 때문에  (기존의 플로우는 어디까지나 백엔드 PM님께서 만드셨다보니) 아마 생산성에 대해서도 새로운 의견이나 기획자 입장에서 손 봐야될 부분이 있지않을까 싶어 아젠다로 올려 다 같이 컨펌하고 수정하는 시간을 가졌다.  

 

아마 디자이너 님이 오시면 또 한번 변경되지않을까 생각한다. 근데 괜찮다 어디까지나 이 플로우는 지금 있는 사람들끼리만 생각할 수 있었던 최선의 그림이니까.

 

이 과정에서 비개발과 개발자의 의견차이도 조금있었다. 아마 기술 검토 부분에서 있었던 논의 였던것 같은데 기억상으로는 이렇다. 

 

"초기 스타트업에서는 어찌되었건 그냥 돌아가게 되던 빨리 결과물이 나오는 게 중요하다" 라는 말에 '결과물이 빨리 나와야 된다는 것'에는 이견은 없지만 기존에 정말 돌아가게끔만 개발하여 확장성이나 재사용성 같은 기초적인 고려를 하지 않아서 결국 기술 마이그레이션을 하여 투 트랙을 걷고 있는 현재 상황만 봐도 알수 있듯  중장기로 봤을때 더 큰 비용과 리스크를 가져갈 수 있다. 는 의견을 나누고 다들 각자의 입장을 조금 더 이해하게 되지 않았나 생각한다. 

 

처음 들어왔을땐 바로 마이그레이션 해야될 수 밖에없었어서 심히 부담되고 스트레스도 되었다만. 역시 세상일 어떤 것이든 좋은면만있지않고 나쁜면만 있는게 아니란걸 다시한번 느꼈다. 아마 마이그레이션이 필요없어서 그냥 넘어갔다면 이상황에 대해서 모든 팀원이 다 인지하고있는 지금이랑 달리 비개발자인 다른 사람들을 설득하기 힘들었을 거란 생각이들었다. 

 

 

 

 

2-3)  함께 성장하기 그리고 애자일  

공명하는 팀에서는 모두가 기쁘게 임무를 수행할 수 있다. 이런 분위기를 조성하는 데는 많은 것이 필요치 않다. 귀담아듣기, 이해 표현하기, 아이디어 공유하기, 간식 권하기, 실수를 모른 척하기, 성공 축하하기, 인기 드라마에 관해 잠깐 수다 떨기, 업무를 다른 사람에게 미루지 않기, 성과가 기대에 못 미치더라도 감사 표현하기. 작은 몸짓과 습관이 공명 관계를 만든다. 컨설턴트 듀오 아시히와 에히터가 말한 것처럼, 기본적으로 “눈높이를 맞추고 친근해져야 한다.”

- 엑셀런스 

 

아비투스라는 책을 보고 재미있기도 하고 감명깊기도하여 저자의 다른 책인 엑셀런스를 읽었었다. 

사실 애자일을 기대하고 본 책은 아니였는데 책 중후반부에 탁월함에 대해서 설명하면서 애자일에 대한 이야기도 종종 나와 인용해봤다

 

나는 진정으로 평등하게 받아들여질 수 있는 편안하지만 격식있는 관계가 정말 중요하다고 생각하고 함께 성장하는데 가장 필수적인 요소라고 생각한다. 

 

그 다음이 개개인의 역량이라고 생각하고.

 

그래서 굳이 뭘 할때마다 의도나 말한 것에 대한 설명을 일일이 덧붙이지는 않지만 주로 하는 노력들은 그런 편안한 분위기를 만드려는 노력에서 기인하기도한다.

 

물론 참 어렵다

 

편안하기만 하면 개판이 되고 격식을 강조하면 경직되어 편안하지않아 아이디어가 쉽게 나오진 않으니까. 

 

3주차 

 

 

논의가 끝난 다음의 모습?

 

   3주차에는 특별히 어떤 뭔가가 있기 보단 주로 있었던 일은 문서화 틀의 전체 변경에 의해 생긴 테스크 추척 에 대한 생산성 관련된 업무 나 해야할 작업들의 논의와 회의의 연속이였다. 

 

소통 : 모호한 팩트 가 아니라 명확한 팩트로 감정 안 상하게 하기 

 

3 주차에는 대부분 기존에 없던 시스템을 위해 내가 주도적으로 진행한 논의가 대부분 이였다. 

그래서 소통과 관련된 인간적인 이야기를 해보고자 한다.

 

소통은 프론트엔드 말고 백엔드든 기획자든 디자이너 든 다 가지고있어야 되는 기본적인 역량이지만, 특히 프론트엔드 개발자는 기획자 , 디자이너, 백엔드 개발자 모두와 소통해야 되기 때문에  소프트 스킬이 관건이기도하다. 

 

오래 다니지는 않았지만 한 달차에도 잠시 명시했듯이  퇴사한 이전 작업자가 실수했거나 핫픽스로 고쳐야 되는것이 생기면 내가 불려나가서 고치게 되었다. 

 

매일 아침 스크럼 회의 때에는 이전 작업의 복기와 오늘 할 일에 대한 공유가 이루어지는데  핫픽스 사항이나 어떤 구현이나 뭐가 안되면 내가 추궁을 받거나 새로운 시스템을 만들어와야된다는 형태였다.

 

 내가 짠 코드가 아니였기 때문에 나로써는 기분이 상하고 다른 이의 실수를 내가 짊어지고 공개처형 당하는 듯 했다.

그나마 이런 상황이 인생에서 처음은 아니였어서 면역이 있어 자기 스스로 무너져내리지는 않았으나

 

여러번 소통하고 회의하고 매일 스크럼을 하다보니 이에 대해서 의견이 조금 충돌하기도 했다.

 

"회사에 일어나는 일은 일적인 이야기이니 비하하지않는 한 팩트만 전달해도 본인의 자존감과 작업물은 분리해서 생각해야된다"
와
"결국 사람끼리 하는 일이기에 전달할 때에는 기분상하지 않는 방식으로 분명하게 말해야 된다"
라는 의견의 충돌이였다.

 

사실 처음 저 의견을 들었을 때에는 팩트랑 감정이랑 구분 못하는사람으로 취급된 기분이였다. 

 

내 경우로 예를 들면 문제는 정확한 팩트가 지금 프론트가 못했다가 아니다.  프론트가 문제다 라는 워딩은 많은 게 생략되어서 지금의 내가 잘못 했다는 식으로 넘겨짚고 떠넘겨지기 딱 좋은 모호한 팩트다.  진짜 원인의 팩트는 이전 작업자가 잘못 작업 해놓고 가서 생긴 문제 라고 말해야 내 입장에서도 팩트다. 

 

여기서 나는 "기분상하지 않는 방식으로 분명히 말해야 된다" 는  후자의 입장이다.  

 

당연히 알겠거니 당연히 회사의 일과 본인의 감정은 분리해서 생각하겠거니  모두가 알아서 성숙하게 받아들이겠거니 하고 앞뒤 다 생략하고 말하기보다. 감정이 상할 만한 상황 자체를 제거하고 전달을 해야 시너지도 나고 존중되고 모두의 생산성이 올라간다고 믿는다.

 

꼭 전달할때 언어에 감정을 담아서 친절한 척 연기 하고 진정한 마음깊은 공감과 이해의 메세지가 담긴 전달을  해야된다는 이야기가 아니고 차갑게 이야기 해도 상관 없다. 

 

듣는이가 감정을 배제할 수 있도록 정말 깔끔하게 팩트만 이야기하자는 의견이다 

 

사람은 그 사람의 상황만 알아주더라도 큰 위로가 되는 법이다. 

 

감정이 상하는 방식의 모호한 팩트로 전달해서 그 사람이 받아들이지 못한다면 일은 몇일이고 지체되고 뒤로 미루어질 것이다. 

 

명확하게 잘못된 부분만 이야기했는데 못 받아들이는건 그 사람의 태도와 성숙함을 논해볼 만 한 일이지만 

 

전달하는 방식에서 결과 팩트만 모호하게 말하여 다 떠넘겨지고 한 사람이 바보가 되고 감정을 전부 다 건드린다면 그것 역시 좋은 방법이 아니라고 생각한다.

 

사실 그런의미에서 온지 얼마 되지도않았는데 나는 벌써 감정적으로 지쳐있었다. 

 

그래서 직접 몇번이나 의견을 전달할때 원인도 같이 말해달라고 의견을 드리기도했다.  직접적인 의견을  말하는  것은 사실 잘 맞춰가기 위한 필수불가결한 작업임을 알기에 먼저 시도하는 일 이기도 했다 

 

소통적인 문제 때문에 회사에 나오기 싫고 우울하고 자존감까지 떨어지는 일이 없었으면 좋겠고, 내가 좀 더 같이 일하기 좋은 개발자가 되었으면 좋겠다고 늘 생각한다.

 

 

 

 

4주차

 

 

 

3차 mvp 시작

 

기간 공수가 끝나고 3차 mvp 가 시작 되었다.

 

디자이너가 없는 상황에서 기획자님도 새로 온 상황이였으나 피그마로 간단한 건 만들 수 있다고 3차 디자인을 기획자님이  만들어주셨는데 이미 있던 컴포넌트를 붙여쓰는 내 입장에선 막상 개발에 들어가니  1,2픽셀단위로  기존 컴포넌트 스펙과 달랐으며 css 속성도 다 건드려야되는 상황에 마주했다. 

 

게다가 기존에 있는 컴포넌트는 알고는 있었지만 다시 써야되는 입장이 되니 최악의 구조였다

 

레거시를 보고있노라니  핸들러는 여기저기 붙어있어서 어디서 동작하는지 가늠할수없었고  결합구조 조차도 알아보기 힘들었으며 else if 는 수없이 많았고 심지어 라이브러리 까지 뒤섞여있었다. 

 

레거시 스펙에는 타입스크립트가 없었는데 나는 타입스크립트에 익숙해있어서 당연히 이것이 스트링으로 초기화를 해놓았으니 그대로 타입이 보장되겠거니 하고 생각하다가 그 변수가 결국 스트링이자 불리언이자 배열 객체 같이 여러 타입으로 한 번에 다쓰는 타입스크립트로 치면  any 나 다름없이 쓰고있음을 보기도 했다. 

 

분명 Input 태그에 대한 Input 컴포넌트인데 새하얀 빈페이지에 Input태그 하나 넣었을 뿐인데 그 페이지에 접속이안되는 경우도 생겼다.  이런 경우는 난생처음이였다.  

 

타입스크립트가 없는데 심지어 자식 컴포넌트에서는 props를 전부 ...props로 받아와서 뭐가 필수 props고 뭐가 내려오는지 어따쓰고 뭘 해야되는지 조차 멘붕의 연속이였다.

 

그 중에서도 가장 힘들었던 부분은  변수명이랑 벨류가 매치가 되지않아 뭐가 뭔지 모르고 매직넘버가 의미하는 바 조차도 추론할수없으니 그냥 a ,b ,c 로 선언된게 차라리 낫다고 생각했다 왜냐면  any 나 다름 없었기에 이 변수 네이밍대로 추론이 결코 뜻대로 되지않았고 결과적으로 그냥 이건 a,b,c라고  선언되었다고 생각하고 하나씩 뜯어서 맞춰보니 그제서야 해결됬다. 

 

덕분에 아마 다음에 같은 상황이 와도 멘붕은 이제 안하겠지 그런 의미에서는 배우는 것이 참 많았다. 

 

다 알 필요는 없이 어느정도만 알아도 쓸 수 있겠거니 했던 기대는 무너지고 input 태그 에 관련된 컴포넌트 하나 뜯어보는데만 몇일이 걸렸다. 그나마 기간을 넓게 잡아놔서 다행이라 생각했다. 

 

 

IR

 

참고로 IR은 투자받기 위해서 우리쪽의 정보를 밝히거나 제공하는 활동인데 이를 통해 투자도 받았다.  누군가는 서비스의 가치를 알아주는구나 해서 기쁘기도했다. 또 나름대로 다시 잘 만들어서 내 기술을 가치로 승화시키겠다는 입사했을 당시의 각오를 다지기도했다. 

 

 

 

끝으로..

 

두 달 차에도 정말 많은 일이 있었다.  여기다가 차마 다 못적을 정도로 

 

한 달차에 말했던 마이그레이션 도 계속 진행되었고 내 개인적으로 애자일 뿐만이 아니라  우테코 프리코스도 다시 참여하기도 하고 주말 마다 해야할 것도 평일에 하는것도 참 많았다. 예전 처럼 블로그에 한달 무지성 고군 분투 일기를 작성하지 못하다보니 공부 내용들은 전부 깃헙쪽에다가 기록해서 다시 일일  1 커밋을 실행중이기도하다. 

 

현업이 아주 고통스럽지만은 않다. 프로덕트에 대해서 이해하고 비교하고 개선시키는 맛도 있으니까. 

사실 깜냥이 안되서 못할 만한 일들을 전부 경험하고 있기도 하니 그런 부분에선 굉장히 감사하고 재미있다고 느끼고 있다. 

 

내가 같이 개발 문화를 만들어가는 입장이기도해서 더 많이 피곤하기도 하고 의견 충돌도 많았지만 그렇다고 소통에서 도망치거나 회피하거나 하진 않았다.

 

맞춰 갈 부분은 맞추고 나는 나대로 계속 내 의견을 견지할 것이다. 

 

특히나  조직문화에 대해서 많이 느끼고 고민했던 한 달 이였다.