[세미나] Level Up 요약정리 by moongs

레벨업 썸네일

본 포스팅은 moong님의 블로그에 올라온 글을 한빛N이 허락을 받고 게재한 포스팅입니다.

본 포스팅은 moong님의 블로그에 올라온 글을 한빛N이 허락을 받고 게재한 포스팅입니다.

post-thumbnail

HanBitN MSA?

한빛N MSA(Micro Seminar Assemble)는 한빛미디어 디지털콘텐츠개발연구소에서 준비한 세미나 시리즈다. 학교와, 학원 등에서 다루지는 않지만, 현업에서 일을 할 때 필요한 지식, 기술, 정보 등을 전달하는 걸 목표로 진행되는 세미나다.


첫 출근부터 끝까지 다함께 레벨업

주변에서 일 잘하는 동료, 친구들을 보면 되게 타고난거 같다는 느낌을 받는다. 과연 그들은 정말 '타고난 일잘러'일까? 그들도 사람이기에 남들과 똑같이 수많은 시행착오를 겪으며 일을 잘하는 지경에 이르게 됐을텐데, MSA 시리즈의 마지막을 장식할 이번 세미나에서는 (현)당근마켓 개발리더 박미정님께서 개발자로 일해오며 얻은 경험을 토대로 세운 일에 대한 태도와 기준을 공유하는 시간이었다.

본 게시글에 사용된 강의 자료는 한빛미디어의 지원을 받았습니다.


일을 시작하는 당신에게

기대치 조절하기

기대치는 나와 회사 양방향으로 필요하다.

어떤 회사에 새로 입사해서 일을 시작할때 제일 중요한게 기대치를 조절하는 일이다. 기대치는 새로 입사한 나도 회사에 바라는게 있고, 반대로 회사도 바라기 마련이다. '회사가 나를 받아줬으니, 회사의 기대에 부흥해야지!' 라며 단방향으로 생각하지는 말자. 양방향의 기대치는 비슷한 선상에 있어야 가장 행복한 시나리오인데, 서로 맞지 않으면 위와 같은 문제가 생긴다.

그러면 기대치는 어떻게 맞춰야 할까?

  • 전제
    회사에 지원할때면 그 회사의 JD를 본다. JD에는 지원하고자 하는 팀에서 어떤 일을 하겠다는게 분명히 명시되어 있고, 지원한 당사자 역시 분명히 회사에 원하는게 있을 것이다.

    전제를 세운 이유?

    많은 사람들이 어떤 회사의 타이틀이나 기술스택만 보고 지원하는 경우가 있다. 이보다 회사가 제시한 JD를 보며 어떤 일을 하게될지 파악하고, 내가 하고 싶은게 있는지, 기여할 수 있는게 있는지에 대한 고민을 해야된다는 말이다.

  • 입사 후
  1. 이런 전제가 있다면 입사 후에는 실제로 머릿속에 생각한 기대치와 눈 앞에 주어진 일이 있을텐데, 내 앞에 있는 일들과, 내가 회사에 기대했던 것들을 조합해서 3개월 동안 무엇을 달성할것인지 목표 수립을 하자. 이것부터 시작이다.

  2. 혼자 목표 수립하는건 어디까지나 단방향이다. 단순히 내가 하고싶은 것과 달성할 계획을 세운거 뿐이지, 아직 회사의 기대치와 맞추지 않았다. 그러니 회사의 기대치를 대변할 수 있는 팀 리더와 소통해 조정하는 과정을 거치자.

  • 수습 후
    회사에서는 나름대로 목표 수립기간과 평가 기간들을 가져가는데, 단기/중기/장기적으로 내 목표와 실제 눈 앞에 있는 일을 조합해 리더와 소통을 반복하는게 중요하다. 팀원이 명확한 목표의식을 갖고 회사에 가치기여를 할 수 있게 하는건 리더의 역할이기 때문에!

