웹개발자 MBTI 직무 추천 — 프론트엔드·백엔드·DBA 성향 궁합

 

 

"너 I라서 백엔드가 딱이야."
"제가 P인데 DBA 해도 괜찮을까요?"
"프론트는 E가 잘한다던데 진짜예요?"
"성향 따라 직무 갈리는 거, 그거 좀 미신 아닌가요?"

 

 

팀에서 한 번쯤 들어보셨을 법한 말들입니다. 술자리에서든 슬랙에서든, 개발자들끼리 모이면 MBTI 이야기가 빠지질 않습니다. 저도 그 자리에 끼어 한참 떠들다가, 문득 이런 생각이 들었습니다. 정작 우리가 말하는 건 "이 사람은 원래 이런 성향이다"가 아니라 "이 자리에서는 이런 성향이 덜 괴롭더라"에 가깝지 않나.

그래서 개발자 MBTI와 직무의 궁합을 한번 정리해봤습니다. 십수 년간 옆자리에서 여러 개발자를 봐오며 느낀, 성향과 자리의 궁합 같은 것입니다. 분명히 말씀드리면 이건 정답표가 아닙니다. MBTI는 과학이 아니고, 저는 점쟁이가 아닙니다. 그저 어떤 성향이 어떤 자리에서 조금 더 편안해 보이더라는 관찰일 뿐입니다.

이번 글은 제 개인적인 분류 대신 대중적으로 통용되는 개발 분야와 직무를 기준으로 정리했습니다. 직무를 고민하는 주니어, 팀원을 어디에 배치할지 고민하는 리드, 그리고 그냥 "내 성향이면 어디가 맞을까" 궁금한 분들을 위한 글입니다. 진지하게 받아들이기보다, MBTI 짤 보듯 가볍게 읽어주시면 좋겠습니다.

📋 목차

1. 먼저 짚고 갈 것 - MBTI는 과학이 아닙니다
2. 두 개의 축으로 나눴습니다
3. 웹 개발 - E와 S의 자리
4. 모바일 앱 개발 - S와 J의 자리
5. 게임 개발 - N과 P의 자리
6. 데이터·AI 개발 - N과 T의 자리
7. 시스템·인프라 개발 - I와 T의 자리
8. 프론트엔드 - 보이는 것을 만드는 사람
9. 백엔드 - I와 T의 자리
10. 풀스택 - N과 P의 경계에 선 사람
11. DevOps·SRE - 안정성에 집착하는 사람
12. 데이터 엔지니어 - 구조를 설계하는 사람
13. DBA - J가 타협하지 않는 자리
14. 보안·QA - 의심과 꼼꼼함의 자리
15. 한눈에 보는 성향·자리 종합표
16. 그래서, 안 맞으면 못 하나요?

1. 먼저 짚고 갈 것 - MBTI는 과학이 아닙니다

본격적으로 들어가기 전에 양심선언부터 하겠습니다. MBTI는 심리학계에서 신뢰도와 타당도가 떨어진다는 비판을 꾸준히 받아온 도구입니다. 한 연구에서는 5주 뒤에 다시 검사했을 때 약 절반이 처음과 다른 유형으로 분류됐다는 결과도 있습니다(Pittenger, 2005). 카를 융의 심리유형론을 기반으로 만들어졌지만, 그 이론 자체가 현대 심리학에서 과학적 사실로 다뤄지지는 않습니다.

게다가 많은 분들이 돌리는 16personalities는 사실 정식 MBTI가 아닙니다. 성격 5요인(빅 파이브) 모델을 토대로 MBTI식 네 글자 라벨을 입힌 별개의 테스트이고, 마이어스-브릭스 측과도 공식적인 관련이 없습니다. 그러니 "내 MBTI는 INTJ야"라고 할 때 그 글자가 우리를 정확히 설명한다고 믿는 건 좀 위험합니다.

