[준비하기] (9) 기술 면접 + 부록

productuidev·2022년 5월 10일

개발자취업 비전공자개발자 인프런 커리어가이드

개발자 준비하기

목록 보기

19/19

인프런 비전공자를 위한 개발자 취업 올인원 가이드 강의 정리

(9) 취업하기 편 : 기술 면접

1. 기술 면접은 어떤 면접인가?

0) 신입 개발자 채용 면접은 어떻게 진행되는가?

서류 전형 > (코딩 테스트 or 사전 과제 전형) > 1차 면접 > 2차 면접 > (3차 면접) > 합격
1차 면접
ㄴ 기술 면접
ㄴ 면접관 : 실무진(개발 팀장, 시니어 개발자)
2차 면접
ㄴ 기술 면접 or 문화적합성 면접
ㄴ 면접관 : CTO, 임원급 직원, 인사담당자 등
블라인드 채용
ㄴ 코딩 테스트 or 사전 과제 > 서류 전형 > 1차 면접 > 2차 면접 > (3차 면접) > 합격

1) 기술 이해도 평가

A. 이력서와 포트폴리오에 기재된 기술 스택
B. 회사에서 사용하는 기술 스택
C. CS(Computer Science) 기초

A ∩ B : 채용공고의 내용을 잘 기록해서 내가 보유한 기술 스택과 지원한 회사가 필요로 하는 기술 스택의 연관성을 빨리 찾자

C : 기술에 기반이 되는 기초적인 질문

OO 기술의 핵심 개념들은 무엇이 있고, 설명할 수 있는지

OO 기술의 핵심 개념들과 연결되는 기초적인 CS지식들을 제대로 이해하고 있는지

다른 대체 기술을 사용하지 않고 OO 기술을 사용한 이유

OO 기술의 한계는 무엇이고, 한계 상황에서 어떻게 대처할 것인지

기초적인 CS 지식, 주 개발 언어와 관련된 기초 지식 질문

2. 성장 가능성 평가

신입 개발자는 당장의 실무 능력보다 앞으로 얼마나 빠르게 팀과 업무에 적응할 수 있을지를 더 비중있게 평가
비전공자에게는 더욱 중요한 평가 요소
면접관들은 대부분 전공자 출신에 개발을 오랫동안 해오신 분들이다
전공자들이 어떤 것들을 배우고 익혔는지 알고 있는 만큼, 비전공자들이 전공자에 비해 부족한 부분들도 알고 있다.
그럼에도 불구하고 비전공자를 면접에 불러들인 이유는, 성장 가능성(잠재력)을 기대하기 때문이다

일반직 : 태도, 기세, 말하는 톤
기술직 : 비언어적인 요소보다는 증명할 수 있는 사실

성장 가능성(잠재력)을 어필하려면 증거가 필요하다

개발을 얼마나 좋아하는지 보여주세요

Github, 개발 블로그, 이력서, 포트폴리오 이 모든 것들이 증거가 된다.
핵심은 본인이 얼마나 개발을 즐기고 있고, 얼마나 열정적으로, 진지하게 개발자로서 성장하려는 의지가 있는지 보여주는 것이다.
비전공자라면 왜 개발자가 되려는지 그 이유에 대해 답변할 준비를 해야한다.


// BAD (수동적인 이유)

개발자라는 직업이 인기가 많아서
다른 분야는 취업이 어려워서
코딩이 멋있어 보여서

// GOOD (능동적인 이유)

나는 비전공자로 이러이러하게 살아왔는데
어떤 계기로 개발을 접하게 되었으며
개발을 해보다 보니 너무 재미를 느껴서 몰입했고
어떤 개발자로 성장해서
어떤 개발을 목표를 하고 있다

// 만약 아직 이유가 명확하지 않다면 진지하게 생각해보고 면접용 답변을 만들자

3. 의사소통 능력 평가

개발자는 전적으로 협업하는 직업 (with 개발자들, 기획자, 디자이너 등등)
면접에서 의사소통 능력을 반드시 평가
대놓고 '지금부터 의사소통 능력을 평가하겠습니다'라고 알려주지 않는다.
면접 중에 오고 가는 대화를 통해 은연중에 지원자의 의사소통 능력을 평가한다.
코딩 테스트에서 만점을 받고 기술 이해가 완벽해도, 의사소통 능력이 부족하면 면접에서 탈락한다.
실제 이전 회사에서도 뛰어난 개발 실력을 갖춘 지원자들이 의사소통 능력 부족으로 탈락하는 경우가 많았다.
의사소통 능력 != 뛰어난 언변

여기서 말하는 의사소통 능력이란,
1) A에 대해 질문했을 때, A에 대해 답변하는 능력
2) 다른 사람들과 협업하면서 발생한 문제를 해결하기 위해 사용한 의사소통 방식
3) 그 밖에 팀 프로젝트에서 어떻게 대처했는지 (협업상황에서 의사소통 방식)

