개발자는 실제로 어떤 일을 하는가 — 개발 직군 지도

“저 개발자예요"라는 말은 사실 별로 많은 정보를 주지 못합니다. “저 운동선수예요"라는 말과 비슷합니다. 축구 선수인지 수영 선수인지 알 수 없는 것처럼, 개발자 안에도 하는 일이 전혀 다른 여러 직군이 있습니다. 같은 회사에서 일해도 매일 보는 화면, 쓰는 도구, 신경 쓰는 문제가 서로 다릅니다.

이 글은 두 부류의 사람을 위해 썼습니다. 하나는 개발자라는 진로를 고민하면서 “그래서 나는 뭘 하게 되는 건가"가 궁금한 사람입니다. 다른 하나는 개발자와 함께 일하지만 직군이 헷갈리는 기획자, 디자이너, 마케터입니다. 어느 쪽이든 이 글을 다 읽고 나면 머릿속에 개발 직군 지도가 한 장 그려질 것입니다. 코드는 한 줄도 나오지 않습니다.

프론트엔드 개발자 — 사용자가 보는 화면 #

프론트엔드 개발자는 우리가 눈으로 보고 손으로 만지는 모든 것을 만듭니다. 버튼, 입력창, 메뉴, 애니메이션, 화면이 넘어가는 흐름이 전부 이들의 손을 거칩니다.

기본 재료는 세 가지입니다. 화면의 뼈대를 잡는 HTML, 색과 배치를 입히는 CSS, 그리고 동작을 부여하는 JavaScript입니다. 요즘은 React, Vue, Angular 같은 도구를 얹어서 복잡한 화면을 더 효율적으로 만듭니다.

프론트엔드의 핵심 고민은 “사용자가 이걸 쉽고 빠르게 쓸 수 있는가"입니다. 버튼이 어디 있어야 자연스러운지, 휴대폰과 노트북에서 화면이 어떻게 달라져야 하는지, 느린 인터넷에서도 화면이 빨리 뜨는지를 신경 씁니다. 디자이너, 기획자와 가장 자주 대화하는 직군이기도 합니다.

백엔드 개발자 — 화면 뒤에서 동작하는 것 #

백엔드 개발자는 눈에 보이지 않는 쪽을 담당합니다. 로그인이 되는 이유, 주문이 처리되는 과정, 결제가 안전하게 이루어지는 구조가 전부 백엔드의 일입니다.

이들은 서버에서 실행되는 비즈니스 로직을 짭니다. “이 사용자가 이 글을 지울 권한이 있는가”, “재고가 남아 있을 때만 주문을 받는다” 같은 규칙을 코드로 만듭니다. 데이터를 저장하고 꺼내는 데이터베이스 처리도 백엔드의 몫이며, 프론트엔드가 데이터를 주고받을 수 있도록 API라는 통로를 만들어 주는 일도 합니다.

백엔드의 핵심 고민은 정확성과 안정성입니다. 사용자가 만 명이 몰려도 서비스가 버티는가, 돈이 오가는 계산이 한 번도 틀리지 않는가, 데이터가 새거나 사라지지 않는가를 끊임없이 따집니다.

프론트엔드와 백엔드를 더 천천히 풀어 쓴 글이 있습니다. 두 개념이 아직 흐릿하다면 비개발자를 위한 IT 상식 #1 — 프론트엔드,백엔드,데이터베이스를 먼저 읽어 보시기를 권합니다.

풀스택 개발자 — 양쪽을 다 만지는 사람 #

풀스택 개발자는 프론트엔드와 백엔드를 모두 다룹니다. 화면도 만들고 서버도 만든다는 뜻입니다. 인력이 넉넉하지 않은 스타트업이나 작은 팀에서 특히 선호하는 직군입니다.