💡 정리
기대치를 혼자 가지고 있지 말자. 늘상 '나는 이런걸 하고싶고, 기여하고 싶고, 할 수 있어!'를 혼자 가지고 있는건 의미가 없기 때문에, 계속 리더와 소통하며 회사의 기대치와 내가 기대하는게 맞는지 확인하는 과정을 가져야 된다.


스스로 적응하기

셀프 온보딩: 누군가의 도움 관점이 아닌, 스스로 할 수 있는 것

온보딩 과정에서 중요한건 목표 설정이다. 결국에 목표 설정을 했다는건 기대치 조절을 통해 내가 무엇을 해야할지 명확히 알게 됐다는 말이기도 하니까.

how? 목표는 알았는데 어떻게 해나가야 하나?

강연자분의 사례를 통해 조금 더 그 방법을 알아보자. 회사 입사를 하자마자 맡게된 일이 쿠폰시스템을 개발하는 일이라고 하셨다. 그 경험을 소개하자면 다음과 같다. (사진과 동일)

  1. 쿠폰 시스템이 전체 시스템에서 어디에 위치하는지, 사용자의 액션부터 어떻게 상호작용 하는지 큰 흐름 파악
  2. 시스템의 주요 API를 하나 선정해 처음부터 끝까지 따라가며 프로젝트의 구조를 파악
  3. 이슈 백로그 중에서 가장 난이도가 적어보이는걸 선택해 지금까지 이해한 것을 바탕으로 해결하기
  4. 위 3단계를 항상 문서화해 사내 메신저 채널에 해결과정을 공유한 뒤 피드백 요청


이 과정에서 시스템에 대한 깊이있는 이해를 얻을 수는 없지만, 시스템에 스스로 접근을 했다는 경험으로부터 오는 자신감은 일을 시작하는데 되게 큰 동력이 된다.

이 과정에서 얻을 수 있는 것

  1. 팀이 일을 진행하는 프로세스를 선경험 할 수 있다.
    아주 작은 이슈를 해결해봄으로써, 우리팀의 프로세스가 이렇구나 라는걸 파악하는 계기가 될 수 있다.

  2. 도움 받을 수 있는 사람 파악
    팀원들에게 공유한 뒤 피드백을 받으며 어떤 부분을 누구에게 도움받을 수 있을지 알게되는 계기가 된다.

💡 정리
셀프 온보딩 기간동안 팀의 프로세스를 미리 경험하는 과정에서 자신감과 사람에 대한 파악을 할 수 있다는건 되게 가치있는 일이다. 잘 써먹자.


심리적 안정감 확보하기

심리적 안정감 = 어떤 도전, 리스크를 감수하더라도 팀에서 안전할 것이라는 인식

  • 구성원이 눈치 보지 않고 아이디어를 말할 수 있는가?
  • 실수를 솔직하게 털어놓을 수 있는 환경인가?
  • 도움을 요청하는데 거리낌이 없는가?
  • 부하직원이 리더의 의견에 반대할 수 있는가?

보통 심리적 안정감은 회사와 리더가 우리에게 줘야하는 것이 아니냐고 생각할 수 있지만, 이게 잘 되어있진 않기에, 오히려 회사에 이제 막 입사해서 적응하는 시점에 위 질문을 역으로 해석해보자.

  • 눈치 안보고 질문하기
    사실 이 시기에는 눈치 안보고 질문할 수 있는 시기다. 너무나 당연하다. 입사한지 고작 1달됐는데 질문이 없는게 오히려 이상한거니까, 질문을 너무 실컷할 수 있는 시기에 질문을 많이 하자.

  • 실수를 하지 않으면 오히려 이상하다.
    '새로 온 사람이 질문도 안하고 실수를 안한다? = 일을 안하고있다'로 밖에 해석이 안된다. 실수를 해도 너무 괜찮은 시기니 실수를 많이 하면서 배워야 할것들은 배우자.

  • 너무나 도움이 필요한 시기
    위 내용과 같은 맥락이다.

  • 자유로운 의견에 대한 허용 범위가 넓은 시기
    팀에서 몇 년간 한 시스템을 담당하는 사람이 미팅에서 너무 주제에 벗어나는 얘기를 막 하면 문제가 있는거지만, 얼마 안된 신규 입사자가 어떤 회의에서 조금 벗어난 얘기를 하는건 허용가치가 있다. 이 시스템에 대한 이해가 부족한 사람이 오히려 새로운 관점에서 얘기하는 것이기 때문에, 그게 틀린 의견일지언정 넘어갈 수 있다고 생각할 수 있다.