면접관은 실력이 약간 부족하더라도, 기존 팀원들과 팀워크가 잘 맞을 것 같은 지원자를 채용한다.
개발을 아무리 잘해도, 기존 팀원들과 소통이 안되면 불필요한 자원이 낭비된다. (개발자는 회사에서 제일 비싼 자원에 속함)

강사가 생각하는 의사소통을 잘하는 사람
경청을 잘하고, 다른 사람과 생각이 다르더라도 그 의견이 합당하면 잘 수긍할 수 있는 사람
면접에서 자기 의견을 너무 내세우면서 고집을 부리기보다는 면접관의 의견을 잘 경청한 후
본인이 유연하고 합리적인 사람이라는 것을 어필하는 것이 중요

5.2 기술 면접 준비 방법

0. 추천하는 기술 면접

a. 기술 면접에 대비하기 위한 학습 범위와 우선 순위를 정한다.
b. 면접에 자주 나오는 질문들을 한글/영문으로 검색해서 정리한다.
c. 학습 내용을 본인의 문장으로 정리하고, 말로 설명할 수 있을 때까지 학습한다.
d. 최소한 면접 3일 전부터 모의 면접을 진행한다.

1. 학습 범위와 우선 순위 정하기

개발 기술은 광범위하고 깊이도 깊기 때문에, 모든 내용을 준비하겠다는 욕심은 버려야 한다.
신입 개발자 채용 면접인 만큼, 중요한 기술들에 대해 제대로 답변하는 것을 목표로 준비

학습 범위 & 우선 순위

나의 이력서/포트폴리오의 기술 스택에도 있고, 지원한 팀에서도 쓰는 기술들

지원한 팀에서는 사용하지 않지만, 나의 이력서/포트폴리오의 기술 스택에 기재한 기술들

주로 사용하는 프로그래밍 언어 (Java, Python, JavaScript 등)

위의 언어와 함께 쓰이는 프레임워크 (Spring, Django, React.js, Vue.js 등)

Computer Science 기초 (운영체제, 자료구조, 네트워크 등)

2. 면접에서 자주 나오는 질문들을 한글/영문으로 검색해서 정리 (예상 질문 리스트 만들기)

신입 개발자 면접에서 자주 나오는 질문들은 어느 정도 정해져있다.
예시 - 백엔드 개발자
'Java 면접 질문' 'Java Interview Question'
구글링 등을 통해 정보 서칭, 기본서 공부 후 면접 포인트에 맞춰서 준비
검색 결과는 Notion 같은 메모 공간에 최대한 모아서 예상 질문 리스트 만들기
갑작스럽게 원하는 회사의 공고가 떠도 준비할 수 있도록 (커리어 관련된 대비 자료를 따로 모아놓기)

3. 학습 내용을 본인의 문장으로 정리하고, 말로 설명할 수 있을 때까지 학습

예상 질문 리스트의 양이 방대해지면, 다른 사람이 작성한 내용을 복/붙하거나 대충 보고 넘어가기 쉽다.
자신의 입으로 말하려면, 자신의 문장으로 말하려는 내용을 작성해봐야 한다
자신의 문장으로 정리하지 않으면, 실제 면접에서 내용이 기억나지 않거나 말을 버벅거리게 된다.

4. 최소한 면접 3일 전부터 모의 면접 진행

도와줄 사람이 있다면...
예상 질문 리스트를 주고 면접관처럼 질문해달라고 부탁 (Zoom, Google Meet 활용)
도와줄 사람이 없다면...
예상 질문 리스트에 있는 질문들에 대해 입으로 소리 내서 답변 해보기
제대로 답변하지 못하는 질문들이 반드시 발견될 것이다. 제대로 이해하지 못했기 때문이므로 다시 공부한다.
최소한 3일 전부터 모의 면접을 진행해야 제대로 이해하지 못한 부분들을 다시 학습할 수 있다.
면접 전날과 면접 당일에는 새로운 내용을 추가하기보다는, 지금까지 준비한 내용을 복습하는 것이 좋다.

번외) 면접이 끝나면 면접 내용을 반드시 복기해서 기록해두기

이력서나 포트폴리오에 큰 변화가 없다면, 다른 회사에서도 비슷한 질문을 받을 가능성이 굉장히 높다.
면접이 끝나고 바로 복기하지 않으면, 자세한 내용이 기억나지 않을 것이다. 반드시 면접 직후에 자세하게 기록해야 한다.
이 기록이 본인에게 가장 큰 도움이 되는 면접 준비 자료가 된다.

합격/탈락과 상관없이 내가 부족한 부분이나 헛점을 발견할 수 있는 자리인 만큼 면접 후 최대한 자세하게 떠올려보기

5.3 기술 면접 대비 자료 모음

1. Technical interview Guidelines for Beginners

