면접장에서도 "이력이 참 화려하시네요!" 라는 이야기를 들었을 정도로, 제 이력서에는 수많은 방황의 흔적이 눈에 띄게 기록되어 있습니다. 새로운 변화와 도전에 주춤한 성향 탓에 처음에는 안정을 찾아 공무원이라는 직업을 선택했어요. 그러나 직업관이 맞지 않아 개발자로 전환하게 되면서, 저를 키운 것은 팔할이 바람일 정도로 예상치 못한 도전을 꿈꾸게 되었습니다. 이런 저의 이야기가 궁금하지 않으세요?
화려하시네요!" 라는 이야기를 들었을 정도로, 제 이력서에는 수많은 방황의 흔적이 눈에 띄게 기록되어 있습니다. 새로운 변화와 도전에 주춤한 성향 탓에 처음에는 안정을 찾아 공무원이라는 직업을 선택했어요. 그러나 직업관이 맞지 않아 개발자로 전환하게 되면서, 저를 키운 것은 팔할이 바람일 정도로 예상치 못한 도전을 꿈꾸게 되었습니다. 이런 저의 이야기가 궁금하지 않으세요? 공무원
제가 왜 공무원을 그만두게 되었는지 고민한 흔적을 담아봤어요.
과거의 선택은 현재의 나를 만들었다
모두가 처음엔 장밋빛 미래를 꿈꾸듯 나 또한, 주무관으로서 펼쳐질 희망찬 미래만 꿈꿨고 이면에 숨겨진 모습을 바라보기에는 통찰이 부족했다. 이전에 공무원을 그만두고 개발자가 된 이유에서도 적었지만, 다시금 회고해 본다. 당시에는 "왜 공무원을 그만 두나? 너 문제 있어?"로 해석할 여지가 아주 아주 많았기 때문에 풀지 못했던 사연까지 구구절절...
하고 싶지 않은 일 내려놓기
하고 싶은 일을 하려면, 일단 하고 싶지 않은 일부터 내려 놓는 과감한 결단이 필요하다. 생계가 걸린 문제이다 보니 쉽게 용기내기 어려운 문제임이 분명했다.
공무원을 그만두고 싶었던 이유
대입 시험은 원하는 만큼의 성적이 나오지 않더라도 점수에 맞춰 대학을 갈 수는 있지만, 공무원 시험에서는 상위 20%에 들지 못하면 탈락이다. 그렇게 어려운 시험에서 합격해 놓고서 왜 나는 그만둬야 했을까?
1. 적성에 맞지 않았던 사실상 사무직 업무
적성에 맞지 않아도 잘할 수 있으니까 업으로 삼아도 괜찮겠지 했던 생각은 굉장히 잘못되었다는 것을 깨달았다. 시간은 째깍째깍 흘러가지만, 일이 너무 하기 싫었다. 개발자가 개발만 잘한다고 다가 아니듯 사무직도 사무자동화 프로그램만 잘 다룬다고 해서 다가 아니었다.
개발자 커뮤니티의 익명의 누군가로부터 "개발은 취미일 때 즐겁다"는 조언을 맥락없이 받아들인 내 탓이 크다. 물론, 마감 기한 안에 무리한 요구사항을 쳐 내야만 하는 기업에 근무했다면, 스트레스 받는 것이 맞다. 나도 SI에 다닐 때 그런 비슷한 고민을 했던 적이 있으니까. 하지만, 돌아 보면 적어도 개발 자체가 싫었던 적은 없었으며 인생을 살면서 개발을 업으로 삼았을 때 제일 낙이 컸다. 지금도 그렇다.
2. 수직적인 조직 문화와의 갈등
수직적인 문화를 체험하고 싶다? 그렇다면 살아있는 레거시 박물관인 공직의 문을 두드리면 된다
함께 하고 싶은 시니어 동료의 부재
개발자가 적성에 맞는 지금도 체력이 달려서 일이 힘든 경우가 있다. 그렇지만, 함께 일하는 동료가 좋고 문화가 좋아서 이건 크게 문제되는 일이 아니다. 내가 알아서 컨디션 회복해서 열심히만 하면 해결되기 때문이다. 공무원으로 재직했던 때에도 타 부서 동료에게 무시당하지 않도록 잡아주시던 든든한 과장님이 계실 때가 있었다. 일이 힘들더라도 보람차고 재미있었다. 군대에서 근무했을 때부터 전산과 관련된 보직은 거의 일반적으로 암적인 면을 떠올릴 때의 슈퍼 을의 이미지라고 생각하면 된다. 타 부서 동료의 전산 장비가 고장나면 가져다 주는 것이 일반적이었다. 그런데 당시 과장님은 타 부서가 직접 찾아오라고 바꾸셨고 곤란한 내부 민원 전화를 받으면 당신에게 돌리라고 하실 정도로 파격적인 분이셨다. 그런데 안타깝게도 내가 임용된 지 얼마 되지 않아 과장님이 다른 부서로 발령을 받으심과 함께 이 문화는 사라졌다.
나다움을 찾기 위한 여정
전산직 공무원 하는 일
•
전산직은 원래 소수만 뽑아가서 TO가 굉장히 좁고 국가직조차 많이 뽑지 않았던 시절이 있었다. 그리고 정보보호직이 생긴 지가 얼마 되지 않았는데 이마저도 TO가 적다.
•
그런데 2017년(추가채용)을 기점으로 점점 전산직에 관한 수요가 점차 늘어나고 있다. 당시 정부에서는 생활안전분야에 관한 인력을 충원하겠다고 했는데 전산직이 여기에 포함되나 보다. (뇌피셜 →) CCTV 와 같은 업무를 전산직이 맡아서 할 수가 있어서? 생활안전과 밀접한 분야이기 때문이 아닐까 싶다.
•
국가직 전산개발직을 기준으로 2021년도에는 무려 186명을 뽑았다.
•
지방직의 경우에는 각 지자체마다 필요한 수요가 다르기 때문에 그것을 지표로 활용하기에는 무리가 있을 것 같아서 국가직을 기준으로 TO를 설명드렸습니다. 이후 내용에서는 제가 경험한 지방자치단체(지방직)을 기준으로 다룹니다.
전산직으로 임용될 때 주의사항
(지방직 기준)
전산직은 코딩을 할까?
결론부터 말하면 공식적인 업무로 코딩을 지방직에서 하는 경우는 거의 없다고 봐야 한다. 지방자치단체의 홈페이지를 관리하거나 유지보수하는 것은 계약된 업체가 진행하는 부분이기 때문에 전산직 공무원은 이러한 계약사항을 관리하는 일이다. 개인적으로 업무 편의(?)상 개발을 할 수야 있겠는데... 현업을 진행하다 보면 생각보다 잡무가 쏟아지는 일들이 많아서 그런 엄두를 내기는 어려울 수도 있다.
전산직이 하는 일
•
내가 경험했던 것이나 선임 주무관께서 했던 업무를 바탕으로 이야기해볼까 한다.
•
아래 명기된 사항은 업무로서 분절해 놓은 것이지, 내가 공직생활을 하면서 맡았던 것을 나열한 것이 아니다. 그리고 이게 다가 아니다.
전산직 공무원 하는 일
전산직 공무원이 되는 법
쉬어가는 코너
갑자기 전산직이 되는 공무원? 에 관해 저술하는 것에 대해 독자분들께서 의아해하실 것 같다. 그것도 개발자 블로그에서. 그런데 생각보다 공무원에 관해 궁금해하는 지인들이 많았으며 프로그래밍에 자신이 없는 분들이나 적성에 맞지 않는 분들께서는 가끔 공무원을 희망하기도 한다. 그리고 지난 포스팅에서 공무원을 그만둔 이유에 관해 이야기했는데 오늘은 쉬어가는 코너의 의미로 이야기해볼 것이다.
전산직 공무원 ?
공무원은 여러 가지 직렬로 나뉜다. 가장 인기 있는 직렬은 행정직. 사실 전산직렬은 소수 직렬로 매해 많이 뽑아도 30명일 정도로 정말 적은 인원만을 뽑았다. 지방직을 본다면 1명만 뽑는 경우도 많이 뽑는다고 할 수 있고 아예 뽑지 않는 지역도 있을 정도로 그렇게 공직에 대한 수요가 높지는 않다.
그런데 글을 작성한 시점인 2021년인데 정부에서는 경찰·교원·생활안전 분야를 담당하는 공무원을 많이 채용하고 있다. 여기서 의외인 게 전산직이 생활안전 분야라니? 아무래도 CCTV 등 생활안전 분야를 담당하는 부분에서 전산 장비를 다루거나 관리해야 할 필요가 있어서 같이 증원되는 것 같다고 느꼈다. 아무튼 !! 그래서 이전에는 많이 뽑아야 30명 남짓 되었는데 2021년 공고 기준으로는 전산개발 186명, 정보보호 직류 18명을 뽑는다고 한다…. 200명이 넘어가는 수치는 정말 처음 본다. 언제까지 많이 뽑을지는 모르겠지만, 사물인터넷, 제4차산업 혁명 등이 대두하고 있는 시점에서 전산직의 중요성이 더욱 드러나는 시점이 아닐까 한다. 만약에 생각이 있으신 분들께서는 많이 뽑을 때 준비해 보시는 것도….
공무원 종류
공무원 종류(?)에도 여러 가지로 나뉜다.
보통 국가직, 지방직, 지방교육청, 경찰, 해양경찰, 소방직, 군무원, 계리직(우정사업본부) 등으로 나뉜다.
여기서 전산직을 위주로 뽑는 직렬에 관해 설명해 보겠다.
전산직과 연관이 있고 시험을 보는 시기별로 분류했다.
1. 국가직 (매년 3~4월)
가장 많이 뽑는 시험이다. 매년 첫 시험으로 치러지는데 이 시험에서 많이 뽑기 때문에 사람들도 가장 눈에 불을 켜고 응시하는 시험이다. 특히 소수 직렬인 전산직은 자신의 주소지나 거주 3년 이상인 주소지의 지방자치단체에서 뽑지 않는 경우 응시할 수 없기 때문이다.
전산 개발과 정보보호직으로 나뉘는데 정보보호직은 개인정보 위주(마이핀 등)의 업무를 수행한다고 들었다. 전산 개발직에서는 아마 전산장비를 관리하거나 각 청사 내에서 사용하는 소프트웨어 라이선스, 내부 IP 인가 시스템 운용 등의 업무를 수행한다. 그런데 업무가 워낙 다양해서 하나로 설명할 수는 없지만, 이것 하나만은 확실하다. 프로그래밍은 9급에선 하는 일이 거의 없을 것이다. 프로그래밍과 관련된 것은 용역업체와의 계약을 통해 진행될 것이고 그걸 관리하는 게 전산직일 테니까. 그러나 일부 과학기술정보통신부 같은 곳에서는 7급 주무관이 코딩한다고 들었던 적이 있는데 필자가 국가직에서 근무한 경험이 없어서 논외로 한다.
2. 지방직, 교육청 (매년 5~6월)
지방직은 정말 바늘구멍이다. 서울시만 하더라도 많이 뽑아봐야 열댓 명이 전부였다. 경기도로만 나가더라도 전산직은 많이 뽑아도 3명이고 1명을 뽑아도 많이 뽑는 경우라고 할 수 있다.
그러나 지방직은 자신이 거주하는 주민등록지에 속한 지방자치단체에서만 응시할 수 있다. 이외로도 3년 동안 주소를 둔 지방자치단체에서도 응시할 수 있는데 이외의 주소지에서는 전혀 응시할 방법이 없다. 예를 들어 현재 주소가 서울시이고 경기도 의왕시에서 4년을 살았다면, 서울시와 경기도에서는 응시할 수 있다. 그러나 살아본 적도 없거나 3년 미만 동안 주소를 둔 강원도, 충청도 등에서는 시험을 볼 수 없다는 의미이다.
전산직 공무원이 되는 법
개발자
공무원을 그만두고 개발자가 된 저는 만족스러운 삶을 살고 있을까요?
팀블라인드 소개
팀블라인드는 직장인이 회사 이메일로 가입하면 특정할 수 없는 회사 소속의 개인이 글을 자유롭게 남기며 소통할 수 있는 커뮤니티 서비스이다. 뉴스 기사에서 부당한 직장 이야기가 다뤄진다면 팀블라인드 커뮤니티의 캡처 화면은 흔히 접할 수 있다. 그런데 입사 이후에 미국에도 별도의 서비스가 있다는 것을 알게 되었다. 한국의 블라인드 서비스처럼 미국의 블라인드 서비스도 마이크로소프트, 구글, 아마존, 메타, 테슬라 등 유명한 기업에 종사하는 사람들이 많이 사용한다고 한다. 그런데 한국과 미국은 문화가 다르다 보니 서비스가 독립적으로 운영되고 정책에서 두드러지는 차이가 있다. 그래서 한국 개발자 분들이 미국 서비스까지 개발을 맡다가 점점 미국 서비스도 한국만큼 규모가 커지면서 미국/캐나다 등 각지의 개발자를 영입하여 서비스를 운영하고 있는 시기였다.
한국 서버 개발팀이 서비스를 운영하다가 미국/캐나다 개발자에게 바톤을 넘기면서 긴밀히 협력해야 하는 시점에 있었다. 주기적으로 서로의 업무 내용을 공유하기 위해 한국 시각 기준 오전 9~10시에 양국 개발팀이 서버 개발에 회의를 온라인으로 진행했다. 꼭, 업무 내용이 아니더라도 개발에 도움이 되는 툴을 소개하거나 좋은 개발 문화 만들기 위한 주제, 그리고 특정 기술을 주제로 발표하는 기회로 발표할 수 있는 시간을 만들어가고 있었다. 첫째로 희망자가 자원하거나 그렇지 않은 경우에는 순번을 정하며 발표를 준비하게 되었는데 그중 내가 발표를 자원하게 되었다.
발표를 준비한 이유와 준비하게 된 주제
순번으로 걸렸던 것도 아니고 지목 당한 것도 아니었다. 도대체 내가 왜 나서게 됐을까? 나는 개인적으로 두 번 다시 태어나더라도 이런 기회를 경험하기 어렵다는 판단이 든다면 본능적으로 나서게 되는 면이 있다. 그래서 미국 개발자들과 함께 교류하고 싶은 마음에 선뜻 나서게 됐다. 마치 그 시기에 “자바스크립트는 왜 프로토타입을 선택했을까”라는 글에 꽂혀 있었다. 당시에는 이 포스팅을 몇 번을 읽어도 전부 이해하기에는 역부족이었다. 그런데 내가 한번 다른 사람들을 대상으로 한 발표를 준비한다면 보다 잘 이해할 수 있지 않을까? 하는 마음에 이 어려운 주제를 선택했다.
어떤 개념을 이해하거나 정복해 보겠다는 다짐을 하면서도 막상 큰 벽에 부딪히게 되면 거기서 헤어 나올 방법을 찾아야 한다. 그러나 자발적인 동기로는 오래 가지 못한다. 마찬가지의 경우로 PT를 받는 것도 혼자서는 레그프레스 무게 만땅 치고 4개밖에 못 밀겠다고 생각하던 것이, 옆에 사람이 붙어서 개수를 세고 있으면 10개까지도 하게 된다. 그래서 발표도 외부 동기를 이용한다면 나의 역량을 한층 더 성장시킬 수 있을 것이라고 생각했다.
발표 준비와 과정
한국과 미국 개발자 분들을 대상으로 하다 보니까 한글로만 발표 자료를 준비할 수는 없었다. 그래서 통역하시는 분과 협업이 필요한 상황이었다.
통역하시는 분이 계셨지만, 굳이 내가 직접 영어로 말하고자 했던 이유가 있었다. 몇 번의 한/미 양국 개발자의 세미나를 들어 보니 통역하는 과정에서 언어간 스위칭 비용(시간)이 많이 드는 것을 알게 되었다. 내용이 영어로만 적혀 있는 경우에는 전적으로 통역사 분의 힘을 빌려야 하기 때문에 통역할 차례가 올 때까지 마냥 기다리는 수밖에 없었다 보니 집중력이 흐려지는 경우도 있었다. 20분 분량의 간단한 발표일지라도 언어 스위칭 비용 때문에 2배의 시간이 걸리는 것이 일반적이었다. 그래서 통역이 전문적으로 필요하지 않은 부분은 슬라이드 노트에 미리 메모해 외운 체(?)하며 내가 직접 언어를 스위칭하여 시간을 절약하며 집중을 유도했다(오, 저 사람 영어 할 줄 아나 봐!).
PPT 화면에 글자가 많이 들어가는 것을 좋아하지는 않지만, 양국 개발자의 원활한 이해를 돕기 위해 불가피하게 2개국어를 모두 화면에 실었다. 양국 개발자의 원활한 이해를 돕기 위해서는 PPT 자료도 2개국어가 모두 적혀 있으면 좋겠다고 생각했다. 내가 먼저 한국어로 발표하면 다음에는 통역사가 번역해 주시는 형식으로 진행됐다. 이때 내가 한국어로 말하는 틈에 미국 개발자는 통역사의 번역을 듣기 전에 화면을 통해 내용을 먼저 접하게 된다면 보다 집중을 끌어올릴 수 있을 것이라고 기대했다.
한/미 개발자 대상 글로벌 발표를 하고 난 뒤…
팀블라인드를 알게 된 계기
팀블라인드로 옮기기 전에 근무했던 회사에서는 Spring boot, Vue를 이용한 작업을 주로 맡게 되었는데 그중 Vue 작업을 많이 하게 됐다. 그러다 보니 자바스크립트를 많이 공부하게 되었다. 프로젝트를 진행하면서 서버가 Node.js로 구성된 프로젝트도 맡았었다. 팀에서 담당하는 프로젝트를 문맥 교환이 자연스러울 정도로 익숙해져야 한다는 정책에 따라 나는 거의 3개월 주기로 다른 성격의 프로젝트를 접하게 되었다. 그런데 기술 스택이 조금씩 차이가 있었다. 백엔드는 Spring을 쓰는 프로젝트도 있었지만 Node.js 기반의 프로젝트도 있었다. 두 가지 영역을 왔다갔다 하면서 작업해야 하니 Java까지 사용해서 두 개의 언어를 다루는 것보다는 하나의 언어를 다룰 수 있는 Javascript 진영에 마음이 끌렸다. 백과 프런트 둘 다 구현하면서 한 가지 언어만 신경쓰면 되니까!
당시 근무했던 SI 회사 분위기
그런데 SI 업무 특성상 갑작스러운 신규 프로젝트를 팀에서 담당하게 되고 내가 담당하진 않았지만, 인원이 모자라게 되면서 급하게 투입되었다. 그리고 주말에도 불려나가게 되었다. 회로를 불태우는 평일을 위해 주말엔 쉬고 싶었는데 마음대로 안 나갈 수 있는 상황은 아니었다. 회사에서는 불가피한 업무에 양해를 구한다는 느낌보다는 필요하다면 당연히 나올 것처럼 생각했다. 그리고 격무에 시달리는 동료들의 코드 품질이 나날이 하락하는 것을 체감했다.
. 회로를 불태우는 평일을 위해 주말엔 쉬고 싶었는데 마음대로 안 나갈 수 있는 상황은 아니었다. 회사에서는 불가피한 업무에 양해를 구한다는 느낌보다는 필요하다면 당연히 나올 것처럼 생각했다. 그리고 격무에 시달리는 동료들의 코드 품질이 나날이 하락하는 것을 체감했다. 아직까지도 이 이후로 5중으로 둘러싸인 반복문을 본 적은 없었다. 당시에는 내 두 눈을 의심했다. 얼마나 프로젝트 기한이 촉박했으면 이런 선택을 할 수밖에 없었을까? 그런데 당시에는 내가 신입사원이니까 5중 반복문을 하나의 덩어리로 인식하는 데 훈련이 필요하지 않은 걸까? 하는 생각까지 해봤다. 지금 시점에서 생각하면 얼마나 우스운 일인지… 이때부터 커리어에 대한 진지한 고민을 시작했다. 이 프로젝트가 마무리되더라도 똑같은 일이 반복될 것 같았다. 그렇다면, 성장할 수 없는 데다가 코드를 리팩터링하지 않고 만드는 것에만 급급한 습관이 내 몸에 스며들 것 같았다.
사람 일은 어떻게 될지 모른다는 불안감에 틈틈이 개발자 시장 상황을 살피던 중 우연히도 팀블라인드 회사를 알게 되었다. 당시 근무하던 회사와 비슷한 기술 스택을 사용하고 있었다. Vue.js를 사용하고 Node.js 기반으로 작업하고 있으니 이직하더라도 도메인 학습만 된다면 바로 업무를 할 수 있을 것 같다는 기대감이 들었다. 그리고 회사가 만들고 키우는 서비스를 보면서 ‘나도 서비스에 애착을 가지면서 성장할 수 있지 않을까?’ 하는 기대를 품게 되었다. 결국 나는 팀블라인드에 서버 개발자(Node.js)로 지원하여 입사하게 되었다.
팀블라인드에 합류하기로 한 이유
직장 문화 현대화를 위한 사명에 동참
블라인드 커뮤니티에서는 내가 소속한 회사가 보이고 익명 사용자로서 소통할 수 있는 공간을 제공해 준다. 이 공간에서 사내 부조리한 일들이 어떻게 벌어졌는지 공론의 장이 된다. 그중 몇몇 충격적인 사건은 몇 번 방송을 타거나 뉴스 기사로 올라오기도 한다. 파급력이 커지면서 회사원이라면 대개 이 커뮤니티에 가입할 것이다. 나는 공직자로 생활한 적이 있는데 2010년대에도 고위직 공무원들이 “관습”을 핑계로 부조리한 일을 저지르는 것을 봤다. 1980년대에 머물러 있는 퇴폐적 직장 문화가 현대화되길 바라는 마음이 있었던 것 같다. 그래서인지 이 회사가 계속해서 눈에 밟혔고 내가 구성원으로 합류하게 된다면 좀 더 나은 사회를 만드는 데 기여할 수 있을 것 같았다. 물론 혹자는 익명이라고는 하지만, 지켜질지에 의문을 품는 사람들도 있을 거다. 나도 그런 생각을 품었던 적이 있다. 실제로 공직에서는 익명으로 설문을 진행하지만, 사실 추적하면 다 나온다는 우스갯소리가 돌기도 했다. 그만큼 익명성이 지켜지기 힘들기는 했다. 이런 구시대적 사회를 경험하고 나온바, 나도 그 부분이 걱정됐다. 하지만 블라인드는 “잃어버리면 안 되는 것은 가지고 있지 않는다.”는 보안 철학을 가지고 있었는데 그걸 믿어보기로 했다. 경험해 보니 실제로도 그랬다.
나에 대한 뜨거운 관심
정말 신기한 것은 2021년까지 나에게 가장 많은 관심을 보여주었던 회사였다. 인터뷰에서는 같이 일하게 될 팀원 분들이 들어오셔서 이런 저런 물음을 주셨다. 나의 이력서에 밑줄까지 쳐 오시고 궁금한 점을 하나 하나 물어 주셨다. 누군가는 “그게 뭐 대수라고”라고 생각할 수도 있다. 하지만, 내가 공무원을 했다가 때려 치우고 첫 커리어를 내딛기 위해 개발자로서 면접장에 들어섰는데도 이걸 안 물어보는 회사도 있었다. 서로의 관심이라는 것을 중요하게 느꼈던 터라 팀블라인드에서도 내게 관심을 가져주지 않으면 어떡할까 하는 걱정도 있었다. 그런 걱정이 무색하게도 인터뷰에서는 블로그에 쓴 글까지 꺼내 질문해 주셨는데 사람을 뽑는 것에 진심이라는 것이 느껴졌다. 심지어 블로그에 왜 글이 안 올라오냐는 질문까지 받았다. 지원자일 뿐인데도 이렇게 많은 준비를 해 오신 것이 인터뷰 자리에서 보였다. 긍정적으로든 부정적으로든 일을 하는 데 동료가 영향을 가장 많이 끼친다고 생각했는데 팀블라인드 동료와 함께라면 일상이 즐거울 것 같았다. 실제로도 그랬다.
입사 첫 날의 감동과 기대했던 점
그동안 일방적인 합격 통보 메일과 입사 안내 메일은 받아봤어도 이렇게 회사 구성원 한 분으로부터 한 사람을 대한다는 느낌을 받아 본 경우는 처음이다. 오퍼 수락 후 친절하게 챙겨주시는 직원분의 따뜻한 메일에 입사하기로 나의 결정은 공고해져 간 채 입사 첫 날이 다가오게 되는데…
팀블라인드에 입사하기까지…
아직 만 1년의 시간을 채우려면 몇 달의 기간이 필요하지만, 그래도 입사 후 몇 달간 많은 경험치를 얻어냈다는 판단이 들어서 글을 써보겠다고 다짐을 하게 되었다.
그동안 개발을 혼자서만 공부하면서 성장을 했었는데 현업에서 어떻게 경험치를 쑥쑥 키우게 되었는지에 관해 회고해보고자 한다.
1년차 개발자의 성장 회고
1. Javascript 언어의 이해
현업에서는 Front-end는 자바스크립트를, Back-end는 Java 언어를 사용하는 환경에서 작업을 하고 있다. 풀 사이클로 업무를 수행하지만, 보통의 경우에는 Javascript를 이용하여 Front-end단의 작업을 수행하는 이슈가 훨씬 많다. 그런데 생각보다 토이 프로젝트로 작성했던 프로젝트가 아닌 이상 SPA로 만든 프로젝트 소스 코드를 확인하는 것은 이번 회사가 처음이었기 때문에 조금 긴장이 섞였었다.
모던 Javascript 튜토리얼을 통한 학습으로 기본기 다지기
물론 하나의 이슈를 작업할 때 모든 소스코드를 훑어보는 것이 아니라 필요한 문서(.js)만 살피면 되는 것이지만, 그래도 이러한 문서들이 낯설게 느껴지면 안 되겠다고 생각하여 모던 Javscript 튜토리얼을 학습해 가며 소스코드를 병행해 보기 시작했다. 그런데 확실히 자바스크립트 소스 코드에 많이 익숙해져서인지 이제는 소스코드를 읽을 때 예전보다는 좀 더 빠른 속도로 읽어내려갈 수 있었다.
프로토타입 언어에 관해 알아가기
자바스크립트는 객체지향이라는 패러다임도 공유하지만, 확실히 자바와는 다른 무언가가 있었다. 프로토타입 기반 언어라는 것을 몰랐던 것은 아니었지만, "자바에서는 클래스였다면 자바스크립트는 프로토타입기반의 언어이다."라는 정의 정도만 말할 수 있을 정도였다. 그런데 지금은 이 프로토타입 기반의 언어는 클래스와는 어떠한 차이가 있는지에 관해 조금은 설명할 수 있다.
this 이해하기
예전에는 강사가 화살표 함수를 쓰니까 따라 쳤던 기억이 난다. "ES6에서는 () => {...}와 같이 간략하게 적을 수 있으니까 화살표를 선호하는구나" 정도에서 멈췄었다. 물론, 지금도 완벽하게 알고 있다고 자신할 수는 없는 상황이지만, 적어도 해당 Context의 내용을 공유하기 위해서 간편하게 화살표 함수를 사용한다는 것 정도까지는 설명할 수 있다.
예를 들어, obj가 가리키는 {} 객체 내부에서의 this는 객체 자신을 가리킨다. obj에 say라는 메서드가 있다고 가정하고 이곳에서 console에 this.name을 출력하고자 한다면홍길동 님이 될 것이다.
} 객체 내부에서의 this는 객체 자신을 가리킨다. obj에 say라는 메서드가 있다고 가정하고 이곳에서 console에 this.name을 출력하고자 한다면홍길동 님이 될 것이다.1년차 개발자의 성장 회고
