올바른코드에서의 마지막 프로젝트가 마무리 되었다.

마지막인지라 최대한 깔끔한 코드와 다른사람이 인수인계를 받아도 어려움을 겪지 않을 코드를 작성하기 위해 노력했지만 아쉬움이 많이 남는다.

많이도 힘들게 했지만 개발자로써의 삶을 시작할 수 있게 해준 올바른코드.

낯선 타지에서 살아남을 수 있는 기회를 준 올바른코드.

항상 감사한 마음 잊지 않겠습니다!

올바른코드 마지막 회고 지금 바로 시작합니다!

이슈Permalink

1. ORM CachePermalink

이번 프로젝트는 기존 프로젝트와 다르게 Sequelize에서 MikroORM으로 ORM을 바꿔서 작업을 진행했다.

그것에 관한 건 밑에서 마저 이야기하도록 하고.

MikroORM은 자잘한 기능들을 제공해 더 나은 퍼포먼스를 제공하려고 노력한다.

아님 말구...ㅎ

그런데 ORM 사용 중 특정 상황에서 데이터를 삭제해도 삭제가 안되는 게 아닌가? ㅋㅋ

그 상황이란 ManyToMany(N:M) 관계에서 발생했는데.

결과적으로는 MikroORM 내부적으로 쿼리의 결과를 Caching 해놨다가 일정 시간이 지나면 cache를 비우게 되는데

ManyToMany(N:M) 관계에서는 뭐가 문제인지 Cache를 지워주지 못하는 이유였었다.

어쩔 수 없이 그 부분을 실행할 때는 인위적으로 cache를 비우는 method를 호출해서 처리해야 했다.

Sequelize와 달리 비교적 최근에 기획된 프로젝트이기도 하고 한참 성장하는 단계의 ORM이다보니 자잘한 error를 겪었다고 생각하는데.

Repository에 가도 해당 이슈도 없고 관련된 언급도 없던 걸로 보아 이렇게까지 사용한 사람이 없는 걸까 생각도 들었다.

좋은 기획을 하고 개발된 라이브러리라도 그 자체의 숙성시간이 필요하다는 말이 다시금 생각나는 순간이었다.

2. Socket.ioPermalink

Nest.js에서는 Wrapping된 Socket.io를 제공한다.

Nest에서 Singleton으로 잘 사용하라고 편의상 제공해준다고 생각한다.

Socket 작업이야 심심하지 않게 작업을 해봤으니 프로젝트를 진행했는데 이상하게 Test용 html과 local server가 socket 연결이 안 되는 거 아닌가

일단 난 잘했다구

경험해본 적 없는 cors error가 지속해서 발생했는데, 당황하지 않을 수가 없었다. 그런데 이유를 알고 나니 굉장히 허무한 문제였다.

Nest의 버전이 올라가게 되면서 socekt.io의 버전이 2.x에서 3.x로 올라가 cor 관련된 설정을 개발자에게 넘겨서 생기는 문제였다.

당연히 Nest와 관련된 자료들에서는 찾지 못했고 socket.io에 관한 문서에서 가까스로 찾아냈다.

Wrapping을 통해서 사용하기 편하게 제공해준 건 좋지만 알맹이(socket.io) 자체가 바뀌어버리니 바로 문제점을 찾기가 어려웠다는 게 아주 아쉬웠다.

물론 socket.io 라이브러리는 dependency로 부가적으로 다운로드 되지만…

해결책은 그냥 socket.io의 버전을 낮췄다.

이유는 작업을 할 때는 이미 퇴사가 확정된 상태였고, 새로 들어오는 신입 포지션의 개발자가 작업하기에 이미 2.x 버전의 socket.io로 사용된 소스를 재활용하는 게 회사에서 적용하는데 더 좋을 거라고 판단했기 때문이다.

이유가 꼭 대단해야 할 이유는 없다!

난관Permalink

1. RAND()Permalink

App의 메인 화면에서 광고를 무작위로 뽑아서 추출해줘야 하는 상황이 있었는데.

ORM도 내장된 Query Builder도 RAND() 함수를 지원하는 게 없었다.

결국은 메인 광고 리스트를 가져와서 service layer에서 가공해서 처리했다.

사실 이전까지만 해도 DB에서 할 수 있는 건 최대한 DB에서 하는 게 좋다고 생각했지만 나는 DBA가 아니라 Back-end 개발자라고 생각하니 service layer에서 작업하는 것도 좋겠다는 생각이 들었다.