오픈소스 깃헙 저장소 (Jbee)
50명의 이상의 컨트리뷰터 참여
Reverse Interview : 면접에서 회사에 궁금한 점을 물어볼 때 참고
방대한 양의 기술 면접 준비 자료가 카테고리별로 잘 정리되있다

2. 신입 개발자 전공 지식 & 기술 면접 백과사전

가이드 형식의 블로그
내용이 비교적 단순해서 빠르게 접근하고 확인하는 용도

3. Tech Interview

3명의 컴퓨터 공학부생이 직접 기술 면접을 준비하면서 면접 대비 내용을 정리한 저장소
질문 답변 연습
방대한 양의 기술 면접 준비 자료가 카테고리별로 잘 정리되있다

4. 프론트엔드 개발 인터뷰 핸드북

Front-end Job Interview Questions 한글 번역판
HTML, CSS, JavaScript 3가지 주제만 다룸
프론트엔드 뿐만 아니라 웹을 개발하는 모든 개발자에게 유익

5. 우아한 Tech - 10분 테코톡

우아한 테크코스에 참여중인 개발자 준비자분들이 각자 한 가지 주제에 대해 10분 내외로 발표한 영상
한 가지 주제만 다루고 누군가 설명해주는 영상이기 때문에 글로 된 자료보다 이해가 잘 됨
경력 개발자가 쓴 내용이 아니기 때문에 깊이에 한계

6. Coding Interview University

Google 인터뷰를 위해 8개월 동안 풀타임으로 공뷰한 이유라는 글을 쓴 미국 개발자가 만든 저장소
미국 실리콘밸리 코딩 인터뷰 준비하기 위한 자료라 국내 취업 대상에는 다소 거리가 있으나 개발자에게 도움되는 내용
자료구조와 알고리즘에 대해서는 한국의 다른 자료들보다 훨씬 풍부한 내용이 담겨있다 (실리콘밸리 취업을 준비한다면 유용)

7. Tech Interview Handbook

코딩 인터뷰를 준비하는 방법의 A부터 Z까지 자세하게 가이드해주는 문서
한국에서의 개발자 취업과는 조금 거리가 있는 내용들이지만
언젠가 해외나 미국 실리콘 밸리 개발자로 일할려는 목표가 있다면 반드시 참고하는 것이 좋은 자료

10. Knowre의 신입 웹 개발자 교육을 위한 웹 개발 교육 커리큘럼

부록 : 한 발자국 앞에서 전하고 싶은 이야기들

신입 개발자로 입사하기 전에 알아두면 좋은 것들

1. 입사하기 전에 알아두면 좋은 것들

1. 질문을 잘하는 방법

질문을 잘하는 개발자 필독!
질문을 하자!
ㄴ 질문하지 않으면 절대 알 수 없는 것들 (회사 내 서버 정보, 보안 설정, 협업 규칙, 자체 라이브러리 사용 등)

ㄴ 능동적으로 행동
누군가 알려주겠지, 질문하지 않고 알아서 하는 것 (x)
필요한 정보를 얻기 위해 자발적으로 질문하는 것 (o)

ㄴ 정보가 부족한 상황에서 무작정 행동하여 문제를 일으키기 보다는, 질문하는 것이 백배 천배 낫다.
질문을 하지 말자!
ㄴ 동료 개발자에게 질문하지 않아도 구글링을 통해 알 수 있는 정보들 (스택오버플로우, 개발블로그 등에서 확인 가능한 정보)
ㄴ 구글링 한 번 해보지도 않고 무조건 동료 개발자들에게 질문하는 것은 동료 개발자의 시간을 빼앗는 행동
ㄴ 개발자들은 업무에 집중하면 Context(맥락)에 갇힌다. 업무에 집중하고 있는 개발자에게 질문하면 Context Switch 발생
ㄴ Context Switch가 발생하면, 질문 받은 개발자의 집중력과 생산성을 떨어뜨리며 반복되면 스트레스가 된다.
ㄴ 질문하기 전에, 구글링으로 해결할 수 있는 질문인지 잠깐이라도 고민해보고 구글링 해보는 습관 필요

동료 개발자의 시간을 배려해주는 개발자가 되자

2. Git-Flow 사용 방법

Git-Flow는 일종의 Git 브랜치 전략
개발자들 각자 작성한 코드를 어떤 방식으로 통합하고 관리하고 배포할 것인지에 대한 전략 (협업 방식 중 하나)
팀의 상황에 맞게 Git-Flow를 변형해서 사용하기도 하지만 기본적으로 Git-Flow 기반
협업하는 방식이나 체계가 정해져 있지 않은 회사인 경우, 팀 리드/팀원들과 같이 논의 후 도입하는 것도 하나의 방법 (강사의 경험담)

Git-Flow를 알아두면 좋은 이유

Git-Flow를 미리 알고 있으면, 팀에서 어떤 방식으로 Git branch를 관리하는지 파악하기 쉽다.

Git-Flow를 제대로 이해하지 못한 상태에서 협업을 진행하면, 프로젝트의 Git Branch가 꼬일 가능성이 높다. (팀원들이 고생한다)

