Web계 엔지니어 상세 카드

SECTION 01

Web계 엔지니어란

Web系エンジニアとは

한마디로 말하면, 자기 회사가 운영하는 웹서비스나 스마트폰 앱을 직접 기획 단계부터 참여해서 코딩하고, 출시한 뒤에도 계속 개선해나가는 직종이다.

SIer SE와 가장 다른 점: SIer는 "고객의 주문을 받아서" 만들지만, Web계 엔지니어는 "자기 회사의 서비스를 자기 손으로 직접 만든다." 내가 쓴 코드가 바로 유저(사용자)한테 전달되고, 유저의 반응을 보면서 바로 개선할 수 있다. 이 "만든 것이 바로 세상에 나가는" 감각이 Web계의 가장 큰 매력이다.

개발 방식도 다르다. SIer가 "처음에 전부 설계하고 → 만들고 → 납품"하는 워터폴(폭포) 방식이라면, Web계는 "작게 만들고 → 출시하고 → 유저 반응 보고 → 개선"을 빠르게 반복하는 애자일(민첩) 방식이 주류. 1-2주 단위로 새 기능을 출시하는 것도 흔하다.

Web계 엔지니어를 이해하는 3가지 포인트

① 기술력이 직접 요구된다 — SIer SE는 설계/관리가 메인이지만, Web계는 직접 코딩한다. 프로그래밍 언어, 프레임워크, 클라우드 등의 기술 스킬이 업무에 직결. 신졸이라도 "기초는 있다"는 전제로 채용하는 기업이 많다.

② 스피드와 자율성의 문화 — "완벽하게 만들어서 납품"보다 "빠르게 출시하고 고쳐나가자"는 문화. 개인의 재량이 크고, "이렇게 하면 어떨까요?"라고 제안하면 바로 시도해볼 수 있는 환경. 그 대신 자기 주도적으로 움직이지 않으면 아무도 시켜주지 않는다.

③ "유저"와의 거리가 가깝다 — 만든 기능이 바로 유저한테 전달되고, 유저의 반응(접속 수, 이탈률, 리뷰 등)을 데이터로 바로 확인할 수 있다. "내가 만든 것이 누군가의 생활을 바꾸고 있다"는 실감이 강한 직종.

Web계 엔지니어의 하루는 이런 느낌이다 (메가벤처 백엔드 엔지니어 3년차 예시)

10:00 출근(플렉스 타임). Slack 확인, 오늘 할 일 정리
10:30 데일리 스탠드업(매일 아침 짧은 팀 미팅, 15분) — 어제 한 것, 오늘 할 것, 막힌 것 공유
11:00 코딩 — 새 기능의 API(서버 쪽 처리) 개발
12:30 점심
13:30 코드 리뷰 — 팀원이 쓴 코드를 확인하고 피드백. 동시에 내 코드도 리뷰 받음
15:00 기획자(PdM)와 미팅 — 다음 스프린트(1-2주 단위 개발 기간)에 넣을 기능 논의
16:00 버그 수정 — 유저 리포트에서 발견된 문제 원인 파악 및 수정
17:30 배포(デプロイ) — 수정한 코드를 실제 서비스에 반영
18:30 퇴근 (집에서 개인 공부/사이드 프로젝트 하는 사람도 많음)

SIer SE와 뭐가 다른가? — 한눈에 비교

무엇을 만드나: SIer = 고객 맞춤형 업무 시스템 / Web계 = 자사 웹서비스/앱
누구를 위해: SIer = 고객(기업) / Web계 = 자사 유저(소비자 or 기업)
코딩 비중: SIer = 적음(설계/관리 중심) / Web계 = 높음(직접 코딩)
개발 방식: SIer = 워터폴(순서대로) / Web계 = 애자일(반복 개선)
출시 주기: SIer = 수개월-수년 / Web계 = 매일-매주
복장/분위기: SIer = 정장 or 비즈니스 캐주얼 / Web계 = 사복, 자유로운 분위기

