처음 개발 공부를 시작한 해가 마무리 되면서
올해 어떤 공부를 했는지, 내가 어떤것에 집중했는지, 그로인해 내가 느낀점은 무엇인지 되짚어보고자 한다

코끼리를 냉장고에 넣어보자 생각한 계기

프로그래밍 공부를 시작한 계기

옛날부터 프로그래밍은 동경의 대상이었다.
개발 공부를 어떻게 해야 할지 몰랐다. 그냥 이 정도가 최선인가보다 그저 그렇게 치부하며 대학교 생활이 마무리되는 듯 했는데

육군사관학교에 정보보호병으로 군 복무를 하면서 그곳에 있는 내부망, 서비스를 관리하고 여러 사람을 만나고,
속한 부대원들과 함께 편하게 일하기 위해서 여러 가지 스크립트를 짜면서 진지하게 개발 공부를
하고 싶다고 마음먹는 계기가 되었다.

전역 후 친구 한 명과 안정적인 서비스를 하나 만들어보자는 것을 목표로 잡았다
하지만 처음부터 그것이 가능할 리 없었고 심지어 함께 코드를 작성하며 협업하는 방법도 잘 몰랐다
먼저 무엇을 배워야 하는지도 몰라 무작정 검색을 하기 시작했고

웹 개발자가 되기위한 로드맵이 개발에 대해서 큰 그림을 그리는 데 큰 도움을 받았다

이때부터 코끼리를 냉장고에 넣는 여정을 시작한다

첫 스터디 프로젝트와 거기에서 얻은것

강의를 들으면서 코드를 따라치는 건 정말 한주 하다 멈춰버리기 십상이었다
이 코드가 왜 이런 식으로 돌아가는지 블랙박스 그 자체인데 그 과정을 반복하는 영상을 보기가 싫었다
그래서 그냥 그 영상들의 목표를 그대로 내 목표로 설정하고 깃 레포를 파서 무작정 박치기(검색)를 시작했다..

→ 지금은 조금 후회된다 질 좋고 잘 정리된 지식 학습 기회를 놓쳤다 그만큼 고생을 더했다..

Babelfish 단어장 CRUD

• 개인진행
• Express + MySQL + JWT
• 2021.01 - 2021.02 [ AWS 프리티어의 인스턴스 제한으로 배포를 종료했다 ]
• Backend Repository
• Frontend Repository

처음 진행한 스터디 프로젝트다
다양한 단어를 자유롭게 저장, 수정, 삭제하고 시험 친 기록을 저장할 수 있게 해보자고 마음먹고 진행했다

프로젝트 문제점

• 로우쿼리를 그대로 사용해서 SQL Injection에 취약하다
• 오류처리 및 응답 책임이 서비스에 있어 반복적인 코드가 많았다
• Data Validation에 대한 책임이 서비스에 있어 반복적인 코드가 많았다
• Promise를 사용했지만 than 구문이 너무 길어져 가독성이 떨어진다
• 문서화가 되지 않아 개발 시간보다 문서정리에 시간이 더 걸렸다
• 카멜케이스, 스네이크 케이스 자기 멋대로 코드를 작성했다
• 트랜잭션, 동시성을 고려하지 않고 데이터베이스에 접근했다

배포방식

• AWS S3에서 레포를 Clone해 PM2로 실행

이후 추가 개선 사항

• 서비스 단에서 처리하는 오류처리를 미들웨어로 에러 핸들링하도록 개선 했다
• 데이터 유효성 검사 모듈을 중앙집중식으로 새로 설계했다
• Docker-compose 사용한 NginX 로드밸런싱후 S3에 재배포했다

진행하며 느낀점, 배운점

• RESTful 한 API를 구성해야 하는 것을 배웠다

최대한 URL에는 자원을 명시하기만 하고, 메서드로 행동을 적용하기 위해 노력했다
하지만 그 안에 관계를 넣어야 한다는 생각 때문에 필요 없는 path 경로가 들어가기도 했다

• 로우쿼리는 가독성을 많이 떨어트린다고 느꼈다

이때는 다른 계층으로 분리할 생각을 하지 못했다
서비스에서 그대로 로우쿼리를 사용하니 가독성이 너무 떨어지고 두 개의 언어가 동시에 존재하는 불편함을 느꼈다

