📝 적어서 머릿속으로

최근에 예상치 못하게 상당히 좋은 기회를 얻어서 토스 채용에 참여하게 되었고 보이는 것과 같이 최종적으로 기술면접에 통과하지 못했습니다.물론, 면접 직후에도 또 결과를 받은 후에도 아쉬움이 남았지만, 상당히 좋은 인사이트를 얻게된 계기였다는 생각이 들어서 글을 남겨보려 합니다. 저는 개발자로 커리어를 시작하면서 이직을 빠르게 준비하지는 않았습니다. 오히려 한 회사에 몇 년은 있어야겠다는 생각이 있어서 이직 준비를 거의 하지 않았습니다. 조금씩 새로운 환경에 대한 궁금증이 생겨날 쯤부터 이직 시장의 분위기를 알아볼 겸 몇몇 회사에 지원을 했었고 기술 면접부터 최종 합격까지 결과를 받기도 했습니다. 면접까지 진행한 회사가 많지는 않았지만 소위 1차 면접 혹은 직무/기술 면접에서 탈락한 경우는 없었습니다. 이..

금융권에서 IT 개발자로 일하면서 현장에서 '레거시(Legacy)'라고 불리는 오래된 코드를 자주 마주하게 됩니다.저는 이런 코드를 단순히 레거시('오래된 코드'나 '기술 부채')라고 말하고 싶지는 않습니다. 이 코드들은 십수 년간 수천만 건의 거래를 버텨낸 '살아남은 코드'이자, 당시의 치열한 고민이 담긴 '선배들의 유산'입니다.금융권의 특성상 '혁신적인 성능'보다 '단 하나의 오류도 없는 안전'이 1순위였을 테니까요. 하지만 최근 신규 프로젝트나 공통 모듈 개발 과정에서도 무의식적으로 StringBuffer가 사용되는 모습을 보며, 개발자로서 작은 물음표를 던지게 되었습니다. "우리는 지금 안전을 위해 StringBuffer를 쓰는 걸까, 아니면 관습적으로 쓰고 있는 걸까?"1. 10년 전의 정답이 ..

데이터가 알려준 해결책: '뺄셈'의 기술과 의사결정 과정 [1편]에서 우리는 자체 구축한 모니터링 시스템을 통해, 빌드 중 메모리가 폭발하는 원인이 과도하게 복잡한 Chunking 설정'과 불필요하게 빌드되는 모듈이 있음을 데이터로 확인했습니다.하지만 원인을 알았다고 해서 무작정 코드를 삭제할 수는 없습니다. 이번 글에서는 기존 코드의 의도를 파악하며 안전하게 개선하는 과정과, 실제 문제를 해결해 나가는 기술적 의사결정을 담았습니다.1. 첫 번째 난관: manualChunks, 과연 줄여도 되는가?가장 큰 메모리 병목지점은 vite.config.js의 manualChunks 설정이었습니다.많은 if-else 문이 라이브러리들을 잘게 쪼개고 있었습니다.🤔 고민: "이 코드는 이유가 있어서 존재하지 않을까..

폐쇄망 환경에서 OOM 잡기: "도구"가 없으면 만들어 쓴다. 들어가며최근 저희 팀이 운영하는 대고객 서비스 프로젝트 빌드 중, JavaScript heap out of memory (OOM) 오류가 발생하기 시작했습니다.당장 급한 불을 끄기 위해 메모리 할당량을 늘리는 조치를 취했지만, 이는 근본적인 해결책이 아니었습니다."메모리를 늘려서 해결"하는 방식은 언젠가 임계치를 넘으면 반드시 재발합니다. 더 큰 문제는 "정확히 어디서, 왜 메모리가 튀는지 모른다"는 것이었습니다. "관측할 수 없으면, 개선할 수 없다."금융권이라는 특수한 환경(폐쇄망) 탓에 Prometheus나 Grafana 같은 좋은 시각화 도구를 쓸 수 없었습니다.또한, 경량성과 즉시성이 중요한 시점에서 해당 도구를 반입하는 것은 배보다..

최근 많은 화두가 되고 있는 스테이블 코인에 대한 좋은 강연을 듣게 되었습니다. 스테이블 코인 뿐아니라 현재의 금융 시스템의 한계를 지적하면 코인이 나오게된 배경과 생태계의 구성, 반대로 코인의 금융 네트워크에서 바로 이용되기 어려운 한계를 암호학 관점에서 바라보고 이 한계를 깰 수 있는 동형암호에 대한 연설까지 금융과 IT 기술에 관심이 있는 사람이라면 아주 유익한 강연이었다고 생각하여 글을 정리하고 공유 합니다. 1부. 동형암호화란 무엇인가― 기존 암호 방식의 한계와 ‘데이터를 보지 않고 계산하는’ 기술의 등장최근 데이터 보안 분야에서 가장 큰 화두는 **동형암호(Fully Homomorphic Encryption, FHE)**이다.이 기술은 “데이터를 암호화한 상태 그대로 계산할 수 있다”는 점에..

