풀스택 개발자

Full-stack Developer

역할

기능 하나를 화면부터 서버와 데이터 저장까지 한 사람이 끝까지 만들어 내보내는 개발자입니다.

등장 배경

기능 하나를 내보내려면 층 두 개가 다 필요합니다. 사용자가 보고 조작하는 화면 쪽인 프론트엔드와 그 뒤에서 데이터와 규칙을 처리하는 백엔드입니다. 댓글 알림 하나를 붙이려 해도 알림을 저장할 자리를 만들고, 보낼지 말지 판단하는 규칙을 짜고, 화면 위쪽에 빨간 점을 띄우는 일이 모두 있어야 합니다.

이 둘을 다른 사람에게 나눠 맡기면 비용이 생깁니다. 주고받을 데이터의 모양을 맞추는 회의가 필요하고, 한쪽이 먼저 끝나면 다른 쪽을 기다리고, 중간에 조건이 바뀌면 다시 맞춰야 합니다. 층이 셋이고 사람이 여섯인 조직에서는 이 값이 감당할 만하지만, 만드는 사람이 셋뿐인 팀에서는 조율에 드는 시간이 구현에 드는 시간을 넘어섭니다. 기능 하나에 두 사람이 붙는다고 만드는 시간이 반으로 줄지는 않고, 맞추는 시간만 새로 생깁니다.

초기 팀의 회의 기록에는 그래서 같은 문장이 반복됐습니다. "서버는 다 됐는데 화면이 아직이요", "그 값을 그렇게 내려 주시면 화면에서 한 번 더 바꿔야 해요", "이건 누가 고치는 거죠". 기능 하나가 실제로 막힌 시간보다 서로를 기다린 시간이 길었습니다. 그 낭비를 없애려고 한 기능을 한 사람이 끝까지 들고 가게 한 것이 이 자리의 출발입니다.

하루 업무

기능 하나를 가로로 자르지 않고 세로로 끝까지 밀고 갑니다. 댓글 알림을 예로 들면 하루의 일은 이렇게 이어집니다.

  1. 저장할 모양을 정합니다. 알림 한 건에 누가·무엇에·언제·읽었는지를 담기로 하고, 이 기록을 넣어 두고 꺼내 오는 데이터베이스에 자리를 만듭니다. 여기서 정한 모양이 뒤의 모든 단계를 묶습니다.
  2. 규칙을 짭니다. 자기가 쓴 댓글에는 알림을 보내지 않고, 같은 문서에 댓글이 연달아 달리면 한 건으로 묶습니다. 이런 판단은 화면이 아니라 서버에서 합니다. 화면에서 걸러 내면 알림을 보내는 경로가 하나 늘 때마다 같은 규칙을 여러 군데에 적어 두게 됩니다.
  3. 화면과 서버가 주고받을 창구를 만듭니다. 프로그램끼리 무엇을 어떤 모양으로 주고받을지 정해 둔 약속이 API인데, 화면도 자기가 만들기 때문에 화면이 실제로 필요한 모양 그대로 내려 주도록 정할 수 있습니다. 한쪽이 보낸 값을 다른 쪽에서 다시 가공하는 단계가 줄어듭니다.
  4. 화면을 만듭니다. 읽지 않은 알림 개수를 띄우고, 목록을 그리고, 눌렀을 때 해당 문서로 보냅니다. 알림이 하나도 없을 때와 불러오는 중일 때의 모습도 함께 만듭니다.
  5. 내보냅니다. 합친 코드를 자동으로 검사하고 문제가 없으면 서버까지 올리는 CI/CD를 거쳐 나가고, 나간 뒤 알림이 실제로 도착하는지 확인합니다.

혼자 끝까지 가는 만큼 남이 봐 주는 자리가 더 중요해집니다. 합치기 전에 동료가 변경을 읽고 의견을 다는 코드 리뷰에서 한쪽 층에만 익숙한 사람이 놓치는 것을 잡습니다.

함께 일하는 사람

층 사이의 대화가 머릿속에서 끝나기 때문에, 밖으로 나가는 대화는 층이 아니라 결정을 향합니다.

무엇을 만들지는 프로덕트 매니저와 정합니다. 층을 다 볼 수 있어서 값을 따져 가며 범위를 줄이는 대화가 가능합니다. 알림을 실시간으로 밀어 줄지 30초마다 확인할지를 두고, 앞쪽은 사흘이고 뒤쪽은 반나절이라는 식으로 답을 내놓는 자리입니다.