도움 없이도 잘하는 척 = 너무나 위험하다.

신규 입사자가 '자신은 도움 없이도 잘한다'는 잘난척을 하는건 사실 그동안 해왔던 일에 대해 얼마나 견고하고 깊게 했는지를 보면 너무나 쉽게 들통나기 때문에 도움 없이도 잘하는 척을 하려고 애쓰지 말자.

막 입사해 적응할 시기는 오히려 질문/도움에 대한 채널을 찾고 안정감을 확보할 수 있는 시기다.
이 시기에 실수를 안하고 질문을 안하면 점점 더 불안한 회사생활을 할 수 밖에 없으니, 많이 질문하고 실수하는 과정에서 안정감을 얻도록 하자.

💡 정리
'심리적 안정감을 확보했냐?'라는 질문을 역으로 해석해 하자.


더 신나게 일하고 싶은 당신에게: 중기

적응이 끝났다면 일에 몰입해 동료들과 일에 대한 결과를 만드는 중기에 대해 알아보자.

우선순위 조율하기

우리가 실제로 할 수 있는 일의 양은 너무나 물리적 한계가 있다. 그리고 모든 시간을 일에 투자한다고 해서 그게 정말 일이 잘 진행되고 있다고 동일시 할 수 없다. 정말 시간만 쓰는걸수도 있기 때문인데, 이런 관점에서 내게 주어진 시간 내에서 내가 정말 필요한 일을 하고 있는가? 라는 생각이 중요하다고 하셨다.

이걸 위해선 당연히 우선순위를 식별하고 조율하는 역량이 필요하지만, 누군가가 우선순위가 높다고 주장하는 일의 결과가 회사/사용자에 얼마나 기여가치를 하는지 보다 '내가 성과를 낼 수 있는 일'와 같이 개인의 결과에 초점을 맞추고 일의 우선순위를 주장하기 때문에 어려운게 많다.

우선순위 대상을 공동의 결과로 두지 않고 개인의 결과로 두기 때문에 조율이 어렵다.

그래서 보통 사용하는게 긴급도/중요도인데, 두 개념은 명백히 다르다.

  • 긴급하면서 중요한 일 = 즉시 처리
  • 긴급하지 않지만 중요한 일 = 전략 및 일정 수립하기
  • 긴급하면서 중요하지 않은 일 = 위임 혹은 일 축소
  • 긴급하지도 않고 중요하지도 않은 일 = 연기 혹은 취소

💡 간혹 왜 올라오는지 모르겠는 일(긴급X, 중요X)
막상 뜯어보면 이런 경우엔 보통 하고 싶은 일을 가져오는 케이스라고 한다.

실제로 백로그를 놓고 어떤 일을 먼저 해야할지 정할땐 중요도와 긴급도에 대한 정의를 먼저 내려야 한다. 정의가 서로 다른채로 논의하면 의견이 모아지긴 커녕 각기 다른 결과가 나오는 결과가 나올 가능성이 있기 때문이다.

회사에서 공통의 영역으로 개발되는 서비스나 플랫폼을 개발해서 내부 개발자에게 적용하는 팀에서 우선순위를 조율한다고 했을때, 중요도와 긴급도는 다음과 같이 정의할 수 있다.

  • 중요도: 개발자 생산성이 얼마나 오르는가? 얼마나 많은 개발자에게 영향을 주는가?
  • 긴급도: 지금 이걸 (내부 개발자에게 제공) 안하면 얼마나 큰 문제가 생기고, 어디까지 영향을 미치는가?