• Endpoint를 문서로 만들고 유지하는 것은 힘들다 생각했다 동시에 문서의 중요성도 느꼈다

Endpoint를 업데이트할 때 추가적으로 문서를 업데이트해야한다는 부담감이 상당했다
하지만 프론트엔드를 작업하면서 잘 정리된 문서의 중요성을 느낄 수 있는 계기가 되었다

• 반복적인 코드를 줄이니 같은 일을 두 번 하지 않아도 되더라

기존엔 에러 처리, 데이터 유효성 검사 코드가 서비스에 있어서
에러 메시지를 수정하려면 프로젝트 폴더를 일일이 모두 뒤져야 된다거나
데이터 유효성 검사의 정규식 구문이 틀렸는데 이것을 사용하는 모든 서비스에 대한 코드를 수정해야 된다거나 하는 상황이 있었다
모듈을 중앙 집중식으로 새로 작성해서 구현하니 이런 일을 두번하지 않아도 되어 좋았다
이때부터 조금식 좋은 구조에 대해서 고민하기 시작했다

Harmony Kakao Oauth 회원가입 및 게시판 [배포중단]

• 개인진행
• AWS API-Gateway + AWS Lambda + Mysql/SequelizeORM
• 2021.03 - 2021.04 [ AWS Lambda 제거 ]
• Backend Repository
• Frontend Repository

사실 이 프로젝트는 학교에서의 권유로 어쩔 수 없이 맡게 된 프로젝트였다

한 달 내에 백엔드, 프론트를 만들어야 했고

팀원도 할 줄 모르는 팀원뿐이라 혼자서 진행했다 ( 흔한 대학교 조별 과제 )

이번 기회에 serverless로 한번 만들어보면서 배우자라는 마인드를 가지고 프로젝트에 임했다.

진행하며 느낀점, 배운점

• 현재의 서버 패러다임에 대해서 조금이나마 알 수 있는 계기가 되었다

상태를 가지지 않는 것이 정확히 무엇인지

상태를 가지지 않음으로 수평 확장 가능한 서버를 만들 수 있다는 것과

그것을 구현하기 위해 스토리지가 있다는 것을 배웠다

• 코드의 가독성, 일관성이 지켜질 때 얻게 되는 장점에 대해 알게 되었다

처음으로 Prettier를 통해 해당 프로젝트에서 일관된 코드 포매팅을 할 수 있다는 사실을 알게 되었고

Promis에서 Async를 대신 사용하면서 코드의 가독성이 확보될 때 로직 자체에 집중할 수 있다는 것이 어떤 것인지 알게 되었다

또한 상수는 대문자 스네이크 케이스로 작성, 변수는 카멜 케이스로 작성, 클래스는 첫 글자가 대문자, 함수는 소문자, 등 코드 컨벤션을 지켜서 작성했을 때 주석이 없어도 다른 사람이 보았을때도 이 객체가 어떤 역할을 하는지 추정할 수 있었다

결과적으로 깔끔하고 가독성 좋은 코드를 작성하자, 진짜 좋은 코드는 주석 없이도 이해할 수 있는 코드라는 말이 무엇인지 와닿게 되었다

• 깃 플로우, 개발 방법론에 대해서 알게 되다

Notion에서 Github로 개발 워크 플로우 전환기 에서 볼 수 있듯 처음 노션으로 개발을 했지만

깃 브랜치 전략과 깃허브 칸반보드를 사용해서 깃허브를 단순 프로젝트 저장소가 아닌

깃허브를 통한 커밋 기록 관리와 협업 방법에 대해서 배울 수 있었다

기초의 부재는 기술 부채를 만들더라

내가 느낀 초보 개발자의 기술 부채에 대해서

기술적으로 해결되어야 할 문제를 미루고 비즈니스 문제를 해결하는 시점을 당기는것

흔히 기술 부채는 위와 같은 상황일 것이다

하지만 내가 처음 개발을 하면서 느낀 기술 부채는

중요한 기술적 문제를 모르는상태로 출발하다 문제를 알고 뒤늦게 후회하는 것 이였다.

공부하면서 프로젝트를 하다 보니 어느새 져 있는 빛 라는 느낌이 강했다

여기서 문제는 뒤돌아서, 아니면 밑의 비정상적인 바퀴 상태를 볼 수 있는 시야를 가지지 못했다는 것이다

몇 가지 경우를 꼽자면