솔직히 말하면: Web계 엔지니어의 현실

기술 공부가 끝나지 않는다. Web 기술은 변화가 극도로 빠르다. 작년에 배운 프레임워크가 올해 이미 구식이 될 수도 있다. 업무 시간 외에도 기술 블로그를 읽고, 새 기술을 시도해보는 "자기 투자"가 사실상 필수. 공부 자체가 즐겁지 않으면 버티기 어렵다.

신졸 미경험 채용은 쉽지 않다. SIer와 달리 Web계는 "입사 후 가르쳐준다"는 전제가 약한 기업이 많다. 신졸이라도 인턴 경험이나 개인 포트폴리오(직접 만든 앱/서비스)를 요구하는 곳이 늘고 있다.

서비스가 안 되면 바로 대응해야 한다. 자사 서비스에 장애가 생기면 밤이든 주말이든 대응해야 하는 경우가 있다. 특히 인프라/백엔드 담당은 장애 대응(온콜) 당번이 돌아올 수 있다.

그 대신, "자기가 만든 것이 수만, 수백만 유저에게 직접 전달되는" 체험은 다른 어떤 직종에서도 맛볼 수 없다. 그리고 기술력이 시장 가치에 직결되기 때문에, 실력을 쌓으면 이직/연봉 협상에서 강한 포지션을 가질 수 있다.

SECTION 02

Web계 엔지니어의 세분화

Web系エンジニアの細分化マップ

같은 "Web계 엔지니어"라도 무엇을 담당하느냐에 따라 필요한 기술과 일하는 방식이 다르다. 크게 나누면 프론트엔드, 백엔드, 인프라, 그리고 풀스택의 4가지.

먼저 용어부터 정리

프론트엔드 = 유저가 직접 보고 만지는 부분. 화면 디자인의 구현, 버튼을 눌렀을 때의 반응 등. HTML/CSS/JavaScript가 기본 기술.
백엔드 = 유저 눈에 보이지 않는 "뒤쪽" 처리. 데이터 저장, 계산, 로그인 처리, 결제 처리 등. Java, Python, Ruby, Go 등의 언어가 많이 쓰임.
인프라 = 시스템이 돌아가는 "토대." 서버, 네트워크, 클라우드(AWS 등) 환경을 구축하고 관리.
풀스택 = 프론트엔드부터 백엔드, 때로는 인프라까지 폭넓게 다루는 만능형. 소규모 스타트업에서 많이 요구됨.

포지션	무엇을 하나	주요 기술	특징
프론트엔드	유저가 보는 화면을 만듦. UI(유저 인터페이스) 구현	HTML, CSS, JavaScript, React, Vue.js, TypeScript	디자이너와 협업 많음. "보이는 것"을 만드는 보람. 기술 트렌드 변화 빠름
백엔드	데이터 처리, 비즈니스 로직, API 개발	Java, Python, Ruby, Go, PHP, SQL	서비스의 핵심 로직 담당. 대규모 트래픽 처리 등 기술 깊이가 요구됨
인프라/SRE	서버, 네트워크, 클라우드 환경 구축/운용	AWS, GCP, Docker, Kubernetes, Linux	"서비스가 안정적으로 돌아가게 만드는" 역할. 장애 대응이 미션. 자격증(AWS 등) 유리
풀스택	프론트+백엔드(+인프라)를 폭넓게 담당	위의 기술을 폭넓게	소규모 팀/스타트업에서 많이 요구. 혼자서 서비스를 만들 수 있는 힘. 재량 극대화

회사 유형도 알아두자

메가벤처 = 라쿠텐, Yahoo! JAPAN(LINE야후), 사이버에이전트, DeNA, 메루카리 등. 대규모 유저 기반, 안정적이면서도 기술 투자 적극적. 신졸 채용 있음.
성장 스타트업 = SmartHR, 머니포워드, freee 등. 성장 속도 빠르고 재량 큼. 소수 정예. 인턴/포트폴리오 중시.
자사 서비스 기업 = 특정 분야(EC, 미디어, 게임, 핀테크 등)의 자사 서비스를 운영하는 기업. 분야마다 기술 스택이 다름.

