작년에 쓰려고 했다가 미루고 미루다 드디어 쓰게 됐다.IT 서비스 기업에 가고 싶다면, 요즘은 라이브 코딩 테스트를 거의 피할 수 없는 것 같다. 실제로 내가 작년에 본 면접 중 절반 이상인 4곳 모두 라이브 코테를 봤다. 내가 본 회사와 직무는 이렇다.당근 - 백엔드 인턴데브시스터즈 - 쿠키런 서버 개발자야놀자 Next - 소프트웨어 엔지니어 인턴어피닛(밸런스히어로) - AI-Native 소프트웨어 엔지니어 인턴데브시스터즈를 제외하면 모두 인턴 채용이었는데, 그럼에도 라이브 코테를 봤다. 심지어 데브시스터즈와 야놀자는 코테를 보고 면접으로 라이브 코테를 또 보는 프로세스였다. 아마 공채가 아닌 이상 거의 다 보는 추세인 것 같다. (물론 내가 그런 곳만 붙은 걸 수도 있다.)문제는, 네 곳의 방식이 전..
전체 글
이전 글에서 "판단력이 먼저고, 도구 활용은 그다음이다. 하지만 그다음이 안 중요하다는 뜻은 아니다"라고 썼다. 이번 글은 그 그다음 이야기다. 나는 처음에 Anthropic 해커톤 우승자의 셋업을 그대로 가져다 썼다. 내가 막 Claude Code를 쓰던 때 주위에서 가장 많이 추천하던 것이기 때문이다.. 그래서 무작정 깔고 사용했다. 근데 그렇게 쓰다 보니까 문제가 생겼다. CLAUDE.md에도 코딩 스타일이 있고, Rules에도 비슷한 내용이 있고, 뭐가 어디서 적용되는 건지 모르겠는 거다. 남이 만든 걸 쓸 때는 몰라도 됐는데, 내가 직접 만들려고 하니까 각각이 뭔지를 알아야 했다. 그래서 찾아보면 CLAUDE.md, Rules, Skills, Agents, Hooks, MCP... 이런 것들이 ..
더 늦기 전에 이런 주제로 한 번쯤 정리해보고 싶었다. 시간이 지날수록 AI가 빠르게 발전하면서, 지금 이 생각마저도 틀린 말이 되거나 도태된 생각이 될 수 있으니까. (그래서 오래 지난 뒤 이 글을 본다면 틀린 말도 많을 것이다. 그렇지만 현재 상황에서 보고 생각한 바를 써보려 한다.) AI가 하루가 다르게 바뀌고 있다. 나도 계속해서 Claude Code를 만지작거리고 있다. 서브에이전트 구성, CLAUDE.md 세팅, 토큰 최적화. 주변 개발자들한테 "AI 어떻게 써?" 물어보고 다니면서, 나름 꿀팁도 모으고 있었다. 자극적인 뉴스들 속에서 "뭘 해야 하지", "대체되는 거 아냐" 생각하면서, 도태되지 않으려고 어찌저찌 따라가고 있다. 근데 어느 순간, 이런 생각이 들었다. 내가 지금 모으고 있는 ..
AI를 얼마나 잘 활용하느냐가 개발자의 경쟁력을 좌우하는 시대이다. 최근 인턴을 시작하고 한 달 정도 지나면서, 내가 가장 강하게 체감한 변화도 바로 이 지점이었다. 만약 계속 취준만 하고 있었다면 세상이 이렇게 빠르게 변하는 걸 잘 몰랐을지도 모른다.개발을 보조 도구로 AI를 쓰는 방식에서 AI를 전제로 일하는 방식(AI-Native)으로 넘어가는 흐름이 생각보다 훨씬 빠르다. 그리고 그 변화를 가장 직접적으로 느끼게 해 준 도구가 Claude Code였다. 돌아보면 내 개발 경험은 3~4년 정도 된다. 피로그래밍으로 시작해서 멋쟁이사자처럼, SOPT 같은 동아리를 거치며 Django, HTML/CSS/JS, Spring 등을 두루 경험했고, 실제 서비스를 운영하면서 CI/CD, 서버 아키텍처, 인프라..
회고록올해를 시작하며 거창한 계획을 세웠던 게 엊그제 같은데, 어느덧 올해의 마지막 날이다. 개발자로서 프로젝트가 끝나면 늘 회고를 하듯, 1년을 마무리하는 시점에서 내 스스로도 회고가 필요한 시기라 생각했다. 1. 목표 달성률 점검 (KPT인 듯 아닌 듯)올해의 목표는 크게 다음과 같았다. 블로그 꾸준히 쓰기, 코테 준비, 운동, 영어 공부, 책 읽기 등 이외의 자잘한 목표들이 있었다. 결론부터 말하자면, 영어 공부 빼고는 유의미한 흔적들은 남긴 것 같다. (영어는 내년의 나에게 넘긴다.) 하나하나 짚어보자면, - 블로그는 뒤로 갈수록 취준과 프로젝트 준비 핑계로 소홀해졌던 게 사실이다. 그래도 초반엔 매주 하나씩 꼬박꼬박 썼고, 나중에도 한 달에 한 번은 생존 신고를 했다. 덕분에 올해가 몇시간 남지..
오늘은 책을 읽고 정리해 본 CS 개념이다! (공부할 겸 정리해서 올려본다.) 1. 컴퓨터 구조의 큰 그림컴퓨터가 이해하는 정보컴퓨터가 다루는 것: 데이터 + 명령어 컴퓨터의 핵심 부품-> CPU(중앙처리장치), 메모리(주기억장치), 캐시메모리, 보조기억장치, 입출력장치CPUCPU는 명령어를 읽고, 해석하고, 실행하는 핵심 부품이다.산술논리연산장치(ALU): 사칙연산, 논리연산을 수행한다.제어장치(CU): 명령어를 해석하고 각 부품에 제어 신호를 보낸다.레지스터: CPU 내부의 임시 저장장치로, 처리 과정에서 필요한 데이터를 일시 저장한다.메모리와 캐시 메모리메모리(RAM)는 현재 실행 중인 프로그램의 데이터와 명령어를 저장한다. 메모리는 주소를 통해 접근하며, 휘발성이기 때문에 전원이 꺼지면 내용이 사..
04. 아키텍처4.3 MyISAM 스토리지 엔진 아키텍처MyISAM 스토리지 엔진의 성능에 영향을 미치는 요소인 키 캐시와 운영체제의 캐시/버퍼에 대해 보자.4.3.1 키 캐시InnoDB의 버퍼 풀과 유사한 기능을 한다. 하지만 MyISAM 키 캐시는 인덱스만 대상으로 동작하며, 데이터는 캐시 하지 않는다. 디스크 쓰기에 대해서도 부분적인 버퍼링 역할만 수행한다. 키 캐시 히트율(Hit rate) = 100 - (Key_reads / Key_read_requests * 100)키 캐시가 얼마나 효율적으로 작동하는지 간단히 확인할 수 있는 수식이다. Key_reads는 디스크에서 인덱스를 읽은 횟수, Key_read_requests는 키 캐시에서 인덱스를 읽은 횟수이다. 일반적으로 99% 이상 유지를 권장..
04. 아키텍처4.2 InnoDB 스토리지 엔진 아키텍처MySQL의 스토리지 엔진 가운데 가장 많이 사용되는 InnoDB 스토리지 엔진이다. InnoDB는 MySQL에서 사용할 수 있는 스토리지 엔진 중 거의 유일하게 레코드 기반의 잠금을 제공하기 때문에 높은 동시성 처리가 가능하고 안정적이며 성능이 뛰어나다. 4.2.1 프라이머리 키에 의한 클러스터링InnoDB의 모든 테이블은 기본적으로 프라이머리 키를 기준으로 클러스터링 되어 저장된다. 즉, 프라이머리 키 값의 순서대로 디스크에 저장된다는 뜻이며, 모든 세컨더리 인덱스는 레코드의 주소 대신 프라이머리 키의 값을 논리적인 주소로 사용한다.프라이머리 키가 클러스터링 인덱스이기 때문에 프라이머리 키를 이용한 레인지 스캔은 상당히 빨리 처리될 수 있다. 결..
오랜만에 책으로 돌아왔다. 이 책 또한 바이블 서적이다. 읽어야지 다짐만 하다 드디어 읽게 되어서 정리해보려 한다!1장은 MySQL에 대한 간단한 소개, 2장은 설치와 시작/종료, 업그레이드 과정과 설정 파일(cnf) 및 시스템 변수들을 간략히 다룬다. 3장에서는 사용자와 권한 관리, 계정과 비밀번호 설정, 권한과 역할에 대해 짚고 넘어간다. 하지만 모두 기본적인 수준이라 큰 비중은 두지 않고, 이제부터는 4장 아키텍처에서부터 본격적인 핵심 내용을 살펴보려 한다. 04. 아키텍처4.1 MySQL 엔진 아키텍처4.1.1 MySQL의 전체 구조 MySQL은 일반 상용 RDBMS와 같이 대부분의 프로그래밍 언어로부터 접근 방법을 모두 지원한다. C API, JDBC, ODBC, .NET의 표준 드라이버를 제공..
이전 포스팅에서도 적었지만 위 사진은 우리의 큰 비즈니스 플로우이다. (다른 부분들은 다 제외하고 외부 API 활용 기준으로 그려봤다.) 우리 서비스는 사실상 브랜드가 이용하는 서비스 하나, 인플루언서가 이용하는 서비스 총 2개로 나눠져 있고, 이때 우리는 Cafe24라는 외부 API를 활용해서 보다 쉽게 둘을 연결해 주는데 도움을 준다. 우리 서비스에서 외부(Cafe24) API를 쓰는 3곳상품 조회: 브랜드가 우리 서비스에서 자사 상품 목록을 보고 등록할 협찬 상품을 고를 수 있도록 Cafe24 상품 조회 API을 읽어온다.할인 코드 생성: 협찬 승인 시 인플루언서별 할인 코드를 만든다.주문 조회: 매일 00:10에 전일 주문을 모아서 동기화한다.이처럼 서비스의 핵심 화면 다수에서 외부 API가 사용..