아직 만 1년의 시간을 채우려면 몇 달의 기간이 필요하지만, 그래도 입사 후 몇 달간 많은 경험치를 얻어냈다는 판단이 들어서 글을 써보겠다고 다짐을 하게 되었다.
그동안 개발을 혼자서만 공부하면서 성장을 했었는데 현업에서 어떻게 경험치를 쑥쑥 키우게 되었는지에 관해 회고해보고자 한다.
1년차 개발자의 성장 회고
1. Javascript 언어의 이해
현업에서는 Front-end는 자바스크립트를, Back-end는 Java 언어를 사용하는 환경에서 작업을 하고 있다. 풀 사이클로 업무를 수행하지만, 보통의 경우에는 Javascript를 이용하여 Front-end단의 작업을 수행하는 이슈가 훨씬 많다. 그런데 생각보다 토이 프로젝트로 작성했던 프로젝트가 아닌 이상 SPA로 만든 프로젝트 소스 코드를 확인하는 것은 이번 회사가 처음이었기 때문에 조금 긴장이 섞였었다.
모던 Javascript 튜토리얼을 통한 학습으로 기본기 다지기
물론 하나의 이슈를 작업할 때 모든 소스코드를 훑어보는 것이 아니라 필요한 문서(.js)만 살피면 되는 것이지만, 그래도 이러한 문서들이 낯설게 느껴지면 안 되겠다고 생각하여 모던 Javscript 튜토리얼을 학습해 가며 소스코드를 병행해 보기 시작했다. 그런데 확실히 자바스크립트 소스 코드에 많이 익숙해져서인지 이제는 소스코드를 읽을 때 예전보다는 좀 더 빠른 속도로 읽어내려갈 수 있었다.
프로토타입 언어에 관해 알아가기
자바스크립트는 객체지향이라는 패러다임도 공유하지만, 확실히 자바와는 다른 무언가가 있었다. 프로토타입 기반 언어라는 것을 몰랐던 것은 아니었지만, "자바에서는 클래스였다면 자바스크립트는 프로토타입기반의 언어이다."라는 정의 정도만 말할 수 있을 정도였다. 그런데 지금은 이 프로토타입 기반의 언어는 클래스와는 어떠한 차이가 있는지에 관해 조금은 설명할 수 있다.
this 이해하기
예전에는 강사가 화살표 함수를 쓰니까 따라 쳤던 기억이 난다. "ES6에서는 () => {...}와 같이 간략하게 적을 수 있으니까 화살표를 선호하는구나" 정도에서 멈췄었다. 물론, 지금도 완벽하게 알고 있다고 자신할 수는 없는 상황이지만, 적어도 해당 Context의 내용을 공유하기 위해서 간편하게 화살표 함수를 사용한다는 것 정도까지는 설명할 수 있다.
const obj = {
name: '홍길동',
test(){
function inner(){
console.log(this.name); // undefined
}
inner();
},
testArrow(){
const arrow = () => console.log(this.name);
arrow();
},
say() {
console.log(this.name, '님');
}
};
JavaScript
복사
예를 들어, obj가 가리키는 {
} 객체 내부에서의 this는 객체 자신을 가리킨다. obj에 say라는 메서드가 있다고 가정하고 이곳에서 console에 this.name을 출력하고자 한다면홍길동 님이 될 것이다.
} 객체 내부에서의 this는 객체 자신을 가리킨다. obj에 say라는 메서드가 있다고 가정하고 이곳에서 console에 this.name을 출력하고자 한다면홍길동 님이 될 것이다.가끔 현업에서도 이와 유사한 구조인데 test()나 testArrow()와 비슷하게 함수를 활용할 때가 많다. test()에서 function 함수를 입력하면 undefined라는 결과가 나타난다. 왜냐하면 test() 메서드 안에 있는 inner() 함수는 객체 리터럴의 this를 의미하지 않고 window를 가리키기 때문에 name의 값을 찾지 못하는 것이다. 더 엄밀히 말하면 inner() 함수는 window 객체를 가리키는데 window.name은 undefined이기 때문이다.
이렇게 자바스크립트의 문법을 하나씩 배워가면서 좀 더 상세하게 알아가고 있다는 점에서 점점 성장하고 있다는 것을 느낀다.
그런데, 문법은 꾸준히 보고 학습하면서 이해하고 때로는 암기도 필요한 부분이라고 생각한다. 다만, 문법만 학습하는 훈련이라는 게 다 알지도 못하면서 굉장히 지루하고 힘든 싸움이라는 것을 느낀다. 아마 이러한 부분은 개발자로서 성장하면서 풀어나가야 할 평생의 숙제이지 않을까 하는 생각을 해본다.
2. Typescript 알아가기
타입으로서의 Typescript
개발자로서 커리어를 준비할 때는 자바스크립트만으로 벅찼고 자바스크립트를 이용한 React 라이브러리를 학습하는 것만으로도 충분히 벅찼었다. 그러면서도 드는 생각은 타입스크립트는 언제 한번 꼭 배우고 싶다. 그런데 그게 빠른 시일 내에 배웠으면 좋겠다는 생각뿐이었다. 그렇게 타입스크립트의 정복 기일이 밀리면서 2020년까지 오게 되었다. 이제는 자바스크립트 문법에 관해 어느 정도 이해하기 시작했다고 느끼는 순간 나는 타입스크립트에도 도전을 해보게 되었다.
타입스크립트를 배우기 전에도 함수나 변수에 타입을 제한한다는 정도는 이해하고 있었다. 자바스크립트로 프로젝트를 진행하면서 내가 만든 메서드가 {name: string}을 반환하는지 string을 반환하는지를 살펴볼 때 자세히 살피지 않으면 구별하기가 힘든 경우가 있었다. 이것 말고도 객체의 구조가 복잡해지면 명시적이지가 않아서 일일이 디버깅을 찍어내면서 최종적으로 올바른 반환형 타입의 모습을 갖추고 있는지를 확인해야 해서 매우 불편했다.
그런데 타입스크립트를 배우고 나서 타입에 관해 명확하게 정의를 해야 하니까 컴파일러 단에서 사전에 오류를 뿜어주고 그 이전에 VsCode가 IDE로 오류를 뿜어주는 것에 매우 감탄했다. 이렇게 엄격한 타입 시스템을 도입하면 타입을 생각하고 정의하는 데는 시간이 오래 걸릴 것이지만, 개발자가 작성하면서 범한 실수를 빨리 찾아줄 수 있어 업무 효율은 오히려 더 오를 것으로 생각한다.
타입스크립트를 배우고 난 뒤 생긴 변화
사실, 내가 재직 중인 회사에서는 타입스크립트를 사용하지 않는다.
그럼에도 불구하고 타입스크립트가 도움이 되는 것은 다음과 같다.
1. 함수에서 매개변수는 각각 어떤 타입으로 받아낼 것이고 어떤 유형으로 반환할 것인가를 생각하는 버릇을 길렀다.
•
보통은 자유로운 타입이니까 일단 반환부터 하고 보자하는 습관이 있었다. 그런데 타입스크립트를 사용하면서 이러한 타입에 좀 더 신경을 많이 쓰게 되었고 자바스크립트만을 쓸 때도 마찬가지로 어떻게 타입을 처리할지에 관해 좀 더 많이 신경을 쓰게 되는 계기가 되었다.
2. 라이브러리를 학습하는 데 도움이 된다.
이렇게 서버에서 데이터를 받아와서 처리하는 방식에는 다양한 방식이 있는데 그중 무한스크롤 방식으로 받아오는 기능을 제공한다.
처음에는 API 사이트에 들어가서 이것이 무슨 기능을 의미하는 것인가를 살펴봤는데 다음의 코드는 매우 이질적으로 보였다.
자바스크립트에는 인터페이스가 없는데.. 도대체 얘 무슨 소리를 하는 거야?타입스크립트를 배우고 나서야 알았다. 내부적으로 ag-grid-vue는 타입스크립트로 구현이 되어 있었기 때문이었다. 그리고 타입 처리를 위해서 인터페이스를 구현해 놨을 거고 무한스크롤을 이용할 때는 IDataSource라는 인터페이스가 구현된 객체를 사용할 테니 getRows()와 destroy() 메서드를 가지고 있을 것이라고 이해가 단번에 되기 시작했다. 그리고 getRows에 넘기는 매개변수인 params의 구조는 IGetRowsParams의 구조와 같이 넘겨주면 된다는 것까지 명쾌하게 이해가 되기 시작했다.
아직은 타입스크립트에 관해 완벽하게 공부한 상태도 아니고 유틸 타입에 관해서도 아직 많은 것들을 공부해야 하기 때문에 지금 시점에서 타입스크립트를 정복했다고 이야기할 수는 없다(현실은 자바스크립트 문법도 계속 까먹는데 뭘). 그러나, 이제는 개발자로서 현업에서 일하기 이전보다 많은 것을 알아가기 시작했다는 것을 느끼며 뿌듯해하게 된다.
). 그러나, 이제는 개발자로서 현업에서 일하기 이전보다 많은 것을 알아가기 시작했다는 것을 느끼며 뿌듯해하게 된다.3. Git과 좀 더 친해지기
취업 전에는 Git을 사용하기 이전까지는 이게 다였다.
•
Git, Github(리포지터리 원격 저장소)와의 차이점을 아는 것
•
Git에서 commit, push, pull하기
•
Git에서 브랜치 만들고 브랜치간 상호 전환하기
•
Git에서 브랜치 병합하기
•
Github과 같은 원격 저장소에서 fork하기, pull request 요청 보내기
•
Git에서 reset하기
현업에서 Git을 사용할 때는 이제 좀 더 많은 것을 알아가기 시작했다.
•
현업에서 배웠던 것들
◦
Git rebase로 커밋 로그 수정하기, 커밋 합치기(squash, fixup)
•
심화학습한 것들
◦
Git rebase를 이용하여 커밋 author 수정하기
◦
Git reset과 revert 차이점 숙지
◦
cherrypick 기능의 이해와 사용하는 법
◦
사실 Git의 브랜치는 커밋 시점을 가리키는 포인터이고 이 커밋은 각각 파생된 시점의 커밋의 고유 ID(SHA1)를 가리키고 있다는 것.
◦
fastforward 용어의 이해
◦
Git rebase로 실수했을 때 reflog라는 명령어 사용하여 잃어버린 커밋 찾기
Rebase와 같은 경우는 현업에서 사용하고 있으니까 선임 개발자에게 배운 것이 있었지만, 현업에서 사용하는 수준만으로 Git을 많이 이해하기란 어려운 것이 현실이었다. 취업 이전에 Git을 공부하고 싶은 마음도 있었지만, Git을 배우는 것보다 우선은 프로그래밍 언어를 좀 더 잘 다루거나 React 라이브러리를 잘 사용하는 것이라고 생각했기 때문에 섣불리 배우지 못했던 것도 있다.
취업 이후에는 팀 개발을 위한 Git, Github 시작하기라는 책을 사서 공부하기 시작했는데 이 책에서 설명해주는 내용을 통해 어떤 원리로 동작하는지에 관해 이전보다 더 깊이 이해할 수 있게 되었다. 그렇다고 Git에 관한 모든 내용을 이해하기에는 아직 무리가 있지만, 적어도 이제 Git을 사용할 때 저는 Git을 사용할 때 제일 무서워요. 특히 Rebase할 때 소스코드가 날아갈까봐 무섭더라구요라는 말을 내뱉지는 않는다. Rebase를 잘못했을 때 reflog라는 명령어를 이용하여 특정 커밋 로그를 찾아내서 헤드 포인트를 이동시킬 수 있다(물론 이런 실수를 해서는 안 되지만, 개인적으로 공부할 때 학습을 시도했던 적이 있다).
하지만, 앞으로도 공부해야 할 것이 많기 때문에 겨우 이정도의 능력을 갖추게 되었다고 해서 안주해서는 안 될 것이다. 특히 상기 명시한 내용은 알았다 혹은 경험했다이지, 명시한 모든 내용을 누군가에게 완벽하게 설명할 수 있을 정도로 정복한 것은 아니기 때문이다.
다만, 이렇게 회고록을 작성하는 이유는 개발자로서 연차만 쌓는 것이 아닌 해당 연차만큼의 경험치를 축적하면서 더 많은 성장을 이루고자 기록으로서 남겨두는 것이다. 반 년 동안 정신없이 회사생활을 적응하는 데만 몰두해서 아무것도 배운 것이 없는가 싶었는데 생각보다 많은 경험치를 쌓은 것 같아 다행이라는 생각이 든다. 세월이 지날수록 낡은 레거시한 개발자가 되기보다 경험이 깊어지는 노련한 베테랑 개발자가 되고 싶다.