SECTION 03

Web계 엔지니어에서 보는 역량

Web系エンジニアに求められる力

Web계 채용에서 "이 사람은 맞겠다"고 판단하는 기준은? SIer가 "논리적 사고 + 커뮤니케이션"이었다면, Web계는 "기술력 + 자기 주도성 + 배움에 대한 집착"을 더 직접적으로 본다.

01

기술력 — "직접 만들 수 있는" 힘

Web계에서는 기술이 곧 실력이다. 어떤 언어를 쓸 수 있는가, 어떤 프레임워크를 다뤄봤는가, 실제로 뭘 만들어봤는가가 직접적으로 평가됨. 신졸이라도 인턴이나 개인 프로젝트에서의 경험이 강력한 무기.

02

자기 주도성 — 시키지 않아도 움직이는 힘

Web계의 문화는 "자율"이다. 누가 시키기를 기다리면 아무 일도 안 일어난다. "이거 개선하면 좋겠는데"라고 스스로 발견하고, 제안하고, 만들어보는 자세. 이 자기 주도성이 SIer와의 가장 큰 문화적 차이.

03

학습 속도 — 새 기술을 빠르게 흡수하는 힘

Web 기술은 변화가 극도로 빠르다. "지금 아는 것"보다 "새로운 것을 얼마나 빨리 배울 수 있는가"가 장기적 가치를 결정. 기술 블로그 읽기, 오픈소스 기여, 사이드 프로젝트 등 업무 외 학습이 사실상 일상.

04

논리적 사고 — 코드는 결국 논리의 조합

프로그래밍은 "A면 B, 아니면 C"를 빠뜨림 없이 설계하는 일. 복잡한 요구를 구조적으로 분해하고, 효율적인 처리 방법을 찾아내는 논리적 사고가 기본.

05

팀 개발 역량 — "좋은 코드"는 혼자 쓰지 않는다

Web계도 팀으로 개발한다. Git(코드 관리 도구)으로 여러 사람이 동시에 작업하고, 코드 리뷰(다른 사람이 쓴 코드를 확인/피드백)가 일상. "다른 사람이 읽기 쉬운 코드를 쓰는 것"도 중요한 역량.

SECTION 04

커리어패스

Web系エンジニアのキャリアパス

Web계 엔지니어의 커리어는 "기술을 무기로 시장 가치를 올려나가는" 타입. SIer보다 이직이 활발하고, 실력이 곧 시장 가치에 직결되는 세계.

1년차

주니어 엔지니어

선배의 지도를 받으며 소규모 기능 개발, 버그 수정부터 시작. 코드 리뷰를 통해 "좋은 코드란 무엇인가"를 배움. 사용하는 언어/프레임워크에 익숙해지는 시기.

2-3년차

미들 엔지니어

하나의 기능을 처음부터 끝까지 혼자 설계/구현할 수 있게 됨. 기술 선택에 대한 자기 의견이 생기기 시작. 이 시기에 "프론트/백엔드/인프라 중 어디를 깊이 팔 것인가"가 보임.

4-6년차

시니어 엔지니어 / 테크리드

팀의 기술적 의사결정을 리드. "이 문제는 이 기술로, 이 구조로 풀자"를 제안하고 결정. 후배 엔지니어의 멘토 역할. 기술 블로그나 컨퍼런스 발표로 사외에도 인지도를 쌓는 사람도.

7년차 이후

여기서 길이 갈린다

