프론트와 백을 나누지 마세요
프론트와 백을 나누는 이유가 무엇인가? 90년 대까지만 해도 이런 단어는 없었다. 모두 개발자라고 불렀었는데 어느 순간 비전공자들이 개발로 몰리면서 그들은 html과 JS 밖에 할 줄 모르니까 프론트라는 틀을 만들어 버렸다. 웹 개발 시장 자체가 겨우 30%정도 형성되어 있는데 그 속에서도 프론트와 백을 나눠버리면 자신의 몸 값을 오히려 낮추는 행위라고 생각한다.
프론트엔드 개발자라고 하더라도 실행 속도를 늘리기 위해 웹 어셈블리(C, C++, Rust 같은 언어로 작성한 코드를 브라우저에서 직접 실행할 수 있게 만든 기술)를 사용해야 할 때도 있다. 이 때는 C로 코드를 작성해야 하는데 프론트만 했던 사람이라면 과연 C로 작성할 수 있겠는가?
시야를 넓게 보세요
3티어 아키텍처라고 들어봤는가? 예전엔 프리젠테이션 계층, 비즈니스 로직 계층, 데이터 계층으로 나눴었다. 흔히 프론트, 백, 그리고 DB로 나눈 것이다.
개발은 여러 직군이 있다. dev, 개발팀, QA, DB, 네트워크, IOT 등등이 존재한다.
좀 더 큰 회사에서는 프론트, 백 이런 개념이 없다. 소프트웨어 엔지니어, 서버 엔지니어, dev 엔지니어 이렇게 불린다.
프론트엔드 개발자라도 알고리즘, 자료구조 지식이 있는 사람이 설명하는 기술 설명과 아예 배경 지식이 없는 사람이 설명하는 기술 지식은 확연히 다르다.
취업 이야기
신입은 일단 눈을 낮춰서 배울 수 있는 곳으로 들어가는 게 좋다. 그리고 2번 째와 3번 째를 노려라. 그때 실력이 있느냐 없느냐로 개발자의 길이 가릴게 된다.
중견이나 대기업은 인사팀 권한이 막강한데 인사팀이 기술에 대한 지식은 전무해서 학력, 스팩 등 눈에 보이는 것 위주로 본다. 하지만 스타트 업은 당장 일을 할 수 있는 사람을 구하기 때문에 기술 지식을 중요하게 생각한다.
면접관들이 포트폴리오를 열심히 볼거라고 생각하겠지만 그렇지 않다. 보통 1인 프로젝트를 했다고 하면 어디서 소스 코드를 가져왔다고 생각한다(효과 없음). 면접자에게 어떤 질문을 해야할 지 참고하는 정도로만 본다고 한다.
흔히 프로젝트라고 불리는 단위는 유저가 100명 이상 있을 때 그렇게 부른다. 유저가 많아지면 많아질 수록 로드밸런싱이나 아무튼 배워야 될 게 많은 데 그런 기술에 대한 고민을 해본 사람을 긍정적으로 본다.
기술 스택이 약해도 협업 할 줄 아는 사람을 기업은 원한다. 여기서 협업이란 단순히 프로젝트를 많이 한 것을 협업으로 생각하지 않는다. 팀 프로젝트를 같이 해도 실력이 좋은 사람은 혼자 여러 기능을 개발하려는 경향이 있다. 하지만 각각 개발 후 합칠 때 문제가 생겨서 완성을 못한다면 평가를 할 수가 없고, 결국 0점이나 마찬가지이다. 이 같은 문제를 막기 위해서는 잘하는 사람은 못 하는 사람을 백업해줘야 하고, 만약 잘하는 사람이 자기 혼자 개발하려고 한다면 다른 팀원은 그 분을 설득해서 서로 백업할 수 있는 환경을 만들어야 한다. 이런 백업이 모여서 프로젝트를 완성시킨다.
누구에게나 타이밍이 존재한다. 취업에 대한 불안감이 크겠지만 그 타이밍이 오기 전까지 자신의 실력을 갈고 닦기 위해 최선을 다하면 된다.
프론트를 해야할 지 백을 해야할 지에 대한 고민을 많은 학생들이 한다고 합니다. 하지만 지금은 당장의 문제를 해결하는 데 집중하고 나만무 때 가서 고민을 해도 늦지 않다.
나이 때문에 고민이 될 수도 있겠지만 기술직은 나이보다는 실력을 먼저 봅니다.
자신의 기술 스택을 과장해서 이야기할 필요 없다. 면접관들은 그 사람이 팀과 함께할 수 있는 사람인 지를 중점으로 본다.
트렌드는 빠르게 바뀌고 있다
요즘 트렌드는 기능 개발 뿐만 아니라 TDD를 무조껀 하는 방향이다. 기능 개발 할 때 단위 테스트는 빼 먹지 마라. 결국 테스트를 하지 않고 나중에 서버 올리고 나서 발생한 에러를 잡는 것보다 테스트를 해가며 안전하게 가는 방향이 훨씬 빠르기 때문이다.
예전까지만 해도 기업에서는 폭포수 모델(요구사항 → 설계 → 구현 → 테스트 → 배포 → 유지보수)을 사용했다. 근데 이렇게 하면 개발 기간이 오래 걸리고, 만들고 나서도 시장에서 팔리는 않는 문제가 생겼다. 그래서 에자일(작은 단위로 빠르게 만들고, 테스트하고, 피드백을 반영하면서 개선해 나가는 구조)을 많이 쓴다고 한다.