제 다른 블로그인 동방생활에 'MBTI는 객관적인 나가 아니다, 사실은 내가 추구하는 나'라는 글을 쓴 적이 있습니다. 거기서 했던 이야기가 이번 글에도 그대로 적용됩니다. MBTI는 "나는 원래 이런 사람"이 아니라 "나는 이런 사람이고 싶다"에 가깝습니다. 검사할 때마다 결과가 바뀌는 이유도, 그날 내가 되고 싶은 모습이 조금씩 다르기 때문일지 모릅니다.

 

 

💡 그래서 이 글의 전제는

"이 MBTI는 이 자리를 해야 한다"가 아닙니다.

"이 자리에서 일하다 보면 이런 성향이 자연스럽게 길러지고,

그 성향이 강한 사람이 덜 지치더라"는 관찰입니다.

인과의 방향이 반대일 수도 있다는 뜻이죠.

 

2. 두 개의 축으로 나눴습니다

개발자를 한 줄로 세워서 "넌 프론트, 넌 백엔드" 하는 건 너무 단순합니다. 실제 현장에서는 두 가지 질문이 따로 놉니다. 하나는 무슨 분야에서 일하느냐, 다른 하나는 어떤 직무 역할을 맡느냐입니다.

예를 들어 같은 백엔드 개발자라도, 트래픽이 폭발하는 웹 서비스에서 일하는 사람과 정밀함이 생명인 임베디드 환경에서 일하는 사람은 요구받는 결이 완전히 다릅니다. 분야가 큰 환경을 정하고, 직무가 그 안에서 내 역할을 정하는 셈입니다.

 

 

📌 두 개의 축

- 개발 분야(무엇을 만드나) - 웹 / 모바일 앱 / 게임 / 데이터·AI / 시스템·인프라
- 직무 역할(어떤 롤이냐) - 프론트엔드 / 백엔드 / 풀스택 / DevOps·SRE / 데이터 엔지니어 / DBA / 보안 / QA

 

 

MBTI의 네 글자도 이 두 축 위에 자연스럽게 흩어집니다. 사람들과 부대끼는 정도(E/I), 구체적인 것과 추상적인 것 중 무엇에 끌리는가(S/N), 논리와 관계 중 무엇을 먼저 보는가(T/F), 계획과 즉흥 중 어디가 편한가(J/P). 자리마다 유독 잘 맞는 글자가 있더라는 게 핵심입니다. 하나씩 보겠습니다.

3. 웹 개발 - E와 S의 자리

웹 개발은 변화가 가장 빠른 분야입니다. 프레임워크는 몇 년 단위로 바뀌고, 사용자는 우리가 짠 코드의 우아함에는 관심이 없습니다. 그냥 잘 되는지, 안 헷갈리는지만 봅니다.

그래서 눈앞의 구체적인 경험에 집중하는 S 성향이 유리합니다. 이상적인 설계를 머릿속에서 굴리는 것보다, 실제로 돌려보고 만져보고 고치는 쪽이 빛을 봅니다. 또 웹은 기획·디자인·CS와 끊임없이 부딪히며 만들어지기 때문에, 이곳저곳 물어보러 다니는 걸 일의 일부로 받아들이는 E 성향도 덜 지칩니다.

여기에 빠른 변화에 유연하게 올라타는 P 기질이 섞이면 더 좋습니다. 어제의 정답이 오늘 바뀌는 분야라서, 한 방식에 너무 집착하면 오히려 피곤해집니다.

4. 모바일 앱 개발 - S와 J의 자리

모바일은 제약이 많은 분야입니다. 화면은 작고, 디바이스는 제각각이고, 스토어 심사를 통과해야 하며, 한 번 배포하면 사용자가 업데이트하기 전까지 버그가 그대로 남습니다.

그래서 디테일을 놓치지 않는 S 성향이 강점이 됩니다. 기기별 화면 차이, 미세한 터치 반응, 배터리 같은 손에 잡히는 요소들을 챙겨야 하니까요. 동시에 출시 일정과 심사 규정을 칼같이 지켜야 해서 J 성향도 어울립니다. 여기에 사용자가 어떻게 느낄지 헤아리는 약간의 F 기질이 더해지면 완성도가 살아납니다.

