Razelo 기술노트

나는 AI agent를 적극 활용하는 편이다. 특히 ChatGPT를 여전히 애용하는 중이다. code complete보다 질의응답형 챗봇이 내겐 좀 더 유용했다. code complete 형은 사실 매번 내가 짜려는 거보다 선수쳐서 띄워주는게 싫었다. 내가 잘 작성하고 있는데 희미하게 bot이 예상하는 코드를 제안해주고 얼떨결에 그걸 Complete시켜버리는게 썩 유저 경험이 좋지 않았다. 내가 생각한 코드가 아니라서 대부분 다시 지워버리고 또 짜던 와중에 또 auto Complete시켜버리고, 그게 짜증나서 이런 유형은 잘 쓰지 않는다. (뭐 꽤나 긴 로깅 포매팅 자동 완성에는 도움된다.) GPT는 유료 버전으로 수년간 사용 중인데 며칠 전 처음으로 Cursor를 제대로 써봤는데 꽤 놀라웠다. 모든 c..

최근 몇가지 Linux에서 개인적으로 확인해보고 싶은 내용이 있어서 MacOS UTM에서 가상화로 Ubuntu를 띄워놓고 작업 중이었다. 그런데 작업을 하다가 commit을 했는데 왜 오늘 날짜인 25일에 잔디가 심어지지 않는 이상한 현상을 발견했다. 가상머신 시스템 Clock을 보니 이상하게도 어제 24일 13시로 찍혀있었다. 아무리 UTC가 차이가 난다고 해도 -8시간을 훌쩍 넘어서 거의 22시간 가량 차이가 날리는 없다고 생각했다. (오늘은 25일이다. 이 글을 쓰는 시점은 대략 오전 11시) 음 아마도 UTM 가상 머신을 종료하지 않고 어제 하루 동안 그대로 두었는데, 그 순간 시스템 Clock이 멈춰버린 것으로 추축했다. 어제 밤중에 작업을 하다가 UTM 가상 머신을 Log off -> Po..

종종 쓰시는 블로그 글을 관심있게 보고 있는 개발자 분 블로그에 좋은 글이 올라와서 첨부한다. 다시 읽어봐도 좋은 내용이 많다. 조직적으로도, 특히 "개인적으로도" https://jojoldu.tistory.com/858

Parallel Programming에 대한 괜찮은 아티클을 아래 첨부한다. 시간나면 읽자... https://mirrors.edge.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.2024.12.27a.pdf

보통 Config.ts 같은 파일에 설정 항목들을 정의해놓곤 한다. 인증 정보 말고 불변 컬렉션 느낌의 데이터를 정의해둘때 이런 곳에 두는데, 가끔 변수명을 대문자로 할까 싶을때가 있다. 참고로 정리하면 불변이라 내용이 바뀔 여지가 없는 설정 데이터면 대문자가 좋고, 값이 바뀔 여지가 있는 데이터면 소문자가 좋다.