근데 사실 이렇게 기준이 명확해도 우선순위 조율은 늘 어렵다.

긴급도와 중요도를 판단할 수 있는건, 사실 백로그로 가져온 대상이 되는 일들의 배경을 명확하게 이해하고 있다는 전제가 있어야 한다. 이 일이 '어떤 문제, 현상이 있었기에 해결해야 된다!'라고 이해하지 않으면 긴급도, 중요도를 판별할 수 없다.

근데 되게 많은 사람들이 우선순위를 논하는 자리에 일들을 가져올때 보통 "이거 우리 해야돼" 라고만 하고, 이게 어떤 문제, 현상이 있었고, 어디까지 영향을 끼쳤는지 데이터를 가져온 사람은 극히 드물다.

이런 이유로, 아무리 긴급도, 중요도 같은 기준이 있다 하더라도 그게 워킹하지 않는 케이스는 그 일의 배경을 명확히 이해하지 않은 상태로 왔기 때문에 절대 조율이 될 수 없다.

💡 정리
우선순위를 조율하기 전, 일에 대한 '분명한 문제, 현상, 영향도에 대한 분석'이 있어야 한다.
이런 분석자료가 있어야 이 일이 중요하다고 상대방에게 설득할 수 있다.


제대로 회의하기

회의는 정말 의사결정하는데 중요한 장치지만, '제대로된 회의'를 하지 않기 때문에 피곤한 대상으로 여기기 쉽다. 일을 하는 우리가 회의를 하는 목적은 문제 해결 방법을 같이 모색하기 위함이고, 그 방법 중에서도 어떤 방법으로 해결할지에 대한 의사결정을 하기 위해 진행하는 목적이 제일 크다.

그래서 회의를 주체하기 전에 '이게 정말 필요한 회의인가?'를 생각해봐야 한다.
다시 말하면, 이 회의가 누구한테 필요한 회의인지가 명확해야 한다는 점이다.


명확히 할 수 있는 방법?

주최자는 회의에서 얻고 싶은게 가장 많은 사람이다. 의사결정을 끌어내고 싶은 사람들의 시간을 절약하면서 효율적으로 회의를 진행하려면, 회의 이전에 안건에 대한 배경지식을 비슷한 수준으로 끌어 올려놔야 한다. 이걸 위해 위 사진처럼 자료(ex. 사전분석한 문서)를 사람들에게 각자 봐야할 내용을 전달, 검증 받으며 사전회의록을 만들 수 있다.

결국은 주최자의 노력이 필요한 일이다.

비동기 회의

회의 일정을 잡을때 이게 반드시 한자리에 모여서 동기(synchronize)로 진행되야 할 회의인지 한번 고민해보자. 이로인해 지금 당장 더 중요한 일을 못할 수 있고, 충분히 협업 도구를 통해 비동기로 할 수 있는 경우도 있기 때문이다.

회의 중 주의할 점

  1. 가끔 발언을 많이 하는 사람들이 있다. 되게 의미있는 얘기를 긴시간 해주면 정말 좋지만, 보통 말이 길어지는 경우엔 주제에 벗어나는 경우가 많다. 그래서 주최자(혹은 다른 참여자)는 발언자가 말이 길어진다고 느껴지면 지금 발언이 주제와 벗어나고 있진 않은지 인지하며 끊어주는 역할이 필요하다.

  2. 내가 끌어내고 싶은 사람의 의견이 있을때, 상대의 이점을 기준으로 말해야 설득력이 있다.

    • ❌ "이걸 해야 내가 뭘 할 수 있어"
    • ✅ "이걸 해야 너네에게 이런 이점이 있어"
  3. 회의가 마무리되기 전, 항상 누가 뭘할건지 도출해야 한다. 그렇지 않으면 번복되는 경우가 많고 다들 기억이 희미해져서 다른얘기하는 경우가 많아 의미없는 시간이 될 수 있다. 회의록이 되게 사소해보여서 회의록 정리 및 공유를 미루는 경우가 많은데, 이런 경우 미팅의 효과가 되게 많이 떨어진다. 그러니 가장 기억이 또렷할때 회의를 정리하자.

