전체 글

연봉협상 2년차가 넘어서 연봉협상을 진행했다. 좋은 기회로 인해 대표님과 직접 연봉협상을 진행하게 되었고, 거의 2주 넘게 협상이 진행되었다. 서로 창과 방패처럼 치열하게 다투다가 결국은 합의점을 찾아 협상을 마무리하게 되었다. 첫 회사이고 이번까지 연봉협상을 2번 진행했지만 잘 되어가고 있는지는 모르겠다.이전에는 '~~처럼 되고 싶다'라는 추상적인 목표가 있었는데, 루퍼스에서 만난 멘토님의 조언을 듣고 'N년차에는 최소 이정도는 받아야지'라는 구체적인 목표를 세웠더니, 그 목표를 향해 달려갈 수 있게 되었다. 내가 이렇게 연협을 할 수 있는 무기를 가지게 된 것도 전부 루퍼스에서 만난 사람들이 있어서, 루퍼스에서 배운 기술이 있어서 가능했다.https://qkrqkrrlrl.tistory.com/202..

AI가 유행하고, 에이전트가 유행하면서 내가 느끼는 문제점 두 가지 정리해보려고 한다. 첫 번째 문제. '잘못된 지식 전파' AI의 여파로 잘못된 CS 지식이 퍼지는 경우가 많아지기 시작했다.최근에 많은 저연차들이 본인의 CS 학습을 위한 사이트를 개설해서 배포해 공유하는 경우를 종종 만났다. 의도는 이해한다. 내가 공부하기 위해 만들었고, 다른 사람들도 이 내용을 알면 좋을 것 같아서 배포하고 홍보한다. 하지만 에이전트로 CS 학습을 진행해 보면 느끼겠지만, 지금도 '위에서 말씀드린 답변은 잘못 알려드렸습니다.'라고 정정하는 경우가 발생한다. AI로 인해 생기는 가장 큰 문제라고 생각한다. 잘못된 정보를 진실로 믿고 전파하는 행동. 두 번째 문제. '당신의 글은 직접 쓰셨나요?' 많은 사람들이 ..

7월 22일. 입사 딱 2년 되는 날이다. 6월 중순부터 연봉협상을 위해 칼을 갈았다. 그동안 해온 것, 성과로 남긴 것, 앞으로 해낼 수 있는 것을 하나씩 정리했다. 정리하다 보니 빠질 수 없는 게 AI 업무 자동화였다. 루퍼스로, 또 좋은 인연으로 에이전트 소식을 남들보다 빨리 접했고, 운 좋게 잘 만들어진 하네스를 얻어 우리 개발팀에 맞게 뜯어고쳐 사용했다. 에이전트를 팀에 활성화 시키고, 하네스로 룰을 잡고, 도메인 지식을 채워 넣으니 신규 개발이든 유지보수든 시간이 확 줄었다.같은 시간에 더 많은 일을 수행할 수 있게 된 것이다. 그러다 문득 '이 하네스, 에이전트, AI 지식들... 내가 엄청난 걸 알고 있지는 않지만 본사에서는 어떻게 쓰고 있을까? 다른 사람은 어떤 관점을 가지고 있을까?'..

1분기 입사하고 반 년이 지났다.회사에서는 A 프로젝트를 계속 수행했고, 2차 사업 얘기도 나오면서 프로젝트에 대한 애정이 많이 커졌던 시기다. 특히 사이드 프로젝트를 만들었을 때는 '이렇게 열심히 만들었는데 사용자도 없네' 생각이 들면서 좌절감을 맛 봤었는데,회사의 솔루션을 해당 기관에서 열심히 사용해준 덕분에 개발에 쏟은 시간이 행복하고 유의미하다는 생각이 들었다. 회사 슬랙에 내가 처리했던 에러를 열심히 정리하여 공유하는 글도 많이 올렸었고, '어떻게 하면 고객사에게 이 솔루션으로 더 많은 기능을 제공하고, 현재의 불편함을 해소할 수 있을까?' 라는 고민을 스스로 많이 하기 시작했다. 솔루션으로 더 많은 기능을 제공하고, 더 많은 문제를 확인하기 위해서는 '내가 사용자가 되어보는 법'이 최적의 접..

