개발자 역량의 관한 연사 회고

팀 역량 강화

왜 팀의 역량이 중요한가?

• 예전 소프트웨어는 크기가 작고 간단했지만 현대 소프트웨어는 신경쓸것도 더 많아지고 크기도 커지고 있다.
• 그것들을 혼자선 처리하긴 무리가 있기에 팀이라는 조직을 꾸리는것이다.
• 팀 역량이 프로젝트 전체에 역량으로 나타나기 때문에 팀의 역량이 중요하다

무엇이 팀의 역량에 영향을 미치는가?

Psychological safety(심리적 안정)

• 기본적인 여유가 있어야 한다.
• 누구든 좋은 아이디어나 기술이 있다면 의견을 말할 수 있어야하고 비난받지 않을것이라는 확신이 있어야 한다.
• 안정되지 않은 팀은 정체될것이다.

Impact of work(일에 대한 중요성인지)

• 내가 만든 사업이 어디에 어느정도 쓰였고 어떤곳에 긍정적 영향을 미쳤는지 본인이 알아야 동기부여와 자부심과 성취감을 느껴야한다.
• 보상은 금전적인것 뿐만 아니라 사람을 주목시켜주고 칭찬 혹은 대체유가등 좋은 보상이 있으면 역량에 대한 동기부여가 될 수 있다.

Meaning of work(일의 의미)

• 내가 왜 이 사업을 진행하고 어떤의미가 있는지 알아야 한다.

1. 어떻게 팀의 역량을 향상시킬 것인가?
   • 팀의 리더는 성장 경로를 제시해주어야한다.
   • 근무시간의 일부는 역량 개발에 쓸 수 있도록 해야한다.
2. 어떻게 팀의 역량을 측정할 것인가?
   • 팀의 자격증 갯수나 근무시간으로 가지고 평가하지 않아야 한다.
   • 면담을 자주해서 본인의 역량을 파악할 수 있다.

• 스타트업에 경우 일정에 문제, 자본의 문제들로 체계들을 갖출수 없는 회사들이 많지만 팀내에서는 더욱 motivation을 이끌어내야한다.

DEV PROCESS

• 개발만 잘한다고 일을 잘하는것은 아니다.
• 모든 개발 주기에 대한 역량이 필요하다.
• 풀스택 개발자가 아닌 풀프로세스 개발자가 팀에 역량을 끼친다.

개인 역량 강화

• 각각의 연차에 따라 중요시 하는 기술들이 달라지게 된다.
• 대부분의 개발자는 프로그래밍과 알고리즘만 공부하는데 아키텍처나 소프트웨어 방법론에 대한 기술도 중요하다.
• 연차가 높아질수록 Soft Skill도 중요시 되는데 커뮤니케이션, 팀 매니지먼트, 동기부여가 해당된다.
• 모든 기술을 도입할때 기본적으로 이 기술은 왜 만들어졌고, 왜 사용하는지, 기존의 기술과 어떤점이 다른지, 이 기술은 어떤 장점과 단점이 있는지 파악하고 어떻게 사용하는지 파악 후 사용하니 어떤점이 문제인지 파악해야한다.
• 개인의 역량은 회사에서 컨텐츠를 얻을 수도 있지만 그것을 실천하는건 오직 개인의 책임이다.
• 시간날때 역량을 강화하는것이 아니라 시간을 내서 역량강화에 노력해야한다.
• 모든것은 기록하고 시간을 나눠서 실용적으로 사용하라
• 어떠한 기술에 대해 말로 막힘없이 설명할 수 있어야 나의 기술이 되는것이다.

CLOUD & MSA & DDD

Cloud

• 클라우드를 클라우드 처럼 사용하고 있는지 확인해야 한다.
• 대부분의 온프로미스와 같은 맥락으로 사용하고 있지만 클라우드의 장점을 파악해 온프로미스와 다른 장점을 가진 클라우드를 사용해야 한다.

MSA

• MSA는 프로젝트의 크기가 거대해지고 배포나 협업에 대해 어려움이 나타날때 각각의 서비스별로 필요한 부분만 분리시켜야 한다.
• MSA는 분리할수록 비용이 커지기 때문에 분리가 필요한 부분만 분리해야한다.
• 프로젝트에 성질에 따라 모놀리식 아키텍쳐가 더 좋을수도 있다.

DDD

• 비지니스팀과 개발팀은 같은 언어, 단어를 사용하고 이해도가 같아야 한다.
• 비지니스 전체에 대한 컨텍스트 바운드를 설계해야한다.
• 컨텍스트 바운드 설계는 개발자만으로는 절대 불가능하고 기획자가 필수로 참여해 같이 설계해 나가야 한다.

그 외의 말

• 비지니스팀과 개발팀은 매우 가까워야하며 함께 의논이 가능할 정도로 지식 공유가 되어야 한다.
• 비지니스팀에서 개발팀으로 기능 요구를 받으면 명세서를 작성하고 그 명세서에는 어떠한 식으로 기능을 구현할지 참과 거짓을 판단할 수 있는 문장으로 작성해야하며 그것을 비지니스팀에 확인을 받은 후 진행하는것이 좋다.
• 모든 명세서를 작성하고 진행중에 요구사항이 변경될 시 2차 업데이트로 넘어가 진행하는것이 좋다.
• 서로에 대한 나쁜 피드백을 좋게 전달하는것이 좋은 커뮤니케이션이다.
• 비지니스팀은 개발팀이 조금 더 일하고 조금 더 노력하면 모든 가능할것이라고 착각한다, 하지만 개발팀은 한정적인 자원이란걸 일깨워주어야한다.
• 개발이 재미없어질땐 레드싸인이다.

나의 느낀점

좋았던점

• 팀, 개인, 역활에 대한 역량을 어떻게 끌어올릴지 힌트가 되었던것 같지만 오늘들은 말씀대로 팀과 개인, 역활에 대해 실천이 되려면 회사에 역활도 중요하단걸 알수있었다.
• 개인의 역량에 대해 더욱 노력해야한다는 동기부여가 되었다.
• 카이아이에 대입해보고 현재의 문제점들은 많이 느낄 수 있었다.

아쉬운점

• 안정적이고 여유있는 기업 배경에서 가능한것들을 설명을 해주신 것 같다.
• 현실적으로 저 체계들을 잡아나갈수 있는 회사들이 몇이나 될까 의문이 들었다.

피드백 -> 많은것을 한번에 바꾸려 하지말고 천천히 하나하나 차근차근 바꿔나가야한다.