길A: 기술 전문가(아키텍트/IC) — 시스템 전체의 기술 설계를 총괄. 관리직이 아닌 기술의 최고봉(Individual Contributor).
길B: 엔지니어링 매니저(EM) — 엔지니어 팀을 관리. 채용, 육성, 팀 생산성 향상이 미션. 기술+사람 관리 양쪽.
길C: PdM(프로덕트 매니저) — "무엇을 만들 것인가"를 결정하는 역할. 기술 이해+비즈니스 감각.
길D: CTO/VPoE — 회사 전체의 기술 전략을 이끄는 경영진. 스타트업이면 비교적 빨리 도달 가능.
길E: 프리랜서/독립 — 실력이 있으면 조직에 속하지 않고 일할 수 있는 것도 Web계의 특징.

SECTION 05

ES/채용 포인트

Web系エンジニア採用のポイント

Web계 엔지니어 채용은 SIer과 방식이 꽤 다르다. ES(엔트리시트)보다 "기술 시험 + 포트폴리오 + 면접"으로 평가하는 기업이 많다.

Web계 채용의 전형적인 흐름

① 서류 (이력서 + 포트폴리오) — 직접 만든 앱/서비스/GitHub 링크를 제출하는 경우가 많음. ES 대신 이것이 1차 관문
② 코딩 테스트 — 온라인으로 알고리즘 문제를 풀거나, 과제형(작은 앱을 만들어서 제출)인 경우도
③ 기술 면접 — "이 코드를 왜 이렇게 썼는가", "이 설계의 장단점은" 등 기술적 사고를 깊이 확인
④ 컬쳐 핏 면접 — 회사의 문화/가치관과 맞는가를 확인. "왜 이 회사인가"보다 "어떤 환경에서 어떻게 성장하고 싶은가"를 봄

포트폴리오가 최강의 무기

Web계에서는 "뭘 만들어봤는가"가 말 100마디보다 강하다.

좋은 포트폴리오: 실제로 동작하는 웹앱/서비스. GitHub에 코드가 공개되어 있고, README(설명)도 정리. "왜 이것을 만들었고, 어떤 기술을 사용했고, 어떤 과제를 어떻게 해결했는가"를 설명할 수 있으면 최강.
없는 것보다 나은 포트폴리오: 프로그래밍 학습 사이트의 과제를 응용해서 만든 것이라도 OK. "만들어본 경험이 있다"는 것 자체가 무경험보다 훨씬 강력.
약한 포트폴리오: 튜토리얼을 그대로 따라만 한 것. "자기 생각으로 뭔가를 추가하거나 변형한" 흔적이 없으면 차별화 안 됨.

프로그래밍 미경험인데 Web계에 가고 싶다면

솔직히 말하면, Web계는 SIer보다 미경험자 채용 문턱이 높다. 하지만 불가능하지는 않다.

방법 1: 인턴부터 — 대학 재학 중 장기 인턴으로 실무 경험을 쌓는 것이 가장 현실적. 일본에서도 엔지니어 인턴 채용이 늘고 있음.
방법 2: 독학+포트폴리오 — Progate, Udemy 등으로 기초를 배운 뒤, 자기만의 앱/서비스를 만들어서 포트폴리오로 제출.
방법 3: SIer로 먼저 들어간 뒤 이직 — SIer에서 2-3년 경험을 쌓고 Web계로 이직하는 패턴도 현실적. 다만 SIer에서 코딩 경험을 쌓을 수 있는 포지션인지 확인 필요.

SECTION 06

면접에서 자주 파고드는 질문

面接で掘り下げられるポイント

Web계 면접은 "기술적 사고의 깊이"와 "왜 이 회사/이 서비스인가"를 집중적으로 본다. 아래 질문을 클릭하면 답변 방향을 볼 수 있다.

Q 왜 SIer가 아니라 Web계(자사 서비스)를 선택했는가?

Web계 면접의 핵심 질문. "자기 손으로 직접 만들고, 유저의 반응을 보면서 개선해나가는 것에 매력을 느낀다"가 기본 방향. "설계서를 쓰는 것보다 코드를 쓰고 싶다", "유저와의 거리가 가까운 환경에서 일하고 싶다" 등 SIer와의 구체적 차이를 이해한 위에서 답할 것.