5. 게임 개발 - N과 P의 자리

게임은 "재미"라는 정답 없는 목표를 향해 달리는 분야입니다. 기획서대로 만들어도 막상 해보면 재미없는 경우가 허다하고, 그래서 수없이 만들고 부수고 다시 만듭니다.

그래서 아직 없는 경험을 상상하는 N 성향, 그리고 끝없는 실험과 갈아엎기를 견디는 P 성향이 잘 맞습니다. 완벽한 설계에 집착하기보다 "일단 만들어보고 재밌나 보자"가 통하는 자리죠. 또 재미와 감성을 다루는 일이라 F 기질이, 대규모 협업이 많아 E 성향이 도움이 됩니다.

6. 데이터·AI 개발 - N과 T의 자리

데이터와 AI 분야는 보이지 않는 패턴을 다룹니다. 눈에 보이는 화면이 아니라, 수치 뒤에 숨은 구조와 인과를 찾아내는 일입니다.

그래서 추상적인 가능성과 패턴을 읽는 N 성향이 핵심입니다. 동시에 모델 성능, 통계적 유의성, 데이터 품질 같은 건 감정으로 풀리지 않고 오직 논리와 수치로만 풀리니 T 성향이 받쳐줘야 합니다. 혼자 깊게 파고드는 시간이 많아 I 성향이 편한 편이기도 합니다.

7. 시스템·인프라 개발 - I와 T의 자리

시스템과 인프라는 모든 것의 토대입니다. 임베디드, 운영체제, 서버 인프라처럼 화려하지 않지만 무너지면 전부가 멈추는 영역이죠. 저는 개인적으로 이 분야를 가장 존경합니다.

여기서는 누가 알아주지 않아도 묵묵히 자기 할 일을 하는 I 성향, 그리고 안정성과 정합성을 논리로 따지는 T 성향이 빛을 봅니다. 또 절차와 재현 가능성을 중시하는 J 성향도 강점이 됩니다. "일단 질러보자"가 가장 위험한 자리이기 때문입니다.

8. 프론트엔드 - 보이는 것을 만드는 사람

이제 직무 역할 축으로 넘어갑니다. 프론트엔드는 사용자 눈에 직접 보이는 결과물을 만듭니다. 픽셀 하나, 애니메이션 0.2초의 차이가 사용성을 바꾸는 자리입니다.

그래서 구체적인 결과에 집중하는 S 성향, 사용자가 어떻게 느낄지 헤아리는 약간의 F 기질이 어울립니다. 디자이너·기획과 소통이 잦아 E 성향이 편하긴 하지만, 혼자 깊게 파는 프론트 전문가도 많아서 E가 필수는 아닙니다. 요즘은 상태 관리와 렌더링 성능까지 다뤄야 해서 추상 구조를 보는 N 기질이 섞인 프론트가 점점 귀해지고 있습니다.

9. 백엔드 - I와 T의 자리

백엔드는 사용자 눈에 보이지 않는 곳에서 일합니다. 잘 돌아가면 아무도 모르고, 멈추면 모두가 압니다. 이 자리의 숙명입니다.

그래서 누가 알아주지 않아도 혼자 코드와 씨름하는 시간을 외롭다기보다 집중의 시간으로 받아들이는 I 성향이 어울립니다. 또 트랜잭션, 정합성, 동시성 같은 문제는 "이게 더 인간적일 것 같아서"로 풀리지 않습니다. 오직 논리와 원칙만 통하기에 T 성향이 강점이 됩니다.

10. 풀스택 - N과 P의 경계에 선 사람

풀스택은 프론트와 백엔드를 넘나듭니다. 한 영역을 깊게 파기보다, 전체 그림을 보며 필요한 곳을 그때그때 메우는 자리입니다. 스타트업이나 소규모 팀에서 특히 빛을 봅니다.

