개발자의 절망

빅테크의 임팩트 기반 성과 평가는 끔찍하다 (pcloadletter.dev)

Impact-based performance evaluation in big tech is terrible

 

위 컬럼을 읽고 느끼는 소회는 아래와 같다.

 

개발자에게 절망이란 소통의 단절을 의미한다.

 

대부분의 어플리케이션 개발의 구성 요소

 

1. Database

2. Backend Server

3. Frontend

4. 기획

5. QA

6. 인프라

 

위 구성요소 중 개발이 아닌 부분이 없다.

 

모든게 개발 요소이고 판단요소이다.

 

단절이 무엇이냐?

 

Database 개발자가 Application, 즉 Backend에서 벌어지는 일을 모르는 것이다.

Backend 개발자가 Frontend에서 벌어지는 일을 모르는 것이다.

Frontend 개발자가 QA에서 벌어지는 일을 모르는 것이다.

인프라 개발자가 Database, Backend, Frontend에서 벌어지는 것을 모르는 것이다.

 

흔히 우리가 개발할 때 loose coupling이라는 표현을 사용한다.

 

강하게 연결하지 말고 유연하게 구현하라는 것이다.

 

하지만, 현실에서 벌어지는 일은 어떠한가?

 

기획 단계에서 기획자가 개발의 구성요소를 모른다면 자신이 만드는 화면과 시나리오가 어떻게 개발될지 모른다면 일정관리를 할 수 있겠는가?

화면만 만들고 DATA에 대한 정합성을 고려하지 않는다면 그것이 기획인가?

 

Database 개발자가 화면에서 벌어지는 일을 고려하지 않고 Not Null과  Allow Null을 판단하지 않는다면 데이터에 대한 정합성은 어떻게 지킬 것이가?

 

Backend와 Frontend개발자가 서로의 데이터 전달을 어떻게 주고 받을지 고려하지 않는다면 조회와 저장은 어떻게 구현될 수 있겠는가?

 

모든 것이 개발되고 QA가 기획과 개발된 사항에 상세한 부분을 알지 못한다면 과연 누가 테스트하고 배포 결정을 할 것인가?

 

그리고 매번 다른 논리로 그 결정을 한다면 어떻게 배포를 할 수 있다는 말인가?

 

인프라가 자동화되어 있지 않다면 시스템이 확장되고 서버가 늘어날 수록 인프라에 대한 관리는 어떻게 할 것인가?

 

매번 모든 개발자가 배포에 목숨을 걸어야 할 만큼 고통스럽고 절차가 없다면 어떻게 유지 지속성이 있겠는가?

 

위 모든 것을 고려하는 회사가 있다.

 

바로 이카운트.

 

그래서 처음에 너무나 복잡해 보이는 과정 때문에 힘들고 어려울 수 있다.

 

하지만, 그 과정을 모두 겪고 다른 회사에서 정 반대의 상황에서 일해 본다면 위 사항이 정리된 회사에서 일하는 것이 얼마나 중요한지 알 수 있을 것이다.

 

위에 나열한 사항이 없는 회사는 절대 성공할 수 없다.

 

절대로...