프로젝트를 개발하고, 버그를 수정하고, 새로운 버전을 출시하는 등의 프로젝트 라이프 사이클을 이해하기 쉬워진다.

참고하기 좋은 자료들

생활코딩 Git Flow Model 강의

우아한 형제들 기술 블로그 우린 Git Flow를 사용하고 있어요

Git-Flow Cheatsheet

3. 기본적인 리눅스 명령어

회사에서 사용하는 대부분의 서버는 리눅스 환경으로 구성된다.
자주 사용되는 기본적인 명령어만이라도 알아두는 것이 좋다.
입사하면 동료 개발자들은 전공자일 가능성이 높다. 전공자에게 리눅스 명령어는 당연히 알아야 하는 것

참고하기 좋은 자료들

만화로 배우는 리눅스 시스템 관리

인프런 강의 : 리눅스 커맨드라인 툴

유튜브 강의 : Linux Sysadmin Basics

37 Important Linux Commands You Should Know

2. 개발자의 길에 도전하며 도움 되었던 마음가짐

1. This is not rocket science!

"이거 어려운 일 아닌데! (왜 어렵게 생각해?)"
우주로 로켓을 쏘는 과학에는 정말 답이 없을 수 있지만, 내 수준에서 만나는 문제들은 반드시 문제의 원인과 답이 있다.
개발자에게 문제 상황은 계속 발생하는데, 마음가짐에 따라 문제 해결 성공률이 달라진다.
자기 자신에게 "별 거 아닌 일에 청승 떨지 마라!"고 다그치는 역할

2. 먼 산 바라보듯 바라보기

이미 저 멀리 앞서가는 개발자들을 보면, 도저히 따라잡을 수 없을 것 같아 개발자로 성장하려는 의욕이 떨어졌다.
강사의 생각 정리
ㄴ 인정하자. 잘하는 개발자들의 저 경이로운 실력은 그들이 개발에 쏟아온 시간과 노력에 대한 정당한 보상이다.
ㄴ 나는 나대로 열심히 살아왔고, 다양한 분야에 도전해온 것은 시간 낭비가 아니라 값진 경험이다.
ㄴ 조급해하지 말고, 나와는 관계없다는 생각으로, 먼 산 바라보듯 슈퍼개발자들을 바라보자.
ㄴ 언젠가 저 산에 오를 수 있다고 믿고, 나만의 속도로 꾸준히 성장하면 된다.

나와 별개의 잘하는 사람을 기준 삼지 말자.

3. Wingspan이 상관 없는 직업

미국 프로농구 키 만큼이나 팔 길이가 중요한 스펙 (신체적인 능력)
선천적인 능력이 중요한 직업이 아니다.
개발 실력 차이 = 투입한 시간과 노력의 차이 (o) 선천적 능력 차이 (x)
시간과 노력을 투자하면 된다는 마음가짐과 실천이 중요한 직업

3. 개발자로서의 나의 롤모델

4. 자주 묻는 질문들 (FAQ)

1. 정보처리기사 자격증 꼭 따야 하나요?

보통 주변에서 하니까 덩달아 하게 되는 경우가 많다.
SI 회사/프로젝트 투입 개발자(프리랜서 개발자)에게는 필요할 수도 있다 (서비스회사에서는 불필요)
정보처리기사 자격증 공부가 도움되지 않는 것은 아니다. 하지만 다른 학습 방법을 활용하는 것이 더 효율적이다.

💬

공공 SI/금융 프로젝트 개발(프리랜서)인 경우 필요할 수도 있는 것 같다

투입인력의 등급/단가가 정해진 경우가 있기 때문에.. by KOSA (한국소프트웨어산업협회)

아주 간혹 자격증 수당을 주는 회사도 있는 것 같다

2. 방통대/사이버대 컴퓨터공학 학사 학위를 따야 할까요?

개인적으로 비추천 (강사가 느낀 점 : 개발자에게 학력은 의미가 없더라)
다른 분야는 학벌, 학력을 중요시하는 회사들이 많지만, 개발 분야는 전혀 아니다.
개발자의 학벌과 학력을 중요시 하는 회사라면 좋은 회사가 아닐 가능성이 매우 높다.
간혹 질문하는 사람 중 학력 컴플레스가 너무 심한 분들은 학사 학위를 따는 것도 좋다고 생각한다.
ㄴ 자신의 취약점을 학력과 연결하는 경우가 있어 자신감을 얻고자 한다면 (피해의식 뿌리뽑기)
강사가 생각하는 학위의 가치 == 대학교를 다니면서 하게 되는 다양한 경험, 인적 교류 등의 가치 (학위 자체가 가치있는 것은 아님)
부모님 세대의 경우 그것이 중요할 수 있으나 현재는 인식과 이해가 달라지고 있음

💬

