발생 상황 ``` ☁ _Lecture_k8s_starter.kit [main] ⚡ kubectl get services NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE chk-hn LoadBalancer 10.96.253.167 192.168.1.11 80:30941/TCP 12m ``` 쿠버네티스 실습 중에 LoadBalancer service를 만들고 클러스터 내부와 외부에서 External IP로 각각 접근을 실행하였습니다. 클러스터 내부에서는 문제없이 접근할 수 있었으나, 클러스터 외부에서는 timeout이 발생하였습니다. 외부에서 ping을 날려봤지만, timeout이 됩니다. curl 192.168.247.5:30623 // 응답없음... 발생 원인 추측했던 원..

들어가며최근 제가 다른 실수(타입 추정이 잘 안되는 문제)를 계기로 제네릭에 대해 다시 공부할 일이 생겼습니다.그러며 새로이 깨달은 것이 `공변성(covariance)` 과 반공변성(Contravariance)`에 대해 제대로 이해하고 있지 않기도 하고.매번 헷갈린다는 생각이 들어서 이번 기회로 조금 정리해보려고 합니다. 이미 Java로 코드를 구현할 때, 이 개념을 자연스럽게 사용하고 있었는데요.새삼 개념과 객체지향 리스코프 치환 원칙 LSP까지 짚어보니 좀 복잡했지만 왜 이렇게 사용해야했는지 이해할 수 있어서 유의미했던 공부였습니다. 공변성과 반공변성먼저 변성(variance)은 타입 시스템에서 서로 다른 타입 간의 관계를 설명하는 개념입니다. 다시말해 상속관계에 있는 A, B 타입이 있을 때, 이를..

발생 상황 spring boot gradle test kotest, spoke 테스트 SpringBoot 프로젝트의 테스트를 로컬에서 실행했을 때 모든 단위 테스트와 API 테스트가 통과했으나, Github workflow 실행시 갑자기 단위 테스트 중 몇 개가 깨져버렸습니다. 로컬과 origin 코드가 동일한 상황에서 로컬에서는 계속 잘 통과하는 데 무엇이 문제일까 헤매었습니다. 근데 예외코드가 약간 이상합니다. 분명 실패한 테스트는 수정 로직인데, 예외 스택에 삭제 테스트가 함께 포함되어 있습니다. // 예외 로그 중 시그니처가 살짝 수정되어있습니다 com.backend.domain.test.Modify > 수정 > 작성자가 수정할 경우 성공한다 FAILED java.lang.AssertionErro..

발생 상황 `EmbeddedRedis` 가 적용된 테스트를 실행시키려고 할 때, 다음의 에러 로그가 뜬 후 프로세스가 죽는 현상이 있었습니다. `Can't start redis server. Check logs for details. Redis process log:` 그러나 process 가 이미 죽어버려서 로그를 볼 수도 없는 상황. 해당 문제에 대해 사수님께 질문하여 'OS 문제인 것 같다' 는 결론을 얻었습니다. 발생 원인 얼마 전에 MacOS를 Sonoma 14.x로 업데이트 했는데, 그로 인해 OS security policy가 변경되며 `EmbeddedRedis` 실행에 실패했던 것입니다. [👉 related issue] Most likely security policies forbid th..

들어가며 2024년이 시작한지도 벌써 두 달이나 지났습니다. 진짜 뭐했다고 이렇게 시간이 빨리 흘러가는 지 참..! 정말 오랜만에 쓰는 회고입니다. 하루하루가 휘몰아치고 있는데, 넋놓고 휩쓸리다가 이렇게 흘려보내기 너무 아쉽다는 생각이 들더라고요. 지금의 고민들을 적어두고 싶기도 하고 작은 소득도 박제하고 싶어요ㅎㅎㅎ 그래서 짧게나마 두 달을 정리하고 가고자 합니다. 아래 그림은 티타임에서 정리한 월간 회고 👇사실 이 글에서는 더 잡다한 얘기가 있을 수 있습니다.....  신입개발자의 성공적인 랜딩을 위하여 올해 1월부터 저는 신입 개발자로서의 일상을 시작했습니다. 아침에 일어나 출근을 하고, 직장에 갔다가 퇴근을 하는 이 루틴이 너무 오랜만이어서 많이 긴장되더라고요. 그래서 첫 한달은 일을 하고오면 ..

들어가며 이 글은 최근 테스트 작성을 많이 하기 시작하며 염두하기 시작했던 부분들을 잊지 않기 위해 작성해보았습니다. 사실 작년까지는 테스트 코드 작성을 정말 최소한으로만 해왔었는데요. 짜고나서 동작을 확인할 때, 테스트하고 싶은 것만 테스트하고 (정말 로직만 확인하는 테스트) 그나마도 구현이 계속되어 테스트를 고쳐야할 때면 가끔 코드를 들어내기도 했습니다. TDD나 테스트가 좋다고는 하지만 오히려 구현에 발목을 잡히는 것이 아닌가 하는 생각도 들었고요. 최근 테스트를 열심히 짜보며 이런 생각을 고치게 되었습니다. "그동안 내가 테스트가 유효할 만큼의 테스트를 짜보지 않아서 잘모르고 있었다, 변경에 취약한 테스트를 짜고 있었다"는 생각이 들어 중간 소결차 글을 써봐야겠다는 생각이 들었습니다. 특히 회사에..