[RubyOnRails] RoR로 기업과제 회고

간만에 서류합격! 그런데 기업과제가?

요즘 서류 합격 소식이 뜸해서 별 기대 없이 살고 있었는데, 갑자기 연락이 와서 짧게 인터뷰까지 보게 되었다.

채용 과정에 과제 전형이 있어서 진행하게 되었는데, 루비온레일즈를 쓰는 회사여서 난생 처음으로 rails를 써보게 되었다.

사실 이전 글에서도 썼듯이, 당분간은 새로운 언어를 배울 생각이 없었지만,

평소에 관심있는 기업이었고 인터뷰 분위기가 너무 좋았어서 제대로 도전해보기로 마음먹었다.

한국어로 된 자료는 거의 없어서 영어로 된 자료들을 찾았는데, 하면서 영어가 익숙해지게 된 1+1 효과가 있었다.

처음엔 일단 공식 문서로 달려가서 튜토리얼을 따라하고, 가이드를 거의 다 읽었다.

가이드가 너무너무 친절하게 설명해줘서 솔직히 레일즈 뿐만 아니라 백엔드 전반에 대한 지식을 강화할 수 있었다.

다른 귀여운 문서도 찾았는데 가이드가 너무 잘 돼있어서 나중에 읽어야지 하고 북마크만 해뒀다.

요구사항 분석 및 과제 전 생각들

과제를 시작하기 전에 이런 생각들을 했다.
요구사항을 면밀히 분석하고, 기획하고, 거기에 조금 더 완성도를 더하고 싶었다.

생각만큼 잘 되진 않았지만, 그래도 목표로 했던 것 중에 반 이상은 성공해서 기뻤다.

데이터베이스 설계

DB modeling을 하면서 테이블 설계 과정을 노션에 꼼꼼하게 기록했다.
위키가 있었다면 거기에 적었을텐데, private이라 유료계정이 아니면 wiki를 팔 수 없는 것 같다.

데이터베이스를 설계하는 것은 언제나 많은 시간이 드는 것 같다.
비록 지금은 몇 없는 기능이지만 앞으로 어떤 기능이 확장될지를 고려하면서 설계하는 것이 재미있다.

wireframe

피그마로 간략하게 wireframe을 만들었는데, 만들면서 과연 내가 프론트까지 이렇게 예쁘게(?) 만들 수 있을지 걱정이 조금 됐다.
왜냐면 루비도 레일즈도 처음인데, 프론트까지 예쁘게 만들 시간이 있을지 그림이 그려지지 않았다.
결국 마지막에는 시간이 없어서 기획했던 3페이지 분량을 한 페이지에 다 때려박아서 제출하게 되어 아쉬움이 남는다.

환경설정은 언제나 어려워

레일즈가 기본적인 뼈대가 이미 있어서 (production/test/development를 나눠놓은 거라던가 MVC 패턴으로 디렉토리가 만들어져있는 것, TDD 환경이 갖춰진 것 등) 다른 것들보다는 크게 삽질하지는 않았지만, 아무래도 처음이다보니 조금의 삽질은 있었다. 나 혼자 쓰는 거지만 개발자는 결국 협업을 하게 될테니까, 린트를 설정하고, pre-commit을 설정하고, CI에서 test와 lint checking까지 설정했다. 그 과정에서 시간이 안맞아서 조금 헤매는 일이 있었지만, 덕분에 알게 된 것도 많았다.

TDD? TDL(Test Driven Learning)!

그동안은 수도코드를 먼저 짜고, 기능을 만들고, 테스트를 붙이는 순서로 작업을 했었다.
하지만 TDD에 익숙해지고 싶어서 이번 과제의 경우 테스트를 짜면서 학습을 했는데,

그게 학습 시간을 줄여주는 효과가 있었던 것 같다.
테스트를 통해 빠른 피드백을 받으면서 문제점을 찾아 금방금방 수정해나갈 수 있어서

오히려 시간이 절약되지 않았나 하는 생각이 든다.
비록 API 몇 개 뿐이지만, 100개가 넘는 테스트 코드를 짜면서 커버리지 100퍼센트를 유지했고,
이게 다시 동기부여로 이어져서 더 열심히 하게 되는 선순환을 가져다 준 것 같다.

 

