MBTI 검사를 해보다 (ENTJ), 개발자와 성격 유형 이야기

개발자이지만 더욱 개발자처럼 되고 싶다 시리즈. [성향]편이다.

오늘도 유튜브 강의를 듣던 중 그의 신비로운 알고리즘이 나를 이상한 곳으로 인도했다. "개발자에게 좋은 MBTI는 무엇인가"라는 주제였다.

나는 뭐지? 과거에 했던 기억이 있는데 막 엄청 좋은 것도 나쁜 것도 아니었던 걸로 기억한다. 그런데 결혼 후 성향도 바뀌고 직업도 바뀌었으니 한 번 해봤는데, 엉뚱한 것이 튀어나왔다.

ENTJ 대담한 통솔자형

ENTJ 유형 보기 (16Personalities)

그래도 같은 분류에 잡스형이 있어서 조금 위안이 된다.

---

개발자에게 좋은 MBTI가 있을까

검사 결과를 보고 나서 든 생각인데, 이 질문 자체가 좀 이상하다.

흔히 개발자 하면 INTP나 INTJ 같은 내향적·분석적 유형을 떠올린다. 실제로 그런 통계가 인용되기도 한다. 그런데 개발자가 하는 일이 하나가 아니다.

• 혼자 코드를 파고드는 시간
• 기획자·디자이너와 요구사항을 조율하는 시간
• 코드 리뷰에서 의견을 주고받는 시간
• 장애 상황에서 빠르게 판단하고 지시하는 시간
• 주니어를 가르치는 시간

앞의 것은 내향적 성향에 유리하고, 뒤로 갈수록 외향적·판단형 성향이 유리하다. 경력이 쌓일수록 뒤쪽 비중이 늘어나기도 한다.

그러니 "개발자에게 좋은 유형"보다는 "내 유형에서 강점이 되는 지점과 의식적으로 보완할 지점"을 아는 게 실용적이다.

MBTI를 대하는 태도

MBTI가 재미있는 건 사실이지만, 몇 가지는 알고 쓰는 게 좋다.

• 결과가 자주 바뀐다. 나도 과거와 다른 결과가 나왔다. 상황, 기분, 최근 경험에 영향을 받는다
• 이분법이 실제 성향을 잘 못 담는다. 51%와 49%는 거의 같은데 알파벳은 정반대로 나온다
• 심리학계에서 신뢰도 논란이 있다. 학술적으로는 Big Five(5요인 모델)가 더 널리 쓰인다
• 자기 충족적 예언이 된다. "나는 T라서 공감을 못 해"라고 규정하면 정말 안 하게 된다

그래서 나는 이렇게 쓰는 게 맞다고 본다. 자기 이해의 출발점이나 대화 소재로는 좋지만, 사람을 규정하거나 채용·평가의 근거로 쓰면 안 된다.

그래도 팀에서 유용한 부분

MBTI 자체보다, 그걸 계기로 서로 다르다는 걸 인정하게 되는 효과는 실제로 있다.

• 회의 스타일 — 즉석에서 말하며 정리하는 사람과, 미리 생각한 뒤 말하는 사람이 있다. 아젠다를 미리 공유하면 후자가 참여할 수 있다
• 피드백 방식 — 결론부터 듣고 싶은 사람과 맥락부터 듣고 싶은 사람이 있다
• 의사결정 — 빠르게 정하고 수정하는 쪽과, 충분히 검토하고 정하는 쪽. 둘 다 필요하다
• 회고 — 문제 지적이 편한 사람과 불편한 사람이 있다. 진행 방식을 설계할 때 고려한다

결국 유형 이름을 아는 것보다, "저 사람은 나와 다른 방식으로 편할 수 있다"는 전제를 갖는 것이 협업에 도움이 된다.

ENTJ가 나왔으니

설명을 읽어보니 계획 세우고 밀어붙이는 쪽이라고 한다. 개발자로서 강점이 될 만한 부분과 조심할 부분을 나눠보면 이렇다.

• 강점 — 일정 관리, 우선순위 판단, 결정을 미루지 않는 것
• 조심할 것 — 결론을 먼저 내리고 남의 의견을 늦게 듣는 것, 효율을 앞세우다 사람 마음을 놓치는 것

테스트 결과를 정답으로 받아들이기보다, 이런 식으로 스스로를 점검하는 질문지 정도로 쓰면 딱 좋은 것 같다.