　내가 생각할 때 대학교는 정말 하고 싶은 공부(전공)이 있는 게 아니면 안 가는 게 나은 거 같다.
난 원래 중학교 때 웹마스터라는 게 되고 싶어서 나모웹에디터와 포토샵으로 사이트를 혼자 따라하면서 만든 경험이 있었다. 그때는 무료 호스팅도 많아서 손쉽게 따라할 수 있었고, 중학교 3학년 때 진로를 결정할 때 해당 분야를 더 공부하고 싶던 중 선린인터넷고라는 고등학교를 알게 되서 그곳에 가고 싶었다. 지금은 워낙 특성화고, 마이스터고 같은 게 많지만 당시에 아빠는 전형적으로 스탠다드한 인식을 갖고 계셨고, 아빠 역시 당시 직장에서 남과 다소 다른 부분이 있었던 터라 내가 실업계를 나오면 사회적으로 대우받지 못한다고 반대하셔서 나는 그냥 일반적인 인문계 고등학교에 갔다. 그리고 평범한 일반적인 학생들처럼 지내게 되니 웹에 대한 관심은 다소 떨어졌다. 오히려 대학에 가서는 난 웹과 관련된 경험은 거의 하지 않았다.
그때 일찍 하고 싶었던 쪽으로 갔다면 내가 관심있는 분야에 대한 흥미를 더 높이고 깊이 있는 학습을 할 수 있었을 것 같지만, 난 오히려 늦게 시작해서 좋은 점도 분명 있는 것 같다. 다른 분야에 대한 경험으로 인해 일할 때 오히려 보완되는 부분도 있었다.
물론 일정 경력 이상이 넘으면 경력적으로 전문성을 더 요한다든가 사람을 관리하거나 가르치는 자리에 갈 수도 있기 때문에 그런 점에서는 분명 학사 이상의 학위는 필요할 수도 있다. 그리고 아무래도 다른 사람에게 전문적이거나 그에 상응하는 실력을 갖췄다고 공식적인 인정을 받으려면 단 1줄인 것처럼 보여도 그 학위가 필요할 수도 있다. 물론 1줄이지만 그 행간에는 보이지 않는 노력이 있었을 것이다. 경력도 마찬가지.. (모든지 쉬운 건 없다)
그러나 학위만큼 필드에서의 경력 역시 물론 중요하기 때문에 두 마리 토끼를 다 잡을 수 있는 사람이거나 내가 이런 부분은 더 부족하니까 좀 더 공부해서 숙련도를 쌓아야겠어라고 생각하는 사람이라면 더 많은 학습이 필요할 거라 생각한다. (그러나 나는 사실 필요한 만큼만 실리적으로 공부하는 편이다.....)
물론 자기가 원하는 대로(생각한 대로) 경력을 쌓는 사람도 있을 거고 우연찮게 기회를 얻는 사람도 있고 그냥 하다보니 오랫동안 한 길을 가는 사람도 있어서 정답은 없는 거 같다. 다만 이것 저것 많이 알아두고 준비를 많이 한 사람이면 얻을 수 있는 게 많지 않을까? 꼭 대학이 아니라더라도 자격증이나 일반 강의 수료도 그렇고 그냥 뭐든 배워두면 좋은 것 같다. (쓸모가 있다)
그리고 이 공부를 해보면서 느끼는 건.. 공부를 많이 한 사람이 갈 수 있는 필드가 따로 있다고 생각하여 한계를 정하는 건 좋지 않지만 내가 어디에 가치를 두고 개발을 하는지 어느 정도는 정해두고 나에게 학위가 필요한지 아닌지 판단하는 게 좋다고 생각한다.

3. 국비지원학원 단과반 수강하는 게 좋을까요?

개인적으로 비추천 (더 저렴하고 양질의 인터넷 강의가 많다)

💬

적절하게 본인에게 맞는 것이 있다. 다만 좋은 국비지원학원 선생님도 분명 있을 것이다.
다만 요즘에는 학습 플랫폼이 많고 정보가 많아서 잘 찾으면 좋은 온라인 강의가 많은 것 같다는 데에 동의

집체 교육(오프라인 교육)의 장점 : 사람들과의 교류/팀플, 바로바로 질의응답 가능

온라인 교육의 장점 : 효율적인 시간 관리, 정보 탐색 후 선택 가능

5. 개발자가 된 비전공자들의 모음

💬 날이 더워지니 오늘은 회사에서 집중이 안되서 나중에 들으려고 한 부분인데 미리 당겨 들었다..

💬 왜 개발자가 되려고 하는지 생각을 정리하고 있다. 벨로그에도 찾아보니 부트캠프나 국비지원을 다니는 분들이 적은 수기들이 많은 것 같아서 한번 읽어보기도 했다.

💬 인프런 강의를 모두 듣고 이 이야기에 대해서 잘 답변하기 위한 준비가 필요한 시점이 되고 있는 것 같아 조금 생각을 정리했다. 다만 이 개발을 공부하면서 진지하게 생각한 부분이 있다.