TOP-N과 인덱스 스캔이왜 그렇게 동작하는지까지 사내에서 페이징처리를 위해서 고전 방식의 쿼리를 이용한 TOP-N 방식을 사용한다.예시SELECT *FROM( SELECT ROWNUM as row_num, T.* FROM ( SELECT * FROM MY_TABLE WHERE :조건 ORDER BY :인덱스_컬럼 ) T WHERE ROWNUM (:pageNum - 1) * :pageCountpageNum: 페이지 번호pageCount: 한 페이지에 표기할 아이템 수 위와 같은 규칙에 맞게 작성되어있는 페이징을 처리하는 서비스의 테스트를 진행했다. 처음은 단순하게 생각했다.PK정렬 -> 인덱스 존재 -> 인덱스로 정렬 없이 상위 N개를 먼저 읽어온다. 하지만 실제 개발서버에서 진행한 오라클의 ..

JS를 활용하는 front 소스에서 사용자 입력을 통해서 함수를 더 진행시킬지 중단할지 정해야하는 경우가 많이 생깁니다. 모든 Modal 창을 통해서 callback 처리를 각각 함수에서 받아서 처리하면 문제가 생길 일이 없지만, 복잡한 비지니스 로직해서하나의 함수에서 연속적으로 사용자 입력을 받아할 경우가 생길 수 있습니다. 최근 실무에서 위와 같은 문제가 생긴적이 있는데 이를 해결하기 위해서 사용한 간략한 기법을 정리해 봅니다. 예시코드let success = '' //resolve를 담을 변수let fail = '' //reject를 담을 변수const returnPromise = () => { console.log("returnPromise call") return new P..

하코테 8일차 문제 역시 스택/큐 문제입니다.해당 문제에서는 큐를 이용한 문제 풀이를 하였으나 반드시 자료구조 큐를 이용할 필요없이 성능 향상을 위한 방식을 고려해볼 수 있어습니다.문제 설명프로그래머스 팀에서는 기능 개선 작업을 수행 중입니다. 각 기능은 진도가 100%일 때 서비스에 반영할 수 있습니다.또, 각 기능의 개발속도는 모두 다르기 때문에 뒤에 있는 기능이 앞에 있는 기능보다 먼저 개발될 수 있고, 이때 뒤에 있는 기능은 앞에 있는 기능이 배포될 때 함께 배포됩니다.먼저 배포되어야 하는 순서대로 작업의 진도가 적힌 정수 배열 progresses와 각 작업의 개발 속도가 적힌 정수 배열 speeds가 주어질 때 각 배포마다 몇 개의 기능이 배포되는지를 return 하도록 solution 함수를 ..

하코테(하루 코딩 테스트) 2주차의 두번째 문제 입니다.이번주는 회사 일정으로 문제풀이 및 블로그 글 작성이 버거움이 있었어서 블로그 글을 몰아쓰게 되었습니다.그래도 매일 한 문제씩 풀자고 목표를두니 작성을 포기하지는 않게되어서 도움이되네요.문제 설명초 단위로 기록된 주식가격이 담긴 배열 prices가 매개변수로 주어질 때, 가격이 떨어지지 않은 기간은 몇 초인지를 return 하도록 solution 함수를 완성하세요. 제한사항prices의 각 가격은 1 이상 10,000 이하인 자연수입니다.prices의 길이는 2 이상 100,000 이하입니다. 입출력 예prices return[1, 2, 3, 2, 3] [4, 3, 1, 1, 0]입출력 예 설명1초 시점의 ₩1은 끝까지 가격이 떨어지지 않았습니다.2..

하코테를 시작하고 2주차가 시작되었습니다.월요일에 큰 일정이 없어서 무사히 문제를 풀 수 있었습니다. 지난주에는 계속 해시 문제를 풀었다면, 이번주에는 스택/큐 문제가 나올 것으로 보입니다.문제 설명배열 arr가 주어집니다. 배열 arr의 각 원소는 숫자 0부터 9까지로 이루어져 있습니다. 이때, 배열 arr에서 연속적으로 나타나는 숫자는 하나만 남기고 전부 제거하려고 합니다. 단, 제거된 후 남은 수들을 반환할 때는 배열 arr의 원소들의 순서를 유지해야 합니다. 예를 들면,arr = [1, 1, 3, 3, 0, 1, 1] 이면 [1, 3, 0, 1] 을 return 합니다.arr = [4, 4, 4, 3, 3] 이면 [4, 3] 을 return 합니다.배열 arr에서 연속적으로 나타나는 숫자는 제거하..