Docker for mac 이슈
출석체크를 하고 ZEP에 접속했더니 맥북이 멈췄다. 강제로 재부팅을 하니 도커 에러가 발생했고, 도커를 실행하지 않아도 주기적으로 계속 에러가 발생하는 현상이 나타났다. 도커를 재설치하게 되면 이미지들을 다시 설정해야 해서 생각만 해도 아찔했다. docker-compose 파일 관리의 중요성을 느끼며 해결 방법을 검색하기 시작했다.
운이 좋게도 같은 증상을 겪는 다른 사람이 docker for mac 레포지토리에 이슈를 등록한 것을 발견할 수 있었다.
실시간으로 몇 분 전 표시와 함께 의견들이 오고 갔으며, 이를 참고하여 시도해 보던 중 마침 새로 달린 의견을 통해 문제를 해결할 수 있었다.
내가 매일 쓰는 GitHub의 Issue가 오픈소스에서는 이렇게 적극적이고 자유로운 참여도 이루어지는 것이 신기한 경험이었다.
튜터님 피드백
추상화하는 방향성이 옳은지?
질문
알림 이벤트 서비스와 알림 템플릿 서비스에서 추상화를 통해 결합도를 낮추는 작업을 많이 반영했습니다. 그러나 코드가 아닌 문서에 기반하기 때문에 일말의 불안함도 있었고, 필요한 값이 잘 들어왔는지 같은 예외 처리를 어디서 해야할지 햇갈립니다. 흐름의 마지막인 실제로 사용하는 곳에서 해야 하는지, 재시도 요청도 그곳에서 해야 하는지에 대한 의문이 들었습니다. 예를 들어, 카프카 리스너에서는 토픽마다 데이터가 다르기 때문에 DTO가 아닌 Map으로 받고 일괄적으로 처리하는 로직이 있습니다.
대답
리스너에서는 데이터가 들어왔는지 여부를 확인할 필요가 있다. 전처리 서비스에서 검증이 필요할 것으로 보인다. 각 서비스별로 부여된 책임에 맞는 검증을 진행해야 한다. 추가로 재시도 로직이나 관련 로직도 동일하게 적용된다. 리트라이 로직은 비즈니스 로직으로 간주되며, 메시지 수신 확인은 데이터의 유실이 없는지 확인하는 역할을 한다.
설계 참고 할만한 기술
질문
상황에 맞추어 반영하다 보니 추상화하는 방향으로 진행됐는데, 지식이 부족해 어떤 것을 조사해야 참고할 수 있을지 몰라 어려움이 있었습니다. 비슷한 기술적 개념이 있을까요?
대답
팩토리 패턴과 중간다리 어댑터 패턴, 포트 어댑터 패턴과 유사한 것 같다. 참고해보면 좋을 것 같다.
잘못된 설계인가?
질문
튜터님과 팀원들에게 설명하고 작업 사항을 공유할 때 어려움을 느끼면서, 방향을 잘못 잡고 있나 고민이 들었습니다. 설계가 직관적이거나 심플하지 못하기 때문이라고 생각하는데, 잘못된 설계 방향이었을까요?
대답
주관적인 기준으로는 이상한 방향으로 가지 않는 것으로 보인다. 담당하는 도메인 자체가 외부 클라이언트에 의존하고 있기 때문이다. 자칫하면 코드가 지저분해지기 쉽다. 데이터가 다르기 때문에 정리를 하지 않으면 유지보수나 완성도를 고려할 때 그런 설계가 필요하다. 직관적으로 갈 수도 있지만, 코드의 유지보수성과 완성도를 생각하면 이러한 설계도 필요한 것 같다.
어떤 개발 프로젝트에 참여하게 되더라도 힘을 조절할 필요는 없다. 이것은 나의 스타일이 되는 부분이다. 리팩토링하는 경험이 매우 중요하며, 왜 이러한 설계가 나왔는지 문서가 잘 되어 있다면 괜찮을 것 같다.