나는 왜 개발자가 되려고 하는가?

1. 알아야 바꾼다

　과거 디자인을 하다보면 아무래도 내가 생각한 것을 직접 구현하고 싶은 충동에 빠지는 경우가 있다. 물론 약간의 경험이 생기니 회사 일은 여러 이해관계가 교차하기 때문에 단 1명의 생각에 의해서만 바꿀 수 없는 경우가 많지만.. 뭔가 개선하거나 제안을 할 때 개발을 조금 더 알면 내가 생각하는 방향으로 제안하거나 설득할 수 있다.
물론 실제 런칭되지 않더라도 그 과정에서 얻어가는 유의미한 부분도 있다. 물론 개발에 맞추다 보면 다소 주관을 잃고 틀에 맞춰지게 될 수도 있지만 내가 예전에 코딩이나 개발까지 아는 선임 디자이너들을 보면서 느낀 부분은 알면 더 잘 소통하고 설득하고 만들어 갈 수 있다는 점이다. 그럼 어디까지 알아야 하는가도 다르겠지만 구현에 좀 더 관심이 있거나 해당 분야로 확장하고 싶다면 어느 정도 알면 좀 더 바꿔나갈 수 있는 부분이 분명 있다.

2. 직업 != 자아실현, 나의 속물 근성 인정하기

　사실 내가 개발자에 도전한다고 했을 때 커리어를 걱정해준 사람도 있었고(근데 난 사실 그동안 커리어를 생각하면서 디자인을 한 건 아니다. 그럴거면 외주를 하지 않았을 거니까) 시작하기에 늦다거나 아무래도 연봉이 높으니까 너도나도 뛰어든다고 생각한 사람도 있었다. 그런데 생각해보면 개발자라는 직업은 꽤 고부가가치 직업이다. 복잡한 작업은 작업량이 많지만 단순한 작업은 코드 몇 줄, 파일 몇 개, 커밋 하나면 끝나는 작업도 있다. 그렇다고 개발이 엄청 쉽고 단순하다는 건 아니다. 그 몇 줄을 바꾸기 위해 알아야 하는 배경지식과 학습량을 필요로 하기 때문이다. 복붙만으로 끝나는 일도 거기에 왜 붙여야 하는지 모르는 채로 할 수는 없으니까..
그런데 사람은 누구나 일을 할 때 삶의 질이 더 나아지길 소망하지 않나? 뼈빠지게 일해서 죽을 때까지 고생하는 것보다 만약 내가 어떤 재능이나 조금이라도 잘 할 수 있는 부분이 있는데 그것이 조금 덜 고생하고 조금 더 가치있는 일이라는 건 안다면 그에 맞는 훈련을 하고 일을 할 것이다. 또한 시간당 비용이라는 것도 있다. 같은 한 달을 놓았을 때 편의점 알바(비하 아님) 208시간보다 사실 덜 일하고 더 많은 보상을 얻어갈 수 있는 일이라고 생각한다. 그리고 대부분의 사람들은 내가 일하고 노력한 것에 대해 주어지는 보상이 많기를 바란다.
개발자는 분명 다른 직업에 비해 조금 더 보수가 높은 직업은 맞다. 물론 이것 역시 논란이 있고 업종별 규모별로 차이는 있지만 평균적으로. 물론 그만큼 공부하고 노력도 필요하다. 노동은 땀으로 말한단 이야기도 있지만 다른 형태로 하는 노동으로 고부가가치를 내고 보상을 받을 수 있다는 점에서 매력적이고 대부분의 사람들이 시작하는 이유일 것이다. 그런 점에서 자신이 더 나은 삶을 싶다는 속물 근성은 어느 정도 인정할 부분이 있다고 생각한다. 이것은 학문연구라든가 고차원의 개발이 아닌 일정한 직업훈련을 거쳐 실무에 투입되어 처리하고 경력을 쌓을 수 있는 수준의 개발을 말한다. 그리고 운 좋게도 시장에는 다양한 형태의 개발자를 필요로 한다. 그래서 자신이 정보를 찾아 선택하여 일정 학습을 하여 준비한다면 충분히 도전할 수 있는 일이라고 생각한다. 나처럼 UI개발(퍼블리셔)라도 말이다.

3. 사회에 기여할 수 있다