• 게시글 좋아요 버튼의 동시성을 고려하지 않아 이후에 이 사실을 알게 되고 트랜잭션과 동시성을 고려해서 다시 로직을 작성했다
• 오류 발생, 처리에 대한 역할 구분을 확실하게 해주지 않아서 서비스 내에서 서비스를 호출할 경우 이전 서비스 로직의 에러가 먹혀버리거나, http 에러 응답을 컨트롤러가 아닌 서비스에서 발생시켜서 다시 로직을 작성했다
• 오류 처리 시 오류에 대한 메시지와 에러 코드를 서비스 로직에서 발생시켜서 수정이 어렵고 재사용성이 떨어져 재사용 가능한 에러 클래스를 작성했다
• 이 모듈 어디에 만들었더라…(import 부분을 보면서)

이때부터 확실히 내가 기초가 부족하구나 라는것을 느끼고 특정 라이브러리, 특정 프레임워크에 사용하기 전

반드시 사전 공부를 하고 내가 이 기술로 어떤 문제를 해결할 수 있는지 생각하고 적용하는 과정을 거치게 되었다

( 기존에 했던 스터디 프로젝트도 크게 보면 이런 과정이였지만 이 과정을 인지 및 구체화 하고 세부적인 과정에도 적용하는 계기가 되었다)

그리고 기본적으로 MVC를 나누는 것을 시작으로 프로젝트의 구조 자체에 많은 고민을 하게 되었다

수정사항이 생기더라도 수정할 대상을 바로 파악할 수 있고 확장이 자유로운 플랫폼화가 되는것을 목표로 프로젝트를 설계했다

이때무렵부터 코드에 주석을 달고, 코드 뎁스를 줄이고, 적절한 구조를 만드는 것이 재미있었고 또 많이 공부했다

좋은 코드에 대한 고민, 실천

바벨탑이 무너진 이유는 소통 때문인 것이 확실하다

내가 1년간 공부하며 좋은 코드란 무엇인가에 대해서 어떤 식으로 느꼈는지, 어떻게 실현해나갔는지 말해보고자 한다

이전 주제에서 구조에 대한 고민과 깔끔한 코드를 만들기 위한 여러 가지 규칙들을 생각하면서

그대로 소스 코드에 녹여내는 과정을 거쳤다

그렇기에 자연스레 좋은 코드는 깔끔한 코드 컨벤션과 좋은 구조인 것이 아닐까 생각했다

하지만 생각이 조금 부족했다는 것을 조금 지나 깨달았다

그 이후 친구와 함께 지금 내 글이 있는 이 블로그 플랫폼 프로젝트(TILog)를 시작했다

진지한 프로젝트로, 취업 전 마지막 프로젝트이기에 의미가 컸다.

하지만 우리는 프로젝트 첫 스타트부터 막혔다

프로젝트 폴더가 왜 이런식 으로 구성되어 있는지 이후에는 어떻게 해야 하는지 이런 컨벤션 자체가 서로 맞지 않았다

서로 모여서 프로젝트를 어떻게 구성할 건지, 코드 컨벤션은 어떻게 할 건지 2일 내내 이야기했다

그 이후에 마틴 파울러의 아키텍처의 중요성에 대한 영상에서 많은 힌트를 얻게되었다

이 영상에 나오는 수많은 이야기 중에 이런 이야기가 있다

아키텍처의 정의에대해 진짜 중요한 사실은
아키텍쳐는 개발자들의 상식에 크게 영향을 받는다 또한 전문 개발자들은 시스템 디자인에 대한 지식을 공유한다 이는
여러분들이 소프트웨어 프로젝트를 진행하고 지속적으로 커질 경우 프로젝트를 주도하고있는 팀원간에 프로젝트에 대한 이해도가 잘 공유되어야 한다는것이다
...
당신이 소프트웨어 시스템이나 아키텍쳐를 설계할 때 무엇이 중요한지 핵심가치에 대해서 생각을 할 것이다
팀장으로써 소프트웨어 프로젝트를 이끌어 나갈 때나 혼자서 프로젝트를 진행할때도 무엇을 핵심가치로 둘 것인가 정할것이다
코드를 짤때도 무엇이 가장 중요한지 핵심을 생각하면서 소스코드에 녹일것이다 아키텍쳐에서는 이런 핵심가치를 위한 결정들이 매우 중요하다

