2017년 - 지나간 일을 되돌아봄
승돌 쓰다
글 쓰는 프로그래머 승돌입니다.
지난번 작성했던, 신입 개발자의 개발력을 높이는 방법은?? 두 번째 의 글의 공유가 자그마치!! 320번 공유되었습니다. (놀라운 숫자였습니다.)
라이킷 눌러주시고 || 공유해주시고 || 댓글 남겨주시고, 읽어 주신 모든 분들에게 감사합니다.
오늘은 2017년의 지나간 일을 되돌아보려고 합니다.
간략하게 제가 느낀 한 해의 회고를 남겨둔 곳이 있는데요. 간략 회고를 남겼습니다.
2017년 - 지나간 일을 되돌아 봄, 시작하겠습니다.
2017년의 한 해는 업무의 적응기
저는 특정 서비스를 하는 프런트 파트에서 일하는 개발자입니다.
물론, 입사한 지 어언 1년이 지남에도 불구하고 업무를 완벽히 아는가?
질문에 답을 하자면, No라고 답할 수 있습니다.
업무의 영역은 크게 두 가지이지만, 한 가지의 업무 자체도 워낙의 크기에 제가 모든 세세한 부분을 알기가 어렵습니다. 사실, 그래서 2017년은 참 많이 부족한 사람이라 느낀 해이기도 하네요.
이제 막, 입사하신 분들, 예정이신 분들은 겁내지 않아도 괜찮습니다. (해치지 않아요)
1년 지나도 이렇게 업무를 완벽히 처리하지 못하는 사람 저 여깄어요!
(제가 생각한 바를 충족하지 못했습니다. 그래서 부족한 한 해..ㅠㅠ였습니다.)
그럼 나는 일을 못하는 개발자인가? 그에 대해서는 말하고 싶은 게 있습니다.
너는 무엇을 했니?
업무적인 면에서는 사실, 그렇게 큰 성장을 하지 못했다는 것은 사실입니다.
그럼에도 불구하고, 새로운 것들을 도입하는 데에는 제가 관심이 많다 보니 이것저것 도입을 하게 된 계기가 되었습니다.
사실, 신입 개발자가 회사에 들어가 기여할 수 있는 부분이 많을 수도 적을 수도 있습니다.
웹 서비스를 하는 회사라면 더더욱이요. 규모가 큰지, 작은지에 대해서도 기여할 수 있는 크기가 나뉩니다.
그렇다면, 내가 할 일이 정녕 없었을까요? 아니요. 개발자는 경력이 많든 적든, 공부를 하는 사람이어야 하고, 그것을 적용해보는 노력을 해야 합니다.
그러한 예를 하나 소개하고 싶습니다. (실은, 일 열심히 했습니다.)
저는 인프라 관리측면에서 효과적인 Ansible이라는 녀석을 처음 접했습니다.
생각해보니 이 친구는 Infrastructure as Code라는 새로운 개념에 알맞은 인프라 환경 설정 자동화를 돕는 녀석입니다. Configuration Management Tool이라고도 불립니다.
제가 이 친구를 왜 도입했을까요?
개발자는 인프라에 대한 지식을 본인이 지녀야 한다고 생각하는 편입니다.
요즘 AWS, Azure, GCP 같은 클라우드 서비스에서 모든 것을 다 해줍니다.
그렇지만, 가장 중요한 인프라 관리를 못하는 개발자는 인프라 문제가 발생했을 때, 조치할 수 있는 것이 없습니다. Devops라고도 하지만, 그것이 과연 어느 한쪽에만 치우쳐진 엔지니어만의 몫일까요?
실질적인 웹 서비스가 나가기까지 System Engineer (SE)분들이 해주시는 영역이 존재하며, 웹 개발자가 시스템 상에서 해야 할 몫이 있습니다. 그 부분은 웹 개발자가 맡아야 합니다.
그 부분을 저는 신입 개발자로서 해야 할 몫이 저것이다!!라고 생각했습니다. (파트내 성장 프로세스 같기도...?)
사실 리눅스를 배우는 걸 좋아하는 편이라...좋았습니다.
개발자가 왜 갑자기 인프라 이야기를 꺼내는 걸까?라고 하시면, 음... 이유 없이 의식의 흐름입니다.
고로, 2017년에는 인프라적인 지식을 쌓는 한 해이기도 했습니다.
이를테면, Tomcat이라던가...
톰캣 고양이라던가...
리눅스라던가...
쉘 스크립트라던가... 하..
회고하기에는 너무 적은 양이 아닐까... 왈칵..그리고 저는 2017년은 생각의 전환이 많았던 해이기도 했습니다. 꿈많고, 욕심 많던 개발자였기도 했습니다.
일 잘하는 개발자는 어떤 사람일까? 능력이 좋은 개발자의 재정의
사실, 저는 이전부터 유명한 개발자이고 싶어 했습니다. 이를테면 네임드 개발자 그런... 개발자요.
개발을 정말 잘~ 한다라고 평가받고 싶었습니다. (어처구니없는 생각이었네요.)
어느 날, 멘토님과 이야기를 한 적이 있었습니다. 이런저런 이야기를 하다가 제가 본 인터넷 기사를 하나 보여드렸습니다.
내용은 흰머리가 날정도로 나이 드신 분께서 실무 개발을 하신다는 분의 기사를 보았습니다.
그 이야기를 나누면서 저도 그렇게 되고 싶고, 좀 개발을 잘하고 싶다고 말씀드렸습니다.
멘토님이 저에게 해주신 이야기는 이렇습니다.
"개발을 잘하는 건 뭘까?"
"개발 잘하는 사람이 누구야?"
이렇게 되물으시고, 제가 느낀 것은 아! 유명한 사람만 개발을 잘 하는 사람이 아니구나.
잘하는 것은 정량화할 수 없구나.
"나는 한 분야의 도메인 지식을 완전히 흡수한 개발자가 되고 싶다"
"그 분야의 도메인 깊이감을 지니고, 설계를 잘하는 개발자"로 일하고 싶다고... 하셨는데, 생각해보니 그렇습니다.
개발을 잘한다는 것은 평가하기 어렵습니다. 네임드 개발자.. 많은 이들이 알아주면 좋겠죠.
(저도 그런 것을 바랐고, 욕심을 가지고 있었습니다.)
생각해보니, 우리가 알만한 개발자들의 실력만 와! 정말 대단하다고 생각하기보다는 남이 알아주지 않아도 회사에서 열심히 개발을 하고, 좋은 서비스를 내기 위해 고군분투하고 있는 은둔형 고수들이 많다는 사실을 깨달았습니다. 과연, 이름이 널린 개발자들만 대단한 고수들인가?에 대한 의문이 생겼습니다.
아, 이때 깨달았습니다. 자신의 자리에서 열심히 서비스를 만들어내고, 프레임워크를 만들어내고, 라이브러리를 개발하는 사람들 모두가 다 "잘 하는 개발자"였구나. 꼭 남이 알아주는 네임드가 아니어도 되겠다.
이때부터 저의 목표는 "나와 같이 일하고 싶어 하는 개발자"로 방향을 틀게 되는 계기가 되었습니다.
정말 세세한 코드의 구현보다 실질적인 서비스의 결과물이 중요하고, 같이 일하는 동료에 대한 생각을 하게 되었습니다. 이때에 깨달았습니다. 그리고 깊이 있는 도메인 지식이 중요하다는 것도요.
(대신 클린 코드를 지향하는 것은 옳습니다.) 누가 개발을 잘하고 어떻게 잘하냐에 대한 저만의 선입견적인 견해가 사라졌다.라고 표현할 수 있겠네요.
코딩 잘한다는 것은 무엇일까?
코딩을 잘 한다는 것을 과연 정량적으로 도출할 수 있을까요?
없다고 생각합니다.
시간 대비 라인수?! 혹은 효율적인 알고리즘? 빠른 프로토타이핑 개발?
어떤 게 좋은 것인가에 대한 의구심이 들었습니다.
(저는 아직 걸음마 단계의 개발자입니다.)
서비스 개발자는 빠른 개발이 중요합니다. (저의 생각일 뿐, 정답이 아닙니다.)
모든 것이 빨리 변화하고, 대응해야 하는 것들이 많은 곳이 IT분야입니다.
그 속에서 정말 아름다운 코드만 만들 수 있을까요?
프로그래밍이란, 절대적인 시간이 필요로 합니다.
프로그래밍 생산성을 높이는 작전도 본인이 잘 짜야합니다.
IDE 잘 쓰기 위한 학습
단축키 사용
마우스 사용을 최대한 줄이기
lint 사용하기
코드 컨벤션 Rule 적용
이러한 것들도 우스워보이지만, 중요한 요소이기도합니다.
그리고 시스템적, 코드 방법론적으로도 코딩을 잘할 수 있도록 돕는 것들이 있습니다.
CI 서버 도입
정적 코드 분석 툴 사용
테스트 코드 작성
위와 같은 시스템, 툴, 방법론을 이용하면, 프로그래밍을 좀 더 효율적으로 할 수 있습니다.
말 그대로, 잘~할 수 있게 도와줍니다.
결론적으로 코딩을 잘한다는 것은 개개인의 철학마다 다르다는 사실입니다.
어떠한 요소로 뽑아낼 수 있다는 것에 의구심을 품게 되었습니다.
그리고 2017년의 얻은 것은 무엇인가를 정리했습니다.
소박한 목표를 이루었다. (라고 말해보자.)
같은 직업을 가진 사람들을 위한 글쓰기 시작
업무에 도움이 될만한 것들에 기여함. (비밀+ㅁ+)
"나만 아는 것은 중요하지 않다."라는 마인드로 기술 공유 시작 (파트 내)
외부 콘퍼런스 참석 3회 (너무 적네요..ㅠ)
같이 일하는 사람들에 대한 생각의 확립
2017년 얻은 것은 생각의 변화
개발자로 일한 지 1년이 지났다.
그렇다고 내가 무언가 개발자로서 능력이 많이 향상되진 않는다는 것을 느꼈다.
업무와 개발 능력의 성장은 다르다. 다만, 개발적인 성장을 업무에 녹여내는 것이 진짜 실력이다.
미래의 로드맵 준비
향후 4년 뒤는 항상 준비해야 한다고 생각하게 되었다.
내가 무슨 일을 하고 싶은지? 어떤 서비스를 만들고 싶은지?
설계의 중요성
무슨 일을 하든지 설계 능력의 중요성을 깨닫게 되는 한 해가 되었다.
큰 그림을 그리는 생각을 자주 하는 습관을 들이는 것이 좋을 것 같다고 느꼈다.
데이터는 어떻게 전달받고, 전달해주며 어떻게 가공해야 하고 어디에 어떤 방식으로 저장해야 효율적인가?
어떻게 사용자에게 더 좋게 보여줄 수 있을까? 에 대한 고민도 해야 한다고 생각한다.
풀 스택 개발자의 함정
프런트, 백엔드를 둘 다 한다고 해서 좋은 것은 아니다.
둘 다 못하는 개발자가 될 수 있다.
헛된 허영심에 부풀어, 풀 스택 개발자가 짱이라는 생각은 버려야 한다.
지속적인 학습 습관 (Continuous Study Plan)
책을 읽되, 처음부터 끝까지 읽어야 책은 아니다.
약간의 버릇이 있다면, 책을 머리말부터 부록까지 순서대로 보는 습관이 있었습니다.
책의 인덱스가 있다는 사실을 잘 활용하는 것도 시간을 줄이며, 지식을 쌓는 방법입니다.
올해도 무척이나 지키지 못했던 것은 영어로 된 문서를 두려워하지 말자.
의도적인 학습으로 인해 능력을 키워야만 할 것 같습니다.
의식의 흐름으로 작성했습니다. (용서해주십시오...)
저는 2018년 연말에는 어떤 성장을 했을지, 어떤 생각의 변화가 있을지 궁금해지네요.
저의 글들이 생각들이 읽어주시는 분들에게 조금이나마 도움이 되었으면 합니다.
감사합니다.