다소 오글 거릴 수 있지만... 개발자는 시스템을 만드는 일을 한다. 그 시스템들은 뭔가 불편함을 개선하고 더 편리하게 만들어 주기 위해 나온 것이다. 내가 하는 일이 작지만 더 나은 방향으로 개선하는 데 도움을 줄 수 있는 부분이 있다. 가령 웹접근성만 해도 사각지대에 놓인 누군가도 같은 범주 안에서 똑같이 사용할 수 있도록 만드는 목적을 한다. 이 부분에서 나는 내가 디자인을 다소 놓더라도 사용자 경험을 개선한다는 건 다른 직군이어도 공통 분모로 갖고 있는 부분이니까 나는 완전히 내가 하고 싶었던 걸 놓은 것은 아니라고 생각한다. 기업이든 공공분야든 개발자로 일하게 되면 어쨌든 개선을 필요로 하는 일이 많기 때문에 분야를 찾다보면 내가 하는 업무가 누군가에게 직간접적으로 도움이 될 수 있는 일들이다.
내가 블로그에 주로 언급하는 내 친구는 프리랜서 개발자이기 때문에 다양한 프로젝트를 해왔다. 그 중에 재작년에 보건소 헬스케어 프로젝트를 한 적이 있다. 친구야 프리랜서다보니 사실 경력 대비 단가를 따져서 일을 구하는 편인데 그러다보면 주로 SM보다는 SI업무를 선택한다. 그리고 친구의 경우 초반 개발자 경력이 공공분야에 상주하는 SM이었기 때문에 업무적으로 다소 루즈해짐을 느껴서 약 5년 정규직을 하고 그 이후는 전부 프리랜서로 일했다. 늘상 하는 프로젝트를 하다가 한 회사에서 투입되는 프로젝트에서 이어지는 프로젝트가 생겨서 SM을 투입됐다. 그런데 어느 정도 사업 수주가 진척이 되기 까지 고도화 전 운영을 맡는 일이었다. 그런데 친구가 짜증을 냈다. 이유가 그 헬스케어 앱은 너무 느려서 사소한 오류가 많이 나고 그래서 보건소의 간호사나 의사로부터 전화가 오는 데 그 이유가 보건소에 오는 고령층 유저들이 그 앱을 켜서 걷기라든가 산책같은 운동을 하고 스마트워치와 GPS 연동을 통해 기록이 되는데, 자기가 운동한 기록이 남지 않는다는 내용의 컴플레인이 주로 오는 것 때문이었다 한다. 거기다 고도화 전 운영이라 업무가 많이 없으니 담당자를 뽑기 전까지 개발자에게 전화 받는 업무를 시킨 것이다. (경력 10년차 개발자로서는 사실 싫을 것이다) 처음 친구는 "아 이 프로젝트 괜히 했어"라고 투덜거렸으나 이후에 담당자가 약 1달 반 후 오기까지 일단을 했다. 처음에는 싫었으나 같이 프로젝트에 상주하는 사람(차장님)이나 원청회사가 나쁘지 않았고, 그 고령층 유저들이 계속 기록에 목숨 거는 이유가 사실은 기록으로 순위가 매겨지면 보상으로 10만원 상품권을 받기 때문인 걸 알았기 때문이다. 그래서 나중에는 전화도 자주 묻는 질문이 있어 아예 어떤 케이스에는 어떤 답변이나 이후 어떤 기능을 개선해야 할 것 같은지 간단하게 문서화했다고 한다(이후에 고도화 진행에 필요하도록 전달) 그 외 간단한 개발을 하고 이후 친구의 투입기간은 끝나게 되었고 그 앱은 그래도 다소 개선이 되어 구동 속도도 빨라졌다. 또 전국 보건소 관련 종사자분들이 이런게 안되요 라고 문의하는 오픈채팅방에도 초대받아 답변도 해야했다는 데 처음에는 싫었지만 나중에는 나쁘지 않은 눈치였다
그런 경험담을 들을 때 어쨌건 개발자는 시스템을 만들고 유지보수하고 개선하는 일을 하기 때문에 프로젝트 안에서 크든 작든 무언가를 맡게 된다면 분명히 타인에게 도움을 줄 수 있는 일이기 때문에 어떻게 보면 보람된 일이라는 생각도 든다.

현실적인 고민

다만, 내가 늦게 시작했기 때문에 정말 현실적으로 몇 가지 우려되는 부분도 있다.

1. 독학의 한계

　현재 인강을 보면서 독학을 하는데, 인터넷은 정보의 세상이라 그런지 좀 더 딥다이브하여 하던 일을 그만두고 부트캠프같은 곳에 참여한 사람들이라든가 전공자들에 관련된 블로그들을 보면 일단 규칙적으로 공부하는 습관이 있고, 기본 개념이나 복잡한 프로젝트를 하더라도 분석하는 방법이 잘 되 있다. 이런 점에서 나 역시도 그냥 인터넷 강의를 듣고 따라하는 것보다는 리뷰나 멘토링을 받는 게 필요하지 않을까 싶은 부분도 있다. 얼개만 알고 이해하는 거나 그냥 돌아가게끔 만드는 것과 원리를 알고 이해해서 만드는 건 다르니까.
다만 규칙적으로 학습하는 습관과 잘 이해하는 방법을 터득하게 되면 분명 도움이 된다. 그리고 인터넷에 정보는 정말 많아서 찾다보면 사실 비슷한 정보가 중복되는 경우도 많다. 그 속에서 괜찮은 정보를 필터링해서 나에게 유의미한 정보를 찾으면 일부는 독학으로 메워지는 건 있다.
그러나 개발은 기본적으로 협업이 많다. 그래서 사실 걱정되는 건 독학을 하거나 혼자 무언가를 만드는 건 분명히 일정 지식은 쌓을 수 있지만 실제 과정에서 일어나는 다양한 케이스에 대처할 수 없는 부분이 생긴다. 욕 먹으면서 배워가는 거라지만 누구나 욕 먹어가면서 구르고 싶진 않을 것이다. 그리고 내향적인 성향이 많은 개발자 조직에서는 아무래도 처음 인상이 default가 되는 경우가 많기 때문에, 기본값이 좋으려면 아무래도 혼자 공부하는 것은 다소 한계가 있을 것이다. 그래서 망설여지는 부분도 있다. 그리고 요즘은 개발자가 유망하다보니 하고 싶은 사람이 너도나도 있는데, 제대로 가르치는 곳은 돈이 많다고 아무나 입학 시켜주지도 않는다. 또한 어느 정도 베이스가 있는지 보는 경우도 있다.

