IT적응기95 로드밸런서 (L4 vs L7, 세션 관리, HAProxy) 서버를 두 대로 늘리던 날, 저는 완전히 예상 밖의 문제를 맞닥뜨렸습니다. 트래픽은 잘 분산되는데 로그인이 요청마다 풀리는 겁니다. 로드밸런서를 단순히 "트래픽을 나눠주는 장치"로만 생각했던 게 문제였습니다. 이 글은 그 경험을 바탕으로 L4와 L7의 차이, 그리고 세션 관리 전략까지 실제로 써보며 느낀 것들을 정리한 내용입니다.L4 vs L7, 뭐가 다른가로드밸런서는 OSI 모델에서 어느 계층에서 동작하느냐에 따라 크게 두 가지로 나뉩니다. 여기서 OSI 모델이란 네트워크 통신을 7개 계층으로 분류한 표준 모델로, L4는 4번째 전송 계층, L7은 7번째 응용 계층에 해당합니다.L4 로드밸런싱은 TCP/UDP 수준에서 소스·목적지 IP와 포트 정보만 보고 트래픽을 분산합니다. 패킷 내부 내용을 들여다보.. 2026. 6. 15. DNS 캐시 포이즈닝 (재귀 리졸버, DNSSEC, 다층 방어) 주소창에 URL을 입력하는 순간 눈에 보이지 않는 과정이 시작됩니다. OS가 먼저 로컬 DNS 캐시를 뒤지고, 거기 없으면 재귀 리졸버(Recursive Resolver)에 질의합니다. 여기서 재귀 리졸버란 사용자 대신 루트 네임서버부터 차례로 질의를 이어가며 최종 IP 주소를 찾아오는 중간 대리인입니다. 흔히 ISP나 구글(8.8.8.8), Cloudflare(1.1.1.1) 같은 공개 DNS 서버가 이 역할을 합니다.리졸버는 루트 네임서버(Root NS)에 먼저 물어 TLD 네임서버 주소를 받고, 그 TLD 서버에서 권한 있는 네임서버(Authoritative NS) 주소를 받은 뒤, 거기서 최종 IP를 가져옵니다. 이 IP는 TTL(Time To Live) 값과 함께 캐시에 저장됩니다. TTL이란 .. 2026. 6. 14. MCP 완전 정복 (표준화, 보안, 실전 활용) 출시 첫 달 10만 건이었던 SDK 다운로드가 15개월 만에 9,700만 건으로 뛰었습니다. 970배입니다. 이 숫자를 처음 봤을 때 솔직히 믿기지 않았습니다. 그런데 직접 써보고 나서야 왜 이렇게 빠르게 퍼졌는지 이해가 됐습니다.AI 통합의 표준화, 왜 지금 MCP인가혹시 LLM(Large Language Model)마다 연동 방식이 전부 달랐다는 사실을 알고 계셨나요? LLM이란 GPT나 Claude처럼 대규모 텍스트 데이터로 훈련된 언어 모델을 말합니다. OpenAI function format, Anthropic tool format, Gemini function format — 같은 작업을 하려면 각 모델에 맞는 코드를 따로 짜야 했습니다. 개발자 입장에서는 사실상 같은 통합을 세 번 반복하는 .. 2026. 6. 11. 바이브 코딩 - 첫 경험, 툴 비교, 검증 워크플로우 로그인 기능 하나 만드는 데 이틀을 쓴 적 있으십니까. 저는 있습니다. JWT 토큰 구조 잡고, 리프레시 토큰 로직 짜고, SQLAlchemy 세션 관리까지 손으로 한 줄씩 치던 그 시절 얘기입니다. 그때 바이브 코딩을 처음 만났고, "이게 진짜 되나?" 싶었던 첫 반응이 지금도 생생합니다. 2026년 현재, 그 의심은 반쯤 맞고 반쯤 틀렸다는 게 솔직한 결론입니다.바이브 코딩에 대해 글을 쓰면서 제가 가장 경계하는 건 두 가지 극단입니다. 하나는 "AI가 개발자를 대체한다"는 과장된 낙관론, 다른 하나는 "AI 코드는 쓰레기다"는 방어적인 거부감. 둘 다 현실과 거리가 있습니다. 실제로 1년 이상 바이브 코딩을 병행해온 입장에서, 이건 도구입니다. 아주 강력한, 그러나 검증 없이는 아주 위험한 도구입니.. 2026. 6. 7. 개발자-기획자 갈등 - 언어차이, 구조문제, 협업전환 솔직히 저는 오랫동안 이 갈등이 '사람 문제'라고 생각했습니다. 기획자가 개발을 모르거나, 개발자가 소통을 못하거나. 그런데 20년을 일하고 나서 깨달은 건, 그게 절반도 맞지 않는 진단이라는 것입니다. 개발자와 기획자 사이의 충돌은 생각보다 훨씬 구조적이고, 그래서 훨씬 더 다루기 까다롭습니다.지금 돌이켜보면, 초반 5년 동안의 저는 기획자에게 상당히 무례했습니다. 기획서를 받을 때마다 '왜 이렇게 허술하냐'는 생각이 먼저 들었고, 리뷰 미팅에서 기술적 제약을 설명하다 지쳐서 "안 됩니다"로 끊어버린 적도 많았습니다. 당시엔 그게 합리적이고 효율적인 판단이라고 여겼는데, 지금 돌아보면 그건 소통의 실패가 아니라 언어의 불일치였습니다. 나는 feasibility의 언어로 말했고, 기획자는 UX의 언어로 .. 2026. 6. 5. 사이드 프로젝트 완성법-완성의 정의, MVP, 외부 압박 10년 동안 열두 개의 사이드 프로젝트를 시작하고 단 한 개도 완성하지 못했습니다. 직접 손가락으로 세어봤을 때 저도 순간 멍했습니다. 왜 이렇게 많은 프로젝트가 README.md만 남긴 채 깃허브 어딘가에 잠들어 있는지, 그 이유를 찾는 데 생각보다 오래 걸렸습니다. 원인은 의지력이나 시간이 아니었습니다. '완성의 정의'가 없었던 것이었습니다.솔직히 이 사실이 처음엔 받아들이기 어려웠습니다. 나름 10년간 개발자로 살아왔고, 스스로 꽤 실용적이라고 믿어왔으니까요. 그런데 열두 개의 잔해를 하나씩 들여다보니, 전부 같은 방식으로 죽어 있었습니다. 잘 쓴 README, 세심하게 설계한 DB 스키마, 아무도 쓰지 않을 기능 목록들. 완성되지 않은 것들이 공통적으로 가진 건 '시작의 흔적'뿐이었고, '끝의 정.. 2026. 6. 4. 이전 1 2 3 4 5 6 7 8 ··· 16 다음