Q 지금까지 만들어본 것 중 가장 자신 있는 것은?

포트폴리오 기반 질문. "뭘 만들었는가"뿐 아니라 "왜 만들었는가, 어떤 기술적 과제가 있었고, 어떻게 해결했는가"를 구조적으로 설명. 결과물 자체의 완성도보다 "사고 과정"을 더 높이 평가하는 기업이 많다.

Q 우리 서비스를 써본 적이 있는가? 개선점은?

지원하는 회사의 서비스를 실제로 써보고 가는 건 기본. "좋았다"만으로는 부족. "이 기능은 이런 이유로 좋은데, 이 부분은 이렇게 바꾸면 유저 경험이 더 좋아질 것 같다"는 식의 구체적 제안. 엔지니어 관점에서 "이 기능은 기술적으로 이렇게 구현되어 있을 것 같다"까지 말하면 강력.

Q 새로운 기술을 어떻게 학습하는가?

학습 의욕과 방법을 보는 질문. "공식 문서를 읽고 → 작은 프로젝트로 직접 시도해보고 → 막히면 커뮤니티에서 질문한다" 같은 구체적 프로세스. 최근에 배운 기술이 있으면 구체적으로 언급. "누군가 가르쳐주면 배운다"는 수동적 자세는 NG.

Q 프론트엔드/백엔드/인프라 중 어디에 관심이 있는가?

기술 방향성을 보는 질문. "다 관심 있다"보다는 하나를 골라서 "왜 그 영역에 끌리는가"를 설명. 예: "유저가 직접 만지는 화면을 만드는 프론트엔드에 끌린다. UX(유저 경험)를 기술로 개선하는 것에 보람을 느끼기 때문." 아직 확실하지 않으면 "지금은 ○○에 관심이 있고, 실무를 경험하면서 결정하고 싶다"도 OK.

Q 팀 개발 경험이 있는가?

Web계도 팀으로 개발한다. Git을 사용한 공동 개발, 코드 리뷰, 역할 분담 등의 경험이 있으면 강력. 없으면 "개인 프로젝트에서 Git을 사용해 버전 관리를 했다" 정도라도. 해커톤(단기간 팀 개발 이벤트) 참가 경험은 매우 좋은 어필 포인트.

Q 업무 외에도 기술 공부를 하는가?

Web계에서 이건 거의 "당연히 한다"를 기대하는 질문. "한다"고 답하되, 구체적으로 "뭘 하고 있는가"를 보여줘야 한다. 기술 블로그 읽기, 개인 프로젝트, 오픈소스 컨트리뷰션, 기술 서적, 온라인 강의 등. "강제가 아니라 즐거워서 한다"는 자세가 포인트.

SECTION 07

자기분석 키워드 연결

自己分析キーワードとの接続

자기분석에서 찾은 강점이 Web계 엔지니어에서 왜 쓸모 있는지를 설명할 수 있어야 한다. "코딩이 좋으니까 Web계에 맞다"가 아니라, "어떤 성향이 Web계의 어떤 환경과 맞는가"까지.

향상심

Web 기술은 변화가 극도로 빠르다. "지금에 만족하지 않고 계속 더 나은 방법을 찾는" 자세가 필수. 이 업계에서 향상심이 없으면 1-2년 만에 뒤처진다.

주체성

Web계의 문화는 "자율." 시키지 않아도 문제를 발견하고 개선안을 제안하는 사람이 가치를 만든다. "누가 가르쳐주겠지"가 아니라 "스스로 찾아서 해결한다"는 자세.

탐구심

"왜 이 코드는 이렇게 동작하지?" "더 효율적인 방법은 없을까?"를 파고드는 호기심. 기술을 "도구"로만 보는 사람과 "탐구 대상"으로 보는 사람의 성장 속도 차이는 크다.

논리적사고력

코딩은 논리의 조합. 복잡한 요구를 분해하고, 빠뜨림 없이 처리하는 구조를 설계하는 힘. 버그(오류)를 찾을 때도 "왜 이 현상이 일어나는가"를 논리적으로 추적하는 능력이 핵심.

