2024-10-26 스프링 사용자 모임(KSUG) 가을 세미나 후기(2)- 패널토크

TLDR

• 2024-10-26 한국 스프링 모임(KSUG)에서 주최한 가을 세미나에 다녀왔다. (https://www.inflearn.com/course/offline/ksug-seminar-2024#program)
• https://yeoon.tistory.com/175 연사에 발표에 이어 패널토크를 기록했다.

 

개발자에게 성과란?

• 성과에 대해 말할때 기여와 성과를 구분해야한다. 본인이 수행한 일 자체가 아니라 본인이 한 일이 가져온 비즈니스 가치가 성과다.
  • 기여 : 비즈니스 목표 달성에 기여 (ex. API 성능을 높였다. 개발 부채를 개선했다.)
  • 성과 : 비즈니스 가치의 결과 (ex. API 성능을 높여 구매 전환이 00만큼 일어나 매출 달성에 기여했다.)
• 개발자 개인에게 성과는 역량이 있다.
  • 역량(장기) : 경험을 통해 쌓아가는 자산 → 나의 개발실력
  • 성과(단기) : 노력, 열심히 해도 안나올 수 있는 것
• 개인차원에서 성과는 연봉이다.
  • 높은 자존감 : 좋은 직급, 좋은 회사 이직, 연봉의 상승
  • 외부 평가 성과 : 전략적으로 비즈니스 영향 많이 주는 일을 해서 좋은 평가 → 승진 -> 연봉의 상승

 

개발자 성과의 측정하는 방법

• 조직의 목표가 명확하게 있어야한다. (숫자로 표현되면 이상적)
• 조직의 목표와 부합한 성과가 성과이다. 목표가 있어야 달성여부를 측정할 수 있다.
• 스타트업의 대부분은 망한다(95%).
  • 망하는데 C-level에서 제대로 된 목표를 설정했다고 신뢰할 수 있을까?
  • 소프트웨어는 100% 인건비다. 리드타임, 일정 관리가 제대로 된 성과다. 
• 성과를 측정하는 이유
  • 보상, 인센티브를 위해서

 

유연한 설계란?

• 콘웨이 법칙 → 조직의 모습 설계/구축이 잘된 모습
• 대부분 회사가 공통적으로 가장 중요한 시스템이 가장 큰 레거시이다.
  • 항상 급하고, 요구사항이 많아 괴물 같은 레서시 시스템이 된다.
• 괴물 같은 모습이 되지 않도록 구성원 간 약속, 복잡도에 대한 경계가 중요하다.
• 개발 생산성이 떨어지지 않는 설계
• 현대 시스템에서 아키텍처의 문제에 사람 심리를 뺀 것이 문제다.
  • 설계가 유연한지 아닌지는 사람의 심리적인 문제
  • 사람의 심리적인 장벽이 아키텍처의 가장 큰 문제 (예를 들어 spring 개발자를 채용해서 PHP를 유지보수 하라고 하면 싫어할 것이다. 설계가 좋아도 사람이 해당 설계가 싫을 수 있다.)
  • 최대한 작게, 작게 쪼개서 만들고 언제든지 버릴 수 있게 만들어야 한다.
    • 언제든 새로 만들수 있게 가볍게 만들기
    • 버리기 쉬운 아키텍처 선택하기
  • 버리기 쉬운 아키텍처가 유연한 설계이다. 시스템은 줄어들 수도 커질 수도 있다.
• 유연한 설계는 복잡한 설계와 같은 말이다. 유연함과 복잡도 사이에서 최선을 찾는 것이 유연한 설계이다.
  • 설계가 계속 망가지고, 지속적인 개선이 필요하다. 끊임 없는 리팩토링
  • 복잡해지는 이유는 어떻게 변경 될지를 모르는 것
    • 비즈니스를 최대한 멀리 봤을때(1달 ~ 6달)까지를 기준점으로 잡고 설계 시작하고, 바꿔나아간다.

 

엔지니어 리더의 소양은?

• 엔지니어 리더는 사측과 노측을 연결하는 가교 역할 수행
  • 노측 입장에서의 개발자의 만족도 : 좋아하는 것 시키기
  • 사측 만족도 : 일정 관리 (소프트웨어는 100% 인건비 → 빠르게 개발만 하면 회사의 이득)
• 회사는 리더 될 사람을 잘 평가할 수 있다고 착각하고 있다.
• 리더가 하고 싶은지 물어보고 리더를 하고 싶은 사람을 시키는 것이 가장 좋은 방법이다.
  • 좋아하는 일, 하고싶어하는 일 ⇒ 자기주도적으로 하는 사람이 보여줄 수 있는 퍼포먼스는 엄청나다.
  • ex) 평소 바라고 기대하던 리더상이 있던 사람에게 리더를 시키는 경우 -> 리더상의 실현
• 매니징, 코딩을 분리하지 않은다. 소프트웨어 개발 전체 과정을 코딩으로 본다.
  • 하고 싶어하는 사람, 그것을 즐기고 좋아하는 사람이 하는 것이 중요하다.

 

주니어/미들/시니어 역할과 책임?

• 회사마다 정의가 다르다.
• 구글 엔지니어링의 레벨 같은 것 찾아보면 명확하게 정의되어 있다.

 

 

수많은 이기심이 회사의 성공을 가른다. C-level에게 사측 고민을 미루고 내 개인에 집중하자.

 

패널님들