인터뷰 내용은 다음에서 확인하실 수 있습니다!
https://velog.io/@junghyeonsu/%ED%96%A5%EB%A1%9C%EB%8F%99%EC%9A%B1%EB%8B%98%EC%9D%84-%EB%A7%8C%EB%82%98%EB%8B%A4
기술 역량을 떠나서 개발자로서, 사람으로서 굉장히 배울 점이 많은 분이라는 생각이 들었다.
겸손한 태도
DM으로 연락을 주고받을 때도 느꼈지만 정말 겸손하신 분이다. 그런데 오히려 그런 태도 때문에 항상 어디선가 많이 배울 수 있으시지 않으셨나 하는 생각이 든다. 단적인 예로 현재 한 기업에 CTO이심에도 불구하고 블로그 글을 보면 프론트엔드 코드 리뷰를 받으시며 공부하시는 것 같다. 그 분을 보면서 조금 더 안다고 거들먹거리지 않으며 항상 배우려는 자세를 가져야지 하는 생각이 정말 많이 들었다.
경청하는 태도
나나 현수가 질문할 때도 꽤 긴 질문이였음에도 불구하고 모든 질문에 대해 순서대로 다 답변해 주시고, 들으시면서 계속 이해한게 맞는지 확인하셨다. 진짜 다른 사람들의 말을 경청한다는 생각이 들었으며 말도 거침없이 잘 하시는데 이래서 훌륭한 개발자는 소통도 잘해야 한다는 말이 나오는 구나 하는 생각이 들었다.
테스트하기 좋은 코드란 뭘까?
인터뷰를 진행하면서 코드 설계를 할 때 테스트하기 좋은 코드를 짜는 것 또한 능력이라는 말을 강조하셨다. 이 말이 무슨 말일까? 조만간 찾아서 공부해 봐야겠다.
현재 나의 우선순위는 뭘까?
어쨌든 현재 내 목표는 좋은 백엔드 개발자가 되는 것이기 때문에 백엔드 코드를 더 잘 다루는 것이 우선과제가 아닐까 싶다. DevOps적인 측면의 욕심은 조금 내려놓고, 현재 나에게 있어 공부가 필요한 요소들에 생각해 봤다.
현재는 회사 코드에서 업무와 관련된 코드만 뜯어보고 있었다. 그러면서 다른 곳에서 좋은 코드를 찾고 있었는데, 향로님의 조언을 듣고 다시 생각해 보니 잘하는 개발자들의 코드를 매일 접하고 있다는 걸 깨달았다.
따라서 업무를 넘어 회사의 전반적인 코드를 살펴보면서 공부할 수 있는 요소들에 대해 다시 생각해 보았다.
api들을 정리하며 우리 회사에서는 어떤 서비스를 사용하기 위해 어떻게 통신할까?
DB를 다루는 부분들은 어떻게 조작할까?
아키텍쳐를 살펴보며 여기는 왜 이렇게 구성했는지 고민하고 이 구성에 대한 장단점을 객관적으로 판단할 수 있어야겠다. (장애 대응, 성능 개선에서도 이득이 될 것 같다)
테스트코드와 예외처리들을 확인하면서 어떠한 경우에 어떤 에러가 발생하기 때문에 이런 식으로 처리했구나 하는 부분들을 배울 수 있을 것 같다.
예전 장애 히스토리, 로그 등을 볼 수 있게 요청하고, 기록들을 보면서 어떨 때 이런 문제가 발생했고 그걸 막으려고 어떤 노력을 했구나 하는 기록들도 보면 많이 배울 수 있을 것 같다.
아쉽게도 사내 DB 테이블 구성도와 api 명세서에 있는 설명들은 예전 버전에서 업데이트되어 있지 않다. 그러나 회사 코드들을 살펴보면서 내가 이 정보들을 업데이트하면 이것 만으로도 회사에서 인정 받을 수 있는 기회이기도 할 것 같다.(오히려 좋아)
작은 규모의 스타트업이라 아쉬운 부분들이 많지만, 다행인 점은 정말 좋은 시니어 분이 계시다는 것이다. 업무 관련된 일이 아니더라도 회사 관련 코드 혹은 그걸 넘어 개발적으로 질문을 드리면 항상 너무 좋은 답변을 해주시는 분인데, 그 분에게서 최대한 많이 배울 수 있도록 해야겠다는 생각이 든다.
향로님께서는 JVM으로 실력을 쌓는 것을 추천해 주셨지만, 그렇다고 해도 일단 회사는 나를 키우려고 고용한 것은 아니고 인턴에 걸맞는 task를 해결하라고 고용한 것이다. 물론 성장시키려는 목적도 있겠지만 어쨌거나 회사의 이익상 후자의 목적이 더 클 것이라 확신한다.
어쨌든 회사는 나에게 급여를 주고, 나를 배려한 여러 환경들을 제공해 주기 때문에 회사를 위한 공부를 우선하는 것이 맞다는 생각이 든다. 당장 내가 공부하면 생산력을 끌어낼 수 있는 기술들은 TS와 Node이다.
현재는 TS와 Node 기술들의 사용법 정도에 그치는 수준이지만, 원리와 활용법 정도를 우선 공부한 후에 영한님 강의를 들으면서 JVM, OOP, 쿼리, 테스트 등에 대한 공부를 하는 것이 맞다는 생각이 든다. 어쨌든 좋은 코드와 아키텍처라는 결은 같을 것이라 판단되기 때문에 이조차도 JS 기술에 대한 역량이 늘어날 것이란 생각이 든다.
개인 프로젝트도 조만간 해보려고 한다. 개인 프로젝트를 진행하며 트래픽을 받아보면서 이런 코드를 짜면 얼만큼 이상의 트래픽을 견딜 수 없구나, 실 트래픽을 받게 되면 이러한 에러를 동반하는 구나, 클라우드 워치로 트래픽을 받아보며 아 어느 상황에서 쿼리가 튀니까 이 부분이 위험한 부분이구나 등의 기록들을 모두 히스토리화해서 정리해 두면 정말 소중한 자산이 될 것이라는 확신이 들었다.
docker 위에 db를 올려놓고 가상의 트래픽을 부하시키는 등의 방법도 있겠지만, 예외 상황을 받기 위해선 실사용자를 확보해 유저들을 받아보는 것이 더 좋은 방법이겠다는 생각이 든다. (물론 전자도 좋은 방법이다.) 트래픽을 많이 받을 수 있는 서비스를 만들어 보려면 어떤 서비스를 만들어야 할지 고민해보는 과정도 필요할 것이다.
구현해보면서 실행해 보는게 목적이라면, 우리가 이미 비즈니스 로직을 꿰고 있는 오목, 체스와 같은 게임들을 만들어 보는 것도 좋다고 하셨다. 그런 게임들은 친절하게도 비즈니스 로직이 게임 설명서에 다 적혀있다. 이것도 완전 꿀팁이 아닐까?
생각날 때마다 글을 보면서 다잡고 열심히 공부해서 나도 언젠간 선한 영향력을 끼치는 멋진 개발자가 되고 싶다는 생각이 든다. 정말 생각 이상으로 값지고 행복한 시간이었다!! 😄
이 글을 읽어주신 분들에게 조금이라도 도움이 되었으면 정말 좋겠습니다. 다들 좋은 하루 보내시길 바랍니다!
와 오빠 안녕하세요!!! ㅋㅋㅋㅋ 인기글에 떠서 보러왔어영 👋👋