연차가 쌓이는 것, 관여하는 일이 많아지는 것

보통 일과 바쁨이란건 왔다갔다 한다고 여겼는데,

시간이 갈수록 하는 일과 바쁨의 정도가 리니어하게 증가하는 느낌이다.

근데 생각해보면 당연한 것이다.

연차가 쌓이면 그만큼 경험과 제품에 대한 지식이 많아 진다는 것이다.

결국 많은 사람들이 나를 찾는 확률이 점점 높아진다는 것이다.

기획, 디자인, 개발자와 제품에 대한 논의를 하고

개발자와 개발에 대한 얘기를 하고 (제가 개발자이기 때문에)

영업이나 다른 직군들과도 제품 히스토리나 고민을 얘기하게 된다.

가끔은 영업을 하는 분들이 가져오는 제품 커스텀이나 신기술을 논의하기도 하고

종종 하소연을 듣는 시간도 필요하다.

점점 J인척 하는 P가 되는 것

아무리 내가 오늘 해야할 계획을 세워도 항상 그렇진 않다.

위와 같은 일들은 갑자기 생겨서 갑자기 나에게 찾아오기 때문이다.

가끔은 내가 해야할 계획보다 우선순위가 더 중요한 것들이 오게 된다.

가끔은 중요하지 않을 수 있지만 먼저 해줘야 할 일들도 오게 된다.

이 때 필요한 것은?

나도 그랬고 같이 일했던 주니어 개발자도 그랬는데 Do Not Disturb를 원했던 친구들이 많다.

개발뿐만 아니라 많은 직군들도 공감할 것 같은데 일에는 흐름이란게 있고 그 흐름을 타면 정말 안되던 것도 잘 된다.

그래서 그 시간을 지켜주는게 중요하다고 생각했다.

연차가 쌓이면? 그런거 없다.

그렇기 때문에 요새 느끼는건 일의 전환 능력, 커뮤니케이션, 집중력, 체력이 중요한 역량이 된다고 느끼고 있다.

하던 일을 스위칭 해서 잘 커뮤니케이션 하고 돌아오기. 그리고 꾸준하기

하던 일을 멈추고 다른 일을 하다가 다시 돌아와서 마저 처리할 수 있는 능력.

결국 이런 일련의 활동을 하루에도 몇 번씩 하게 된다.

그 과정에서 집중력이 필요하고 이 집중력을 유지하기 위한 체력이 필요하다는걸 요새 많이 느낀다.

그리고 그 바탕으로 좋은 커뮤니케이션을 하게 되는 것 같다.

특히 상황을 파악하고 명확하게 커뮤니케이션을 해야 불필요하게 시간이 길어지지 않는다.

그러기 위해선 집중력이 필요하고 체력도 필요하고...

가끔은 알아서 다 잘해주었으면 싶다.

정말 그렇다.

하지만 알아서 잘되는건 없다.

그저 내가 고민하고 행동하고 그걸 팀과 나누고 같이 변화를 만들어가는게 조직이고 팀이 아닐까 싶다.

어쨌든 연차가 쌓인다면 나는 고고하게 1-2개의 일만 할 수는 없는건 맞는 것 같다.

그러기 위한 준비를 잘 하는것도 중요한 것 같다.

커리어 고민은 일단 포기

이번에 한기용님께서 커리어 그룹 코칭을 모집한다는 글을 보고 많은 고민을 했다.

한기용님은 이오에 올라온 영상을 통해 처음 알게 되었는데 인사이트가 좋아 안쓰는 링크드인에 가서 팔로우까지 했다.

(근데 워낙 링크드인을 잘 안쓰다보니 결국 잘 안들어가게 되더라구요)

나에겐 없는 경험과 인사이트가 많은 선배 개발자같은 느낌이라 더욱 관심이 있었고 유료임에도 기꺼이 돈을 낼 의향도 있었다.

세션에도 요새 관심이 많은 부분들이 있어서 거의 참여 직전까지 갔지만,

결국 참여하지 않기로 결정했다.

나에게 도움이 될까?

위 세션이 나에게 도움이 될지 고민을 많이 했는데 내 커리어는 일반적이지 않다고 생각해서 포기를 했다.

왜냐하면 나는 스타트업의 창업멤버로 있기 때문이다.