도전정신

새 기술에 뛰어들기, 아직 아무도 풀지 못한 문제에 도전하기, 서비스를 처음부터 만들어보기. Web계는 "안전한 길을 가는 사람"보다 "새로운 것에 뛰어드는 사람"이 성장하는 환경.

협조성

"천재 프로그래머 혼자서"가 아니라 팀으로 만든다. 코드 리뷰에서 건설적 피드백을 주고받고, 다른 포지션(디자이너, PdM)과 소통하며 서비스를 함께 개선하는 자세.

ES/면접 연결 예시 (Web계 엔지니어 지망)

"대학에서 독학으로 프로그래밍을 시작해, 개인적으로 할 일 관리 앱을 만들어 공개한 경험이 있습니다. 유저로부터 '이런 기능이 있었으면'이라는 피드백을 받고 바로 기능을 추가해 업데이트했을 때, '자기가 만든 것이 누군가에게 도움이 되고, 그 반응을 바로 볼 수 있는' 것에 깊은 보람을 느꼈습니다(향상심 + 주체성). 귀사의 서비스에서도 유저에게 가장 가까운 곳에서 가치를 만드는 엔지니어가 되고 싶습니다."

SECTION 08

주의점 / 빠지기 쉬운 함정

Web系エンジニアの落とし穴

Web계 엔지니어를 지망하는 학생들이 자주 빠지는 함정을 모았다. 해당 사항이 있으면 지금이라도 수정하면 된다.

함정 1: "코딩이 좋아서" 만으로는 부족하다

"코딩이 좋다"는 출발점으로는 좋지만, Web계 면접에서는 "그래서 뭘 만들어봤는가"를 반드시 묻는다. 좋아하는 것과 실제로 만들어본 것은 다르다. 포트폴리오(직접 만든 것)가 없으면 "좋아한다"의 증명이 안 된다.

함정 2: 미경험인데 Web계 "만" 지원하는 것

Web계는 SIer보다 미경험자 채용 문턱이 높다. 인턴 경험도 포트폴리오도 없이 Web계만 지원하면 전멸할 수 있다. "Web계가 제1지망"이더라도, SIer 등을 병행 지원하는 현실적 전략이 필요. 혹은 SIer에서 2-3년 경험 후 Web계로 이직하는 루트도 충분히 현실적.

함정 3: "자유로운 환경 = 편한 환경"이라는 착각

사복 출근, 플렉스 타임, 리모트 워크. Web계의 자유로운 분위기에 끌리는 학생이 많지만, 자유는 "자기 관리 능력"을 전제로 한다. 누가 시켜주지 않으니까 스스로 일감을 찾고, 스스로 일정을 관리하고, 스스로 성장해야 한다. "자유 = 편하다"가 아니라 "자유 = 자기 책임이 크다"라는 것을 이해할 것.

함정 4: 기업 규모/지명도만 보고 선택

라쿠텐, 메루카리 같은 유명 기업에만 눈이 가기 쉽지만, Web계에서 중요한 건 "어떤 기술을, 어떤 환경에서 경험할 수 있는가." 소규모 스타트업은 재량이 크고 성장이 빠를 수 있고, 대기업은 대규모 시스템 경험을 쌓을 수 있다. "유명 회사"가 아니라 "나의 기술적 성장에 가장 좋은 환경이 어디인가"로 선택할 것.

함정 5: "업무 외 공부"를 하기 싫다면 각오가 필요

Web계에서는 업무 시간 외의 기술 학습이 사실상 "문화"이다. 강제는 아니지만, 하지 않으면 주변과의 격차가 빠르게 벌어진다. "일은 일이고 퇴근 후에는 공부 안 하고 싶다"는 자세가 나쁜 건 아니지만, Web계에서는 그 자세로 장기적으로 성장하기 어렵다는 현실을 알고 선택할 것.