💡 정리
1. 회의는 정말 중요한 의사결정수단이니 잘 활용하자.
2. 진짜 중요한 일을 놓치지 않도록 효율적인 회의를 하자.


설득에 대한 태도 바로잡기

우리는 일을 하면서 되게 빈번하게 설득하는 일을 경험하지만 매번 쉽지 않다. 아무래도 설득 대상을 분석하려는 노력 없이 내가 하고싶은 얘기만 하기 때문이다. 내가 누군가를 설득하려 할때, 설득 당하는 입장인 상대의 사고 과정은 위 사진과 같다.

조금이라도 관련이 없거나, 도움이 되지 않거나, 신뢰성이 없다면 바로 무시를 하기 때문에 상대를 설득할땐 정말 상대방이 관심이 있는 주제인지, 상대에게 도움이 되는 방향으로 말하고 있는지, 상대에게 내가 해결하고자 하는 방법과 과정이 설득력이 있는지 확인하며 질문을 던져야 한다.

Tim) 설득 과정에서 주어인 '나'를 '상대'로 바꿔 말하는 연습을 해보자.

다음으로는 실제로 설득했던 과정을 예시로 설명해주셨는데, 부가 설명 없이도 충분히 설명이 될 것 같다. 해당 내용에 대한 자세한 설명이 듣고 싶으면 한빛미디어에서 제공하는 VOD를 확인해보자.

https://www.hanbitn.com/product/msa2023-levelup/

'내꺼가 안됐다고? 왜? 어째서?'

지금까지는 설득하는 방법을 말했는데, 사실 설득 당하는 노력 또한 중요하다. 보통 우리는 자신의 의견이 받아들여지지 않고, 상대 의견이 받아들여지면 이를 감정, 경력, 자존심으로 연결시킨다. 사실 '나의 주장'이 아닌 '우리의 주장'으로 생각하면 그렇게까지 상처받지 않을텐데 결국 내 의견, 역량이 채택되지 않았다는 생각으로 가기 때문에 설득 당하는건 되게 어려운 일이다.

누구나 언제든지 더 좋은 의견을 제시할 수 있다는 생각을 해야, 우리팀이 해결해야할 근본적인 해결책에 빨리 도달하게 된다. 그렇기에 그 사람의 배경, 경력과 상관없이 설득당하는 과정이 잘 이뤄지는 팀은 '심리적 안정감'을 가진 조직이라고 볼 수 있다.

이 설득 당하기는 너무 당연하지만 어려운 태도인게, 나도 언제든 틀릴 수 있음을 인정하고 상대방을 이해하려는 태도라는 것이다. 내가 낸 의견에 누가 손들고 반대 의견을 낼때 괜히 팔짱끼고 쳐다보는 것 보다 어떤 의견을 내려는지 경청하려는 태도가 필요하다. 이때 수용되는 의견이 다르더라도 '내 의견이 아닌 네 의견'이라 생각하지 말고, '우리 제품을 위해서는 그 결정이 낫겠다'는 생각으로 전환하려는 노력을 해야된다.

💡 정리
잘 설득하는거 만큼 설득 당하는것도 중요하다. 언제나 내 의견만 수용될순 없고, 오히려 아닌 경우가 훨씬 많다. 그럴때마다 상처받지 말고 오히려 '우리팀에서 더 좋은 결과를 내겠네!' 라는 방향으로 생각해야 된다.
제품을 위해 설득당하는 모습은 동료에게 신뢰를 준다.


평가 활용하기

일의 한 사이클을 돌면 마지막은 항상 평가가 찾아온다. 보통 평가기간을 늘 피곤하게만 생각하는데, 주기적으로 돌아오는 평가기간을 그렇게 보내면 아까우니, 개인의 관점에서 어떻게 잘 활용할 수 있을지 알아보자.