창업멤버는 일반적인 커리어 플랜과는 조금 다른 것 같다.

계속 일을 하면서 느낀건 나는 한 우물을 파기 어렵다는 생각을 했다.

회사 초기에 같이 인프라를 공부하던 동료가 DevOps 포지션을 옮겨서 커리어를 시작하고

2017년에 같이 AI를 공부하던 스터디 멤버들이 지금은 좋은 포지션에서 계속해서 일을 하는걸 보고

조금 부러워했던 적도 있다.

인프라는 최소한의 공부는 계속 하지만 AI는 지금 공부하지 않는다.

그때는 공부를 하고 지금은 안하는 이유는 당시 회사에서는 그 공부가 필요했고 지금은 아니기 때문이다.

만약에 회사에 전문적으로 맡아줄 분이 있다면? 나는 그 공부를 안하고 다른 필요한 공부를 하게 될 것이다.

지금도 회사 규모가 크진 않지만 회사가 점점 커지면 나도 내 전문분야를 계속 공부할 수 있을까?

사실 잘 모르겠다.

내 커리어는 어떻게 해야할까?

어쨌든 내 커리어에 대한 결론을 한 번 내리고 싶었다.

그리고 나는 자기합리화를 잘 한다.

누군가에게 회사 임원의 평가는 회사 매출과 비례하다고 들은 적이 있다.

그럼 내 커리어의 마일스톤은 회사와 팀이 잘 되는 것이 아닐까 싶었다.

회사가 좋은 방향으로 가는데 일조하고

그 방향에 기술이 부족함이 없게 준비하고

팀이 잘하는 것에 집중할 수 있게 서포트하고

그러다 부족한 점이 보이면 그 부분을 준비하고 챙기는 것

이게 내 할 일이면 이게 잘 돌아가는게 내 마일스톤이 될 것 같았다.

개발자와 개발리더

지금 생각해보면 내 커리어에 대한 고민은 개발자와 리더의 괴리감에서 오는게 아닐까 싶었다.

둘 다 해야하는데 둘 다 잘하긴 힘들고, 하나만 열심히 하는 사람들이 잘 되는걸 보니 거기서부터 고민이 아니었을까?

지금도 답은 모르겠다.

모르겠지만 일단은 이것도 저것도 할 수 있는데까지 잘 해야하는 것 틀림 없는 것 같다.

다행히 이런 생각을 트위터에 적었을 때 좋게 봐주시는 분들이 많은 것 같아서

여기에 좀 더 긴 생각을 써보게 되었다.

개발자가 생각하는 스타트업에서의 눈높이

눈높이

명사

2.어떤 사물을 보거나 상황을 인식하는 안목의 수준.

조촐하게 시작했던 스타트업이 점점 커지고 있다.

개발자도 점점 늘어나고 디자이너, 기획자도 점점 늘어나고 다양한 직군, 직무의 사람까지 점점 생기고 있다.

회사가 어느정도 초기에 있던 시절.

동료들과 자주 했던 얘기에는 mvp, lean과 같은 단어가 많았다.

일단 출시를 하고 고객 반응을 보자는 얘기도 많았다.

lean은 마법같은 단어다.

뭔가 일을 하다 막힐때면 lean이란 단어가 다 해결을 해주었다.

조금 어설퍼도 빠르게 고객들에게 보여주고 반응을 살펴보자는 생각을 은연중에 하게 해주었다.

그래서 lean이란 참 무서운 단어다.

mvp는 최소 기능 제품이다.

기능이 최소이지 기능의 퀄리티가 최소는 아니다.

하지만 mvp는 빠르게 출시를 해야했고 80%까지 올린 완성도를 90%까지 올리기 위해서는 같은 노력과 시간이 필요했다.

그래서 그냥 출시를 했고 그게 lean이라고 생각했던 시절이 있었다.

사실 초기 스타트업에게는 어느정도 필요한 부분이라고 생각한다.

아마 대부분의 스타트업이라면 고객의 생각에 회사의 존폐가 좌지우지 되고

3년이 되고 5년이 될지라도 계속 성장하고 돈을 벌어야 하기 때문에 어쨌든 제일 중요한건 고객의 생각과 행동이다.