화면의 모양은 프로덕트 디자이너와 맞춥니다. 시안을 받아 옮기면서, 데이터 구조상 지금 화면에서는 줄 수 없는 정보가 있으면 그 자리에서 알려 줍니다. 디자이너 입장에서는 화면 이야기와 서버 이야기를 한 사람에게 물어볼 수 있습니다.

기술 결정은 테크 리드와 나눕니다. 혼자 세로로 밀면 팀 전체의 기준에서 벗어난 방식이 섞이기 쉬워서, 어디까지 혼자 정하고 어디부터 함께 정할지를 미리 그어 둡니다. 서버를 늘리고 줄이는 일이나 배포 경로처럼 제품 전체에 걸리는 부분은 배포와 운영 자동화를 맡는 데브옵스 엔지니어에게 넘깁니다.

실무 용례

"이 기능은 제가 끝까지 들고 갈게요. 화면까지 같이 보는 편이 빠릅니다."

층을 나누지 않고 혼자 맡겠다는 뜻입니다.

"응답을 따로 가공할 필요 없어요. 화면에서 필요한 모양대로 서버에서 바로 내려 줄게요."

양쪽을 다 만드니 중간 단계를 줄이겠다는 말입니다.

"풀스택이라고 다 하는 건 아니고, 배포 쪽은 맡기는 게 맞습니다."

이 자리의 범위가 어디까지인지 긋는 말입니다.

페이지덱이 구성원 열 명이던 시절에 태오는 문서 공유 기능을 혼자 끝까지 만들었습니다. 공유 링크를 저장할 자리, 링크에 만료일과 비밀번호를 붙이는 규칙, 공유 버튼을 누르면 뜨는 화면까지 한 주에 나갔습니다.

지금 마흔다섯 명이 된 뒤에도 같은 방식으로 일하는 자리가 남아 있습니다. 대신 대상이 바뀌었습니다. 결제나 권한처럼 한쪽 층이 깊게 들어가는 일은 각 층의 담당자에게 가고, 태오는 여러 층에 조금씩 걸쳐 있는 기능을 맡습니다. 댓글 알림이나 내보내기처럼 층마다 할 일은 작은데 층은 다 지나야 하는 기능입니다.

흔한 오해

모든 기술을 다 잘하는 사람으로 읽는 경우가 가장 많습니다. 이름에 전부라는 말이 들어 있으니 그렇게 읽힙니다. 실제로는 기능 하나를 혼자 끝까지 밀 수 있다는 뜻이고, 깊이는 대개 한쪽으로 기울어 있습니다. 서버가 주력이고 화면은 남의 도움 없이 만들 수 있는 정도이거나 그 반대입니다. 이 차이를 모르고 채용 공고를 쓰면 화면과 서버와 인프라와 모바일과 데이터까지 요구하는 목록이 나옵니다. 그런 사람은 지원하지 않고, 어쩌다 뽑아도 다섯 몫을 기대받다가 나갑니다.

깊이가 얕을 수밖에 없다는 오해도 함께 다닙니다. 넓게 다루니 그렇게 보입니다. 하지만 버그와 설계 실수는 대개 층의 안쪽이 아니라 층과 층 사이에서 나옵니다. 서버가 내려 준 값의 모양이 화면에서 쓰기 나쁘거나, 실패했을 때 무엇을 보여 줄지 아무도 정하지 않은 자리입니다. 이 경계를 한 사람이 보면 그런 틈이 줄어듭니다. 반대로 조직이 커졌다는 이유로 이 자리를 다 없애면, 기능 하나가 세 사람의 협의를 거치면서 나가기까지 걸리는 시간이 늘고 경계에 낀 문제는 서로의 일로 미뤄집니다.

자주 헷갈리는 용어

용어무엇을 하는가풀스택 개발자와의 차이
그로스 엔지니어실험과 전환 개선을 빠르게 구현합니다다루는 층은 비슷하게 넓지만 목적이 다릅니다. 제품 기능을 완성해 두는 대신 가설을 빨리 확인하려고 만들고, 결과가 나쁘면 만든 것을 그대로 걷어 냅니다

같이 보면 좋은 페이지

마지막 업데이트 2026-09-16