Razelo 기술노트

최근 Bedrock API를 회사에서 마음껏 쓰도록 뚫어줘서 개발자 업무 자동화를 위한 툴링에 AI를 써봤다. 꽤나 흥미로웠다. AWS Bedrock 콘솔에 있는 추론 모델 중 하나를 지정하고 API로 질의할때 system role이라는걸 줘서 어떤 류의 "AI"로 동작할 지 역할 부여를 사전에 할 수 있다. 그리고 나서 질의를 하고 그 결과를 활용하는 방식이었다. (참고로 API response 타임이 생각보다 길다. 뭐 GPT 생각해보면 응답 타임이 긴 것도 납득은 간다.) 결과 품질이 꽤나 좋았다. 매번 물어볼 때 마다 당연히 답변은 달라지지만 그래도 쓸 만한 로직의 일부로써 AI가 동작한다는게 인상적이었다. 뭐 요즘 cli로 claude도 세팅해서 여러 개 띄워놓고 동시에 일시켜놓고 하는 것들도 ..

최근에 이런 저런 여유 시간이 생겨서 회사에서 개발자 생산성 향상을 위해 몇 가지 툴링 작업을 해봤다. 자랑은 아니고 그냥 배운 점들이 많아서 내용 정리겸 적어본다. 특히 Gitlab API에 이렇게 많은 기능이 제공되는지 몰랐다. 그리고 R&D 해보면서 나중에 개인 사이드로도 도입해볼 법한 재밌는 것들을 많이 발견했다. 아래 간략하게 내용을 정리해본다. 이런 류의 툴링은 항상 개발자에게 있어서 "맛난 간식"같은 느낌이다. 뭐 내가 툴링을 좀 좋아하는 성격인 것 같기도 하다. 1) 장기간 방치된 릴리즈 브랜치 알림 기능 회사에서 릴리즈 완료 이후 해당 릴리즈 머지 요청이 필요한데 종종 방치되어 한달이 넘어가는 릴리즈 브랜치가 생기는 경우가 있곤 했다. 그래서 이를 방지하고자 Gitlab 프로젝트의 브..

나는 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

유연한 소프트웨어 엔지니어가 되야 한다는 생각을 종종 한다. 특정 기술 스택에 얽매여서 자신은 xx개발자라거나 하는 둥 한정되어선 안된다고 생각한다. 물론 전문성을 갖추려 노력하는 것은 와중에 실력있는 개발자가 되기 위해 당연한 노력이지만 언제든 다른 무언가를 개발해야할 필요가 생겼을때 즉각 뛰어들 수 있는 사고를 가져야한다.

보통 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