테크 리더들이 생각하는 "개발자 원칙"

 

 

필자는 학습 루틴이 느슨해지거나, 나태해질 때 쯤 우아한 테크 Youtube 채널을 들어가 신입 개발자 분들의 10분 테코톡을 보면서 요새 궁금해하는 키워드들이 무엇인지 탐색해보곤 한다. (이와 동시에 공부하기도 한다.)

 

그 중에서도 주기적으로 진행하는 컨텐츠, 우아한 테크 세미나는 현업 개발자 분들의 스피치 및 인터뷰로 짧은 시간 안에 양질의 테크 트렌드와 이직 시장 분위기를 파악할 수 있어 애청하는 편이다.

 

지난 3월, 우아한 형제들에서 진행하는 우아한 테크 세미나 라이브 스트리밍을 시청한 적이 있는데 요즘의 무기력한 자신을 돌이켜 보며 당시 메모했던 내용을 복기하며 포스팅을 올려본다.

 

특히 자주 접하던 네임드 개발자 분들의 질의응답 인터뷰가 인상적이었는데, 7개월이 지난 지금 내용을 곱씹어 보니 그때와 지금의 내 마음가짐과 현업에 대한 나의 인식이 어떻게 다른지 생각해보게 되었다.

 

 

 

 

 

제어할 수 없는 것에 의존하지 않기 - 인프랩 이동욱

프로그래머에게 요구되는 것은 100점이 아닌 80~90점짜리 프로그램을 기한 내에 완성하는 일이다.
- 나카지마 사토시, [오늘, 또 일을 미루고 말았다]

• 연구원이 아닌 프로덕트 엔지니어의 일은 고객이 원하는 기능을 고객이 원하는 시점에 전달하는 것
• 즉, 일정 > 퀄리티? ⇒ 아무리 급해도 항상 80~90점짜리 소프트웨어를 일정 내 개발할 수 있는 방법
• 일정을 항상 잘 지키는 분들의 공통점
  • 본인만의 기준과 원칙으로 빠르게 결정 (경험)
  • 선택의 순간마다 고민하는 사람 vs 원칙에 따라 빠르게 결정하고 중요한 것만 고민하는 사람
  • 좋은 코드를 결정하는 방법이 최신의 영감에 따라 움직이지 않음
• 힘든 개발자 시장에서 회사 입장에서 제어할 수 있는 것 : 개발문화/프로세스에 대한 변화
• 제어할 수 없는 것에 거리두기 + 제어할 수 있는 것에 집중하기

 

나의 생각

 

위 내용에 적극적으로 동감한다.

 

6년 차 개발자로 일하면서 때로는 내가 이직을 하거나 환경을 바꾸지 않는 이상 바꿀 수 없는 요소들이 더러 있다. 예를 들어, 내가 일하고 있는 회사의 사업 카테고리라던가, 주요 결정권자들의 업무 지시 방식 등 개인의 노력만으로는 바꾸기 쉽지 않은 부분들은 아무리 수평적인 관계인 조직이더라도 어디에나 있기 마련이다.

 

개발자로 일하면서 문제를 발견하고 즉각적으로 업무 효율을 개선해나갈 수 있는 것들이 무엇인지 고민하는 것. 이 요소에 대한 유무는 앞으로 개발자 생태계를 살아감에 있어서 현명하게 커리어를 결정하고 나아갈 수 있는 큰 원동력이 될 것이라 생각한다.

 

또 이런 방향성을 개발자들과 공유하면서 고리타분한 생각은 걷어내고, 도움이 될 만한 방향으로 성장하는 것이 중요할 것 같다. 

 

Q&A

 

Q. 유연성 있게 성장할 수 있는 개발 방법이나 습관

• 박미정 : 내가 작성했던 코드를 다시 작성하는 것 (확장성, 시스템 설계 등)
• 이동욱 : 주니어 때부터 연습해야하는 부분인데 내가 틀렸다고 인정 하는 것
• 박성철 : 소프트웨어 개발자로 성장하는 과정을 즐기는 것. 어느정도 수준에 다달아야 하고, 그 부분을 즐기는 것.

 

 

 

 

 

Q. 좋은 리더십과 좋은 피드백을 주고받는 방법

• 박미정
  • 팀원 한 명 한 명에 맞는 피드백을 주려고 함
  • 팀원 한 명 한 명을 깊게 관찰하고 염탐(?)한다
  • 어떻게 일을 하는 사람이고, 문제에 어떻게 행동을 보이는 사람인지 계속 트랙킹
    • 어떤 성향의 사람인지 알고싶어서
    • 슬랙에서 메시지를 주고받는 뉘앙스까지 관찰
• 이동욱
  • 일기를 쓴다
    • 누가 이런걸 했다, 회의 때 이런 걸 했다
    • 피드백을 줘야되는 것이 생겼을 때, 조금 빠르게 주는 편
      • 내가 생각하는 게 맞나? 생각하고 금주 내에 피드백 주는 편
  • 전사적으로 하는데 회의를 모두 녹음
    • 녹음을 듣고, 셀프 피드백을 하도록 함
