안녕하세요, 주니어 개발자 Eon입니다.
(어투는 제 회고이니 양해 바랍니다.)
2021년을 마무리하며 올 한 해동안 느낀 점들을 작성하고 회고하는 시간을 가져보겠다.
뭐 대단한 사람도 아니고 기껏해야 주니어 개발자이지만 성장 일기 느낌으로 기록을 남기고 싶어서 작성한다.
때는 바야흐로 작년 8월.. (시간의 흐름대로 작성, 2021년의 시점이 언제인지는 모른다..!!)
개발자로서의 첫 발을 내딛었을 때, 처음 맡게 된 업무는 이미 개발된 웹페이지에 대한 테스트였다.
이미 개발되었고, 서비스 중인 웹페이지를 테스트하고 디버깅하는 업무는 시작부터 고민이었다.
"어디서부터 시작해야 하지?"
하지만 고민의 시간은 짧았다.
사용자의 입장에서 이것 저것 눌러보고 메뉴얼의 일반적인 순서대로 진행하는 것이 아닌 억지로 순서를 바꿔가며 테스트하기 시작했다.
결과는 역시 '여러 가지 문제점을 발견했다.' 였다.
그러나 대뜸 시작한 마구잡이식 테스트였기에 내가 뭘 눌러서 이렇게 됐는지 재현하는 게 쉽지 않았다.
문제점을 인지하고 곧바로 테스트를 진행하며 동시에, 내가 뭘 눌렀는지 하나씩 정리하기 시작했다.
그렇게 테스트 / 디버깅 업무에서부터 하나 배우고 시작하게 됐다.
인사이동으로 팀이 배정이 되고, 본격적으로 개발 업무를 시작하게 됐다.
그리고 곧바로 업무분장을 통해 직무를 부여 받았고, 백엔드를 담당하게 됐다.
Golang을 사용하게 됐다.
처음 접근은 처참하리만큼 실패였다고 말할 수 있다.
대개 '신입 사원에게는 기대 안 한다.' 라는 말들을 하지만, 성격상 월급 꼬박꼬박 받으며 일도 잘 못하는 그런 기간은 빨리 줄이고 싶었다.
그래서 코드를 분석하는 기간이 짧았고, 팀장님께서 요구하신 REST-API 개발을 시작했다.
Go를 써본 적도 없는데 말이다.
처음 보는 문법에 헷갈리는 게 한두 가지가 아니었고 새로운 언어를 배울 때, 누가 가르쳐주지 않고 홀로 배우는 것은 처음이었기에 더 어려웠다.
홀로 공부하는 것은 아직까지도 많은 노력이 필요하다.
var value int
var value int = 0
value := 0
Go를 처음 접할 때, 헷갈린 것들 중 하나가 바로 변수 선언, 초기화다.
뭐, 그래. 좋아! 여기까진 적응하는 데에 어려움은 없었다.
그런데 문제는 이게 왜 이렇게 쓰이는지 찾아보질 않고 계속 코드만 들여다 보고 있었던 거다.
Go에 대한 어떤 기본적인 강의 영상이나 문서나 블로그 글을 찾아보지도 않고 그저 보고 있던 게 내가 평가하는 나의 가장 큰 실수였다.
개발자의 덕목 중 하나가 바로 검색 능력이다.
학교 다닐 때 프로젝트할 때만 해도 잘만 검색해서 개발하곤 했는데, 막상 현업에 발을 내딛고 심지어 새로운 언어를 접하게 되니 머릿속이 백지가 돼 버린...
코드를 쭉 보다가 갑자기 Msg string `json:"message"`
응???
struct tag에 부딪히고야 말았다.
뭐, 어차피 곧바로 개발 시작한 것도 아니었고 기껏해야 Go가 어떤 언어인지 보고 있었으니 이제라도 검색을 해서 공부하기 시작했다.
이제서야 Golang으로 짜여진 코드를 볼 수 있게 됐다.
완벽히 모든 것들을 공부하고 시작한 것은 아니어도, 작성돼 있는 것들은 얼추 어떤 역할을 하는 코드인지 파악할 수 있게 된 것이다.
Golang에는 try catch가 없습니다.. 네?
이걸 몰랐을 때는 코드를 보면서도 참 지저분하다고 생각했다.
API 하나에서 처리되는 에러만 해도 3개 이상..
그런데 이걸 예쁘게 한 번에 처리할 수도 없고 이렇게 써야 한다니..!!
라고 생각했지만, 이렇게 에러가 튀어나올 때마다 바로바로 처리해주는 게 습관이 되고 나서 보니, 에러처리에 대한 직관성이 잘 확보되는 것 같다고 생각이 바뀌게 되었다.
장단점이 확실하지만 뭐 어쩌겠습니까? 지금 제가 써야 하는 언어인 걸요!
REST-API 개발 업무를 맡게 되고 하루 빨리 API 하나 하나 뚝딱뚝딱 만들어내야겠다는 생각이 머릿속을 지배했다.
REST-API에서 Request를 보내는 파트는 go-resty라는 패키지를 사용한다.
코드를 보며 '아 이렇게 보내는 거구나' 라는 직감으로 바로 개발을 진행할 수 있었다.
그런데?
REST-API는 뭘까? 하는 생각이 뒤늦게 들고 말았다.
RESTful한 API.. 심오하다 심오해
퇴근길에 유튜브를 켜서 REST-API에 대한 약 50분 정도 되는 길이의 영상을 시청하게 됐다.
REST-API의 역사 그 자체를 알게 되고, 이제 그 목적을 정확히 알고 개발할 수 있겠다는 생각을 하게 되었다.
또, 여기서 느낀 것이..
'개발자들은 서로의 지식을 공유하는 것이 어렵지 않구나.'
'검색만 하면 누군가 정리해둔 글들이 정말 많구나.'
'글 뿐만 아니라 영상, 강의도 정말 많네?'
새삼스레 느낀 점들이다.
학교에서 개발할 때는 아무 생각없이 그저 '인터넷에 올라와 있으니까.' 찾아서 공부하고 썼던 것들인데, 사회로 나와 보니 이게 당연한 게 아니라는 것을 알게 되었다.
다른 직업군에서는 볼 수 없는 문화가 개발자들 사이에는 형성되어 있는 것 같다.
부모님 세대에서만 봐도 '사수가 일을 안 가르쳐주고 자기 밥그릇 챙기기에 급급했다.' 는 얘기를 심심치 않게 들어볼 수 있는데..
정말 자기가 하는 일이 전문화되어 있고, '이 일은 나 아니면 못 해' 가 아니면 일자리조차 보장되지 않던 시절이었으니까.
아직까지도 이런 마인드가 남아 있는 회사들이 정말 많은 것 같다.
주변 다른 직업군 친구들 얘기만 들어보더라도.. 있다. 분명히..
그런데 개발자들은 자신의 기술을 공유한다.
stackoverflow, velog, github page, tistory 등등 본인이 시행착오를 겪어 이룬 기술을 다른 사람들과 공유한다.
또! 오픈소스라는 분야는 정말 대단한 것 같다.
엄청난 노력이 들어간 코드를 무료로 제공한다는 점이..!!
오픈소스가 없었다면 기술 블로그와 같은 문화도 자리 잡을 일은 없었을 것 같다.
내가 velog를 시작한 이유이기도 하다.
(감사함은 진작에 느꼈고 기여하기 위해 velog를 시작한 것은 꽤나 최근이다.)
비록 알고 있는 범위가 다른 선배 개발자들보다야 훨씬 좁지만, 감사함에 힘입어 시작했다.
포스팅 주기가 그리 짧지 않고 늘어지기도 하지만, 꾸준히 작성해서 사회에 기여하고 싶다.
REST-API를 만들다 보니, 보안에 대한 부분을 신경쓰지 않을 수 없었다.
어떻게 해야 공격을 줄일 수 있을까?
어떻게 해야 공격을 안 받을 수 있을까?
피할 수 없다면 어떻게 해야 서버가 뻗지 않을 수 있을까?
아무리 고민해도 모자라지 않은, 하지만 과하면 독이 되는..
보안은 참 어렵다. 어렵다 어려워 너무..
그러면 사용자를 특정할 수 있고, API 호출을 할 때 유효성 검사만 하면 되지 않느냐?
아니다!!
어쨌든 토큰이고, 어떤 방법으로든 토큰은 탈취당할 수 있다.
탈취당하면 끝이다!!
뭐 얼마나 짧게..??
10분 15분? 은행 웹 페이지처럼??
절대 안 된다.
뭐, 절대라고까진 아니어도 사실 그렇게까지 짧게 설정하면 좋지 않다.
JWT를 쓰지 않았을 때를 가정하고 사용자가 로그인을 한 후에, API 요청을 하게 되면!
서버는 API 요청에 알맞게 동작을 수행하고 응답을 보낸다.
이 과정 사이에 JWT 토큰을 보관하는 DB가 필요하고, 10분 15분이 지나서 토큰이 만료되면 DB에 새로운 토큰을 넣어, 새로 발급해야 한다.
또한 사용자마다 토큰을 다르게 해야 하기 때문에 그 양은 상당하다.
동접자 10만명일 때, (물론 지금 개발하는 서비스가 그렇게까지 거대한 것도 아니지만..) 10만명이 어떤 동작을 수행할 때마다 API 요청을 하고, 거기에 추가로!
추가로, 토큰 시간이 만료되기 전에 새로운 토큰을 발급받는다면??
없어도 됐을 10만 번의 트랜잭션이 10분 15분마다 한 번씩 추가되는 셈이다.
어떡하긴!
JWT만 사용하는 방식에서 벗어나면 된다.
이중 보안!
JWT와 Basic Authentication을 활용할 수 있다.
근데 Basic Auth도 탈취당하면?
CORS라는 방법이 있다!
Cross Origin Resource Sharing
정말 극악무도하지 않을 수 없다.
특정한 도메인에서 오는 요청만 허용할 수 있게 하는 보안 옵션인데, 이게 설정하는 게 여간 까다롭고 복잡하다.
하지만 잘만 설정하면 내가 지정한 도메인에서의 요청만 받고, 나머지 요청은 거절하게 된다.
아무튼 나도 CORS 때문에 고생깨나 했다.
NO!! 그렇지 않다.
하지만 어쩌겠는가..
철통보안을 위해 가져다 쓸 수 있는 모든 보안체계를 투입하게 되면 서버는 버티지 못할 것이다.
적절한 절충안이 필요했고, 일단 당장은 여기까지만 하자는 결론에 이르렀다.
사내 문서화를 위해 사용하는 Wiki는 이 벨로그마냥 정리하기 편하다.
여러 협업툴들이 있지만 당장 현업에서 사용하고 있는 게 wiki이기에.
주로 Wiki에는 사내 프로젝트에서 쓰인 기술이나 코드 기능에 대한 부분, API 문서 등을 작성한다.
그 외에 오픈되어 있는 기술들에 대해서는 velog에 작성하기도 한다.
뭐 아무튼 사내 기밀 유지를 위해 API 기능들을 velog에 소개하진 않고, 어떻게 API 기능을 작성하는지 정도는 공유할 수 있을 것이다.
버전 관리, 이슈 관리를 위해 사용하는 Jira는 정말 편리하다.
나의 업무 진척도를 바로 바로 공유할 수 있고, 내 앞에 티켓이 몇 개나 있는지도 확인할 수 있다.
서로 메신저나 직접적인 대화를 하지 않더라도 업무 부여나 문제 제기가 가능하다.
가장 좋은 점은, 내가 할 일이 무엇이있는지 고민할 필요가 없다는 점이다.
내 앞에 있는 티켓을 전부 처리하면 나는 자유다.
물론 이마저도 성격상 일을 다 처리하면 다른 일거리 없는지 찾아보곤 한다.
'월급 루팡' 이란 내 사전에 없다..
앗, 아직까지 재택근무할 땐 약간 업무 효율이 떨어지는 것 같기도..
바로 위에 재택근무에 대한 부분을 언급하며 급 떠올린 재택근무..
재택근무를 번갈아 가며 하고 있는데 재택을 하면 장단점이 너무나 확실하다.
출퇴근 시간이 온전히 내 시간이 된다.
버스를 타는 시간도, 지하철을 타는 시간도, 사실 출퇴근하며 유튜브나 구글링으로 공부를 하기도 하고 넷플릭스나 모바일 게임을 즐기며 딱히 지루하지 않은 시간들을 보내고 있었지만..
잠을 더 오래 잘 수 있고, 퇴근이 빠르고! 좀 더 게을러질 수 있었다.(?)
집에는 놀 게 너무 많다!!
당장 내 책상을 보면 바로 앞에 데스크탑, 노트북 (노트북은 업무용으로 사용합니다), 닌텐도 스위치, 스마트폰, 태블릿..!!
유혹이 너무나 많다..
심지어 옆으로 고개만 돌리면 침대가 보이니.. 할 말 다 했다.
유혹을 참고 일을 하려니 너무 힘들다 ㅎㅎ..
그렇다고 온전히 일만 8시간 꽉 채워서 한다고 할 수는 없지만..!!
딴 짓은 최대한 안 하려고 하는 편이다.
최근에는 이를 방지하기 위해 스터디 카페를 간다.
적어도 업무 보는 시간엔 휴게 공간이랑 분리해두는 게 좋은 것 같다.
덕분에 재택임에도 업무 능력 상승!!
그럼에도 나는 회사로 출근하는 게 더 맞는 것 같다....
신입!! 말 그대로 신입 그 자체였다.
좌충우돌 개발자 적응기이며, 꿈만 큰 똥덩어리(?)랄까..
열심히 하고자 하는 의욕은 넘치고 배우고자 하는 마음도 크지만 당장에 실력은 없는..
그런 상태다.
그럼에도 불구하고 정말 많은 걸 배웠다는 확신은 있는 그런 한 해였다.
정말, 많은 성장을 할 수 있는 한 해였다.
지금 계속해서 포스팅하고 있는 Golang 기초 시리즈는 꽤 오래 지속될 것으로 보인다.
당장 1년 동안 사용한 Golang이지만 아직까지도 제대로 활용하고 있지 못하다는 느낌이 크다.
공부를 완벽히 해두고 시작한 게 아닌 탓일까, 아니면 아직도 공부하는 방법을 모르는 걸까.
아무튼 기초 시리즈를 포스팅하면서 새로 배우는 것들도 많고 다시 한 번 생각하게 되는 그런 시간들을 가지고 있다.
이 두 가지 타이틀을 걸고 열심히, 치열하게 살아낸 2021년이다.
'나, 이제 제법 개발자의 모습을 갖췄을지도?'
라고 착각을 하곤 한다.
내년엔 어떤 일들이 있을까?
내가 만들고 있는 서비스는 무사히 런칭할 수 있을까?
나는 어떤 개발자가 되어 있을까?
당장에 기대되는 것들이다.
내년엔 제대로 Gopher가 돼 보겠다.
이상입니다.👍