2. 나이

　어느 직업이나 일찍 시작하면 좋은 건 맞다. 개발자는 나이 제한이 다소 없다고 하나 아마 개발자가 된다면 나보다 당연히 나이가 어린 친구들이 많을 것이다. 그래서 일부러 유데미 강의를 들은 것도 있다. 수평적인 회사가 많을 것이기 때문에 나이는 많은 데 잘 모르는 것 같은 사람이 오면 사실 팀원으로서도 불편할 것이고 경륜이 많은 팀장이나 리드가 아니라면 다루기 까다로울 수도 있다. 이 점에 대해서 친구와도 이야기를 나눴는데, 지혜가 쌓이면 괜찮을 거라 해주긴 했다. 나이가 많으면 보통 고집이 셀 거라는 인식이 있는데 만약 잘 모르는데 고집이 세다 = 답답함이지만 지혜로운 데 고집이 세다 = 강단있다고 보일 수도 있으니 지혜를 쌓고 자신의 캐릭터에 대한 컨셉을 잘 잡으면 될 것이라 조언해줬다. 나 또한 준비해야 부분도 있으나 그런 부분에서 유연한 사고를 가진 사람들과 함께 할 수 있도록 노력해야 하는 부분도 있을 것이다. (다만 이 부분 때문에 사실 친구는 일반적인 서비스나 솔루션 회사보다는 SI나 프리랜서를 하는 게 더 나을 수도 있다고 해주긴 했는데.. 나도 사실 그렇게 느낀다.) 그래서 인프런 강의 후반의 부록에 기술면접, 질문이나 Git-Flow 같은 내용이 어찌되었건 늦게 시작하는 사람이 더 적응을 빨리 하도록 도와주는 내용인 거 같아 좋은 것 같기도 하다.

3. 이전 경력

　디자인이나 퍼블리싱을 했었기 때문에 계속 하던 거를 하는 게 낫지 않을까라는 시선도 분명도 있을 것이다. 이 부분에 대해서는 적절한 답변을 더 찾는 중인데, 사실 처음엔 디자인시스템을 구현하고 싶다는 마음에 시작한 부분이 있었는데 개발을 공부하면서 나는 지금 더하기보다 빼기에 집중하고 있다. 과거 내가 디자인으로 설계 위에 더 덧붙인 내용을 제거하고 정말 기본적인 기능 만들기에 (아직은 따라하기 급급하지만) 집중하면서 근본적인 방향을 탐색하고 있다. 그래서 집중하다보면 내 이전 경력을 이랬지만 혼자서라도 개발 프로젝트를 하면서 어떤 부분이 같은지 그리고 다른지도 두 가지 이상의 직군을 가져본 사람으로서 갖는 관점도 이야기할 수 있을거라 생각한다.
다만 협업이 더 많은 직무이기 때문에 나는 다소 마음의 눈(주관)을 버리려고 노력해야 하는 부분도 필요한 것 같다. 디자이너는 그 마음의 눈을 갖고 작업해 나가야 하는 영역인데 개발자는 오케스트라 단원처럼 합을 맞춰가야 하기 때문에 나의 의견만 고집해서는 안 되기 때문이다. 이 점이 현재로서는 극복해 나가야 할 부분 같기도 하다.

너무너무 길었지만... 강의를 끝으로 생각을 정리해볼 수 있어 좋았다! 😆
(수강 후기도 적어야 하지만 아직은 개발자가 된 게 아니라서 나중에...)

productuidev

필요한 내용을 공부하고 저장합니다.

이전 포스트

[준비하기] (6) 개발자 취업준비1 (이력서)

2개의 댓글

고방

2023년 7월 25일

와 정리 대단하십니다.
너무 좋은글 잘보고 갑니다.

답글 달기

infocampus logics

2024년 6월 15일

Wonderful post! We are linking to this great post on our website. Keep up the great writing.