다만 “풀스택이라 모든 걸 똑같이 잘한다"는 오해는 경계해야 합니다. 현실의 풀스택 개발자는 보통 한쪽에 더 강한 중심을 두고, 나머지 한쪽은 필요한 만큼 해내는 형태입니다. 양쪽을 다 만질 수 있다는 점이 강점이지, 양쪽 모두에서 전문가라는 뜻은 아닙니다. 혼자서 작은 서비스를 처음부터 끝까지 만들고 싶은 사람에게는 잘 맞는 방향입니다.

모바일 개발자 — 손안의 앱 #

모바일 개발자는 휴대폰에 설치하는 앱을 만듭니다. 같은 모바일 개발자라도 어느 플랫폼을 다루느냐에 따라 갈립니다.

iOS는 아이폰과 아이패드용 앱이며 주로 Swift라는 언어를 씁니다. 안드로이드는 삼성, 구글 등 안드로이드 기기용 앱이고 주로 Kotlin을 씁니다. 두 플랫폼은 도구와 규칙이 달라서, 전통적으로는 양쪽 앱을 따로 만들어야 했습니다.

이 번거로움을 줄이려고 나온 것이 크로스플랫폼 방식입니다. Flutter나 React Native 같은 도구를 쓰면 코드를 한 번 짜서 iOS와 안드로이드 양쪽 앱을 함께 만들 수 있습니다. 개발 비용을 아낄 수 있어 많은 팀이 선택하지만, 각 플랫폼 고유의 기능을 깊게 쓸 때는 한계가 있어 상황에 따라 선택이 갈립니다.

데브옵스,인프라,SRE — 서비스가 멈추지 않게 #

만들어진 서비스는 누군가의 컴퓨터, 즉 서버 위에서 실행되어야 사람들이 쓸 수 있습니다. 그 서버를 준비하고, 코드를 거기에 올리고, 멈추지 않게 지키는 직군이 데브옵스, 인프라, SRE입니다. 이름은 조금씩 다르지만 영역이 많이 겹칩니다.

이들이 하는 일을 풀어 보면 이렇습니다. 개발자가 짠 코드를 실제 서비스에 자동으로 올리는 배포 과정을 만들고, 그 과정을 자동화하는 CI/CD라는 흐름을 설계합니다. AWS 같은 클라우드 위에 서버를 띄우고 관리하며, 트래픽이 몰려도 버티도록 자원을 조절합니다.

그 중에서도 가장 긴장되는 순간은 장애 대응입니다. 새벽에 서비스가 멈추면 원인을 찾아 되살리는 사람이 이들입니다. 평소에는 “장애가 아예 안 나게” 만드는 일에, 일이 터지면 “최대한 빨리 복구하는” 일에 집중합니다.

데이터 직군 — 비슷해 보이지만 다른 세 갈래 #

데이터를 다루는 직군은 한 덩어리로 묶이기 쉽지만, 안을 들여다보면 셋으로 나뉩니다.

데이터 엔지니어는 데이터가 흐르는 길을 만듭니다. 여기저기 흩어진 데이터를 한곳에 모으고, 분석하기 좋은 형태로 다듬어 쌓는 일입니다. 데이터 분석가는 그렇게 쌓인 데이터를 들여다보며 의미를 찾습니다. “어떤 화면에서 사용자가 많이 이탈하는가” 같은 질문에 숫자로 답하고, 사업 판단을 돕습니다. 데이터 사이언티스트는 한발 더 나아가 통계와 모델을 써서 예측하고 패턴을 발견합니다. “다음 달 매출은 얼마일까” 같은 문제에 가깝습니다.

간단히 말하면 엔지니어는 데이터가 흐르는 길을 닦고, 분석가는 그 데이터로 현재를 읽고, 사이언티스트는 미래를 추정합니다.

머신러닝,AI 엔지니어 — 모델을 서비스에 붙이는 일 #

머신러닝, AI 엔지니어는 학습하는 모델을 만들고 그것을 실제 서비스에 연결하는 일을 합니다. 추천 목록, 얼굴 인식, 번역, 챗봇 같은 기능이 이들의 영역입니다.

