본문 바로가기
Programming/Seminar

2020년 서비스 개발 1년의 회고

by peter paak 2020. 11. 17.
728x90

이 글은 창천항로님의 2016/09/10 Code States J2S 컨퍼런스 참석 후기를 보면서 요즘 드는 생각을 정리하는 글입니다.

1. 쿠팡, A/B 테스트 그리고 개발자 - 양병석

우리 회사에는 기획자가 없다. 애초에 기획자가 의도한 방향이 뭔지 모르는 상황이다. 그러므로 개발자로서 나중에 어떻게 발전할지에 대한 인사이트가 거의 없는 상태에서 개발을 해왔다. 그러다 보니 조직자체가 변화에 유연한 구조에 대한 고민을 하기보다는 순간순간의 피쳐를 개인의 판단에 의해 만드는 구조가 되어갔다. 그래서 나중에 어떻게 발전될 것인지에 대해 고민을 하지 못한 것 같다.

하지만 NextStep에서 TDD, 리펙토링 과정을 들은 이후로 변화에 유연한 구조에 대해 많은 고민을 하게 되었다. TDD로 테스트를 작성하여 빠르게 실패하고 코드를 작성하여 지속적인 리펙토링이 가능하게 하는 코드, 코드 리뷰를 하면서 변화가 예상되는 지점에 대해 고민을 하고, 현재의 코드를 그에 맞게 리펙토링하는 일련의 과정에 대한 관심이 커지게 되었다.

하지만 조직의 구조는 나의 생각과 달랐다. 애자일 방식을 채택하여 한주에 하나의 스프린트를 하고 금요일에 회고를 하는 방식을 지향했다. 한주 동안 어떻게 마무리 했고 앞으로 어떻게 할 것인지에 대해 리뷰하는 시간을 가졌다. 이렇게 들으면 기초적인 애자일 방식이라고 생각하겠지만 문제는 기획자가 없다는데 있다. 즉, 앞으로의 목표를 설정하거 목표를 구체적으로 정리하지 않는 것이었다.

목표가 없는 조직에서는 다음과 같은 문제가 나타난다.

  1. 기획회의에서 피쳐 개발을 논의
  2. 구체적인 기획 명세없이 새로운 피쳐 시작
  3. 개발자의 판단으로 개발
  4. 서비스의 완성도 떨어짐
  5. 개발 왜 이렇게 했어요 + 요구사항 변경
  6. 레거시 변경 또는 삭제
  7. 밤샘 후 어느정도 완성
  8. 어느정도 만족하고 다시 1번으로
  9. 기능은 존재하지만 전체적인 통일성이 떨어져 사용자 경험이 매우 떨어짐
  10. 사용자 감소
  11. 조직의 의욕저하

기획자가 의도한 방향이 나중에 어떻게 발전될지를 개발자도 인지하고 있어야 한다

개발 문화가 잘 잡힌 조직에서는 고민할 필요가 적은 부분이지만, 그렇지 않은 조직에서는 서비스가 가야될 목표를 개발자가 판단하기 힘들다. 그러다 보면 "일단 개발해"가 되어버린다. 목표없는 요구사항만 계속 변경되고 개발하는 시간보다 예전에 작성했던 피처를 지우는데 더 많은 시간을 보내게 된다. 자연스럽게 개발자의 의욕도 떨어질 수 밖에 없는 것 같다.

결국 어떤 큰 그림을 그리게 될지, 그리는 것을 원하는지에 대해 끊임없이 생각해봐야한다

문제는 개발 문화를 바꾸면 해결될 수 있는 문제인데 그렇지 않다는 것이다. 회사의 자원과 인력이 부족하다보니 TDD와 코드리뷰 등의 앞으로의 서비스 방향을 고민하는 비용이 더 크다는 결론을 내린다는 것이다. (개인적으로는 나중에 유지보수하는 비용이 훨씬 커질 것이라는 점이다. 혹은 서비스가 없어져도 큰 손해를 줄이겠다는 뜻이거나...) 물론 회사의 입장을 이해하지 못하는 것은 아니다. 그냥 설득이 안되는 것이 답답하고 아쉽다는 뜻이다. 나의 모자란 실력을 탓할 수밖에... 그렇다 보면 남들 다하는 코드리뷰는 나만 안하네 라는 한탄과 그로인해 늘어가는 남들의 실력을 부러워 할 수 밖에 없었다.