이거만큼 완벽한 회고 기회는 없다. 별도로 시간을 내서 회고하지 말고, 평가 기간이 돌아왔을때 진행하자. 이는 다음 기대치와 목표 설정을 위한 재료를 수집할 수 있는 기회다. 이외에도 다양한 성장 기회를 발견할 수 있는 계기가 되니 잘 활용하자.

본인 평가에 이은 동료 평가다. 본인 평가도 귀찮은데, 동료 평가까지 해야한다니! 사실 이 동료 평가가 랜덤이 아니라, 간접적이라도 업무랑 관련있는 동료를 평가하게 된다. 무엇보다 동료가 일을 잘해야 내 성과에도 긍정적인 영향을 미치니 성장을 위한 피드백을 정성스레 달아주자.

이때 주의점은 비난이 아닌 성장을 위한 피드백이란 점이다.

  • ❌ '이 친구가 그때 만든건 하나도 못쓰고 다 재개발했어'
  • ✅ '그때 그 친구가 코드를 재사용성있게 코드를 짰어야 했을거 같아'

단순히 날이 서있는 비난은 피평가자의 능력이 부족하다고 인식되기 보다는, 오히려 팀 플레이어 측면에서 평가자의 역량을 의심하게 된다. 결국 동료 평가의 과정에서 자신의 역량도 드러난다는 것이다.

이런 의미에서 평가는 서로의 성장을 위한 근거를 만드는 일이므로, 귀찮게 생각하진 말자.


마무리 - 그래서 일을 잘한다는건?

그래서 일을 잘한다는건, 결국 세미나에서 나온 내용을 잘 지키는 것과 동일시하게 볼 수 있겠다.
이번 세미나의 내용을 요약하면 다음과 같다.

  • 내가 하는 일이 회사와 팀에 가치를 제공하는지 답을 할 수 있다면 잘한다고 볼 수 있을 것 같습니다.
  • 팀 플레이어로서 동료들에게 영향을 주는 것
  • 시야를 넓히려고 노력하는 것 (항상 놓친건 없는가? 내 시야가 좁은건 아닌지? 한번씩 의심하려는 시도)
  • 자꾸 공유하고, 자꾸 피드백 받는 과정을 즐기는 것

위 리스트에서는 이번 리뷰글에서 다루지 않은 '그 밖의, 일에 대한 이야기' 파트의 내용도 요약되어 있는데, 해당 파트에서는 강연자분이 '비교적 경험이 적었을때/리더 역할을 맡았을때 직접 보고 겪은 시행착오'를 소개하며 얻어갈 부분을 소개한다. 자세한 내용이 궁금하다면 한빛미디어에서 제공하는 VOD를 확인해보자.

후기

초기에 기대치를 양방향으로 조절하는 과정에서 리더의 피드백을 받으며 내 역량과 회사의 요구가 어떻게 맞물리는지 찾아내는 것, 이후 업무에 대한 우선순위를 조율하고 남들을 설득하는 과정은 마치 퍼즐 조각이 맞을때까지 조각들을 계속 끼우는 시도처럼 보였다. 회사에 입사하면서 펼쳐지는 여정은 이렇게 무한한 퍼즐 조각들을 맞추어 나가는 과정인걸까?

이번 세미나는 아직 카운터에서 퍼즐상자 구매를 망설이고 있는 내게 퍼즐 가이드를 제공하는 듯한 느낌이었다. 굳이 개발자가 아닌 직군의 사람이 들어도 얻어갈게 많을 정도로 어렵지 않으면서 와닿은 부분은 또 많았다. 나처럼 아직 실무 경험이 없다거나, 개발자의 성장과 일잘러로의 레벨업을 원한다면 아래 링크로 들어가 VOD를 확인해보자.

본 포스팅은 moong님의 블로그에 올라온 글을 한빛N이 허락을 받고 게재한 포스팅입니다.

댓글 달기

최신글 더 보기