그래서 큰 그림과 연결을 보는 N 성향, 영역을 자주 갈아타며 유연하게 대응하는 P 성향이 어울립니다. 다만 솔직히 말하면, 풀스택은 성향보다 경험치가 더 중요한 자리입니다. 여러 영역을 거쳐본 사람이 자연스럽게 도달하는 자리지, 처음부터 "나는 풀스택 성향이야"로 시작하는 경우는 드뭅니다.

11. DevOps·SRE - 안정성에 집착하는 사람

DevOps와 SRE는 시스템이 안정적으로 굴러가도록 자동화하고 감시하는 자리입니다. 배포 파이프라인을 만들고, 모니터링을 걸고, 장애가 나기 전에 막고, 나면 빠르게 복구합니다.

이 자리는 여러 성향이 한데 모입니다. 절차와 안정성을 중시하는 J 성향, 장애 원인을 논리적으로 파고드는 T 성향, 새벽 장애를 혼자 침착하게 다루는 I 성향까지. "같은 장애가 두 번 나면 그건 내 책임"이라는 강박에 가까운 책임감을 즐기는 사람이라면 잘 맞습니다.

12. 데이터 엔지니어 - 구조를 설계하는 사람

데이터 엔지니어는 흩어진 데이터를 모으고, 정제하고, 분석 가능한 형태로 흐르게 만드는 파이프라인을 설계합니다. 앞서 본 데이터·AI 분야가 "무엇을 알아낼까"라면, 이 직무는 "그걸 알아낼 데이터를 어떻게 흐르게 할까"에 가깝습니다.

그래서 데이터의 전체 흐름을 입체적으로 그리는 N 성향, 그리고 품질과 정합성을 타협 없이 따지는 T 성향이 핵심입니다. 분석가와 가까이 일하지만 정작 작업 자체는 혼자 깊게 파고드는 시간이 많아 I 성향이 편한 편입니다.

13. DBA - J가 타협하지 않는 자리

DBA(데이터베이스 관리자)는 데이터라는 한 영역을 가장 깊고 단단하게 지키는 자리입니다. 제가 본 직무 중에 타협이 가장 안 통하는 포지션입니다.

J 성향이 여기서는 거의 필수에 가깝습니다. 스키마 설계, 백업 정책, 권한 관리. "대충 나중에 정리하지 뭐"는 곧 데이터 유실이나 장애로 돌아옵니다. 여기에 T 성향이 더해집니다. "이 컬럼 그냥 NULL 허용해주면 안 돼요?"라는 부탁에 분위기로 봐주지 않고 "안 됩니다"를 단호하게 말할 수 있어야 시스템이 지켜집니다.

14. 보안·QA - 의심과 꼼꼼함의 자리

보안 엔지니어와 QA 엔지니어는 결이 다르지만, "남들이 안 보는 곳을 본다"는 공통점이 있습니다.

보안은 "이게 뚫릴 수 있나"를 끊임없이 의심하는 자리라 논리적으로 허점을 파고드는 T 성향, 원칙을 지키는 J 성향, 혼자 깊게 분석하는 I 성향이 어울립니다. QA는 "이게 깨질 수 있나"를 집요하게 확인하는 자리라 디테일을 챙기는 S 성향과 체크리스트를 끝까지 지키는 J 성향이 강점이 됩니다. 둘 다 꼼꼼함이 미덕이 되는 자리입니다.

15. 한눈에 보는 성향·자리 종합표

지금까지 본 내용을 한 장에 정리했습니다. MBTI를 네 축으로 나눠 표기했고, 같은 글자라도 강하게 권장되는 필수와 있으면 좋은 서브를 색으로 구분했습니다. 본인 성향과 겹치는 칸이 많은 자리를 가볍게 찾아보세요.

파란 굵은 글자 = 필수(강하게 권장)  |  주황 글자 = 서브(있으면 좋음)  |  · = 중립

반응형

구분	자리	E↔I	S↔N	T↔F	J↔P	핵심 이유
개발 분야	웹 개발	E	S	·	P	변화 빠르고 협업 많음, 구체적 결과 중심
	모바일 앱	·	S	F	J	디바이스 제약·심사, 디테일과 일정 엄격
	게임 개발	E	N	F	P	정답 없는 재미, 끝없는 실험과 갈아엎기
	데이터·AI	I	N	T	·	보이지 않는 패턴, 수치와 논리
	시스템·인프라	I	·	T	J	모든 것의 토대, 안정성과 절차
