개발자 정진석 개발자 정진석

spring boot 4.0 이상부터는 spring boot starter web을 추가 하고 test를 추가 하더라도, RestTestTemplate이나 TestWebClient 같은 임베드 REST client를 제공 하지 않는다. 따라서, 아래 의존성을 추가하고, 테스트 모듈에 다음 어노테이팅이 필요 하다. testImplementation("org.springframework.boot:spring-boot-resttestclient") @AutoConfigureRestTestClientannotation class SomeSpringBootTest{}

### 서론k8s에는 node group이 존재 한다. node group은 작업을 수행 할 pod들이 올라 가게 될 컴퓨팅 자원을 관리 하는데, 작업의 성격에 따라 다른 node group을 선택 해야 할 경우가 많다. 예를들어, 나의 경우 현재 운영중인 인프라와 무관하게 새로 컴퓨팅 자원을 빠르게 사용하고 종료 해야 하는 경우 였는데, 기존 자원에 영향을 끼치지 않게 새로운 노드 그룹을 만들었고, label을 추가 해서 운영 하려고 했다. ### 문제내가 돌리던 작업들은 크게 문제가 없었는데, 갑자기 옆팀에서 배치가 돌지 않는다고 했다. 알고보니 해당 작업들은 팀에 맞게 oidc로 token을 부여 받아 별도의 iam이 필요한 작업들이었는데, 내가 만든 노드 그룹에서 돌 작업들은 필요 없어서 iam ..

문제embed한 vector를 open search에 배치로 적재 하고 있었는데, 갑자기 mapper exception 과 함께 적재가 안되고 메시지가 DLQ로 쌓이기 시작.원인open search 의 knn plugin의 메모리 사용량이 한도에 도달해결# GET _plugins/_knn/stats?pretty을 통해서cache_capacity_reached 가 true인 노드가 있는지 확인 # 캐시를 강제로 비우기PUT _cluster/settings{ "persistent": { "knn.memory.circuit_breaker.limit": "1%" }}# 몇 초 뒤 원래대로 복원PUT _cluster/settings{ "persistent": { "knn.memory.circuit_breake..

부제: 나는 왜 도메인 주도 설계를 추종했나 얼마 전 조영호님의 도메인 주도 개발의 오해 강의를 들었다. 그동안 나도 나름대로 DDD에 대한 공부를 해왔다고 생각했다. Entity, Value Object, Aggregate 같은 형식들은 어느 정도 알고 사용도 하고 있었고, DDD에서 전략 패턴—즉 유비쿼터스 언어를 정의하고 팀이 같은 언어로 도메인을 이해하는 것이 훨씬 중요하다는 사실도 알고 있었다. 하지만 내가 갈증을 느끼던 지점은 따로 있었다. "왜 이렇게 좋은 개념이 현실에서는 잘 안 쓰일까?", "나혼자 할 수 있는게 아닌데, 어떻게 시작 해야 되는걸까?" 나는 바로 그 현실 속 DDD가 궁금했다. ---깨달음 1. “DDD는 안해도 된다”강의를 통해 DDD의 형식적인 부분들도 더 알게 되었지..

(제가 TDD를 좋아하는 이유는 이 글을 먼저 읽고 오면 도움 됩니다.)개발자가 코드를 작성하는 행위는 똥을 빚는 행위와 같고, 코드 배포는 빚은 똥을 세상에 내보내는 행위다. 이렇게 마구잡이로 빚어 내보낸 똥은 나중에 더 큰똥이 되어 개발자를 위협하기 시작 하는데, 이 현상은 비지니스 전개에 큰 장애물이 된다고 누구나 알고 있다. 테스트를 작성 하자. 테스트를 쓴다는 것은 세상에 나가는 똥에게 감시장치를 추가 하는 것과 같다. 감시장치는 똥이 우리 시스템에 똥칠을 하지는 않는지 꾸준히 감시한다. “너 똑바로 하고 있어? 빌드 할때마다 내가 확인한다?”“✅이 똥은 아직까지 고객의 요구사항에 부합해요. ” 똥이 변화 하는 고객 요구에 부합하지 못할 때 감시장치는 여지없이 파이프라인을 멈추고 개발자에게 ..

글 작성 시점을 기준으로 최근에 근무 했던 회사에서의 업무 방식을 정리 한다. 스타트업에서 제품 개발팀의 서버 프로그래머인 나에게, 업무의 시작을 알리는 PRD가 도착 했다.PRD(Product Requirements Document)가 도착 했다.PRD는 주로 이런 내용으로 구성 되었다. 대상 고객, 문제 상황, 해결 방안, 사고 실험, FAQ. 대략 우리의 고객이 이러한 문제를 겪고 있는데, 이런 방식으로 해결 해보고자 한다 잘 되었을 경우 이런 사고의 흐름이 예상 된다와 같은 내용이 포함되어 있다.PRD를 리뷰하는 자리에서 개발자의 역할은 PRD의 완성도를 높힐 수 있는 모든 행위를 하겠지만, 특히 개발자가 할 수 있는 부분을 찾아서 기여 하는 것이다. 개발자로서 PRD를 리뷰하는 자리에서 다음과 ..

테스트 주도 개발(TDD) 기법을 활용하여 고객의 요구사항과 상관없는 불필요한 코드 작성을 최소화하고 코드로 만들어내는 가치가 안정적이고 지속적으로 통합되어 고객에게 전달되는 것에 기여합니다TDD를 수련하고 난 뒤 나의 이력서 상단에 꼭 위치시키는 문장이다. TDD에 익숙하지 않은 사람들은 왜 저 문장이 실현 가능한지 의문을 품을 수 있을 것이다. 그래서 이를 설명하고자 한다.고객의 요구사항과 상관없는 불필요한 코드 작성을 최소화한다이 문장을 이해하려면 우선 TDD의 기본 프로세스를 아는 것이 필요하다. TDD의 기본 프로세스는 다음과 같다실패하는 테스트를 "하나" 작성한다.(Red)작성한 모든 테스트를 통과시키기 위한 구현 코드만 작성한다(Green)1과 2를 반복한다.중복 코드가 있다면 리팩터링 한다..

출처 : https://bbs.ruliweb.com/community/board/300143/read/56002668 들어 가며 개발자가 되고 백엔드 개발자가 되고 싶다고 생각 했을 때 막연히 꿈꿨던 로망이 있다. 아내가 프론트엔드 개발자 였으면 좋겠다 라는 것이다. 물론 그 때 이미 현재 아내와 결혼을 이야기 하고 있었기에 “재미는 있겠다.”, “근데 많이 싸울 수도 있겠다.” 정도의 우스개 소리만 하고 이번 생엔 안되리라 생각 하며 머릿속에서 잊혀져 가고 있었다. “나 프론트엔드 개발자 할래” 어느날 대뜸 아내가 저런말을 했다. 사실 이전부터 몇 번 이야기 나눈적은 있기에 놀랍지는 않았지만, 이번엔 무언가 조금 다른다는 생각이 들었다. 현재 아내가 근무 하고 있는 곳은 글로벌 선사로 수출 수입을 전반..