그래서 고객의 소리에 집중하고 빠르게 반응을 본다는건 매우 중요하다.

하지만 점점 서비스가 커지고 고객이 많아진다면?

우리가 챙겼던 80%의 완성도를 조금 더 높여야 할 때라고 생각한다.

만약 10분간 에러가 났을때 그 에러를 마주하는 사람을 생각해보자.

서비스 초기에는 그 에러를 만나는 유저가 10명도 안될 것이다. 하지만 그 숫자는 점점 늘어날 것이다.

그리고 커지는 서비스에 유저가 바라는 신뢰도, 퀄리티도 점점 높아진다.

조촐했던 스타트업에 사람이 점점 늘어나고 있다.

여기에는 다양한 사람이 있다.

지금 회사에서 오랫동안 함께한 사람도 있고 새롭게 들어온 사람도 있다.

새롭게 들어온 사람도 경력이 많은 사람도 있고 적은 사람도 있다.

우리는 같은 생각으로 퀄리티는 챙기고 있을까?

빠르게 성장하는 스타트업에서 계속 눈높이를 높여가는 것

그리고 그 눈높이를 동료들과 함께 계속 맞춰가는 것은 중요하다는 생각이 들었다.

개발팀장은 무엇을 할까?

나는 회사에서 어떤 일을 하는지 질문을 받은 적이 있다.

스타트업에서 팀장이란 직책을 달고 있는 나는 무엇을 할까?

막상 그 질문을 받았을 때는 대답을 잘 못했던 것 같다.

두서없이 대답을 하고 돌아오던 길에 여태 해왔고 하고 있는 일을 한 번 정리해보면 어떨까 싶었다.

어쨌든 개발을 한다.

• 어쨌든 개발을 하고 개발을 잘 하는 것이 중요하다.

• 이제 초기 스타트업은 조금 벗어난 것 같은 지금도 해야할 개발은 많은 것 같다. 특히 지금처럼 어려운 상황에 성장을 해야 하는 스타트업이라면 신규 제품이나 사업 준비를 포함하여 가설 검증을 하느라 바쁘지 않을까 싶다. 어쨌든 기본은 개발을 잘 하는 것이다.

• 때로는 새로운 프로젝트를 하거나 규모가 커짐에 따라 큰 단위로 고민이 필요할 때가 있다. 대표적으로는 기술 스택의 선택이나 아키텍처 고민, 새로운 기술의 도입이 있다. 그럴때 고민은 동료들과 같이 하지만 최종적인 결정을 내가 하는 것 같다. 내가 결정을 하는 이유는 책임 또한 내가 지기 위함이다.

• 팀이 신경을 못 쓰는 부분도 신경을 써야 한다. 그게 모니터링일 수도 있고 배포에 관련된 부분일 수도 있고 리팩토링일 수도 있다. 계속해서 현재 상황을 점검하고 필요한 업무를 찾아내서 같이 하는 것도 필요하다. 그러다가 중요하게 해야할 일이 생기고 그 시점이 된다면 그런 일을 같이 하기도 한다.

업무를 나눈다.

• 업무를 관리하고 진행하는 일도 필요하다. 우리 회사는 스쿼드 체제로 넘어가면서 그 일을 더 이상 내가 하지는 않는데 예전에는 해야할 업무를 정리하고 각 업무를 누가할지 정하고 일이 잘 진행되는지 체크하는 일종의 스크럼을 매일 진행하였다. 이 때 업무의 난이도에 따라 누구에게 업무를 배정할지, 일이 딜레이가 될 때는 이슈가 무엇이고 어떻게 할지에 대한 논의도 같이 진행된다. 필요하면 유관자와 같이 미팅을 진행한다. 그리고 사람마다 업무 스타일과 성장 욕구가 다르기 때문에 그 부분도 고려하며 일을 나눠주는 것도 중요하다.

팀 문화를 만든다.

• 사실 좋은 문화를 만드는건 함께 만드는 것이라 생각한다. 그리고 그 과정은 팀원들끼리 지속적으로 논의를 하고 필요한게 있다면 도입을 하고 그렇게 시도한 것들이 정말 도움이 되고 지속가능한지 체크하는 과정의 반복이라고 생각한다. 이 모든 과정을 팀장 혼자서 하지 않아도 된다. 동료들과 함께 해도 되지만 그럼에도 놓치는 과정이 생길 수 있고 결정해야할 요소가 있을 수 있다. 그 일련의 과정이 지속적으로 돌아갈 수 있게 중간중간 빠지거나 필요한 부분을 챙기는건 팀장의 역할이라고 생각한다.

