글을 적는 목적

장기적인 관점에서는

• 현재까지 내가 무엇을 했는지
• 현재 내가 무엇을 하는지
• 앞으로 내가 무엇을 해야할지

에 대해서 돌아볼 시간이 필요하다는 걸 느꼈기 때문이다.

현재까지 내가 무엇을 했는지

• 더 보기

  극히 기초적인 수준의 개발능력

  • 자바스크립트, 타입스크립트를 사용할 줄 안다.

  • 일단은 동작하는 아주 간단한 서비스정도의 서버는 혼자서 만들 수 있게 되었다.

    극히 기초적인 수준의 알고리즘

  • 어떤 알고리즘이 있는지, 어떻게 사용하는지 정도를 기초적으로 이해하고있다.

  • 프로그래머스 레벨1을 다 풀었고, 프로그래머스 레벨2는 1/3 정도 풀었다.

  • 그러나 기업들의 코딩테스트는 아직 탈락하는 수준이다.

    극히 기초적인 수준의 전산학과 인프라의 일부 분야 지식

  • 네트워크에 대해서는 아주 기초적인 수준정도만을 이해하고 있다.
    - osi 7 layer, 그리고 aws 의 구성 등등

    극히 기초적인 수준의 소프트웨어 공학 지식

  • SOLID 가 무엇인지, component level 에서의 관리는 어떻게 해야하는지를 클린코드를 보고 알았다.

현재 내가 무엇을 하는지

• 더 보기

  알고리즘 연습

  • leetcode 를 통해서 한 주에 easy 1문제, medium 1문제를 풀고 있다.

    소프트웨어 공학 지식 공부

  • typescript + nestjs 를 사용하여 개발하기에 OOP 에 대한 좀 더 깊은 지식의 필요성을 느껴 객체지향의 사실과 오해에 대해 사람들과 모여서 공부하고 있다.

  • clean architecture 라는 책을 최근에 1회독 하면서 위에 있는 극히 기초적인 수준의 소프트웨어 공학 지식을 얻게 되었다.

    • 중간중간 언급되거나, 사용하게 되는 design pattern 에 대해서 공부하고 있다.
      • singleton
      • abstract factory
      • strategy
      • dependency injection
      • facade

  • 각 method 에 대한 unit test 작성을 시도하고 있고, test driven development 에 대해 알아보았다.

    • service logic 이 의존하는 repository layer 까지도 실제 in-memory database 나 local database 를 통해 주입/생성하여 testing 하기보다는, service logic 에 repository layer 를 mocking 한 채로 solitary 한 testing 을 해야겠다는 결론을 내렸다.
    • test case 파악을 위한 edge case, happy route 도출을 위해선 state transition diagram / matrix 를 그려서 도출해내는 것이 괜찮은 방법이라는 걸 깨달았다.

  • 그러나, 아직까지 dependency 들을 어떻게 mocking 할지에 대해서는 조금 더 공부가 필요하다.
    - jest.fn 등을 사용해서 해 보고 있는데, 쉽지 않다.

    high availability 를 위해 필요한 것들의 탐구

    high availability, 즉 고가용성을 위해서는

  • caching 을 위한 redis

  • containerization 을 위한 docker

  • container orchastration 을 위한 k8s

  • micro service 간의 통신을 위한 kafca 와 같은 message queue

  • database read/write connection 분리

    정도가 필요하다는 사실을 최근에 알았다.

앞으로 내가 무엇을 해야할지

• 더 보기

  시점에 맞는 필요한 공부 하기

  • 가장 중요한 역량인 거 같다.
    - domain driven design 에 대해서 공부해 보려고 했지만, 이는 좀 더 천천히 해도 될 거 같다.

    전산학 기초 지식에 대한 깊은 탐구

  • 많은 라이브러리들이나 프로그래밍 언어에 대한 피상적인 이해만을 하고 넘어가는 것보다는, 그것들이 공통적으로 돌아가는 운영체제에 대해서 알아야겠다는 생각을 했다.

  • 그리고 네트워크에 대해서 알아야겠다는 생각을 했다. 그냥 request, response 정도만을 알고있지, 나머지는 전혀 모르는 상황이다.

    꾸준한, 그리고 더 수준높은 알고리즘 공부를 통한 computational, analytical thinking

  • 이것이 정말로 많이 부족한 거 같다.

    • 특히 lukas 덕분에 내가 time complexity 를 완전히 잘못 계산하고 있다는 사실을 깨달았다.

  • 결국 내가 코드로 작성하는 모든 것은 컴퓨터라는 연산장치를 통해 명령을 내림으로써 연산이란 행위를 하는 것인데, 이 연산에 대한 분석적 사고 그리고 계산적 사고가 되지 않으면 안 된다는 생각을 했다.

  • 개인적으로, 약 500일 동안 하루 1개씩 leetcode 문제를 푼 어떤 사람의 후기가 정말 인상깊었었다.

    안정적인 운영을 위한 logging, parsing, debugging

  • 이것도 정말 부족하다.

  • 현재는 pm2 라는 process management library 를 통해 서비스를 배포하고 있고, 기본적인 logging 기능을 통해서 로그를 남기는 중이다.
    - 그러나, 로그의 형식도 정형화 되어있지 않고, 로그를 검색하는 것도 정말 불편하다.
    - 안정적인 서비스 운영을 위해선 어떤 로그를 어떻게 남겨야할지, 그리고 그걸 쉽게 찾아보기 위해서는 어떤 걸 해야할지 생각해보아야 한다.

    Java, Spring, Spring Boot, 그리고 Kotlin

  • 한국 기준으로 채용공고를 찾아보면 거의 Java, Spring, 혹은 Kotlin, Spring 을 요구하는 경우가 많았다.

  • node + TypeScript 를 통해서만 개발을 했고, 개발을 하고있으면서 커리어에 대한 고민도 하게 되고, 그리고 다른 프로그래밍 언어를 깊게 공부해 본 적은 전무하기 때문에(c를 잠시 해 봤다거나, python 을 잠시 해봤던 적은 있다. 그러나 이를 production level 에서 사용할 수 있을 정도로 해 본 적이 없다) 해 봐야 겠다는 생각을 했다.

  • 특히, Java 와 유사한 TypeScript 를 통해서 개발을 해보면서 'Java 란 어떤 언어일까?', 그리고 '그걸 개량한 언어인 Kotlin 은 어떤 언어일까?' 라는 호기심이 크다.

생각이 많아지지만 생각만 많다면 앞으로 나아갈 수 없다는 사실을 잘 알고 있다. 고민을 하지말고, 무엇을 해야할지 근거를 통해 분석하고, 해야 하는 일을 찾아서 하는 게 해결책이라는 것 또한 잘 알고있다.