사내 정치는 제로섬이 아니라 윈윈이다.

필자는 사내 정치에 대한 개인적인 기준을 세워두지 못한 상태였다.

이 상태에서 다양한 기업에서 면접을 진행하며, 해당 부분에 대한 면접 질문이 들어왔을 때, 깔끔하게 대답할 수 없었다.

 

그런데 주니어 백엔드 개발자가 반드시 알아야 할 실무 지식(최범균 著) 도서에 대해 내용을 학습하면서, 중요한 인사이트를 얻을 수 있었다.

주니어 백엔드 개발자가 반드시 알아야 할 실무 지식 | 최범균 | 한빛미디어 - 예스24

 

 

---

 

새로 추가할 쿼리가 기존에 존재하는 인덱스를 사용하지 않을 때에는 요구사항을 일부 변경할 수 있는지 검토해보자.
작은 변경만으로 인덱스를 활용할 수 있기 때문이다.

 

예를 들어 다음과 같은 테이블과 인덱스를 생각해보자.

create table reservation (
  id bigint not null primary key,
  name varchar(30) not null,
  reserveDate date not null,
  state char(2) not null,
  regDt timestamp not null
);
create index idxRdate ON reservation (reserveDate);

예약자 이름으로 조회하는 기능을 구현해야 할 경우, 다음처럼 name 칼럼을 비교할 수 있다.

select * from reservation
where name = '고객명'
order by regDt desc;

이 쿼리를 수행하면 현재 인덱스가 존재하지 않으므로 테이블 풀 스캔이 발생한다.
풀 스캔을 방지하기 위해 name 칼럼을 인덱스로 추가할 수도 있지만, 요구사항을 일부 변경하면 인덱스를 추가하지 않아도 된다.

• 특정 일자에 예약한 예약자 이름으로 조회

이 요구사항을 위한 쿼리는 다음과 같다.

select * from reservation
where reserveDate = '2024-08-09' and name = '고객명';

이 쿼리는 reserveDate 칼럼을 포함하고 있는 idxRdate 인덱스를 사용한다.
특정 일자에 속한 데이터만 비교하므로 새로운 인덱스를 추가하지 않고도 풀 스캔 없이 예약자 이름으로 데이터를 조회할 수 있다.

 

여기서 중요한 2가지 관점이 있다.

• 이름만으로 예약한 정보를 조회하는 것이 중요한 비즈니스 로직이 아니었다.
• 따라서 날짜 기준을 추가함으로써, 서비스의 성능 향상에 이익이 되는 판단을 수행할 수 있었다.

---

이와 같은 재밌는 실제 사례로는 구글의 검색 페이징이 있다.

구글의 경우 검색창에 검색을 수행하면 12페이지가 존재하는 것처럼 보여준다.

하지만, 실제로 해당 페이지에 들어가면 다음과 같은 결과를 볼 수 있다.

즉, 구글은 페이지의 갯수를 정확히 보여주는 것이 구글의 핵심 비즈니스 요구사항이 아님 이라 결정하고, 다음과 같은 페이지를 보여주는 것이다.

---

이것이 타 부서의 사람들과도 서로 돕고 잘 지내야 하는 이유이기도 하다.

• 각 부서간에 서비스의 미래를 바라보는 지향점은 다를 수 있다.
• 서로간에 이해를 위해서, 각 부서의 역할을 깊이있게 이해하는 것은 중요하다.

해당 비즈니스 로직의 가치와 트레이드 오프는 개발자와 기획자 모두 잘 이해하고 있어야 한다.
따라서 팀 간의 정치는 제로섬 게임이 아닌 윈윈 전략이 될 수 있다.

 

또한, 연봉/위치와 같은 물리적 기준 뿐만 아니라, 자신이 하고싶은 도메인에서 일하는 것 또한 중요한 기준이 된다.

새로운 도메인에 대한 열정적인 이해는 분명 큰 에너지를 소모하는 작업이고, 그렇기에 회사 내에서 가치를 창출하기 위해선 '자신이 개선하고 싶은 도메인이 맞는지'를 확인하는 과정이 필수불가결하다 할 수 있다.