본문 바로가기

전체 글

Claude Code에서 Jira MCP 연결하기 - 이슈 조회부터 댓글 작성, 상태 변경까지 개발 업무를 하다 보면 Jira에서 일감을 확인하고, 요구사항을 읽고, 작업이 끝난 뒤 댓글을 작성하는 일을 반복하게 됩니다.Claude Code에서는 Atlassian Rovo MCP(Model Context Protocol)를 연결하면 Jira와 Confluence 정보를 직접 조회하고 일부 작업을 수행할 수 있습니다.예를 들어 다음과 같은 요청이 가능합니다.DD-123 일감 내용 알려줘DD-123 요구사항 정리해줘내 담당 열린 이슈 찾아줘DD-123 작업 내용 댓글로 정리해줘DD-123 상태를 진행 중으로 변경해줘이번 글에서는 Claude Code에서 Atlassian Jira MCP를 연결하는 방법과 실제 활용 방법을 정리해 보겠습니다.MCP란?MCP(Model Context Protocol)는 ..
갤럭시 휴대폰 변경 전 준비할 것 총정리|Smart Switch부터 카카오톡, 모바일 신분증까지 갤럭시 휴대폰 변경 전 준비할 것 총정리오래 사용하던 휴대폰을 새 휴대폰으로 바꾸면 단순히 유심만 옮기면 끝날 것 같지만, 실제로는 미리 확인해야 할 것들이 생각보다 많습니다.특히 사진, 카카오톡 대화, 금융 앱, 인증 앱, 모바일 신분증 등은 기기 변경 과정에서 별도로 확인해야 하는 경우가 있습니다.이번 글에서는 갤럭시 휴대폰에서 새로운 갤럭시 휴대폰으로 변경할 때 준비해야 할 것과 데이터 이전 방법을 정리해 보겠습니다.예시는 다음과 같습니다.갤럭시 A34 → 갤럭시 S25하지만 대부분의 갤럭시 기기 변경 과정에도 동일하게 적용할 수 있습니다.1. 휴대폰 변경 전에 가장 먼저 확인할 것새 휴대폰이 도착하기 전에 기존 휴대폰에서 몇 가지 백업을 확인하는 것이 좋습니다.가장 중요한 것은 다음과 같습니다.G..
MySQL 문자열 정렬과 Collation - 같은 문자열인데 결과가 다른 이유 MySQL에서 문자열을 저장할 때 VARCHAR만 지정하면 끝이라고 생각하기 쉽다.그런데 문자열을 비교하거나 정렬하다 보면 이런 상황을 만날 수 있다.SELECT 'ABC' = 'abc';결과가 1이 나올 수도 있고 0이 나올 수도 있다.또,SELECT nameFROM usersORDER BY name;를 실행했는데 내가 예상한 순서와 다른 결과가 나올 수도 있다.왜 그럴까?문자열의 저장 방식만 결정하는 것이 아니라 문자열을 어떻게 비교하고 정렬할 것인지까지 결정해야 하기 때문이다.이때 등장하는 것이 Collation(콜레이션)이다.1. Character Set과 Collation은 다르다먼저 둘을 구분해야 한다.Character Set문자를 어떤 방식으로 표현하고 저장할 것인지를 결정한다.예를 들어:u..
MySQL NULL 제대로 이해하기 - = NULL이 안 되는 이유 MySQL을 사용하다 보면 다음과 같은 조건을 작성할 때가 있습니다.SELECT *FROM usersWHERE deleted_at = NULL;그런데 예상과 달리 데이터가 조회되지 않습니다.분명 deleted_at이 비어 있는 데이터가 있는데도 결과가 나오지 않는 것입니다.이런 상황에서 처음 MySQL을 사용하는 경우에는 다음과 같이 생각하기 쉽습니다.NULL은 값이 비어 있다는 뜻이니까 = NULL로 비교하면 되지 않을까?하지만 SQL에서는 이렇게 비교하지 않습니다.WHERE deleted_at = NULL대신 다음과 같이 작성해야 합니다.WHERE deleted_at IS NULL이번 글에서는 MySQL에서 NULL이 정확히 무엇을 의미하는지, 왜 = NULL이 동작하지 않는지, 그리고 실무에서는 어..
MySQL OR 조건과 인덱스 - OR 때문에 쿼리가 느려지는 이유 SQL을 작성하다 보면 이런 조건을 자주 만나게 됩니다.SELECT *FROM usersWHERE status = 'active' OR status = 'pending';또는 서로 다른 컬럼을 비교하기도 합니다.SELECT *FROM usersWHERE email = 'test@example.com' OR phone = '010-1234-5678';문법적으로는 아무런 문제가 없습니다.그런데 데이터가 많아지고 인덱스가 추가되면서 이런 질문이 생깁니다.OR을 사용하면 인덱스를 제대로 사용할 수 있을까?인터넷을 찾아보면 흔히OR은 인덱스를 못 타기 때문에 느리다.라는 이야기도 볼 수 있습니다.하지만 이것은 너무 단순한 설명입니다.MySQL은 OR 조건에서도 상황에 따라 인덱스를 사용할 수 있습니다.중요..
MySQL DISTINCT 제대로 이해하기 - 중복 제거가 왜 느려질까? SQL을 작성하다 보면 이런 상황을 자주 만나게 됩니다.SELECT DISTINCT user_idFROM orders;주문 테이블에 같은 사용자의 주문이 여러 개 있다면 user_id가 여러 번 나타날 수 있습니다.DISTINCT는 이런 중복을 제거해서 한 번씩만 보여줍니다.처음에는 굉장히 간단해 보입니다.그런데 데이터가 많아지면 이런 질문이 생깁니다.DISTINCT는 내부적으로 어떻게 중복을 제거할까?그리고 다음과 같은 쿼리는 어떨까요?SELECT DISTINCT users.*FROM usersJOIN orders ON orders.user_id = users.id;JOIN 결과에서 중복된 사용자를 없애기 위해 DISTINCT를 붙인 것입니다.물론 결과는 원하는 대로 나올 수 있습니다.하지만 왜 ..
MySQL BETWEEN과 범위 검색 제대로 이해하기 - 인덱스는 어떻게 범위를 찾을까? MySQL에서 특정 기간의 데이터를 조회할 때 다음과 같은 SQL을 자주 사용합니다.SELECT *FROM ordersWHERE created_at BETWEEN '2026-08-01' AND '2026-08-31';문법도 간단하고 읽기도 쉽습니다.그런데 한 가지 궁금한 점이 생깁니다.BETWEEN은 실제로 어떻게 데이터를 찾을까요?그리고 다음 조건은WHERE created_at BETWEEN ...다음과 어떤 차이가 있을까요?WHERE created_at >= ... AND created_at 더 중요한 것은 created_at에 인덱스가 있다면 MySQL은 이 범위를 인덱스에서 어떻게 찾느냐는 것입니다.이번 글에서는 BETWEEN 자체의 문법만 설명하는 것이 아니라 범위 조건이 B-Tree 인덱스에..
MySQL 함수 때문에 인덱스를 못 타는 경우 - WHERE 조건을 어떻게 작성해야 할까? MySQL에서 날짜를 검색하다 보면 이런 쿼리를 자주 작성하게 됩니다.SELECT *FROM ordersWHERE DATE(created_at) = '2026-08-31';의미는 명확합니다.created_at에서 날짜 부분만 가져와서 2026-08-31인지 확인하는 것입니다.그런데 created_at에 인덱스가 있다면 어떨까요?CREATE INDEX idx_orders_created_atON orders (created_at);인덱스까지 만들어 놨는데도 쿼리가 기대만큼 빨라지지 않는 경우가 있습니다.왜 그럴까요?핵심은 WHERE 조건에서 컬럼에 함수를 적용하고 있다는 것입니다.이번 글에서는 실제 SQL을 통해 다음 두 가지 조건을 비교해보겠습니다.WHERE DATE(created_at) = '2026-0..