2. 성장하는 개발자 - 강대명

성장이란 무엇인가?

  1. 개발실력
  2. 커뮤니케이션

함께 일하고 싶은 사람인가?

요즘 나는 함께 일하고 싶은 사람인가? 라는 생각을 많이한다.

우리 회사는 말을 거의 하지 않는다. 점심시간을 빼놓고는 말을 거의 하지 않는다. 그렇다 보니 이 사람들은 내가 함께 일하고 싶은 사람일까? 이 사람들은 나를 함께 일하고 싶은 사람일까? 라는 판단이 잘 서지 않게 된다. 그렇다면 함께 일하고 싶은 사람이 되려면 적어도 함께 일하기 싫은 사람이 아니면 가능하다는 가정을 세울 수 있다. 기본적으로 다 좋은 분들이지만 함께 일한다라는 전제에서 구성원을 살펴보면 다음과 같다

  1. 자신의 생각이 대부분 옳다고 생각하는 사람
  2. 회의의 주제를 벗어나 추상적인 이야기를 하는 사람
  3. 서비스의 오너십이 없는 사람

물론 내가 저분들을 평가할 만큼 일하기 좋은 사람이어서 평가를 하는 것은 아니다. 단지 개인적으로 느껴지는 것이 저 3가지이고, 나 스스로도 아직 다른 사람에게 정량적인 평가를 받지 못했기 때문에 스스로가 저런 경우를 일단 피하면 일하기 싫은 개발자에서 멀어진다는 전제에서 작성한 것이다. (개인적으로는 정량적인 평가를 받고 싶다. 샌프란시스코에서 일했을 때도 퇴직자가 동료들을 평가하는 제도가 있었는데 개인적으로는 가장 솔직하고 피드백이 좋았던 것 같다)

1번의 경우는 함께 토론하기가 힘든 케이스 인것 같다. 내가 설득하려고 해도 애초부터 자신만의 정답이 정해져있고 다른 사람의 논리가 합리적인가? 를 생각하지 않는 것 같다. 일단 나의 의견이 틀릴 수도 있다는 전제를 항상 가져야 한다는 것을 느끼게 해준다

2번의 경우는 구체적인 목표설정을 힘들게 하는 케이스였다. 항상 회의의 목표와 벗어나 또 다른 회의를 부른다. 추상적인 단어로 이야기하기에 말은 길어지지만 내용의 주제는 없고 결국 다른 이야기로 귀결된다. 주제를 먼저 이야기하고 구체적인 단어와 예시로 이야기 해야한다는 생각을 들게 해준다

3번의 경우가 개인적으로 나에게 해당되지 않을까 라는 고민을 하게 한다. 다음 단락에서 설명해보고자 한다

내가 움직여야 다른 사람도 움직일 수 있다

앞서 말한 것처럼 조직에 커뮤니케이션이 부재한다. 그래서 입사 초기부터 혼자 일한다는 생각이 많이 들었고 이런 생각이 점점 부정적으로 변했던 것 같다. 우리 조직은 왜 코드리뷰를 하지 않지? 왜 TDD를 안하는거지? 기획자는 왜 없는 것인가? 라는 하소연아닌 하소연을 하게 되고 개인적으로 실력도 부족했기에 개인적인 개발에 더 힘쓰게 되었던 것 같다.

앞서 성장이란 무엇인가에서 개발실력과 커뮤니케이션이라는 두가지 키워드가 나왔다.

나는 여기서 커뮤니케이션의 전제는 개발실력이라는 것을 요즘 많이 느낀다. 개발실력이 부족하면 아무래도 의견을 내기에 자신감이 없을 수 밖에 없다. 내가 모르는 영역이 많이 때문이다. 개발실력을 늘려오면서 내 스스로가 할 수 있는 일이 많다는 것을 느낀다. 예전에는 팀이 테스트 코드를 안만들어도 내가 만들 수 있게 되었다. 예전에는 도메인 지식이 없어서 기획에 참여 못했지만 지금은 작은 소규모 테스크를 꾸려서 기획을 주도할 수 있게 되었다. 코드 리뷰를 안하지만 어제의 내가 작성한 코드를 스스로 리뷰할 수 있고, 다른 사람의 코드를 내가 할 수 있게 되었다.

