TIL-20210509~14

2021. 05. 14.
  • 패캠 알고리즘 코스가 끝났다. 전공자 따라잡기 코스와는 다르게 실패한 느낌이다. 프로젝트 난이도가 점점 올라가다보니 알고리즘에만 온전히 집중할 수가 없었던 것 같다. 다른 팀원들에게 피해를 안 줄 정도로는 구현이 돼야하는데 그 하한선이 너무 높았던 것 같다.

    그럼에도 핑계없이 냉정하게 생각해보면 살짝 느슨해진 것 같기도하다. 글을 쓰는 시점에도, 코테 광탈급이면서 집중해서 해내지 않았다. 그나마 얻은 소득은 여유로웠을때 트리 순회와 힙을 구현해봤다는 정도와 파이썬에 대한 환상이 사라졌다는 점 정도가 있겠다.

  • 주말은 휴식 + 알고리즘을 푸는데 할애했기에 이번 주는 erd에서 미진하다고 생각되는 부분 보완과 로직 구현에 집중했다. 월요일은 erd 마무리 화요일은 구조를 잡는데 시간을 썼다. 문제는 이게 수요일에 마무리가 됐다는 것이다. 이후부터는 밤을 새가며 나머지 로직을 구현하게됐다.

    삽질 포인트는 DB설계를 하며 자연키를 사용하는 구조를 만들어 사용하려고 했다는 것이다. 하지만 이렇게 만들고나니 CRUD 레포지토리로는 자연스러운 구현이 되지 않았다. 기본적으로 ID는 하나만 인식하도록 되어있다. 그리고 레포지토리의 제네릭 또한 하나의 타입만 사용하도록 되어있다. 즉 프레임워크가 하나의 키를 사용하도록 강제한다. 거기에 또 다른 문제는 ID가 존재하는 엔티티를 저장할 경우 업데이트 쿼리가 실행된다. 따라서 커스텀 쿼리를 지정해줬다. 이렇게 구현할 경우 문제점은, aggregate root를 사용하기 너무 힘들어진다. 쿼리가 줄줄이 이어져야하는데 이러러면 쿼리가 엄청 길어진다. 구조가 복잡하기때문에 3~4뎁스 정도의 객체들이 나왔다. 그러면 쿼리 자동생성 시 콘솔에 찍히는 것 만큼 긴 쿼리를 계속해서 만들어내야 한다. 그렇다고 자동 생성되는 쿼리를 사용하게되면 더 큰 문제가 발생한다. 특히 2개 이상의 자연키를 사용함은 해당 키들을 한 쌍으로 묶어 유니크하게 판단하겠다는 의미가 강하다고 생각되는데 그 것과 별개로 쿼리가 생성된다. 즉 내가 생각했던 것과 전혀 다른 상황들이 발생한다.

    그래서 다시 인공키를 집어넣어 erd를 수정했다. 여러개의 컬럼을 묶어서 유니크하게 유지해야 하기 때문에 제약도 걸어줬다. 문제 자체는 어느정도 해결이 된 것 같으나 이렇게하니 해당 값들을 넣어주는게 부자연스러워졌다. 예를 들면, 몇 번째 이닝인지를 키로 사용하게 된다면 삽입을 하기 위해서 반드시 최신화가 되어야 하기 때문에 자연스럽게 업데이트 된다. 반면 인공키를 사용할 경우 키가 새로 생성되는 것과 별개로 이닝 수가 증가해야 한다. 이 정도는 괜찮아 보일 수 있다. 하지만 하위 테이블에서 몇 번째 이닝의 몇 번째 타석의 몇 번째 투구라고 생각을 하게 될 경우가 문제다. 해당 키들을 identifying 용도로 사용하면 참조할 키가 많아져서 복잡한 구조처럼 보여도 로직 자체는 크게 어렵지 않을 수 있다. 그런데 인공키를 사용할 경우 엔티티를 구현할 때 상위 객체를 계속해서 탐색해야 한다. 1뎁스 차이의 객체를 탐색하는 정도는 그나마 괜찮다. 최상위에서 최하위를 확인하는건 그나마 낫다. 그런데 최하위 객체에서 최상위 객체를 알아야 한다던가 하는 경우는 원래 계획대로 구현할 경우 계속해서 좋지 않은 징후가 보였다.

    이런 이유로 처음 생각보다 객체 구조 및 로직이 훨씬 복잡해졌다. 그러다보니 시간이 점점 촉박해지고 로직은 꼬이고 해결하기 힘든 상황이 계속 반복됐다. 결국 모든 것을 포기하고 더티코딩으로 구현하기 시작했다. 그나마 다행인 점은 설계에 꽤 오랜 시간을 쏟았기에 문제가 발생해도 금방금방 문제를 찾을 수 있었다. 하지만 완벽에 가까운 스파게티가 된 코드를 리팩토링 할 엄두가 나지가 않았다. 심심하면 할 수도 있지만, 방치하게 될 것 같다. 구현의 완성도는 높지만 코드의 품질은 낮은 상황이다. 처음에는 테스트를 충실히 구현해주면 소스가 지저분해도 금방 고칠 수 있을거라 생각했는데, 설계를 한 이후에 테스트 코드를 작성하려고 하니, 엄두가 나지 않았다. 작은 부분이나 큰 부분에서 점진적으로 발전을 시켜나가는게 아니다보니 어마어마한 테스트 결과를 작성해줘야 했다. 시간 내에 절대 해결할 수 없다고 판단하고 모두 포기했다. 프런트는 진도가 쭉쭉 나가있고 나의 API를 기다리고 있는 상황이라 더 이상 지체할수가 없었다.

    하지만 이런 상황에서 느낀 점도 있었는데, 비슷한 로직이지만 똑같지 않아 새롭게 만들어야 하는 경우가 발생했다. 이런 경우 기존의 소스보다 훨씬 깔끔한 구조나 놓치고 있어 비효율적이었던 부분을 개선할만한 아이디어들이 떠올랐다. 그리고 그러다보니 또 다시 기존 설계의 문제점들이 보였다. 오늘 이와 비슷한 부분들을 프런트 분들과 얘기해봤는데 크롱도 비슷한 말씀을 해주셨다고 한다. 기존의 소스가 너무 복잡해서 리팩토링이 되지 않을 경우 아예 모두 지우고 처음부터 다시 시작하면 훨씬 좋은 코드를 작성할 수 있다는 것이다. 예전에 비슷한 유형의 애자일 방법도 본 것 같다. 작성하고 피어리뷰를 받은 뒤 리뷰 반영이 아닌 소스를 모두 지우고 처음부터 다시 작성한다는 것이다.

    완벽한 설계를 먼저 하는 것은 불가능한 일이 아니었나 싶다. 아무리 완벽해보여도 일단 작성이 된 코드는 항상 잠재적으로 에러를 발생시킬 수 있다고 생각된다. 물론 지금 당장은 발생하지 않을 수도 있지만 뭔가 하나라도 새로운 상황이 발생하게 될 경우 제대로 동작하리라는 보장이 없다. 결국 여러 이유도 있지만, 이런 이유로 TDD든 아니든 테스트 코드를 작성해 두는 것이 좋은게 아닌가 하는 생각이 들었다.

    이런 거대한 삽질을 2주동안 해보며 느낀 점은, 지금 까지 해본 것 중에 처음부터 점진적으로 발전시켜나가는 방식이 제일 좋았던 것 같다는 것이다. 절대적으로 좋다는 것이 아니라 설계를 먼저 하는 것 보다는 나와 잘 맞는 것 같다. erd 설계자체는 어떻게 할 수 있겠지만, 객체 지향적으로 작성되는 코드와 차이가 생길 경우가 있는듯 하다. 이런 경우 DB 설계까 먼저 돼있으면 DB에 객체를 억지로 끼워맞추게 되는 경향이 생기게 되는데 이게 마음에 들지 않고 별로 좋아보이지도 않는다. 그리고 관계 모델링보다는 객체지향 모델링이 더 와닿는 부분이 많기 때문에 DB는 천천히 만드는게 어떤가 싶다. 그러려면 테스트 시 Mockup

    점진적으로 발전시켜나가야 하기 때문에 테스트코드도 필요하다. 대신 하나의 개발 사이클동안 클린코드나 리팩토링은 고려하지 않는다. 눈에 명확히 보이는거야 그 자리에서 고칠 수 있다. 하지만 그 외에 앞으로 다가올 다른 코드를 위한 구조 설계는 나의 예상과 달라질 가능성이 높다. 사실 내 생각보다 더 낮을 수 있다. 훨씬 낮을 수도 있다. 그렇다 해도 한 번씩 나오는 그런 상황들은 너무 힘들고 멘탈적으로도 좋지 않다. 이번에 지저분하게 짜보니 일단 기능 구현이 되면 좋다. 무엇 보다 기분이 좋다. 그리고 기능 구현이 되면 거기에 대해 테스트 코드를 짜는 것도 가능해진다. 굳이 TDD가 아니라도 할 수 있다. 문제는 찝찝함인데, 잘 견디고 리팩토링하는 식으로 빠르게 반복해나가면서 프로덕션 코드도 계속해서 배포할 수 있는 상황을 만들어주는게 좋지 않을까 싶다. 인프라 구성 이외에 다음 주 목표다.

  • OAuth 구현에 성공했다. 아직 JWT 토큰 인증을 제대로 해보지 않아서 토큰 교환을 하는건 더 공부가 필요하겠지만, OAuth 과정 자체는 이해가 된 것 같다. 깃헙 가이드를 보고 하니 크게 어렵지 않았다. 이 정도면 그냥 라이브러리 하나 만들어줘도 괜찮지 않나 싶다.
  • 헤로쿠 자동 배포에 덕을 많이 본 것 같다. 이번이나 다음 번은 혼자하니 크게 문제가 없는데 여러명이 협업할 경우 어떤 것을 기준으로 헤로쿠에 반영시킬지도 문제가 될 수 있을 것 같다. 그리고 그런 경우라면 그냥 aws에 바로 올리는 것도 방법이 아닌가 싶다.

    하지만 헤로쿠는 내가 관리를 안 해도 크게 문제가 없이 잘 돌아간다는 장점이 있으니 테스트 서버나 목업서버, api 문서 서버 정도로 활용하는 것은 괜찮을 것 같다. 단점은 어쨌든 관리포인트가 늘어날 수 있다는 점이다. 예전에 생각해봤던 스웨거의 문제점 중 하나인 try-out을 실제 배포 된 서버에서 하지 않도록 할 수 있다. 다음 주에는 프로필을 잘 활용해서 헤로쿠에 올리는 용도의 소스만 따로 준비해보는 것도 괜찮을 것 같다. 혼자 대충 생각해보면 가장 감이 오지 않는 부분이 스웨거 의존성을 목업 서버에서만 관리하면 좋을 것 같다는 부분인데, 이것도 자연스럽게 할 수 있는 방법이 있을지 찾아봐야곘다.

정대화
DaeHwa_Jeong@outlook.com

Powered with by Gatsby 2.0