• 예를 들어 일을 하다 보면 새로운 도구, 혹은 세미나나 스터디와 같은 새로운 문화에 대한 얘기가 나올때가 있다. 그럴땐 필요성을 따져서 진행여부를 결정하고 (그런데 보통은 일단 해보는 경우가 많다.) 지속적으로 잘 진행될 수 있게 챙겨야 하며 도입 전, 후에 대한 의견을 정리하고 앞으로도 계속 진행할지 정리하는 것들이 필요하다. 이렇게 까지 하는 이유는 팀에 정말 도움이 되는지 검증하는 것도 있지만 회사의 예산을 쓰는 만큼 과정과 근거의 정리는 꼭 필요하다. (어떻게 보면 회고이다.)

테크 리딩을 한다.

• 테크를 리딩한다는 말이 맞는지는 모르겠지만 회사의 중장기 목표를 상상하며 필요할 기술 스택을 점검하고 때에 따라서는 새로운 기술의 PoC도 진행한다. 만약 초기 스타트업이면 웹호스팅을 쓸 수도 있고 클라우드라면 서버 1대로 사용할 것이다. 서비스의 사이즈가 커져서 그 다음 스택을 고민해야 되는 순간이 오면 그 때는 어떻게 할 것이며 그 시점은 언제일지 생각해보고 필요하면 기술에 대한 PoC도 진행했던 것 같다. 인프라나 데브옵스를 전문적으로 봐주는 인력이 있다면 같이 할 수 있겠지만 큰 회사가 아니면 그런 인력이 있기 쉽지 않다. 그래서 결국엔 스스로 하게되는 것 같다. (사실 팀장으로 있으면 비어 있는 영역의 일은 도맡아 하게 된다. 그렇게 AI나 Web3에 대한 스터디를 한 경우도 있다.)

• 이 과정에서 대표님과 얘기를 많이 하는 것 같다. 중장기 목표를 세우기 위해서는 회사가 나아고자 하는 방향에 대한 이해가 필요하고 그러다 보면 큰 단위의 서비스 변경이나 채용이 필요하는 순간도 오기 때문이다. 그렇기 떄문에 대표님을 비롯한 경영진과의 얘기가 필요하다. 특히 서비스를 잠시 중단하거나 리팩토링을 하게 된다면 그 시간만큼은 기술 개발이 거의 중지되기 때문에 모든 팀원들의 이해가 필요하다.

동료들과 같이 잘 지내기

• 개발자가 점점 늘어나면 서로 잘 지내는 것도 중요하다. 그리고 동료들이 회사에서 보내는 시간이 더 의미있게 만들어줘야 한다고 생각한다. 그러기 위해 가장 좋은 방법은 1:1을 하는 것이라고 생각한다. 사실 하다보면 할 말이 없을때도 종종 있는 것 같다. 그럼에도 서로 얘기할 자리를 만들고 아쉬운 부분과 바라는 부분을 서로 맞춰간다면 좋은 팀이 되는 것 같다.

• 그리고 연봉 협상 시즌이 오면 평가를 하고 협상을 진행하는 일도 한다.

이렇게 정리를 해보았는데 사실 할 일은 더 있다.

동료들과 의견을 나누고 앞으로의 예측을 하기 위해선 스스로의 공부도 필요하다. 그게 지식일 수도 있고 팀을 리딩하는 내용일 수도 있고 경영에 관한 부분일 수도 있다. 그래서 독서도 하고 네트워킹도 하고 때에 따라서는 서비스를 사용하면서 만나게 되는 담당자와도 얘기를 하고 도움을 청하기도 한다. (예를 들어 AWS 담당자가 있다.)

그리고 외부활동도 필요하다. 외부활동은 회사를 알리고 더 현실적인 정보를 얻으며 심지어 채용의 기회도 노려볼 수 있는 좋은 기회인 것 같다.