영어라 이상한 부분이 있지만, 결론은

코드를 짤 때 무엇이 가장 중요한지 핵심을 생각하며 소스 코드에 녹일 것이다

이러한 핵심가치를 정하는 것이 아키텍처에 매우 중요하며 이것은 하나의 상식으로서 팀원 간에 공유되어야 한다

그렇다. 하나의 언어로써 깔끔한 코드, 좋은 구조에 대한 시야를 일치시킬 필요가 있었다

그렇기에 나는 지속적으로 구조, 좋은 코드에 대한 시야를 함께 높이고 공유하기 위해 노력했고 그 예시를 몇 가지 들어보고자 한다

NestJS 도입 [ 내가 지금 하는고민은 누군가 이미 했다 ]

Express도 충분히 좋은 프레임워크다 하지만 우리는 아키텍쳐의 구조에 대한 상식이 부족했고

부족하기에 그것을 코드에 녹여내기엔 한계가 있었다

그렇기에 먼저 공부하는 선배의 조언을 듣고 제일 먼저 프로젝트에 NestJS를 도입했다 결과적으로 옳은 선택이였다

NestJS가 OOP에 입각해서 다양한 레이어의 응집도를 높이고 결합도를 낮춰

빠른 확장이 가능한 하나의 개발 플랫폼을 제공해줬다

우리는 그 안에서 좋은 구조를 위해, 협업을 위해 (DI, Factory, facade..)와 같이

다양한 디자인 패턴들이 필요하다는 것을 느꼈고

OOP, 디자인패턴을 숙지한 상태에서 구현할 경우 훨씬 해당 로직 자체에만 집중할 수 있는 코드가 되는 것을 직접 하면서 느꼈다

→ 아이러니였다 Java의 딱딱함이 싫어 NodeJS를 선택했지만 그 딱딱함을 이해하고 필요성을 느끼게 될 줄이야.. 여기서 또 한번 기초의 중요성에 대해 통감했다

자유롭게 부담없이 개발관련 이야기를 할 수 있게 하자

원래 일상 톡방이지만 서로 자유롭게 일상을 이야기하면서도 좋은 개발 게시글이 있거나 새로 알게 된 지식이 있다면

언제든지 공유하고 그에 대해서 토론 했다 특정 분야에 깊게 들어가는것은 불가능하지만

서로 부족했던 시야각을 더 넓혀주는데 좋은 작용을 했다

깃 플로우, 협업 툴을 적극 사용하자

당연히 해야함에도 불구하고 우리는 함께 협업을 하는 방법에 대해서 무지했고

브랜치 관리 전략과, 티켓 관리에 대해서 서로의 생각을 공유하고 실행했다

배포의 두려움을 이겨내자

이후에 개발에는 많은 시간이 소요되진 않았다 NestJS의 도움으로

의존성 문제에 대해서도 크게 벗어날 수 있었고 빠르게 기능을 확장했다

분명 개발할 때는 문제가 없었는데 배포해보니..

배포를 해야 할 때면 한숨이 나오고 속이 답답해요.. 약이 있나요?

새로운 버전 배포 → SSH 접속 → 서버 다운 → git pull → 서버 시작 → 만약 에러 발생시 다시 처음부터시작(../?)

• 배포를 할 때마다 서버를 닫는다 → 무중단 배포의 필요성
• 서버가 다운되어도 직접 들어가 봐야 알 수 있다 → 헬스체크, 스케일 관리의 필요성
• 배포를 할 때마다 직접 인스턴스에 접속해야 한다 → 하루에 몇번 발생할 지 모르는 시간이 오래 걸리는 반복 작업

대표적으로 저런 문제가 있었고 CircleCI와 AWS ECS를 통해

브랜치 관리 전략과 연계해서 지속적 배포 환경을 만들었고 이로 인해

배포에 대한 두려움이 사라졌다 필요한 기능을 과감하게 추가, 삭제할 수 있게되었고

이후 시간을 더욱더 절약할 수 있게 되었다

SonarQube로 코드 점검하는 시간 가지기

소나큐브란 버그, 코드 스멜, 보안취약점을 자동리뷰해주는 지속적인 코드 품질 검사용 오픈소스 플랫폼이다

오픈소스 프로젝트인경우 에서 무료로 진단을 받을 수 있고