물론 1년이라는 시간동안 엄청나게 발전한 것은 아니다. 말하고 싶은 부분은 적어도 조직에 발전적인 방향을 제시할 정도의 실력과 시야를 가질 정도로 실력을 키웠다는 것이다. 실력을 키우면 커뮤니케이션에서 자신을 가질 수 있고 서비스의 오너십을 가질 수 있다는 말이 된다. 물론 이러한 조직문화가 되어있다면 이런 고민할 필요가 크게 줄어 들 것이다.

내가 움직여야 다른 사람도 움직일 수 있다2

여자친구와 같이 지낸지 3년이 넘어간다.

같이 지내면서 느낀점은 내가 상대방을 변화시킬 수는 없다는 것이다. 나의 입맛에 맞추기 위해 상대방에게 요구하는 것은 잔소리밖에 되지 않는다. 가장 좋은 방법은 내가 먼저 변화하는 것을 보여주는 것이다. 상대방이 나와 맞는 사람이라면 나의 변화를 보고 변화하기 마련이다.

회사에서도 마찬가지라는 생각이 요즘 많이 든다.

기획에 조금 더 많은 시간을 투자하면서 요구사항이 많이 정리되고, 팀원들도 적극적으로 의견을 내고 듣는 것을 느끼고 있다. 특히 회의에는 내가 한 기획을 주제에 벗어나지 않도록 이끌어가는 역할을 하면서, 많은 사람들이 서비스의 큰 그림을 이해하고 발전시키는 것이 전체 조직에서 얼마나 중요한 일인지 깨닫게 되었다. 만약 내가 개발 공부를 안하고 실력이 없다고 느껴졌다면 결국 이러한 변화도 알지 못했을 것이다.

결국, 내가 움직여야 다른 사람도 움직일 수 있다

3. 외국계 회사에서 엔지니어로 성장하기

위의 내용과 관련은 없지만 영어에 대한 괴리가 많이 든다
개인적으로는 개발자가 영어를 잘하는 것은 별로 장점이 없다고 생각한다

나는 샌프란시스코에서 1년동안 인턴십을 하고 그때 처음 프로그래밍을 공부했다. 프로그래밍을 처음 공부했을 때부터 계속 영어로 공부했었다. 왜냐면 회사에서 영어를 할 수 밖에 없는데 이미 한글로는 알고있는 내용이었지만 영어로 공부하지 않았기 때문에 설명할 수 없는 자신이 한심했기 때문이다. 지금의 여자친구도 켄터키 시골 동네에서 온 백인이라 계속 영어를 할 수밖에 없는 환경에 있다. 그래서 영어로 개발을 하거나 의사를 표현하는데 큰 문제는 없다.

하지만 요즘 드는 생각이 개발을 하면서 영어를 잘하는 것은 정말 중요하지 않은 것 같다. 영어를 잘하는 것 보다 개발을 해온 내공이 더 중요하다는 것이 느껴진다. 요즘은 파파고와 같은 번역시스템이 잘 되어있고 많은 사람들이 번역된 자료를 공유하면서 경계가 많이 무너진 것 같다. "영어로 된 공식문서를 읽는데 어려움이 없습니다" 혹은 "문제 해결하는데 있어서 더 유리합니다"는 좋은 코딩 문화에서 실력을 쌓아온 개발자 앞에서는 의미가 없는 것 같다. 지속적인 열정과 노력은 누구도 따라잡기 힘들다

어렸을 때는 "이것이 나의 무기가 될 것이야"라고 생각했는데 참 어렸던 생각이었던 것 같다. 개발을 30이라는 나이에 개발을 시작했다. 성장욕이 강하고 문제를 깊이파는 것을 좋아하여 시작한 개발이고 지금도 개발하는 것이 정말 좋다. 하지만 현실의 벽은 생각보다 높다는 것을 느낀다. 세상에는 정말 많은 개발자가 있고 개발실력이 좋은 사람들이 넘쳐 난다. 그들을 보면서 비교를 안하는 성격이지만 나의 현실과 계속 비교하는 나를 보게된다.

4. 철학하는 개발자 (부제 : 정신승리) - 정호영