이렇게 내가 하는 일들을 조금 정리해보았다.

놓친 부분이 있을 수 있으나 큰 틀은 벗어나지 않을 것 같다.

여기서 조금 더 욕심을 내면 팀장이 아니더라도 팀장이나 대표님과 같은 마인드로 생각하며 행동하기를 바란다. (마치 요식업에서 직원들에게 내 가게다 생각해달라는 것과 똑같은 것일까?)

물론 쉽지 않다. 그런데 누구나 팀장이 되고 시니어 개발자가 되고 그 와중에 또 누군가는 CTO나 CEO가 되는 사람도 있을 것이다.

그렇다면 오히려 처음부터 그런 생각을 가지고 일을 하는게 도움이 된다고 생각한다.

대기업은 어떨지 모르겠다. 비록 내가 대기업에 대한 경험이 없어서 잘 알지는 못하지만 부장님이나 이사님과 같은 생각을 하며 일해볼 수도 있지 않을까 싶다.

번아웃이 온거 같아요.

번아웃이 온 것 같다.

사실 번아웃은 언제 한번 딱! 오는건 아닌 것 같다.

일년에도 수십번 찾아오기도 하고 매주 오는 것 같기도 하고 시도때도 없다.

그리고 그 크기도 다양해서 우리는 알게모르게 잦은 번아웃을 마주친다.

그렇게 우리는 매번 견디며, 때로는 잘 해결하며 살고 있다.

그러다 가끔 눈에 보이는(?) 번아웃이 올 때가 있는데,

그 때는 어떻게 시간을 보내야 할까?

이번 기회에 다른 사람의 번아웃에 대한 내용도 찾아보았는데

그들은 사내에서도 어려움을 겪었지만 나는 그정도까진 아니었던 것 같다.

나의 경우는 회사 밖에서도 뭔가 생산적인 일을 해야 할 것 같은 병에 걸린 나에게

아무것도 하기 싫은 병이 찾아온건데 그래서 그냥 아무것도 안했다.

아무것도 하지 않기

사실 아무것도 안한다지만 100% 온전히 쉬지는 못했던 것 같다.

이래도 되나? 라는 생각부터 온갖 회사일과 하고 싶은 사이드 프로젝트도 생각이 나고,

그러다가 내 집 마련과 같은 현실적인 문제에 좌절하다가 다시 또 회사의 온갖 문제들이 생각나서 걱정하지만!

그 생각을 넘어 내가 뭘 하려는 의욕이 없다면 그때는 쉬는게 맞다고 생각한다.

이왕이면 아무 생각없이 100% 쉼에 집중하고 싶지만 아직 그러긴 어려웠다.

(youtube에서 싱잉볼을 틀어놓고 향도 피웠지만...)

생각이 액션으로 이어질 의욕이나 힘이 부족하다면 쉬는게 맞다.

나만의 호흡으로 하고 싶은걸 하기

그렇게 아무것도 안한 후에는 해보고 싶은 딴 짓을 했다.

TV 프로그램이나 youtube를 보고 책도 보고 만화도 보고 그랬다.

예전엔 이 시간이 아깝다고 생각했다. 생산적이지 못하다고 생각했기 때문이다.

그런데 이렇게 전혀 다른 행동이 의외로 리프래시가 되는 것 같다.

운 좋게 생각의 저변을 넓힐 기회도 찾아오고 새로운 의욕이 생기기도 한다.

시간이 지나고 연차가 쌓일수록 대단한 사람들이 눈에 띈다.

특히 요새는 갓생을 산다는 사람들이 하나둘 보이면서 엄청난 생산성을 자랑하기도 한다.

디스콰이엇만 봐도 얼마나 사람들이 열심히 살고 있는지 내가 '루저' 로 보인다.

그럴땐 그냥 '나만의 호흡' 을 찾는것도 도움이 되는 것 같다.

가끔은 미친듯이 달릴 때도 필요 하지만 그 뒤엔 꼭 쉬어갈 시간도 필요하다.

그리고 그 반복 속에서 '나' 는 어떻게 시간을 보내는지 알게 되고 또 훈련이 되고 바뀌기도 할 것이다.

힘들땐 쉬자.

주니어를 위해 해주고 싶은 말이 있나요?

