[아이디어] 복잡한 로직은 GraalVM JavaScript엔진을..
전기요금을 계산하는 프로그램을 개발해야 했다. 전기요금 계산이 이거 이래도 되나 할정도로 복잡하고, 지역, 계절, 년도등의 변수가 많고, 계산 또한 변수가 너무 많았다.이런경우 이런 계산 로직을 코드로 작성을 하는것보다, 변수에 빠르게 적응을 하기 위해서,다이나믹한 기법을 사용하는게 더 좋을것 같다는 생각을 했다.rule엔진을 사용하는게 좋아보이지만 (drools등), 단순 계산을 위해 rule엔진을 사용하는건 오버엔지니어링이라고 판단을 했다.그리고, rule엔진이 사실, 사용하는게 상당히 번잡하고 복잡하다...먼가 간단하면서, 다이나믹하게 계산식을 적용하고, 반영되게 하는 방법을 원했다. 고민중에 예전에 mocksal이라고 개인 mocking 서비스를 만들때 (https://tech.super100.a..
[개발생각] 캐시 스탬피드
캐시 스탬피드를 실무에서 겪었던때는 다음 티스토리팀에 다닐때, 처음으로 겪어봤다. 그때는 이게 왜이러지 하고 그냥 넘겼었는데...지금 생각하니 참 무지했다. ㅠ 캐시를 사용할때, 캐시가 있으면, 캐시된값을 전달하고, 캐시가 없으면, 디비등에서 조회하여 캐시를 만들고, 해당값을 전달하는 방식으로 코딩을 자주 한다. 여기서 중요한점은, 동시성이 중요한 시스템에서는 (대량 트래픽 서비스), 캐시가 없는 시점에 디비를 조회하는 행위를 여러 요청이 동시에 할수가 있다는 점이다. 캐시가 없는 시점에 캐시를 만드는 경우, 락을 걸지않는 이상, 캐시를 만드는 행위를 동시에 여러 요청들이 수행하게 된다. 여기서 중복 조회 이슈가 발생하게 된다. 엄밀히 보면, 하나의 요청만 디비를 조회하고, 캐시를 만들면 되는 건데,..
[개발생각] 내가 생각하는 개발자란?
초등학교 2학년 겨울쯤에 컴퓨터 프로그래머가 되기로 마음먹었고, 그 마음이 현재까지 한번도 변하지 않았었다.. 내가 가장 잘할수있다고 생각되는 부분이 컴퓨터 프로그래머, 개발자라고 생각했고, 그 생각은 아직도 변하지 않았다.현재도 딱히 다른걸 잘할수있다고도 생각이 들지 않는다.(사진,기타,게임 뭐 깔짝깔짝하긴했는데... 흥미나 실력이 잘 늘지를 않더라 ㅋㅋ) 하지만, 개발에 대해서의 마음가짐은 누구보다도 진심이라고 생각한다. 내가 만드는 서비스에 대해서,한번도 대충 만든다거나, 이정도면 됐다라고 생각하지 않았다.계속 발전시키고, 수정하기 위해서 고민했던것은 분명하다. 예전에 면접을 본곳에서 면접자가 이런이야기를 한적이 있다."엄청 예전일인데, 그당시 개발한 내용을 상당히 디테일하게 설명을 하시는군요, 준..
[아이디어] 대기열 기능 만들기에 대해서
사용자가 갑자기 몰리는 기능, 특히 해당 기능이 무거운 경우 (외부 API연결, 스크래핑, 무거운 쿼리) 사용자의 기능 접근을 의도적으로 일정수준으로 제한을 해야하는 경우가 발생한다. 이런경우, 대기열 기능으로 해당 문제는 해결할수있다. 대기열이란, RateLimiter를 구현하는것이라고 보면 될듯하다.세마포어를 이용해서, 내가 기능에 접근할 최대 횟수를 정하고, 항상 그 횟수안에서 기능의 접근을 허용하고 거부하도록 만드는 구현이다.(가게에 화장실이 x개있고, 사람들이 줄을 서서 화장실에 접근하는 개념 ㅋ) 가장 일반적인 방법은 Redis의 Zset을 활용하는 방법이 있다.이 부분은 AI에이전트들에 물어보면 상세하게 알려줄것이라, 구현의 어려움은 없겠지만, 우리는 어떻게 운용을 해야하는가를 고민해야한다...
[개발생각] 게시판 JPA로 구현할때, 정해야 할것들
예전에 신입 개발자 뽑을때, 게시판 만들기 코딩 과제 많았다고 하던데, 왜인지 알겠다 ㅋㅋ.. 간만에 게시판을 만들어봤는데, 정말 어렵다. 구현이? 아니.. 대량의 호출에도 느려지거나 허무하게 죽지않을 정도로 성능이 나도록 만드는게 정말 어렵다. 어렵다기 보다, 고민 포인트가 정말 많았다. 우선 고민 포인트 몇가지가 있었다. 1) JPA의 관계설정을 사용해야할까? 게시판은 게시판, 포스트, 포스트의 댓글, 그리고 댓글의 댓글등, OneToMany, ManyToOne 의 관계설정이 많이 들어간다. 관계설정을 통해, cascade설정을 하여, 데이터의 저장/삭제등의 동기화를 일관적으로 맞추고, 관계설정에 따라, 알아서 댓글 또는 대댓글등을 불러올수있기에, 상단한 매력으로 다가온다.. 하지만, 편한만큼, 조..
[개발생각] StructuredTaskScope에 대해서
와.. 항상 코틀린이 문법적으로 더 깔끔하다고 생각했는데.. StructuredTaskScope 보고, 그렇지만은 안다는걸 느꼈다.. 코틀린을 하면서, 어렵고 난해하다고 생각하는 부분/기능이 코루틴이였다. 그 개념을 이해하는데, 정말 시간이 걸렸다. 이해한거같은데, 모르겠고, 모르겠는데, 이해되는 부분도있고 하는 애매한 상태가 오래됬는데, 관련 코틀린책을 3번 정도 읽으니, 이해를 마침내 되었다. 그래도 코루틴에서 난해한 부분이 "구조화된 동시성"에 대한 기능에 대한 이해였다.이해는 되지만, 사용법이 깔끔하지 않다고 할까? 특히 코드 블럭이 중첩되는 경우에 "구조화된 동시성"에 따른 동작 흐름을 판단하는건 많이 복잡했다. DB 트랜잭션 전파(Propagation)와도 비슷한 맥락이랄까? ㅋ 암튼, 코틀린..