멘토없이 공부하던 우리들이 함께 체크할 수 있는 역량에는 한계가 있었기에

제 3자가 객관적으로 코드를 진단해 준다는 사실에 서로 기뻐했다

거의 모든 코드 스멜은

• 사용하지 않는 가져오기를 제거
• JS DOC에 명시한 TODO 주석

보안 취약점은

• 파일 업로드시 파일명 (현재시간 + 난수) 생성 부분

프로젝트를 함께한 팀원과 지표를 공유했다.

성능 개선하기

배포한 이후에도 지속해서 서비스를 개선했다 내가 한 것은

• 트랜잭션과 동시성 제어에 대해서 공부하고 조회수, 좋아요 카운트 로직을 새로 작성했다

• 커스텀 레포지토리 패턴을 사용해서 서비스 로직과 쿼리빌더를 분리했다

• ErrorException 에러 발생의 책임과, 처리 책임을 명확히 하고 처리 흐름을 구체적으로 도식화했다

• 오래 걸리는 인기게시글 조회쿼리에 레디스 데이터베이스 캐시를 적용했다 (45ms → 4ms)

• 에러 로깅 리퀘스트 버스트를 막기위해 레디스 큐를 도입했다

• 인기 게시글 조회쿼리를 튜닝하고, 인덱스를 적용해서 성능을 개선했다 (테스트데이터 200만건 기준 47초 → 0.0150.285ms 개선)

이후 프로젝트 목표는 다음과 같다.

• 테스트 코드에 관해서 공부하고 적용하기 이후의 개발은 TDD로 진행하기
• 게시글 검색 기능 (엘라스택)
• 소나큐브의 코드스멜 지속적으로 개선하기
• 이미지 업로드 작업 큐로 구현하기

올해의 마지막은 멘토링으로, 앞으로의 방향성에 대해

한 해 동안 그저 캄캄한 동굴에 등불을 들고 있는 모험가처럼 개발을 공부했고 공부를 하면 할수록 더 깊고 넓다는걸 알게되는 해였다

하지만 그에 반해 내가 쓸 수 있는 시간은 한정되었고 무슨 능력치를 찍어야 하는지 모르는 초보 모험가같은 막막함이 있었다

감사하게도 In!t 이라는 주니어 성장에 대해서 피드백을 남겨주는 멘토링 서비스가 있었고

메인에 걸려있는 이미지가 나의 상황과 똑같았고 한 해를 마무리 하는 느낌으로 멘토링을 신청했다

공통적으로 받은 패드백은 다음과 같았다.

- GOOD
- 아직 실무 경험은 없으신 듯 한데도 사이드 프로젝트가 상당한고민을 통해 좋은 선택들을 했다는 느낌이 듭니다

-BAD
- 개발의 기초가 되는 부분에 대한 공부와 이해도를 높이기 위해 노력하는 부분이 보이지 않는것이 아쉽습니다. 자료구조, 알고리즘, 네트워크, 디자인패턴, 아키택쳐와 같이 어느 개발을 하던지 전반적으로 습득이 필요한 내용에 대한 공부도 같이 심도있게 하는것을 추천하고 싶습니다

솔직히 알고있던 부분이였다 프로젝트를 하면서도 내가 마주했던 문제들은 기초가 있었더라면 충분히 해결할 수 있었구나 라고 생각은 했지만 이것을 제 3자의 입장에서 진지하게 해주는 조언으로 들으니까 조금 더 그 중요성에 대해서 생각해볼 수 있는 계기가 되었다

이후 갈피를 못 잡고 있던 상황에서 앞으로 어디에 무게를 둬야할지 조언을 받을 수 있어서 정말 감사했다

물론 어떤 회사에 들어갈진 모르지만 해당 회사에서 비즈니스 가치를 창출하기 위한 개발 지식에 확보에 대한 노력은 계속할 것이다

또한 프로젝트적인 부분만 신경쓰느라 소홀했던 기초적인 CS 지식과 알고리즘에 대해서 조금 더 집중하는 새해를 보내고자 한다

목차가 정말 많지만 결국 좋은코드란 무엇인지 끝없이 고민하고 공부한 나의 이야기다

결국 올해 내가 공부하고 노력한것이 뒤돌아보니 팀원과 함께 좋은코드를 만드는 방법에 대해서 공부를 한듯 하다

다들 화이팅하자!