사회 초년생들 대상으로 일종의 멘토링 같은 요청이 왔었다.

직군이 개발, 마케팅, 기획등 다양해서 한 분야에 대한 얘기도 하기 애매했다.

어떤 얘기를 해주면 좋을까 생각하다가

기본적으로 겪는 업무 프로세스에서 어떤걸 더 챙기면 좋을지를 준비해보았다.

(아마도 기본적인) 업무 프로세스

• 해야 할 일이 생긴다.
• 유관자들끼리 모여서 일을 진행한다.
• 내가 맡은 역할에 대해서는 열심히 작업을 한다.
• 잘 마무리한다.

나름 아주 기본적인 업무 프로세스를 생각해보았다.

만약 위 업무 프로세스대로 일이 진행된다면 어떤걸 좀 더 신경쓰면 좋을까?

해야할 일이 생겼으면 '왜' 를 생각해본다.

일이 생긴다면 내가 맡은 일만 잘 하려는 모습을 보일 수 있다.

하지만 정말 중요한건 그 일을 왜 하게 되었으며, 지금 하려는 작업으로 무엇을 해결하고 싶은건지를 아는 것이다.

예전에는 다른 직군보다 개발자분들이 이런 생각을 하기가 쉽지 않았다.

A라는 기능을 만들어야 한다면 그 기능을 아주 멋지게 만들 생각을 많이 했다.

그런데 최근에 만나는 개발자들은 다행히 '왜' 만들어야 하는지를 항상 궁금해했다.

'왜'를 생각하면 일을 대하는 태도가 달라진다.

각자가 고민의 대상과 목표가 생기기 때문이다.

그리고 그 고민을 나누면 작업이 더 긍정적으로 변하고 확장성을 가지게 된다.

일이 끝난 후에는 학습점을 만들 수가 있다.

하나의 작업은 보통 그 하나로 끝나지 않는다.

결과가 좋지 않으면 변형해서 다시 시도해볼 수도 있고 결과가 좋다면 더 디벨롭 할 수도 있다.

이런 생각과 함께 일을 하게 되면 일을 하는 모습이 달라질 것이다.

그런데 가끔은 이런 부분이 잘 공유가 안될때가 있다.

그럴땐 물어보자.

'너무 바빠 보여서 물어보지 못했다.' 라는 얘기를 종종 듣는데 그건 말해줄 사람의 고민이 되어야 한다.

정말 바쁘면 몇시간 뒤나 내일 얘기해주겠다라는 말을 하거나 참조할 만한 문서를 건네줄 것이다.

물어보는 사람이 물어볼 타이밍을 고민해서는 안된다.

유관자들끼리 모여서 일을 할 때는 나의 장점을 생각해보자.

하나의 일을 잘 처리하기 위해서는 많은 유관자들이 모여서 일을 진행한다.

함께 협업할 때에는 내가 도움이 될 수 있는 장점이 무엇인지 생각해보고 발전시키면 좋을 것 같다.

협업이 원활하게 진행하기 위해서는 필요한 능력들이 아주 많다.

누군가의 전문 지식, 누군가의 업무 조정 능력, 누군가의 서비스에 대한 이해, 누군가의 기록 등등등...

이런 스킬들을 누구나 다 가지길 원하지만 한 사람이 이 모든 역량을 가지기는 쉽지 않다.

그럴땐 내가 잘하는게 뭔지 생각해보자.

그 장점이 점점 사람들에게 돋보이게 된다면 그 사람은 팀에 영향력을 끼치는 사람이 된다.

팀에서 나를 찾거나 신뢰하는 상황이 오고 간단한 내부 세미나부터 외부 강연 요청에 대한 기회가 생길 수도 있다.

그렇게 커리어가 성장되고 관리가 되는 것 같다.

내가 맡은 역할에 대해서 잘 하기 위해 꾸준히 공부하자

세상이 빠르게 변하고 있다.

유저의 생각, 눈높이도 같이 변화되고 있으며 유저를 잘 알기 위한 방법이나 툴도 많이 나오고 있다.

내가 처음 공부하던 베이직이나 그렇게 좋아하던 jQuery는 지금에선 잘 쓰이지 않는다.

마케팅믹스도 처음 공부했을땐 4P였지만 지금은 다들 7P로 하는 것 같다.

