상황을 파악하는 메타인지
상황을 정확히 파악하는 메타인지
우리는 어떤 작업을 할 때 상황을 정확히 판단하기 위해 메타인지가 필요하다.
시니어는 비즈니스와 기술의 접점을 최대한 판단하면서, 상황을 최대한 빠르게 정리하기 위한 기술적 메타인지가 필요하다.
비즈니스와 생산성
비즈니스: 회사에서 실제로 돈을 벌게 도와주는 개발자로써의 임무
생산성: 코드 퀄리티, 즉 생산성 수치가 높아질수록 비즈니스 코드 작성이 유연해지고 빨라짐
비즈니스와 생산성 모두 중요하지만, 가장 중요한 것은 "비즈니스를 통해 회사가 살아남는것"
비즈니스가 더 중요하고, 생산성에 시간을 할애할 수 없다면 과감하게 생산성을 포기하고 때마다 새로 작성하는게 낫다. (리팩토링은 밥먹듯이)
비즈니스가 급한데, 여러 도메인의 프로젝트가 들어오는 경우
생산성을 고민할 수 있는데, 여러 도메인의 프로젝트가 들어오는 경우
메타인지가 되었다면
어느곳이든 비즈니스를 제외하고 생산성을 챙길 수 있는 회사는 없다.
현재 인원 규모에 맞춰서 비즈니스와 생산성을 구별하고 인원 배치가 필요하다.
인원배치가 어렵다면 동시에 작업을 하든, 개선은 해야할 상황(정말 어렵다면 차세대 등의 방법도 있다.)
팀 내부적으로 어떤 부분이 어렵고 비즈니스를 개발하게 어렵게 만드는지 측정이 되었다면 다음 단계로 넘어갈 수 있다.
팀이 지금 처한 상황과 개발하는 것의 목표를 조화롭게하여, 목표를 이루는 것이 시니어 개발자이며, 리드이다.
비즈니스는 단순한 일부터 복잡한 일까지 여러가지가 있지만, 이또한 성과와 개발자의 흥미등 여러가지를 복합적으로 이해하고 업무를 분장해야하며, 성장에 대한 부분까지 고민하면서 팀의 기술 목표를 만들어야 한다.
단일 프로덕트가 성장하면서 발생하는 문제들
모든 회사의 시작은 하나의 작은 프로덕트로 시작됨
회사가 성장을 하면서 여러 필요한 코드가 생기고, 해당 코드를 적재하기 위한 대다수의 비슷한 아키텍처를 사용한다.
e.g) Container & Presentational Pattern, Atomic Design Pattern,
가장 단순하게 비즈니스 로직과 레이아웃 로직을 분리하고, 레이아웃 로직도 계층별로 나눠서 관리
n년뒤, 여전히 단순한 코드로 비즈니스를 모두 개발할수 없게된다.
Container - Presentationl의 쌍은 합쳐 몇백개가 넘어가고 Atomic Design에 atoms는 100개가 넘어가는 상황 발생
더불어 프로덕트도 어드민, 모바일 등 추가가 된 상황
시간이 지나면서 생기는 비대해진 코드의 문제와 새로운 프로덕트의 등장
개발자는 코드를 계속 작성하게 되고, 시간이 지날수록 코드는 비대해진다.
코드가 비대해지므로써 중복 코드와, 레거시 코드가 많아져 생산성이 줄어든다. 그에 따라 운영에서의 문제가 발생
회사는 새로운 사업과 인원을 충원하며, 그에따라 소프트웨어의 수도 많아진다.
예를 들어 새로운 사업을 하게 되면, 새로운 페이지와 새로운 소프트웨어가 생기게 된다.
그에따른 신규 프로덕트 구축으로써의 문제
문제 파악을 통해 상황 진단하기
1) 신규 프로덕트가 추가된 경우
기술 스택은 어떻게?
유지보수 인원이 적은 경우 - 높은 확률로 이전 기술 스택을 유지하는게 생산성에 큰 도움이됨
유지보수 인원이 많은 경우 - 이전 기술 스택이 생산성에 문제가 있거나 하는 경우 새로운 기술 스택 고려
기술적으로 챌린지가 없는 경우 - 생산성을 떠나, 현재 팀원의 사기를 고양시킬 목적으로 새로운 기술을 도입할 수 있음
빠르게 개발되어야 하는 경우 - 이전 기술 스택을 유지하여 코드를 빠르게 붙여 넣을 수 있는 작업을 진행하여 생산성을 보장
교집합의 코드는 어떻게 운영?
여러 프로덕트가 생기다보면, 여러 프로덕트에서 공통으로 필요한 코드를 추가하는 경우가 존재,
해당 코드를 관리하기 위해
npm library를 만들 수 있고, 단순히 폴더로 분리해서 사용할 수 있다.npm library가 필요한 경우 - 코드가 빈번하게 수정될 수 있는 유지보수성 업무가 많은 경우 사용되어야함
빈번히 수정되어도 버저닝이 되므로, 버전에 따라 마이그레이션을 하고, 마이그레이션 후 영향범위를 수정만 하면 됨
필요 없는 경우 - 코드가 빈번히 수정되지 않는 constant 등의 레벨이거나 정말 긴급한 상황이고 적은 인원이 개발한다면 교집합 코드는 별도의 폴더로만 추출되어 사용할 수 있다.
배포 프로세스는 어떻게?
기존 프로젝트와 동일하게 갈지, 아닐지 선택
프로젝트에 SEO를 사용하거나, SSR 등의 CPU Intensive 한 작업이 필요한 경우 - 노드 서버 기반의 인프라 스트럭처를 그리고, 배포 방식을 서버 배포 형태로 구축
단순 어드민 서비스인 경우 - Route53 - Cloudfront - S3 형태로 간단히 구축, 이 방법은 운영 리소스가 적거나 빠르게 개발되어야 하는 경우 유용
인원은 어떻게 배분?
회사의 업무 방식에 따라 다름
회사의 업무방식이 어드민, 서비스 따로 운영되는 경우 - 이 경우 서비스별로 담당자를 지정
다만, 이 경우 각 서비스에 배정된 인원이 성장 혹은 흥미를 잃을 수 있기 때문에 로테이션 정챌을 정해야 한다.
회사의 업무 방식이 애자일 형태로 피쳐 단위로 나오는 경우 - 이 경우는 피처 별로 담당자를 정해서 관리
가장 좋은 방식은 페어 형태의 개발 방식, 이는 실제로 리소스가 많이 들기에 어려울 수 있다.
2) 프로덕트의 성장으로 코드가 과다해지는 경우
코드 분리를 어떻게 할것인가?
기존 코드에서 코드 분리가 필요한 기준을 마련
예를 들면, 한 폴더에 10개 이상의 파일을 두지 않는다던지
하나의 도메인에 몰려있다면, 하나의 도메인을 잘게 쪼갤 수 있다.
e.g) 배달의 민족 주문 내역이라면, 주문 내역 수많은 상태 떄문에 코드가 여러벌 있을 수 있는데, "주문내역"으로만 퉁 쳐져있는 것을 "배달중/배달완료/배달전"등으로 도메인 단위 폴더링을 쪼갤 수 있다.
코드를 분리하는 과정에서 폴더의 하이어라키 뎁스가 깊어진다면 더 단순한 폴더 형태를 민해야 한다.
Next.js의 App Router 형식과 Page Router 형식을 참고
커다란 프로젝트의 경우 App Router 형식이 적합할 수 있음(추상화)
과제에 따른 업무 분담을 어떤 방식으로 진행할 것인가?
프로덕트의 성장으로 코드가 과다해져 리팩토링을 진행해야 하는데, 리팩토링을 하는 시간이 어려울 수 있음
유지보수 인원의 여유가 있는 경우 - 최소한의 SUS만 진행할 수 있는 인원을 최대한 리팩토링으로 리소스를 빼내고, 다른 담당자들이 비즈니스를 커버해야 함
유지보수 인원의 여유가 없는 경우 - 아키텍처를 정해두고 추후 비즈니스가 적어지면 그 때 리팩토링 시도
메타 인지에 도움을 주는 요소
비즈니스 현황
비즈니스의 진행 방향, 속도, 진척률 등을 체크하여 앞으로 과제가 무엇이 있는지 대략적으로 파악한다.
이후 파악된 것을 바탕으로 미래 계획을 설계하고, 팀원들에게 전파하므로 예측가능한 상황으로 만든다.
팀원
현재 팀원(프론트)의 개발 역량 및 속도 그리고 휴가 현황등을 파악
작업이 진행되려면 팀원의 정보를 알고 있어야 하며, 비즈니스 현황과 더불어 일을 진행시키는데 가장 중요한 체크리스트 중 하나
아키텍처
이전의 아키텍처와 이후의 아키텍처의 차이를 체크하여, 비즈니스 현황에 맞춰 개선 phase를 분리하고 미래에 대해서 구축할 수 있도록 설계를 진행해야 한다.
아키텍처 관점에서 우리가 어느정도로 인원에 비해 낮은 수준 혹은 높은 수준의 설계가 되어있고 인원이 효율적으로 업무하는지 체크할 수있다.
리더쉽
비즈니스 현황과 팀원의 정보를 모두 쳋크하고, 아키텍처를 훌륭하게 만들어도 정작 팀원들과의 유대관계등이 존재하지 않는다면 동작하지 않을것이다.
주기적으로 팀원들과의 교류를 통해 앞으로 나아가고자 하는 것이 무엇이고 어떤 도움이 필요하며 무엇이 좋은지 등의 이야기를 해야 한다.
또한 개인적인 친밀감을 만드는 것도 굉장히 중요한 일
Last updated