• 박성철
  • 각자의 특징을 수용하고, 각자가 잘하는 일을 할 수 있는 상황을 만드는 데 노력
  • 교정 피드백(고치는 것)을 하지 않고, 잘 하는 부분을 더 잘하게끔 상황을 만드는 노력을 함
  • 하지만 이 부분이 한계를 넘어서는 경우, 미안하지 않으려 노력
  • 그저 안 맞는 것일 뿐 그 사람의 잘못이 아님
  • 회사 안에서 맞는 조직을 찾아 제안해준다던가, 안 맞는 부분에 대해 그 사람을 바꾸려고 노력하지 않음

 

나의 생각

 

세 분의 답변 모두 내 뇌리를 관통하는 답변이어서 많은 생각을 하게 되었다.

 

필자도 부사수가 고민스러워하는 부분을 물어오거나 코드 리뷰를 진행할 때마다 적절한 피드백이 무엇일지 고민한다. (이 부분은 앞으로도 항상 고민스러울 것 같다.)

 

박미정 리더님의 방법은 긴 시간동안 팀원들을 지켜봐야 하는 동시에 긴 시간이 필요하므로 피드백을 주기에 가장 정통적 방법이지만 가장 쉽지 않은 방법일거라 생각한다. 조직에서의 시간은 돈이다. 물론 단시간에 사람을 꿰뚫어 볼 줄 아는 혜안을 가진 리더들은 충분히 좋은 방법이라 생각하지만 그 누구에게나 통용하는 방법은 아니라 생각한다.

 

혼자만이 아닌 여러 사람들의 시간을 덜어주기 위해서는 즉각적인 피드백. 이보다 더 지혜로운 방법은 없다. 혹여 그 피드백이 옳은 방식이 아니더라도 이 부분이 노출되는 것 자체에서 개선의 여지가 있다. 팀원간의 잦은 의사소통은 업무 효율에 도움이 될 수 밖에 없다.

 

 

 

 

Q. 팀원들이 성장에 대한 니즈가 많이 없어 보이면 어떻게 불어넣을까?

• 박성철
  • 일이 재밌으면 성장하고 싶어진다
  • 근본적으로 자기 실현에 대한 욕구가 없는 사람은 한 명도 없다
  • 그것을 발현하지 못하게 봉인한 것이 문제, 이것을 열어주는 것이 좋다
  • 성취할 수 있는 경험을 조금씩 해 나가면 좋지 않을까?

 

 

나의 생각

내가 일하고 있는 조직 내에서도 간간히 (특히, 업무가 일정에 치여 바쁘게 흘러갈 때) 개발자들이 무기력감에 휩싸일 때가 있다. 자발적으로 분석하고, 설계하고 개선해나가는 분위기라기보다 위에서 정해진 틀에 맞추기 위해 수동적으로 개발을 하게 되는 경우 특히 그렇다. 일이 항상 재밌을 수는 없을 것이다. 리더가 개발자들에게 동기 부여를 줄 수 있도록 고민하는 것도 좋지만, 개발자들이 자발적으로 작은 성취라도 이룰 수 있도록 의사 표현을 하는 것도 중요하다고 생각한다.

 

올 해 팀장님과 그룹장님과 함께 성장의 환경을 만드는 방법에 대한 토론을 진행한 적이 있다. 성장 의지가 없는 후배를 적절한 타이밍에 이끄는 방법에 대한 것도 고민하는 주제였다. 성과에 대한 칭찬과, 더 잘하고 싶어지는 환경을 만들기. 올 한 해를 솔선수범으로 채우고자 했던 초심을 떠올릴 수 있었다. 경험주의자의 시간은 헛되지 않았다.

 

 

 

 

Q. 실패와 번아웃, 무기력함을 경험한 적이 있는지?

• 박성철
  • 스트레스 관리 - 심리학에서 스트레스를 기피해야 하는 것으로 여겨서 심리학을 싫어한다
  • 디스트레스와 유스트레스를 구분
    • 유스트레스 : 활력을 얻고, 더 잘하고 싶어지게 만드는 상태
    • 디스트레스 : 과해서 견딜 수 없게 되는 상태 ⇒ 정도를 넘어가면 번아웃으로 직결
  • 내가 자신감이 넘치면 유스트레스의 범위가 넓어진다
  • 자신감이 없으면, 조금만 스트레스가 쌓여도 디스트레스가 되어버린다
  • 자신감을 회복하고, 도전하고 해낼 수 있다는 생각을 스스로 만들 수 있게 만드는 게 중요
  • 내가 하는 건, 이불을 개는 것. 즉, 아주 작은 성취를 하고 이를 통해 뿌듯해 하는 것
  • 이로 인해 더 많은 일을 도전하고, 재밌게 할 수 있게 된다.

 

 

나의 생각

 

개발자를 떠나서 모든 직장인들이 공감할 수 있는 내용. 스트레스는 직장 생활에서 뗄 래야 뗄 수 없다. 그 스트레스 상황을 어떻게 해석하고 나아가는지에 대한 아주 좋은 인사이트라 생각한다.

적당한 긴장감과 스트레스는 성장의 재료가 된다. 작은 성취를 습관적으로 해 온 사람이라면 스트레스는 긍정적인 선순환으로 이어질 수있다.

 

 

 

Ref.

[우아한테크세미나] 테크 리더 3인이 말하는 "개발자 원칙"