스마트폰이 나오고 클라우드가 활발하기 시작한지는 약 10년이 되었고

조만간 GA3는 종료가 되고 SQL은 모든 직군이 쓰는 기술이 되었다.

지금은 대규모 언어모델이 나오면서 또 한 번 세상의 판도가 바뀌었다.

그래서 계속 공부를 해야한다.

일을 잘 마무리하기 위해서는 회고하고 학습점을 찾아보자

하나의 일을 끝내고 돌아보면 누구나 잘한 점과 못한 점이 있을 것이다.

내가 다음에 더 일을 잘하기 위해서는 잘한 부분을 더 잘하고 못한 점을 줄여야 한다.

그러기 위해서는 다같이 모여 회고를 하는게 중요하다.

물론 회고를 안해도 잘할 수 있다.

하지만 성장의 폭에서 크게 차이가 난다고 생각한다.

회고를 안하면 같은 실수를 반복할 확률이 높기 때문이다. 사람은 쉽게 바뀌지 않는다.

특히 유관자들끼리 회고를 하면 다른 사람이 생각하는 나의 모습을 알 수 있고

다른 사람의 고민도 알 수 있다.

그래서 꼭 다같이 회고를 하는걸 추천한다.

여기까지가 업무 프로세스에 맞춘 조금 더 신경쓰면 좋을 것들이었다.

만약 여기서 조금 더 신경쓰면 좋을게 있다면 나는 서비스에 대한 이해, 네트워크, 자기관리를 추가하고 싶다.

특히 자기관리 측면으로 나를 너무 갈아넣지 않았으면 좋겠다. 결국엔 안좋은 영향으로 돌아오는 것 같다.

사실 이 모든 것들을 생각하고 챙기기 어렵다면 딱 하나만이라도 신경쓰라고 하고 싶다.

그건 내가 하는 모든 행동에 대해 '고민' 을 많이 하는 것이다.

왜를 생각하는 것도 장점을 생각하는 것도 공부를 하고 회고도 일종의 다 '고민' 이다.

그 고민이 스스로를 크게 성장시켜줄 것이라 생각한다.

정리해보고 싶은 생각

지난 번에 개발자의 고객지향에 대해 생각해본 뒤,

다음으로 정리해보고 싶은건 커뮤니케이션과 개발을 하는 사고에 대해서였다.

개발자에 대해 흔히 오가는 소리 중 하나는 개발자는 커뮤니케이션에 약하다는 것이다. (특히 백엔드 개발자)

개발자가 말하는 것과 문서에 약하다는건 이력서와 면접만 봐도 느낀바가 많다.

하지만 그 말에 공감을 해줄 수 있는건 주니어뿐인 것 같다.

일을 하게 된 이상, 개발자도 말을 잘해야 한다.

정확히는 의사소통을 잘해야 한다.

개발을 하는 사고에 대해서도 요새 생각한 바가 많다.

작은 스타트업에서는 하나의 제품이나 기능을 만들때 한 명의 개발자가 들어간다. (백엔드 한명 프론트 한명? 다른 곳은 아닐 수도 있으나 내가 다닌 회사는 많이 그랬다.)

그러다보니 그 한 명의 생각이 엄청 중요해진다.

만약 누군가가 기능 개발, 개선이 안된다는 결론을 내렸다면 그걸 어디까지 신뢰할 수 있을까.

연차가 낮을 경우 그 판단에 대해 하나의 기술로 나이스하게 풀고 싶어하는 경우를 많이 보았다.

하지만 현실에서는 다른 기술을 데려와야할 수도 있고 제품이나 고객의 사용성을 조금 헤치면서 해결을 해야할 수도 있다.

혹은 그냥 노가다를 해야할 수도 있다.

사실 정답이 없는 생각들이지만 한번 쯤 정리해보고 싶다.

개발자와 고객지향

제품을 기획하고 만들고 출시하기까지 많은 것들이 중요하겠지만

가장 많이 얘기하는 것 중 하나는 '고객지향' 인 것 같다.

그런데 일을 하고 바쁜 와중에 개발자가 그 '고객지향'을 챙기기가 쉽지 않다는 생각을 종종한다. (개발하기 바쁘니까)