직무 역할	프론트엔드	E	S	F	·	보이는 결과물, 사용자 감각
	백엔드	I	·	T	·	안 보이는 곳에서 묵묵히, 논리와 원칙
	풀스택	·	N	·	P	넓게 보고 유연하게, 경험치가 더 중요
	DevOps·SRE	I	·	T	J	자동화, 안정성, 장애 대응
	데이터 엔지니어	I	N	T	·	데이터의 길을 추상적으로 설계
	DBA	·	·	T	J	절대 타협하면 안 되는 무결성의 자리
	보안 엔지니어	I	·	T	J	끊임없는 의심, 논리로 허점 파고들기
	QA 엔지니어	·	S	·	J	집요한 확인, 체크리스트를 끝까지

16. 그래서, 안 맞으면 못 하나요?

여기까지 읽고 "난 백엔드 하고 싶은데 E야, 망했다"라고 생각하셨다면, 잠깐 멈추셔도 됩니다. 결론부터 말씀드리면 전혀 그렇지 않습니다.

그동안 옆에서 본 개발자 중에는 표와 정반대인데 누구보다 잘하는 사람이 수두룩했습니다. 떠들썩한 E인데 백엔드 정합성을 귀신같이 잡는 사람, P인데 DBA를 칼같이 하는 사람, I인데 게임 기획 회의를 휘어잡는 사람. 오히려 "나는 이 성향이라 이건 못 해"라는 말이 발목을 잡는 경우를 더 많이 봤습니다.

처음에 말씀드린 추구미 이야기로 돌아가 보겠습니다. MBTI가 "객관적인 나"가 아니라 "내가 추구하는 나"인 것처럼, 이 표도 "당신이 가야 할 자리"가 아니라 "그 자리에서 일하다 보면 이런 성향이 길러진다"에 가깝습니다. 인과가 거꾸로일 수 있다는 거죠. 조용한 사람이라 백엔드를 한 게 아니라, 백엔드를 오래 하다 보니 혼자 집중하는 게 편해진 것일 수도 있습니다.

 

 

📌 진짜 하고 싶은 말

성향은 자리를 고를 때 참고할 약한 신호일 뿐, 결정하는 잣대가 아닙니다.

안 맞는 것 같은 자리에서 의외로 성장하는 경우가 훨씬 많습니다.

표는 "지금 내가 어디서 덜 지치나"를 가볍게 비춰보는 거울 정도로만 써주세요.

 

마무리

이 글을 진지한 진로 가이드로 받아들이지 않으셨으면 합니다.

MBTI 자체가 그날그날 바뀌는 가벼운 거울이고, 저 역시 점쟁이가 아니라 오래 옆자리를 지켜본 사람일 뿐입니다.

다만 "내 성향이면 어디가 편할까"를 한 번쯤 가볍게 떠올려보는 계기는 됐으면 좋겠습니다.

그리고 혹시 지금 "안 맞는 자리"에 있다고 느끼신다면,

그게 오히려 가장 많이 배우는 자리일 수도 있다는 말씀을 드리고 싶습니다.

성향은 따라오는 것이지, 우리를 가두는 게 아니니까요.

여러분은 어느 분야, 어느 자리에서 가장 덜 지치시나요.

한번 떠올려보면 의외로 재밌습니다.

📚 함께 보면 좋은 글

네이버가 PHP였다고? 한국 IT 대기업들의 충격적인 초기 기술 스택 (네이버·배민·카카오)

개인 생각 - 시대별로 유행했던 개발 기술 30년사 (Struts에서 Bedrock까지, 살아남은 자와 사라진 자)

질문이 엉성하면 답도 없다 - 스택오버플로우가 바꾼 개발자의 사고방식

MBTI는 객관적인 '나'가 아니다 - 사실은 내가 추구하는 나, '추구미'