미국 인턴을 마치고 반년정도 세계 여행을 했었다. 많은 사람들을 만나고 많은 경험들을 하면서 내가 누구인지 확실히 알게 되었다. 그만큼 자존감도 높아졌다. 자존감이 높아진만큼 하루하루가 행복했었다.

하지만 개발을 시작한 이후로 이게 정말 나일까? 라는 생각을 많이한다. 부정적인 의미에서의 고민이 아니라 개발자로서 나는 누구인가 라는 고민을 하게 되었다.

  • 무엇인가 할 수 있다는 믿음
  • 사랑받을 자격이 있다.
  • 자존감이 높은 사람은 회복 탄력성이 높다

개인적으로 위의 세가지는 매우 동의하고 나 자신도 그렇다고 믿고 있다. 하지만 마지막 실패해서 복구를 잘하는 사람은 나인가 라는 물음에 선듯 대답이 나오지 않았다.

삶을 살아오면서 크게 실패한 경험이 많이 없었다. 사실 많았지만 항상 그 실패를 만회하기 위해 노력을 하고 이겨냈고 마치 별거 아닌 일처럼 잊고 살았기 때문이다. 하지만 늦은 나이로 개발을 시작했다는 점그래서 더 빨리 잘해야되 라는 조급함이 스스로를 실패를 해서는 안되는 사람으로 만들었던 것 같다.

개발자로서 실패를 잘하고 빨리 복구하는 능력은 매우 중요하다. 비단 TTD에서도 명확하게 들어나고, 개발능력을 기르기 위해 사이드 프로젝트로 코드를 구현해보는 것 또한 실패하고 배우는 방법이라고 생각한다. 회사에서도 실패를 두려워 한다면 서비스를 개선하는데 많은 시간이 들 수 밖에 없다. 작은 실패를 통해 복구하여 문제를 해결하는 능력을 부족한 것이 나의 부족한 점이라는 것을 새삼 느끼고 있다.

실패를 두려워한다는 것은 미래에 대한 고민이 많다는 것으로 이해할 수 있을 것 같다. "코드를 바꿔서 문제가 커지면 안되니까 그대로 놔두는 것이 좋아" 혹은 "더 좋은 아키텍쳐가 나중에 생각 날 거니까 일단 그대로 놔두자" 등이 바로 미래에 대한 고민이 만들어내는 문제라고 생각한다. 지금까지 미래를 너무 많이 고민했던 것 같다. 오늘은 알고리즘을 공부하고 데이터베이스 관련 책을 일고, 다음주에는 도커와 쿠버네티스를 공부하고 다음 달에는 nextstep 강의를 듣고, 내년에는 Cracking coding interview를 완독해서 미국의 IT회사에 지원해야지 등의 오만 미래의 계획들이 가득차서 당장 현실의 나는 개발이 재미없고 지금 하는 일이 제대로 마무리 되지 않는 것을 느끼고 있지 않은가.

위의 내용들은 현재 시점에 나에게 정말 필요했던 말들이다. 우연히 보게 된 글이지만 좋은 새미나 내용을 정리하신 이동욱님에게도 감사를 표하고 싶다. 참 대단한 개발자이신것 같다. 꼭 마음 한 곳에 새겨놓아야겠다.

  • 현재에 최선을 다하자
  • 적당한 논리력이 필요하다
  • 모르는 것을 인정하자
  • 미루지 말고 바로 해결하자

그 동안 살면서 정신승리의 필요성을 못느꼈다. 하지만 어느 때보다도 필요했던 단어가 아닌가 싶다. "정신승리". 현재 주어진 상황을 깊이 파악하고 개선점을 살펴보다 보면 개발자로서 역량이나 커리어를 조금씩 쌓아갈 수 있을 거라 확신이 든다. 현재의 목표를 위해 내 스스로가 움직인다면 다른 사람도 움직일 수 있고 조직을 긍정적인 방향으로 움직이게 할 수 있을 것다. 회사의 개발문화가 어쩌고 기획자가 어쩌고 혼자 아무것도 하지않고 불평한 한 것은 아닌가 라는 생각이 회고를 쓰면서 많이 들었다. 개인적으로 조금 더 노력할 수 있는 부분이 있었은 텐데 말이다. 그런 부분에 대해 더 고민해봐야겠다. 쓰다보니 너무 늦어졌는데, 내일부터는 좀 더 일찍자는 습관을 들여겠다.

 

728x90