어느 날 울린 전화 한 통 "프로세스가 자꾸 꺼져요" 급하게 로그 파일을 전달 받아서 분석해보니 원인은 OutOfMemory였습니다. 당장 이슈를 깊게 파고들 여유가 없던 상황이어서, 일단 프로세스가 죽으면 자동으로 감지해 재기동하는 스크립트를 만들어 임시 조치를 해뒀습니다. 며칠 뒤, 액추에이터를 이용하여 수동 모니터링 기능을 만들어두고 힙메모리를 보는데 20GB나 사용하고 있는 상황을 발견했습니다. 분명 이렇게 힙메모리를 많이 차지할리가 없는데? 테스트를 위해 로컬에서 프로세스를 실행시켜 약 6시간 넘게 방치했던 결과 GC는 정상적으로 수행되었지만 힙메모리 그래프는 우상향을 하기 시작했습니다. "아 이건 무언가 잘못됐다. 어디선가 자원이 줄줄 새고 있다." 그래서 힙덤프를 만들어서 급하게 메모..

오랜만에 사이드 프로젝트 리팩토링을 진행하면서 오류를 만났다. 기존에 캐싱 데이터는 내부에 맵을 이용해서 캐싱하고 있었다.(사실 큰 데이터도 아니었기 때문, 빠른 구현을 위해) 그러나 시간이 지나 결국 Redis를 사용하고 있기 때문에 기존에 사용하고 있던 맵을 Redis로 이전하기로 결정했다. 별도의 리팩토링 프로젝트를 만들고 RedisConfig를 설정하면서 총 2가지 문제를 만났었다. 우선 초기에 설정했던 RedisConfig다. @Bean public RedisTemplate redisTemplate() { RedisTemplate redisTemplate = new RedisTemplate(); redisTemplate.setConnectionFactory..

이 글은 단순 추천, 광고가 아닌 제 솔직한 후기를 작성했음을 미리 밝힙니다.(절대 맹목적인 추천이 아닙니다.) 1. 왜 많은 부트캠프 중에 루퍼스를 선택했나? 개발자 중에 저와 같은 고민을 하는 사람이 많았을 거라 생각합니다. 회사의 업무를 열심히 하지만 성장하는 것을 못 느낀다사수가 없어 어떤 개발이 맞는 건지 잘 모르겠다이러다 개발자가 아닌 그냥 회사원이 될 것 같다 좋은 환경과 사수를 두고도 회사 일만으로는 성장에 한계가 있다는 걸 늘 느꼈습니다.사이드 프로젝트도 해봤지만, 결국 “이럴 때 어떤 구조가 맞는가? 어떤 기술을 왜 써야 하는가?” 같은 본질적인 고민은 풀리지 않았습니다. 그러다가 개발바닥 오픈톡방에서 '허재'님이 올린 홍보 글을 하나 발견하게 됩니다. 이때만 해도 '허재'님이 누..

SI 환경에서 느낀 로깅의 본질 1. 서비스 환경과 SI 환경의 차이 회사에 입사하기 전까지는 사이드 프로젝트를 서비스 형태로 만들었기 때문에 모니터링에 큰 문제가 없었다.슬랙으로 error 로그를 보내줘도 되고, 그라파나랑 프로메테우스를 통해 실시간 모니터링도 가능했기 때문이다. 즉, 서비스 환경에서는 문제가 생겨도 바로 알림을 받고 대처를 할 수 있었다. 하지만 SI, 내부망, 사내망, 원격 이런 얘기가 나오면 로깅에 대해서는 얘기가 달라지게 된다. 1년 1개월간 SI에서 개발을 진행하며 느낀 문제는 '실시간성이 없다'이다.이때 실시간성은 개발자한테 해당되는 얘기다. 예시로 프로젝트 3~6개월이 하나 잡힌다고 가정해 보자. 열심히 개발을 한다.그리고 운영서버에 해당 솔루션을 올린다. 열심히 돌..