데이터 사이언티스트가 “이 모델이 잘 맞히는가"를 연구한다면, AI 엔지니어는 그 모델이 실제 사용자 앞에서 빠르고 안정적으로 동작하게 만드는 데 더 무게를 둡니다. 모델을 만드는 일과 그 모델을 서비스에 붙여 운영하는 일은 필요한 기술이 다르며, 두 가지가 한 사람에게 모이기도 하고 나뉘기도 합니다. 요즘 가장 주목받는 직군 중 하나입니다.

QA,보안 — 자주 잊히지만 꼭 필요한 직군 #

마지막으로 짧게 두 직군을 더 짚겠습니다.

QA, 테스트 엔지니어는 서비스가 세상에 나가기 전에 문제를 찾아내는 사람입니다. 사용자가 겪기 전에 버그를 먼저 발견하고, 같은 실수가 반복되지 않도록 테스트를 자동화하기도 합니다. “잘 만드는 일"만큼이나 “잘못된 걸 잡아내는 일"이 중요하기 때문에 존재하는 직군입니다.

보안 엔지니어는 서비스와 데이터를 외부 공격으로부터 지킵니다. 어디가 뚫릴 수 있는지 미리 점검하고, 공격이 들어왔을 때 막고, 개인정보가 새지 않도록 관리합니다. 사고가 한 번 나면 회사 전체가 흔들릴 수 있는 영역이라 책임이 무겁습니다.

개발자는 하루 종일 코드만 치지 않는다 #

직군 지도를 그렸으니 흔한 오해 하나를 풀고 가겠습니다. 개발자가 종일 키보드만 두드리며 코드를 쏟아낸다는 이미지입니다. 실제로는 그렇지 않습니다.

하루를 들여다보면 회의, 문서 작성, 설계 논의, 동료의 코드를 검토하는 코드 리뷰, 그리고 이미 짜 둔 코드에서 문제를 찾는 디버깅이 큰 비중을 차지합니다. 코드를 새로 쓰는 시간은 생각보다 적습니다. 좋은 개발은 무엇을 어떻게 만들지 정하는 데서 절반이 결정되기 때문입니다.

그래서 직군을 고를 때 “어떤 언어를 배워야 하나"부터 묻는 것은 순서가 조금 뒤바뀐 질문입니다. 언어는 도구일 뿐이고, 직군이 정해지면 자연스럽게 따라옵니다. 더 좋은 출발점은 “나는 어떤 문제를 풀고 싶은가"입니다. 사람이 보는 화면을 다듬는 일이 즐거운지, 보이지 않는 곳에서 정확하게 동작하는 구조를 짜는 일이 끌리는지, 데이터에서 의미를 캐내는 일에 호기심이 생기는지를 먼저 들여다보시기를 권합니다.

마무리 #

지금까지 프론트엔드, 백엔드, 풀스택, 모바일, 데브옵스, 데이터, 머신러닝, QA, 보안까지 개발 직군을 한 장의 지도로 펼쳐 봤습니다. 보신 것처럼 “개발자"라는 한 단어 안에는 성격이 전혀 다른 일들이 들어 있습니다.

여기서 꼭 기억하시면 좋은 점은 정답인 직군은 없다는 것입니다. 더 멋있어 보이는 직군도, 더 우월한 직군도 없습니다. 각자가 푸는 문제가 다를 뿐이고, 그 문제 중 어떤 것이 본인의 호기심을 건드리는지가 선택의 기준이 됩니다.

프로그래밍 자체에 관심이 생겼다면 왜 모든 사람이 프로그래밍을 배워야 하는가도 함께 읽어 보시길 권합니다. 이 지도가 진로를 고민하는 분께는 방향을, 개발자와 일하는 분께는 동료를 이해하는 단서를 드렸기를 바랍니다.