개발에 대해 요즘 자주 하는 생각을 정리해보고자 한다. 어떤 문제가 발생했을때 어떻게 해결하는게 가장 좋을까라는 생각을 자주 하곤 한다. 만약 개인 프로젝트였다면 써보고 싶었던 기술을 쓰거나 시간이 얼마나 걸리던 간에 fancy해보이는 방법을 선택할 것 같다.그런데 보통 대다수의 개발자들이 그렇듯 일상에서 마주하는, 해결해야할 문제의 99퍼센트는 회사 프로젝트에서 발생한다. 나 또한 그렇다. 그런 상황 속에서 항상 선택하는건 지금 당장 적용 가능한 가장 간단하고 빠른 해결 방법을 적용하게 된다. 물론 설계 단계라면 시간이 충분하니 고민을 해보고 문제는 없는지 검토하는 시간이 여유롭고 R&D할 수 있는 시간도 조금은 주어진다.크리티컬하지 않은 이슈의 경우도 고민할 수 있는 약간의 시간이 주어진다. (..

최근 만들고 있는 어플리케이션에서 큐를 사용하게 되어 큐를 사용하는 아키텍쳐에 대한 고민을 해봤다.  복잡하게 데드레터 정책까지 가져가면서 큐의 메세지에 대한 retry를 실행하려하진 않았다. 실패한 메세지의 경우 어차피 깨진 상태를 갖고 있다고 가정하고 warn 로그를 남기고 아카이브에 해당 작업을 실패로 기록한 뒤 큐에서 곧장 소비해서 없애버리는 정책을 가져가고자 했다.  큐에 넣을 메세지는 어떤 작업을 지시하는 Job에 대한 정보로 사용하고자 했다. 그러다보니 api endpoint를 한 개만 남겨두고 기존에 만들어뒀던 api들을 모두 없애버리는 방법도 있었다. 한 개의 endpoint는 queue에 submit하는 역할만 하는 일종의 producer전용 api가 되는 것이다. 반대쪽 consume..

뭐 말이 많은데 사실 난 잘 모르겠다 그냥 기술에 대한 관심을 가지면서 재밌는걸 찾아보면서 살아가는게 재밌는것 같다 그게 개발자나 엔지니어나 기술PM이 되었던 간에 누구든 기술업계에 종사하면서 기술로 돈을 벌어먹고 있는 사람이라면 그저 기술에 대한 관심을 갖고 재밌어하고 흥미로워하면서 찾아보고 시간을 사용하면 그만인 것 같다 뭘 어떻게 해야한다거나, 정해진 그런 길 같은건 난 잘 모르겠다 통상 어떤 것은 이래야 한다거나 어떻게 해야한다거나 등등 정답은 없는데 그걸 논하는게 의미가 없는 것 같다는 생각이 든다 걸어보지 않은 길을 시작부터 떠드는 건 의미가 없다

작년 2월에 입사하고 벌써 1년이 훌쩍 넘었다.  졸업하자마자 곧장 신입으로 일했고 이것 저것 하다보니 벌써 신입 타이틀을 떼고 주니어가 되었다는게 신기하다.프론트엔드, 백엔드 등등 가리지않고 많은걸 해볼 수 있었다. 신입, 주니어, 시니어 등등 이런건 그저 호칭에 불과하지만 오늘따라 유독 와닿는 단어인것 같다.  마침 카페에 와서 글을 쓰다보니 유독 의미에 대해 생각하게 되는 것 같다.  처음 입사했을 때 지라 티켓만드는 것도 몰랐고, git rebase를 할 줄 몰라서 꼬인 커밋을 해결하지못하고 다시 clone받아야했던 적도 있다. MR은 어떻게 드려야하는지, 질문은 어떻게 해야하는지 그리고 문서 작성과 업무에 대한 공유까지 모든게 낯설었다. 어려운 프로젝트도 있었고 쉬운 프로젝트도 있었다. 그래서 ..

최근 exception핸들링에 대해서 고민이 있다. 애플리케이션을 만들때 어떻게 예외를 처리해야할지에 대해 근본적인 해답이 없다는 생각이 든다.  외부 api호출같은 IO작업에서 주로 try catch같은 exception 처리를 하는게 좋은데, 이미 요청이 실패하거나 크리티컬한 이유로 실패해서 exception이 터졌다면 애초에 처리하고자하는 정상적인 상태에서 깨진 상황인데 이상황에서 뭘 더 핸들링할까라는 생각이 든다. 바꿔 말하자면 이미 깨진 상태인데 뭘 더 하겠냐라는 뜻이다.  크리티컬한 이슈가 아닌 경우를 생각해보자면, 뭔가를 등록하려는데 중복 등록이라던지 혹은 워닝으로만 남겨도 될만한 작업이라면 쉽다. 그런데 인증이 잘못되었거나 뜬금없는 timeout 혹은 전혀 대비되지 않았던 예외케이스처럼 크..

아래 것들을 공부해야할 것 같다...  KotlinMSA DynamoDB MySQL