# 상황을 파악하는 메타인지

## 상황을 정확히 파악하는 메타인지

* 우리는 어떤 작업을 할 때 상황을 정확히 판단하기 위해 메타인지가 필요하다.
* 시니어는 비즈니스와 기술의 접점을 최대한 판단하면서, 상황을 최대한 빠르게 정리하기 위한 기술적 메타인지가 필요하다.

### 비즈니스와 생산성

* **비즈니스**: 회사에서 실제로 돈을 벌게 도와주는 개발자로써의 임무
* **생산성**: 코드 퀄리티, 즉 생산성 수치가 높아질수록 비즈니스 코드 작성이 유연해지고 빨라짐

***

* 비즈니스와 생산성 모두 중요하지만, 가장 중요한 것은 **"비즈니스를 통해 회사가 살아남는것"**
* 비즈니스가 더 중요하고, 생산성에 시간을 할애할 수 없다면 과감하게 생산성을 포기하고 때마다 새로 작성하는게 낫다. (리팩토링은 밥먹듯이)
* <mark style="color:orange;">비즈니스가 급한데, 여러 도메인의 프로젝트가 들어오는 경우</mark>
* <mark style="color:orange;">생산성을 고민할 수 있는데, 여러 도메인의 프로젝트가 들어오는 경우</mark>

### 메타인지가 되었다면

* 어느곳이든 비즈니스를 제외하고 생산성을 챙길 수 있는 회사는 없다.
* 현재 인원 규모에 맞춰서 비즈니스와 생산성을 구별하고 인원 배치가 필요하다.
* 인원배치가 어렵다면 동시에 작업을 하든, 개선은 해야할 상황(정말 어렵다면 차세대 등의 방법도 있다.)
* 팀 내부적으로 어떤 부분이 어렵고 비즈니스를 개발하게 어렵게 만드는지 측정이 되었다면 다음 단계로 넘어갈 수 있다.
* 팀이 지금 처한 상황과 개발하는 것의 목표를 조화롭게하여, 목표를 이루는 것이 시니어 개발자이며, 리드이다.&#x20;
* 비즈니스는 단순한 일부터 복잡한 일까지 여러가지가 있지만, 이또한 성과와 개발자의 흥미등 여러가지를 복합적으로 이해하고 업무를 분장해야하며, 성장에 대한 부분까지 고민하면서 팀의 기술 목표를 만들어야 한다.

### 단일 프로덕트가 성장하면서 발생하는 문제들

* 모든 회사의 시작은 하나의 작은 프로덕트로 시작됨
* 회사가 성장을 하면서 여러 필요한 코드가 생기고, 해당 코드를 적재하기 위한 대다수의 비슷한 아키텍처를 사용한다.&#x20;
  * e.g) Container & Presentational Pattern,  Atomic Design Pattern,
  * 가장 단순하게 비즈니스 로직과 레이아웃 로직을 분리하고, 레이아웃 로직도 계층별로 나눠서 관리
* n년뒤, 여전히 단순한 코드로 비즈니스를 모두 개발할수 없게된다.
  * Container - Presentationl의 쌍은 합쳐 몇백개가 넘어가고 Atomic Design에 atoms는 100개가 넘어가는 상황 발생
  * 더불어 프로덕트도 어드민, 모바일 등 추가가 된 상황

***

* 시간이 지나면서 생기는 비대해진 코드의 문제와 새로운 프로덕트의 등장
* 개발자는 코드를 계속 작성하게 되고, 시간이 지날수록 코드는 비대해진다.
  * 코드가 비대해지므로써 중복 코드와, 레거시 코드가 많아져 생산성이 줄어든다. 그에 따라 **운영에서의 문제가 발생**
* 회사는 새로운 사업과 인원을 충원하며, 그에따라 소프트웨어의 수도 많아진다.
  * 예를 들어 새로운 사업을 하게 되면, 새로운 페이지와 새로운 소프트웨어가 생기게 된다.
  * 그에따른 **신규 프로덕트 구축으로써의 문제**

### **문제 파악을 통해 상황 진단하기**