관점의 차이지만 조금이라도 더 다양한 생각을 할 수 있게 된 것 같다.

개선Permalink

1. DTO와 DomainPermalink

작업을 하다 보니 데이터의 가공을 DB에서부터 해버리면 Query가 presentation layer에 종속되어 layer 간에 결합도 가 높아지고 재사용성이 떨어진다고 생각이 들었다.

business layer에서 mapper를 통해서 가공 후 presentation layer로 넘기는 것도 마찬가지였다.

UI에 종속적인 business layer를 만드는 건 layer를 구분한 의미가 없어진다고 판단이 되었고.

필드만 같다면 얼마든지 가공해서 presentation layer에서 가공해 사용할 수 있을 거 같아. presentation layer인 controller에서 mapper method를 호출해서 response하니 service의 method 재활용성이 많이 올라간 걸 느꼈다.

business layer => presentation layer를 이렇게 처리하고

반대의 경우인 presentation layer => business layer도 새로운 방법으로 처리했다.

5252... 어디까지 갈 셈이야...?

평소에는 validation된 dto를 바로 service로 넘겨서 사용을 해왔는데 마찬가지로 service의 method가 UI에 종속적으로 변한다는 느낌을 많이 받았다.

그래서 controller에서 dto를 도메인으로 바꿔서 serivce로 넘겨 사용했다.

다행히 Nest의 dependancy library중에 object => domain으로 바꿔주는 method가 있어서 business layer에서는 최대한 domain으로만 작업할 수 있게 처리했다.

domain으로 business logic을 처리하니 객체 자체가 validation을 가지고 있는 게 더 났겠다는 생각이 들어 entity에 validation method를 작성해 필요에 따라 호출해서 사용하니 좋았다.

군데군데 코드 간의 decouping 관계를 유지하려고 노력하니 method 자체의 재활용성이 높아지고 코드가 전체적으로 유연해진다는 느낌을 받았다.

2. 개발순서Permalink

기존에 개발을 할 때는 DB Modeling을 끝내고 API 작업을 진행했다.

위에서 말했다시피 나는 DBA가 아니고 Back-end 개발자니까 DB보단 business layer에 집중된 개발을 해야겠다고 생각했고,

그때그때 요구사항이 바뀜에 따라 DB Schema가 계속해서 바뀌기에 API 명세를 만들고 나서 API를 만들면서 필요에 따라서 DB를 만들어 갔다.

어차피 ORM을 사용해서 개발하기 때문에 schema의 변경이 부담스럽지는 않았다.

물론 처음에는 굉장히 어색하고 이게 맞는 건지 싶었지만. 이전까지는 DB를 위한 값들을 가공하기에 바빴다면 이제는 더 자유롭게 business layer를 구성할 수 있다는 느낌을 받았다.

ERD를 마지막에 한 번만 쓱 그려주면 된다는 편의성도 덤이다.

결론Permalink

결과적으로는 깔끔하고 아름답게 퇴사에 성공한 것 같다. 비록 맞후임을 만나서 인수인계를 하지는 못했지만,

한 달 하고도 보름 전에 퇴사 의사를 전달했기 때문에 내가 어떻게 할 수 있는 부분은 아니었다.

나보고 뭘 더 어쩌라고

이제 1년 딱 본 동료들이랑 헤어진다고 생각하니 많이 아쉽다. 같이 고생한걸 아니까 내적친밀감이 올라간거 같기도하고 ㅋㅋ~!

나중에 더 좋은곳에서 더 좋은 모습으로 만날 수 있었으면 좋겠다.

일정기간마다 회고록을 작성할 수 있었던 이유는 Si업무를 하면서 프로젝트 기간이 있었기 때문이었는데.

포스팅은 계속할 것 같지만 지금까지와 같이 프로젝트 단위의 회고는 어렵지 않을까 싶다.

분기별 회고나, 이직할 회사에서의 mission 단위로 하게 되지 않을까….

나도 몰라요

사실 갑작스러운 퇴사가 어디 있겠는가 ㅋㅋㅋ 100% 만족스러운 회사는 없어서 아쉬운 점은 아쉬운 대로 다니는 거지만, 아쉬운 점이 해결된 더 나은 조건이 왔을 때 마다할 이유도 없지 않은가?

자세한 이야기는 꽉찬 1년차 주니어개발자의 SI 탈출기에서 마저 이야기 하도록 하고.

올바른 코드에서의 마지막 프로젝트 회고를 마무리한다.

커튼콜입니다! 올바른코드 동료 여러분 그동안 고생하셨습니다.