과연 개발자가 고객지향적일 수 있을까?

개발자가 가져야할 고객지향적인 모습을 무엇일까? 고민이 되는 순간이다.

보통 같이 일할 사람을 구할 때는 다음과 같은 질문으로 고객지향이 있는지 체크해보곤 한다.

• 제품을 만들때 고객 측면으로 가장 신경 쓴 기능이나 기술은 무엇인가요?
• 제품을 완성하기 전에 사람들로 하여금 써보게 한 적이 있나요?
• 제품을 완성 후에 실제로 고객이 어떻게 쓰고 어떤 의견이 있는지 알아내기 위해 해본 행동이 있나요?
• 제품을 개선할때 어떤 기준으로 어떻게 개선하나요?

하지만 실무로 들어간다면 얘기가 조금 달라진다.

제품을 만들때마다 고객을 생각하면 고객지향적이게 될까? 고객이 좋아하는 제품을 만들 수 있을까?

아마 아닐 것이다.

제품을 만들고 고객이 어떻게 쓰는지 살펴볼 때 누구나 이런 생각을 했을 것이다.

'이걸 왜 안쓰지?'

혹은 다음과 같은 생각도 많이 할 것이다.

'왜 이걸 모르지?'

내가 생각했던 고객을 위한 기능들이 전혀 고객을 위한 기능이 아니게 되는 순간이다.

여기서 필요한 건 고객에 대한 학습이다.

고객에 대한 학습을 통해 제품을 개선하고 만들어 나가는게 고객지향이 되는 것이다.

결국 고객지향적인 사고를 가지기 위해서는 가설에서 끝나는게 아니라

가설이 맞는지 검증을 하고 학습점을 정리해서 그 학습이 이후에 계속해서 반영되어야 한다.

그렇다면 개발자가 고객지향을 가지기 위해서는 학습점을 배워서 계속 제품에 반영하면 되는걸까?

사실 맞는 말이긴 한데 어려운 부분이 있다.

팀이 작으면 괜찮지만 사이즈가 점점 커지면서 어려움이 생기게 된다.

결국 고객에 대한 고민은 PM이나 그로스 담당자가 주로 진행하게 되고

개발자는 개발에 집중하게 되는 것 같다.

특히 내가 참여를 못하게 되는 개발도 생기게 된다.

그럴 때는 아래와 같은 프로세스들이 도움이 되었던 것 같다.

• 제품 기획 단계에서 유관자들이 모여서 논의하기
• 개발 이후 회고하는 시간 가지고 정리하고 기록하기
• 다른 회고 문서도 관심 가지고 찾아보기

결국 사이즈가 점점 커질수록 기록하고 공유하는 문화가 도움이 되는 것 같다.

이 외에도 개발자가 좀 더 신경 쓰면 좋은 점이 있다고 생각한다.

개발자가 자연스럽게 고객의 학습점을 이해하게 되는 지점이 있는데 아래와 같은 상황이라고 생각한다.

• 새로운 제품의 개발 요청
• 기존 시스템의 대한 개선 요청

위와 같은 요청이 들어오게 되는 이유는 보통 고객에 대한 학습점이 생겼기 때문이다.

여기서 개발자가 동료 개발자를 위해 신경써주면 좋은 점이 생긴다.

• 기존 시스템을 개선하게 된 고객의 행동은 무엇일까? 다음에 비슷한 상황이 생기면 그때는 어떻게 설계를 하면 좋을까?
• 코드의 유연성이나 확장성 관련해서 놓친 부분이 있을까?

이런 학습점은 다른 의미로 고객을 위한 개발을 할 수 있는 도움이 된다.

개발을 하는 과정에서 제품의 의도를 파악하고 설계를 하면서 개발자는 많은 고민을 하게 된다.

그 고민의 과정에 기존의 학습점이 추가되어야 한다. 

여기까지가 개발자가 가져야할 기본적인 고객지향적인 모습인 것 같다.

다만 이게 지속적으로 꾸준하게 이루어지기 위해서는 기록과 공유가 중요하다.

게다가 고객에 대한 관심과 호기심, 학습에 대한 의지로 계속 학습을 할 수 있다면,

뛰어난 고객지향적인 사고를 가진 개발자가 되지 않을까 생각해본다.