* 1\) 신규 프로덕트가 추가된 경우
  * 기술 스택은 어떻게?&#x20;
    * **유지보수 인원이 적은 경우** - 높은 확률로 이전 기술 스택을 유지하는게 생산성에 큰 도움이됨
    * **유지보수 인원이 많은 경우** - 이전 기술 스택이 생산성에 문제가 있거나 하는 경우 새로운 기술 스택 고려
    * **기술적으로 챌린지가 없는 경우** - 생산성을 떠나, 현재 팀원의 사기를 고양시킬 목적으로 새로운 기술을 도입할 수 있음
    * **빠르게 개발되어야 하는 경우** - 이전 기술 스택을 유지하여 코드를 빠르게 붙여 넣을 수 있는 작업을 진행하여 생산성을 보장
  * 교집합의 코드는 어떻게 운영?
    * 여러 프로덕트가 생기다보면, 여러 프로덕트에서 공통으로 필요한 코드를 추가하는 경우가 존재,
    * 해당 코드를 관리하기 위해 `npm library` 를 만들 수 있고, 단순히 폴더로 분리해서 사용할 수 있다.
    * **npm library가 필요한 경우** - 코드가 빈번하게 수정될 수 있는 유지보수성 업무가 많은 경우 사용되어야함
      * 빈번히 수정되어도 버저닝이 되므로, 버전에 따라 마이그레이션을 하고, 마이그레이션 후 영향범위를 수정만 하면 됨
    * **필요 없는 경우** - 코드가 빈번히 수정되지 않는 constant 등의 레벨이거나 정말 긴급한 상황이고 적은 인원이 개발한다면 교집합 코드는  별도의 폴더로만 추출되어 사용할 수 있다.
  * 배포 프로세스는 어떻게?
    * 기존 프로젝트와 동일하게 갈지, 아닐지 선택
    * **프로젝트에 SEO를 사용하거나, SSR 등의 CPU Intensive 한 작업이 필요한 경우** - 노드 서버 기반의 인프라 스트럭처를 그리고, 배포 방식을 서버 배포 형태로 구축
    * **단순 어드민 서비스인 경우** - Route53 - Cloudfront - S3 형태로 간단히 구축, 이 방법은 운영 리소스가 적거나 빠르게 개발되어야 하는 경우 유용
  * 인원은 어떻게 배분?
    * 회사의 업무 방식에 따라 다름
    * **회사의 업무방식이 어드민, 서비스 따로 운영되는 경우** - 이 경우 서비스별로 담당자를 지정
      * 다만, 이 경우 각 서비스에 배정된 인원이 성장 혹은 흥미를 잃을 수 있기 때문에 로테이션 정챌을 정해야 한다.
    * **회사의 업무 방식이 애자일 형태로 피쳐 단위로 나오는 경우** - 이 경우는 피처 별로 담당자를 정해서 관리
      * 가장 좋은 방식은 페어 형태의 개발 방식, 이는 실제로 리소스가 많이 들기에 어려울 수 있다.
* 2\)  프로덕트의 성장으로 코드가 과다해지는 경우
  * 코드 분리를 어떻게 할것인가?
    * 기존 코드에서 코드 분리가 필요한 기준을 마련
    * 예를 들면, 한 폴더에 10개 이상의 파일을 두지 않는다던지
      * 하나의 도메인에 몰려있다면, 하나의 도메인을 잘게 쪼갤 수 있다.
      * e.g) 배달의 민족 주문 내역이라면, 주문 내역 수많은 상태 떄문에 코드가 여러벌 있을 수 있는데, "주문내역"으로만 퉁 쳐져있는 것을 "배달중/배달완료/배달전"등으로 도메인 단위 폴더링을 쪼갤 수 있다.
    * 코드를 분리하는 과정에서 폴더의 하이어라키 뎁스가 깊어진다면 더 단순한 폴더 형태를 민해야 한다.&#x20;
      * Next.js의 App Router 형식과 Page Router 형식을 참고
        * 커다란 프로젝트의 경우 App Router 형식이 적합할 수 있음(추상화)
  * 과제에 따른 업무 분담을 어떤 방식으로 진행할 것인가?
    * 프로덕트의 성장으로 코드가 과다해져 리팩토링을 진행해야 하는데, 리팩토링을 하는 시간이 어려울 수 있음
    * **유지보수 인원의 여유가 있는 경우** - 최소한의 SUS만 진행할 수 있는 인원을 최대한 리팩토링으로 리소스를 빼내고, 다른 담당자들이 비즈니스를 커버해야 함
    * **유지보수 인원의 여유가 없는 경우** - 아키텍처를 정해두고 추후 비즈니스가 적어지면 그 때 리팩토링 시도

### 메타 인지에 도움을 주는 요소

#### 비즈니스 현황

* 비즈니스의 진행 방향, 속도, 진척률 등을 체크하여 앞으로 과제가 무엇이 있는지 대략적으로 파악한다.&#x20;
* 이후 파악된 것을 바탕으로 미래 계획을 설계하고, 팀원들에게 전파하므로 예측가능한 상황으로 만든다.&#x20;

#### 팀원

* 현재 팀원(프론트)의 개발 역량 및 속도 그리고 휴가 현황등을 파악
* 작업이 진행되려면 팀원의 정보를 알고 있어야 하며, 비즈니스 현황과 더불어 일을 진행시키는데 가장 중요한 체크리스트 중 하나

#### 아키텍처

* 이전의 아키텍처와 이후의 아키텍처의 차이를 체크하여, 비즈니스 현황에 맞춰 개선 phase를 분리하고 미래에 대해서 구축할 수 있도록 설계를 진행해야 한다.
* 아키텍처 관점에서 우리가 어느정도로 인원에 비해 낮은 수준 혹은 높은 수준의 설계가 되어있고 인원이 효율적으로 업무하는지 체크할 수있다.

#### 리더쉽

* 비즈니스 현황과 팀원의 정보를 모두 쳋크하고, 아키텍처를 훌륭하게 만들어도 정작 팀원들과의 유대관계등이 존재하지 않는다면 동작하지 않을것이다.
* 주기적으로 팀원들과의 교류를 통해 앞으로 나아가고자 하는 것이 무엇이고 어떤 도움이 필요하며 무엇이 좋은지 등의 이야기를 해야 한다.
* 또한 개인적인 친밀감을 만드는 것도 굉장히 중요한 일

### &#xD;