처음에 가볍게 시작한 테스트가 fixture를 만들고, factory를 추가하고,
반복되는 코드와 목데이터를 개선하고, 이런 과정을 통해서 코드의 안정성이 올라갔다.
그래서 마지막에 프론트 코드를 급하게 만들어 합칠 때 자잘한 수정 외에 큰 무리 없이 빠르게 마무리할 수 있었다.
코드가 점점 발전하는 모습을 보며 나도 같이 성장하는 것을 느꼈고, 자신감이 생겼다.
비록 아쉬운 점들이 남아있지만.. 이렇게 환경설정부터 테스트, 배포까지 해내고 나니까 꽤 뿌듯했다.

TDD의 맹점?

종종 느끼는 거지만, 테스트코드가 돌아간다고 해서 그 코드가 신뢰할 수 있는 코드라는 보장은 어려운 것 같다.
코드 커버리지가 100퍼센트이지만 정작 엣지 케이스를 커버하지 못해서 상상도 못한 에러가 난다거나 하는 경우가 있어서
테스트는 조금 더 잘 짜는 방법을 연구해보고 싶게 되었다.

아쉬운 점들

아쉬운 점들이 굉장히 많은데.. 간략하게 적자면 아래와 같다.

• 프론트 작업할 시간이 부족해서 한 3페이지 분량을 페이지에 거의 다 때려박았다. 디자인도.. 눈물
  • 프론트 작업할 시간을 확보하기 위해 css 작업을 최소화하고 mui라이브러리를 갖다 썼다.
  • 템플릿 언어는 내가 오히려 익숙지 않아서 그냥 늘 하던 리액트를 이용했다.
• aws를 쓰고 싶었는데 heroku가 더 경제적이고 더 빨리 배포할 수 있을 것 같아 그렇게 했다.
  • 만약 aws를 썼다면 DB를 RDS로 띄워야 하는데 얘가 좀 비싸다.
  • EC2에 다같이 띄우면 Docker를 써야하는데 그러기엔 시간이 조금 촉박했다.
• 동시에 예약하는 것을 방지하기 위해 locking을 걸고 싶었는데 시간이 부족했다.
  • optimistic locking과 pessimistic locking을 알게 되어 적용해보고 싶었는데 아쉽다.
    • 이에 대한 테스트는 어떻게 해야 할지 잘 모르겠다.
• 복잡도가 높은 테스트에 대해서는 경험이 조금 더 필요하다고 느꼈다.
  • 간단한 테스트는 쉽고 재미있는데, 복잡도가 높아지면 아직 뚝딱 안되니까 답답함을 느꼈다. 그리고 이렇게 하는 게 맞는지 확신도 없다.
• 엣지 케이스에 대한 테스트가 부족 (근데 커버리지는 100퍼센트가 나와서 신기하다)
• helper에 있어야할 것 같은 함수들이 모델에 있음
  • 이건 테스트 용이성을 위해 임시적으로 이렇게 했는데 나중에 따로 옮기고 unit test로 바꿀 필요성이 느껴진다.
• 에러를 커스텀해서 세분화해서 내려주고 싶었는데, 나중에로 미루다보니 결국 못하게 된 게 너무 아쉽다.
  • 에러를 세밀하게 내려주지 않으면 디버깅할 때 엄청 고생한다.
  • 너무 세밀하면 보안에 문제가 될 순 있겠지만 디버깅이 가능할 정도로는 세밀해야한다고 생각한다.
• 비밀번호 암호화를 빠뜨렸다.
  • 이건 필수가 아니라 추가 기능이긴 했지만 나중에 넣어야지 하고 빼먹은 게 아쉽다ㅎㅎ

 

...이 외에도 할 말이 많지만 또 해야할 일들이 남았기 때문에 오늘은 이정도로만 적고 마무리하도록 하겠다.

 

비록 일주일이었지만, 하면서 굉장히 많이 배웠고 자신감이 생겼다.

결과가 어떻게 될지는 모르겠지만 나한테 많이 뜻깊은 시간이 되었다.

이런 재미있는 과제를 준 그 기업에게도 감사한 마음을 가지고 있다.