return new Story();

맥북 아이폰 복사 붙여넣기 안 될 때 해결방법

Parse — Mon, 30 Mar 2026 20:08:32 +0900

맥↔아이폰 복사 붙여넣기 안 될 때 터미널 명령어 한 줄로 해결 (Universal Clipboard)

Handoff 켜져 있고, Wi-Fi·Bluetooth 정상인데도 맥-아이폰 간 복붙이 안 된다면 이 글이 답입니다.

증상

맥에서 복사한 텍스트가 아이폰에서 붙여넣기 안 됨
아이폰에서 복사한 내용이 맥에서 안 나옴
같은 Apple ID, 같은 Wi-Fi, Bluetooth ON, Handoff ON — 전부 정상인데 안 됨
"유니버설 클립보드" 자체가 죽어 있는 느낌

구글링하면 다 똑같은 해결법만 나옵니다. 저도 전부 따라해봤습니다.

심지어 AI한테 물었는데도 같은 답변만 반복합니다.

구글링해서 나오는 방법, 다 해봤습니다

1. Handoff 껐다 켜기

맥: 시스템 설정 → 일반 → AirDrop 및 Handoff → Handoff 끄고 → 10초 기다렸다가 → 다시 켜기

아이폰: 설정 → 일반 → AirPlay 및 Handoff → 똑같이 껐다 켜기

→ ❌ 안 됨

2. Bluetooth 껐다 켜기

양쪽 기기 Bluetooth 끄고 → 30초 기다렸다가 → 다시 켜기

→ ❌ 안 됨

3. Wi-Fi 껐다 켜기

혹시 Wi-Fi 문제인가 싶어서 양쪽 다 껐다 켜봄

→ ❌ 안 됨

4. iCloud 로그아웃 후 재로그인

맥에서 Apple ID 로그아웃하고 다시 로그인. 아이폰도 마찬가지.

→ ❌ 시간만 오래 걸리고 안 됨

5. 양쪽 기기 재부팅

맥 재시작, 아이폰 전원 껐다 켜기

→ ❌ 안 됨

여기까지 하면 보통 "아 그냥 에어드롭 쓰자..." 하고 포기하게 됩니다.

근데 터미널 명령어 2줄로 해결됐습니다.

진짜 해결법: 터미널 명령어 2줄

맥에서 터미널(Terminal.app)을 열고 아래 두 줄을 순서대로 실행합니다.

defaults delete ~/Library/Preferences/com.apple.coreservices.useractivityd.plist ClipboardSharingEnabled

defaults write ~/Library/Preferences/com.apple.coreservices.useractivityd.plist ClipboardSharingEnabled 1

끝입니다. 재시작 없이 바로 적용됩니다.

실행 후 맥에서 아무 텍스트나 복사(⌘+C)하고 아이폰에서 붙여넣기 해보세요.

이게 왜 되는 건가요?

useractivityd는 macOS에서 Handoff, Universal Clipboard 등을 담당하는 백그라운드 데몬(daemon)입니다.

이 데몬이 참조하는 plist(설정 파일)에 ClipboardSharingEnabled 값이 있는데, macOS 업데이트나 설정 충돌 등으로 이 값이 꼬이는 경우가 있습니다.

명령어 하는 일

defaults delete ... ClipboardSharingEnabled	기존의 꼬인 설정값을 삭제
defaults write ... ClipboardSharingEnabled 1	클립보드 공유를 활성화(1)로 새로 설정

시스템 설정 UI에서는 Handoff가 "켜짐"으로 보여도, 이 plist 값은 별도로 관리되기 때문에 UI상으로는 확인이 안 됩니다.

그래도 안 된다면 — 기본 체크리스트

위 명령어로 해결 안 되는 경우, 기본 조건이 안 맞는 건 아닌지 확인해보세요.

1. 같은 Apple ID인지 확인

맥: 시스템 설정 → Apple ID
아이폰: 설정 → 맨 위 프로필

2. Handoff 켜져 있는지 확인

맥: 시스템 설정 → 일반 → AirDrop 및 Handoff
아이폰: 설정 → 일반 → AirPlay 및 Handoff

3. Wi-Fi & Bluetooth 둘 다 ON

유니버설 클립보드는 Bluetooth로 기기를 인식하고, Wi-Fi로 데이터를 전송합니다
두 기기가 물리적으로 가까이 있어야 합니다

4. 양쪽 재부팅

단순하지만 효과적입니다

테스트 환경

macOS 26.3.1
iPhone (최신 iOS)
동일 iCloud 계정, 동일 Wi-Fi

마무리

"분명히 다 켜져 있는데 왜 안 되지?"라는 상황이라면, 십중팔구 useractivityd의 plist 설정이 꼬인 겁니다.

터미널 명령어 2줄이면 해결되니 한번 시도해보세요.

SSE | 실시간 결제 알림 시스템 개발기 (3) - SSE와 LoggingFilter 충돌 해결기

Parse — Sun, 18 Jan 2026 10:30:51 +0900

들어가며

이전 글에서는 로드밸런싱 환경에서의 문제를 Redis Pub/Sub으로 해결한 과정을 다뤘습니다. 기술적으로는 완성된 것처럼 보였지만, 실제 배포 전 테스트 환경에서 예상치 못한 문제가 발생했습니다.

SSE 연결은 성공하는데, 거래 알림이 제대로 전달되지 않거나 연결이 비정상적으로 종료되는 현상이었습니다. 로그를 확인해보니 사내에서 공통으로 사용하는 LoggingFilter가 원인이었습니다.

이번 글에서는 SSE와 LoggingFilter의 충돌 원인, 해결 과정, 그리고 그 과정에서의 기술적 고민을 공유합니다.

문제 발견

증상

테스트 환경에 배포 후 다음과 같은 문제들이 발생했습니다:

1. SSE 연결은 성공하지만 메시지가 전달되지 않음
2. 연결이 예상보다 빨리 종료됨
3. 간헐적으로 500 에러 발생

원인 분석

문제의 원인은 사내 공통 라이브러리의 LoggingFilter였습니다.

일반적인 HTTP 요청-응답 사이클은 이렇습니다:

Request → Filter → Controller → Response → Filter → Client
           ↑_____ 여기서 로깅 _____↑

LoggingFilter는 요청과 응답을 가로채서 로그를 남기는데, 이 과정에서:

Request body를 읽어서 로깅
Response body를 읽어서 로깅
연결 종료

그런데 SSE는 다릅니다:

Request → Filter → Controller → [Connection Held Open]
                                        ↓
                                   [Streaming...]
                                        ↓
                                   [Event 1, 2, 3...]
                                        ↓
                                   [Still Open...]

SSE는 연결을 계속 유지하면서 스트리밍 방식으로 데이터를 전송합니다. 하지만 LoggingFilter는:

Response를 즉시 읽으려고 시도 → SSE는 아직 데이터를 보내지 않았음
Connection을 빨리 종료 → SSE 스트림이 끊김
Buffering 시도 → 메모리 문제 발생 가능

해결 방안 검토

사내 공통 라이브러리는 여러 프로젝트에서 사용 중이므로 직접 수정할 수 없었습니다. 그래서 우회 방법을 찾아야 했습니다.

시도 1: URL 패턴 제외 (실패)

처음에는 Filter 등록 시 URL 패턴으로 제외하려고 했습니다.

java

@Bean
public FilterRegistrationBean<LoggingFilter> loggingFilter() {
    FilterRegistrationBean<LoggingFilter> registration = 
        new FilterRegistrationBean<>();
    
    registration.setFilter(loggingFilter);
    registration.addUrlPatterns("/*");
    // SSE 경로 제외 시도
    registration.addInitParameter("excludePattern", "/api/notifications/subscribe/*");
    
    return registration;
}

문제점: 사내 라이브러리의 LoggingFilter가 이미 @Component로 자동 등록되어 있었고, 제외 패턴 기능을 지원하지 않았습니다.

시도 2: Filter Order 조정 (부분적 성공)

SSE 요청만 먼저 처리하는 Filter를 추가했습니다.

java

@Component
@Order(Ordered.HIGHEST_PRECEDENCE)
public class SseBypassFilter extends OncePerRequestFilter {
    
    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                   HttpServletResponse response,
                                   FilterChain filterChain) {
        String uri = request.getRequestURI();
        
        if (uri.contains("/subscribe")) {
            request.setAttribute("SKIP_LOGGING", true);
        }
        
        filterChain.doFilter(request, response);
    }
}

문제점: LoggingFilter가 SKIP_LOGGING 플래그를 체크하지 않았습니다. 사내 라이브러리를 수정할 수 없으므로 이 방법도 실패했습니다.

최종 해결: @Primary로 Bean 재정의

결국 @Primary 어노테이션을 사용하여 LoggingFilter를 재정의하는 방식으로 해결했습니다.

구현

LoggingFilter 래핑

java

@Configuration
public class FilterConfig {
    
    @Primary
    @Bean
    public OncePerRequestFilter customLoggingFilter(
            @Qualifier("loggingFilter") OncePerRequestFilter originalFilter) {
        
        return new OncePerRequestFilter() {
            
            @Override
            protected void doFilterInternal(
                    HttpServletRequest request,
                    HttpServletResponse response,
                    FilterChain filterChain) throws ServletException, IOException {
                
                // SSE 요청인지 확인
                if (isSseRequest(request)) {
                    // SSE는 원본 필터를 거치지 않고 바로 통과
                    filterChain.doFilter(request, response);
                    return;
                }
                
                // 일반 요청은 원본 로깅 필터 실행
                originalFilter.doFilter(request, response, filterChain);
            }
            
            private boolean isSseRequest(HttpServletRequest request) {
                String uri = request.getRequestURI();
                String accept = request.getHeader("Accept");
                
                // URL 패턴으로 확인
                if (uri.contains("/api/notifications/subscribe")) {
                    return true;
                }
                
                // Accept 헤더로 확인
                if (accept != null && accept.contains("text/event-stream")) {
                    return true;
                }
                
                return false;
            }
        };
    }
}

동작 원리

@Primary 어노테이션은 같은 타입의 Bean이 여러 개 있을 때 우선순위를 지정합니다.

[Before]
Application → LoggingFilter (사내 라이브러리) → Controller

[After]  
Application → CustomLoggingFilter (@Primary) → Controller
                      ↓
              SSE 요청? 
                ↙        ↘
             Yes          No
              ↓            ↓
          바로 통과    원본 Filter 실행

이 방식의 장점:

사내 라이브러리 코드 수정 불필요
기존 로깅 기능 유지 (일반 요청은 그대로)
SSE만 선택적으로 우회 가능

더 나은 대안은 없었을까?

프로젝트를 완료한 후, 더 나은 해결 방법은 없었는지 고민해봤습니다.

사내 라이브러리 팀에 개선 요청

가장 근본적인 해결책입니다.

java

// 사내 라이브러리에 추가 요청할 기능
@Component
public class LoggingFilter extends OncePerRequestFilter {
    
    @Value("${logging.filter.exclude-patterns:}")
    private String[] excludePatterns;
    
    @Override
    protected void doFilterInternal(...) {
        if (shouldSkip(request)) {
            filterChain.doFilter(request, response);
            return;
        }
        // 로깅 로직...
    }
    
    private boolean shouldSkip(HttpServletRequest request) {
        String uri = request.getRequestURI();
        
        for (String pattern : excludePatterns) {
            if (uri.matches(pattern)) {
                return true;
            }
        }
        
        return false;
    }
}

그러면 설정 파일에서 간단하게 제외할 수 있습니다:

yaml

logging:
  filter:
    exclude-patterns:
      - "/api/notifications/subscribe/.*"
      - "/api/streaming/.*"

장점:

모든 프로젝트에서 활용 가능
깔끔한 설정 기반 제어
유지보수성 향상

단점:

라이브러리 팀의 승인 및 배포 시간 필요
다른 팀의 일정에 의존

실무에서의 트레이드오프

우리가 선택한 이유

결국 @Primary 방식을 선택한 이유는:

시간 제약: 프로젝트 일정이 촉박했음
최소 영향: 기존 시스템에 영향 없이 빠르게 해결
실용성: 완벽하지 않지만 요구사항은 충족

기술 부채 관리

하지만 이 방식은 기술 부채를 남깁니다:

문제점:

사내 라이브러리 업데이트 시 동작 보장 안 됨
다른 개발자가 원본 Filter가 동작한다고 착각 가능
암묵적인 오버라이드로 디버깅 어려움

대응 방안:

코드 리뷰와 문서에 명확히 기록하고, 백로그에 개선 작업을 등록했습니다.

배운 점

1. 레거시 시스템과의 통합

모든 프로젝트가 그린필드는 아닙니다. 기존 시스템, 공통 라이브러리와의 충돌은 실무에서 흔한 일입니다.

완벽한 해결책을 고집하기보다, 현실적인 제약 속에서 최선의 선택을 하는 것이 중요합니다.

2. 문서화의 중요성

임시 해결책일수록 명확한 문서화가 필수입니다:

왜 이렇게 구현했는지
어떤 제약사항이 있었는지
향후 개선 방향은 무엇인지

6개월 후 다른 개발자(혹은 미래의 나)가 코드를 볼 때를 대비해야 합니다.

3. 기술 부채 관리

기술 부채는 나쁜 것이 아닙니다. 중요한 것은:

부채를 인지하고 있는가
부채를 관리하고 있는가
적절한 시점에 상환 계획이 있는가

우리는 백로그에 개선 작업을 등록하고, 사내 라이브러리 팀에 feature request를 제출했습니다.

마치며

실시간 결제 알림 시스템을 구축하면서 많은 것을 배웠습니다:

SSE vs WebSocket: 요구사항에 맞는 기술 선택의 중요성
분산 환경: 단일 서버와는 다른 고민과 해결책
레거시 통합: 현실적 제약 속에서의 의사결정
기술 부채: 인지하고 관리하는 자세

완벽한 시스템은 없습니다. 중요한 것은 비즈니스 요구사항을 만족시키면서, 기술적 품질과 현실적 제약 사이의 균형을 찾는 것입니다.

이 시리즈가 실시간 통신 시스템을 구축하거나, 분산 환경에서의 문제를 해결하는 분들에게 도움이 되길 바랍니다.

후속 개선 계획

프로젝트는 완료되었지만, 개선할 부분들이 남아있습니다:

SSE 재연결 처리: Last-Event-ID를 활용한 메시지 재전송
Circuit Breaker 패턴: Redis 장애 시 자동 복구
사내 라이브러리 개선: 공통 LoggingFilter에 exclude 기능 추가
성능 최적화: 대규모 동시 접속 시 메모리 사용량 개선

기술 부채를 인지하고 있으며, 우선순위에 따라 하나씩 개선해 나갈 예정입니다.

SSE | 실시간 결제 알림 시스템 개발기 (2) - 로드밸런싱 환경에서의 문제와 Redis Pub/Sub 해결

Parse — Sat, 17 Jan 2026 10:00:01 +0900

시작하며

이전 글에서는 SSE를 선택한 이유와 기본 구현 방법을 다뤘습니다. 단일 서버 환경에서는 모든 것이 완벽하게 동작했지만, 실제 운영 환경은 달랐습니다. 로드밸런서 뒤에 여러 서버 인스턴스가 배포된 환경에서 예상치 못한 문제가 발생했습니다.

이번 글에서는 분산 환경에서 마주한 문제와 Redis Pub/Sub을 활용한 해결 과정을 공유합니다.

로드밸런싱(다중서버) 환경에서 발견한 문제

문제 상황

운영 환경은 다음과 같은 구조였습니다:

              [Load Balancer]
                    |
        +-----------+-----------+
        |                       |
   [Server A]            [Server B]
        |                       |
        +----------+------------+
                   |
            [RabbitMQ]

두 대의 서버가 로드밸런서 뒤에서 동작하고, 하나의 RabbitMQ 인스턴스를 공유하는 구조였습니다.

문제는 이렇게 발생했습니다:

가맹점주가 Server A에 SSE로 연결됨
고객이 결제를 완료
RabbitMQ에 거래 메시지가 발행됨
Server B의 리스너가 메시지를 소비
Server B는 자신에게 연결된 클라이언트를 찾지만, 가맹점주는 Server A에 연결되어 있음
가맹점주는 거래 알림을 받지 못함

왜 이런 일이?

RabbitMQ의 기본 동작 방식 때문입니다. 여러 컨슈머가 같은 큐를 구독하면 라운드로빈 방식으로 메시지를 분배합니다. 즉, 메시지가 Server A와 Server B에 번갈아가며 전달되는데, 클라이언트가 어느 서버에 연결되어 있는지는 고려하지 않습니다.

거래 1: RabbitMQ → Server A (가맹점주는 Server B 연결) ❌
거래 2: RabbitMQ → Server B (가맹점주는 Server B 연결) ✅
거래 3: RabbitMQ → Server A (가맹점주는 Server B 연결) ❌

결과적으로 거래의 절반 정도만 가맹점주에게 전달되는 심각한 문제였습니다.

해결 방안 검토

이 문제를 해결하기 위해 여러 방안을 고민했습니다.

1. Sticky Session (검토 후 제외)

로드밸런서에서 특정 클라이언트를 항상 같은 서버로 라우팅하는 방식입니다.

문제점:

해당 서버가 재시작되면 모든 연결이 끊김
서버 간 부하 분산이 불균형해질 수 있음
RabbitMQ 메시지가 여전히 라운드로빈으로 분배됨

2. RabbitMQ Fanout Exchange (검토 후 제외)

모든 서버에 메시지를 브로드캐스트하는 방식입니다.

문제점:

각 서버가 별도의 큐를 가져야 함
기존에 있던 Exchange를 활용하는 것을 목표로 함
메시지가 중복 처리될 수 있음
RabbitMQ 구조를 변경해야 함 (기존 시스템과의 호환성)

3. Redis Pub/Sub (채택!)

RabbitMQ에서 받은 메시지를 Redis Pub/Sub으로 재전송하여 모든 서버에 브로드캐스트하는 방식입니다.

장점:

기존 RabbitMQ 구조 변경 불필요
모든 서버가 메시지를 받을 수 있음
Redis는 이미 캐시용으로 사용 중이었음
구현이 비교적 간단함

Redis Pub/Sub 구현

아키텍처 변경

[고객 결제]
     ↓
[결제 시스템]
     ↓
[RabbitMQ Queue]
     ↓
[Server A or B가 메시지 수신]
     ↓
[Redis Pub/Sub으로 재전송] ← 핵심 변경점
     ↓
[모든 서버가 Subscribe하여 수신]
     ↓
[각 서버가 자신의 SSE 클라이언트에게 전달]

이제 RabbitMQ에서 어느 서버가 메시지를 받든, Redis Pub/Sub을 통해 모든 서버에 전달됩니다.

Redis 설정

java

@Configuration
public class RedisConfig {
    
    @Bean
    public RedisMessageListenerContainer redisMessageListenerContainer(
            RedisConnectionFactory connectionFactory,
            MessageListenerAdapter listenerAdapter) {
        
        RedisMessageListenerContainer container = new RedisMessageListenerContainer();
        container.setConnectionFactory(connectionFactory);
        container.addMessageListener(listenerAdapter, 
            new PatternTopic("transaction.*"));
        
        return container;
    }
    
    @Bean
    public MessageListenerAdapter listenerAdapter(
            RedisSubscriber subscriber) {
        return new MessageListenerAdapter(subscriber, "onMessage");
    }
    
    @Bean
    public RedisTemplate<String, Object> redisTemplate(
            RedisConnectionFactory connectionFactory) {
        
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(connectionFactory);
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new Jackson2JsonRedisSerializer<>(Object.class));
        
        return template;
    }
}

RabbitMQ 리스너 수정

RabbitMQ에서 메시지를 받으면 Redis로 재전송하도록 수정했습니다.

java

@Component
public class TransactionQueueListener {
    
    private final RedisTemplate<String, Object> redisTemplate;
    
    @RabbitListener(queues = "transaction.queue")
    public void handleTransaction(TransactionMessage message) {
        // Redis Pub/Sub으로 브로드캐스트
        String channel = "transaction." + message.getMerchantId();
        redisTemplate.convertAndSend(channel, message);
        
        log.info("Published transaction to Redis: merchantId={}, txId={}", 
            message.getMerchantId(), message.getTransactionId());
    }
}

Redis Subscriber 구현

모든 서버는 Redis 채널을 구독하여 메시지를 수신합니다.

java

@Component
@Slf4j
public class RedisSubscriber {
    
    private final ObjectMapper objectMapper;
    private final TransactionNotificationService notificationService;
    
    public void onMessage(String message, String pattern) {
        try {
            TransactionMessage transaction = 
                objectMapper.readValue(message, TransactionMessage.class);
            
            String merchantId = transaction.getMerchantId();
            
            log.info("Received transaction from Redis: merchantId={}, txId={}", 
                merchantId, transaction.getTransactionId());
            
            // 해당 가맹점에 연결된 SSE 클라이언트에게 전송
            notificationService.sendToMerchant(merchantId, transaction);
            
        } catch (JsonProcessingException e) {
            log.error("Failed to parse transaction message", e);
        }
    }
}

ConcurrentHashMap으로 가맹점별 필터링

각 서버는 자신에게 연결된 클라이언트 정보만 ConcurrentHashMap에 저장하고 있습니다.

java

@Service
@Slf4j
public class TransactionNotificationService {
    
    // 가맹점 ID → SSE Emitter 리스트 매핑
    private final ConcurrentHashMap<String, List<SseEmitter>> emitters = 
        new ConcurrentHashMap<>();
    
    public void sendToMerchant(String merchantId, TransactionMessage message) {
        List<SseEmitter> merchantEmitters = emitters.get(merchantId);
        
        // 이 서버에 해당 가맹점이 연결되어 있지 않으면 무시
        if (merchantEmitters == null || merchantEmitters.isEmpty()) {
            log.debug("No emitters found for merchant: {}", merchantId);
            return;
        }
        
        log.info("Sending to {} emitters for merchant: {}", 
            merchantEmitters.size(), merchantId);
        
        List<SseEmitter> deadEmitters = new ArrayList<>();
        
        for (SseEmitter emitter : merchantEmitters) {
            try {
                emitter.send(SseEmitter.event()
                    .name("transaction")
                    .data(message));
                    
                log.debug("Successfully sent transaction to emitter");
                
            } catch (IOException e) {
                log.warn("Failed to send to emitter, marking as dead", e);
                deadEmitters.add(emitter);
            }
        }
        
        // 전송 실패한 emitter 제거
        deadEmitters.forEach(emitter -> removeEmitter(merchantId, emitter));
    }
    
    // subscribe, removeEmitter 메서드는 1편과 동일
}

테스트 및 검증

로컬 테스트

로드밸런서 없이 두 개의 서버 인스턴스를 직접 실행하여 테스트했습니다:

bash

# Server 1
java -jar merchantApp.jar --server.port=8081

# Server 2
java -jar merchantApp.jar --server.port=8082

그리고 각 포트로 번갈아가며 SSE를 연결한 뒤, RabbitMQ에 메시지를 발행하여 모든 경우에 정상 동작하는지 확인했습니다.

결과는 성공적이었습니다. Redis Pub/Sub의 성능도 충분했고, 메시지 유실 없이 안정적으로 동작했습니다.

고려사항 및 트레이드오프

Redis Pub/Sub의 특징

장점:

매우 빠른 메시지 전달 (밀리초 단위)
간단한 구현
수평 확장 가능 (서버를 추가해도 동일하게 동작)

단점:

메시지 지속성 없음: Redis가 다운되면 메시지 유실 가능
구독자가 없으면 메시지 버려짐: 모든 서버가 다운된 상태에서 발행된 메시지는 사라짐

왜 이 트레이드오프를 수용했나?

거래내역 조회 기능 존재: 가맹점 포털에서 언제든지 거래내역을 조회할 수 있음
실시간 알림은 부가 기능: 실시간으로 못 받아도 조회하면 되므로 치명적이지 않음
사내 모니터링 알림: Redis 장애 시 즉시 감지하고 대응 가능
구현 복잡도 vs 비즈니스 가치: 완벽한 메시지 보장보다 빠른 출시가 우선

실무에서는 이런 비즈니스 요구사항과 기술적 완성도 사이의 균형을 찾는 것이 중요합니다.

마치며

로드밸런싱 환경에서의 실시간 통신은 단일 서버와 완전히 다른 접근이 필요합니다. 이번 프로젝트를 통해 분산 시스템의 특성과 메시지 브로드캐스팅의 중요성을 경험할 수 있었습니다.

Redis Pub/Sub은 완벽한 해결책은 아니지만, 우리 프로젝트의 요구사항과 제약사항을 고려했을 때 가장 실용적인 선택이었습니다.

하지만 구현 과정에서 또 다른 문제가 있었습니다. 사내에서 공통으로 사용하는 LoggingFilter가 SSE와 충돌하는 문제였죠.

다음 글에서는 LoggingFilter 충돌 문제와 그 해결 과정, 그리고 기술 부채에 대한 고민을 다루겠습니다.

SSE | 실시간 결제 알림 시스템 개발기 (1) - SSE vs WebSocket 선택 과정

Parse — Fri, 16 Jan 2026 17:54:47 +0900

시작하며

최근 가맹점 결제 시스템에 실시간 알림 기능을 구현하는 프로젝트를 진행했습니다. 가맹점주가 상품과 가격을 설정하여 QR 코드를 생성하면, 고객이 해당 QR 코드를 스캔하여 결제를 진행하고, 결제가 완료되는 즉시 가맹점주의 화면에 거래내역이 실시간으로 표시되는 시스템입니다.

이 글에서는 실시간 통신 기술 선택 과정과 초기 구현 방법에 대해 공유하려고 합니다.

프로젝트 요구사항

프로젝트의 핵심 요구사항은 다음과 같았습니다:

가맹점주가 상품명과 가격을 입력하여 결제용 QR 코드 생성
고객이 QR 코드를 스캔하여 결제 진행
결제 완료 시 가맹점주 화면에 실시간으로 거래내역 표시
거래내역은 RabbitMQ를 통해 전달됨

중요한 점은 서버에서 클라이언트로의 단방향 데이터 전송만 필요했다는 것입니다. 가맹점주는 거래내역을 받기만 하면 되고, 별도로 서버에 데이터를 전송할 필요가 없었습니다.

SSE vs WebSocket 비교

실시간 통신을 구현하기 위해 두 가지 주요 기술을 검토했습니다.

WebSocket의 특징

장점:

양방향 통신 지원
실시간성이 매우 뛰어남
클라이언트와 서버 간 지속적인 상호작용이 필요한 경우 적합 (채팅, 게임 등)

단점:

양방향 연결 유지로 인한 리소스 사용
구현 복잡도가 상대적으로 높음
HTTP가 아닌 별도 프로토콜 사용

SSE(Server-Sent Events)의 특징

장점:

HTTP 기반으로 구현이 간단함
서버에서 클라이언트로의 단방향 통신에 최적화
자동 재연결 기능 내장
EventSource API로 클라이언트 구현이 간단함

단점:

단방향 통신만 가능
HTTP/1.1에서는 브라우저당 연결 수 제한 (6~8개)

SSE 선택 이유

우리 프로젝트의 요구사항을 분석한 결과, SSE가 더 적합하다고 판단했습니다.

1. 단방향 통신으로 충분

가맹점주는 결제 완료 알림을 받기만 하면 됩니다. 실시간으로 서버에 데이터를 보낼 필요가 없었기 때문에 양방향 통신 기능은 불필요했습니다.

고객 결제 → 결제 시스템 → RabbitMQ → 서버 → [SSE] → 가맹점주 화면

만약 WebSocket을 사용했다면, 사용하지도 않을 클라이언트→서버 채널을 위해 추가 리소스를 소비하게 됩니다.

2. 구현 복잡도

SSE는 HTTP 기반이기 때문에 기존 인프라와의 통합이 쉬웠습니다. 별도의 프로토콜 핸들러나 복잡한 설정 없이 Spring의 SseEmitter만으로 간단하게 구현할 수 있었습니다.

3. 리소스 효율성

양방향 연결을 유지하는 것은 서버 리소스 측면에서 오버헤드입니다. 우리 시스템에서는 거래가 발생할 때만 데이터를 전송하면 되므로, SSE의 단방향 특성이 더 효율적이었습니다.

기본 구현

서버 사이드 - SSE Emitter 관리

java

@Service
public class TransactionNotificationService {
    
    // 가맹점별로 SSE 연결 관리
    private final ConcurrentHashMap<String, List<SseEmitter>> emitters = 
        new ConcurrentHashMap<>();
    
    public SseEmitter subscribe(String merchantId) {
        SseEmitter emitter = new SseEmitter(Long.MAX_VALUE);
        
        // 가맹점 ID별로 emitter 저장
        emitters.computeIfAbsent(merchantId, k -> new CopyOnWriteArrayList<>())
                .add(emitter);
        
        // 연결 종료 시 정리
        emitter.onCompletion(() -> removeEmitter(merchantId, emitter));
        emitter.onTimeout(() -> removeEmitter(merchantId, emitter));
        emitter.onError(e -> removeEmitter(merchantId, emitter));
        
        return emitter;
    }
    
    private void removeEmitter(String merchantId, SseEmitter emitter) {
        List<SseEmitter> merchantEmitters = emitters.get(merchantId);
        if (merchantEmitters != null) {
            merchantEmitters.remove(emitter);
            if (merchantEmitters.isEmpty()) {
                emitters.remove(merchantId);
            }
        }
    }
}

ConcurrentHashMap을 사용한 이유:

멀티스레드 환경에서 안전한 동시성 제어
가맹점 ID를 키로 하여 해당 가맹점에 연결된 모든 클라이언트 관리
여러 탭이나 디바이스에서 동시 접속 가능

RabbitMQ 리스너 - 거래내역 수신

java

@Component
public class TransactionQueueListener {
    
    private final TransactionNotificationService notificationService;
    
    @RabbitListener(queues = "transaction.queue")
    public void handleTransaction(TransactionMessage message) {
        String merchantId = message.getMerchantId();
        
        // 해당 가맹점에 연결된 클라이언트들에게 전송
        notificationService.sendToMerchant(merchantId, message);
    }
}

java

public void sendToMerchant(String merchantId, TransactionMessage message) {
    List<SseEmitter> merchantEmitters = emitters.get(merchantId);
    
    if (merchantEmitters != null) {
        List<SseEmitter> deadEmitters = new ArrayList<>();
        
        for (SseEmitter emitter : merchantEmitters) {
            try {
                emitter.send(SseEmitter.event()
                    .name("transaction")
                    .data(message));
            } catch (IOException e) {
                deadEmitters.add(emitter);
            }
        }
        
        // 전송 실패한 emitter 제거
        deadEmitters.forEach(emitter -> removeEmitter(merchantId, emitter));
    }
}

컨트롤러 - SSE 엔드포인트

java

@RestController
@RequestMapping("/api/notifications")
public class NotificationController {
    
    private final TransactionNotificationService notificationService;
    
    @GetMapping(value = "/subscribe/{merchantId}", 
                produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    public SseEmitter subscribe(@PathVariable String merchantId) {
        return notificationService.subscribe(merchantId);
    }
}

클라이언트 사이드

javascript

// SSE 연결 생성
const eventSource = new EventSource(`/api/notifications/subscribe/${merchantId}`);

// 거래 이벤트 수신
eventSource.addEventListener('transaction', (event) => {
    const transaction = JSON.parse(event.data);
    
    // 화면에 거래내역 표시
    displayTransaction(transaction);
});

// 연결 에러 처리
eventSource.onerror = (error) => {
    console.error('SSE connection error:', error);
};

클라이언트 구현이 매우 간단합니다. EventSource API는 자동 재연결 기능까지 제공하여 네트워크 불안정 상황에서도 안정적으로 동작합니다.

단일 서버에서의 동작

초기 개발 단계에서는 단일 서버 환경에서 테스트를 진행했습니다. 이 경우 시스템은 예상대로 완벽하게 동작했습니다:

고객이 QR 코드로 결제
결제 시스템에서 RabbitMQ에 거래 메시지 발행
서버의 RabbitMQ 리스너가 메시지 수신
해당 가맹점 ID에 연결된 SSE Emitter를 찾아 전송
가맹점주 화면에 실시간으로 거래내역 표시

모든 컴포넌트가 같은 서버에 있기 때문에 메시지 전달이 직관적이고 문제가 없었습니다.

마치며

SSE는 서버에서 클라이언트로의 단방향 실시간 통신이 필요한 경우 매우 효과적인 선택입니다. 우리 프로젝트처럼 알림, 피드 업데이트, 실시간 대시보드 등의 사용 사례에서 WebSocket보다 간단하면서도 충분한 성능을 제공합니다.

하지만 이 구현은 단일 서버 환경에서만 완벽하게 동작했습니다. 실제 운영 환경은 로드밸런싱된 다중 서버 구조였고, 이 부분에서는 다른 기술스택에 대한 고려가 필요했습니다.

다음 글에서는 로드밸런싱 환경에서 발견한 문제와 Redis Pub/Sub을 활용한 해결 과정을 다루겠습니다.

동기부여가 되는 생산성 TO-DO앱은 없을까?

Parse — Fri, 15 Aug 2025 13:42:31 +0900

ToDoker 프로토타입 메인 화면

나는 왜 생산형 TO-DO앱 ToDoker를 개발하는가?

생산형 TO-DO 앱에 대한 개발 의지의 시작

제일 처음 생산형 TO-DO 앱에 대한 개발 의지는 자주 사용하던 앱인 Things 3에서 TO-DO를 체크하면 사라져서 성취감을 느끼기 쉽지 않았던 것에서 시작됐다.

나는 현재 웹페이지를 어느 정도 읽었는지 퍼센테이지로 알려주는 Read-Tracker라는 크롬 확장프로그램을 만들 정도로, 내가 어느 정도 진행했고 성취했는가를 시각적으로 보고 고양되는 타입이다. 이 부분은 사소해 보이지만 다음 스텝으로 나가기 위한 사기 상승과 동기부여에 정말 중요하다.

Things 3에서 체크했던 To-Do들이 남아있어서 현재 프로젝트나 오늘 일정을 얼마나 진행했는지 파악하고 싶었다. Things 3를 사용했던 이유는 예쁘고 직관적인 사용성에 있었는데, 여기에 내 니즈가 추가된다면 완벽할 것 같아서 프로젝트를 시작하게 됐다.

그동안 망설였던 이유들

사실 이런 아쉬움은 꽤 오래됐지만, 망설였던 이유가 있었다. 전체 프로젝트를 진행하려면 팀을 꾸리거나 1인 개발로서 전체 개발과 기획, 마케팅을 진행해야 하는데 그 부담감이 컸다.

하지만 Claude Code와 각종 AI Agent들, 그리고 MCP(Model Context Protocol) 가 나오면서 가능성을 봤다. AI가 실제로 개발 파트너가 될 수 있다는 확신이 섰고, 그래서 ToDoker 프로젝트를 본격적으로 시작하게 됐다.

혼자서도 할 수 있다는 자신감, 그것이 이 프로젝트의 출발점이었다.

ToDoker의 3가지 핵심

프로젝트를 시작하면서 명확히 한 3가지 핵심 가치가 있다.

1. 디자인이 예뻐야 한다

평소에 개인적인 디자인 취향이 확고한 편이어서, 대중적인 디자인으로 어필하지 못할 것을 고민했다. 그래서 타협안으로 사용자가 직접 색상을 커스텀할 수 있는 기능을 넣었다. 적어도 색상 때문에 앱 사용이 싫어지는 일은 없어지지 않을까?

하지만 색상 커스터마이징 기능을 구현하면서도 새로운 고민들이 생겼다. 너무 많은 선택지가 오히려 사용자를 혼란스럽게 하지 않을까? 기존 디자인 요소들의 색상들을 커스텀된 색상에 맞춰 변경시켜주는 부분은 오버엔지니어링이 아닐까 등, 이 부분은 다음 블로그 글을 통해에 더 자세히 적어보려 한다.

2. 사용하기 편해야 한다

기능이 직관적이어야 한다는 건 다년간 웹 개발을 하며 몸소 느꼈던 바이다. 많은 기능들과 친절한 문구들로 작업해도 사용자들은 이해하지 못한다. 사용자들은 그리 자비롭지 않다. 직관적인 동작들로 사용자들에게 편의성을 제공해야 한다.

인간의 본성을 이해하는 것이 좋은 UX의 시작이라고 생각한다. 네덜란드 스히폴 공항에서 남자 화장실 변기에 파리 모양 스티커를 붙였더니 소변이 80% 더 정확하게 들어갔다는 유명한 사례가 있다. 사람들은 자연스럽게 목표물을 맞추려고 하는 본능이 있다는 것이다.

마찬가지로 ToDoker에서도 사용자가 자연스럽게 원하는 행동을 하도록 설계하고 있다. 드래그 앤 드롭으로 할 일을 카테고리 간에 이동시키거나, 체크로 완료 처리를 하는 것들이 그런 예시다.

3. 의지를 북돋아줘야 한다

이 부분이 기존 TO-DO 앱과의 차별성을 가질 수 있는 핵심이라고 생각한다. 핵심 기능은 AI를 통한 인사이트와 로그(통계) 기능이다.

사용자는 자신이 기록했던 TO-DO들을 통해서 달성을 어느 정도 했고, 앞으로 어떻게 진행해야 할지 AI를 통해 생각이 정리되는 경험을 하게 될 것이다. 그리고 Suggest 기능을 통해서 앞으로 할 일들에 대해서 추천을 받기도 한다.

예를 들어, "지난주에 비해 업무 관련 할 일 완료율이 20% 증가했네요. 할 일 목록을 보니 지난 주에 비해 조금 벅차 보이지만, 걱정하지 마세요. 지금부터 차근차근 하나씩 해결해 나가면 충분히 해낼 수 있습니다."와 같은 개인화된 조언을 받게 된다.

이러한 과정은 사용자들에게 동기가 되고, 성공적인 인생을 살아가는 데 조금이나마 도움이 되지 않을까 생각한다.

데이터로 확인하는 성장, 그것만큼 확실한 동기부여는 없다.

개발 과정에서 느끼는 것들

ToDoker를 개발하면서 가장 재미있는 부분은 내가 만든 앱을 내가 직접 사용하면서 개선점을 찾아가는 과정이다. 개발자이면서 동시에 파워 유저가 되는 경험이랄까.

며칠 전에는 100% 완료율을 달성했을 때 폭죽 애니메이션을 추가했는데, 실제로 내가 그 애니메이션을 보는 순간 정말 뿌듯했다. 이런 작은 성취감들이 쌓여서 더 나은 하루를 만들어간다는 확신이 든다.

또한 AI 기능을 개발하면서 내 자신의 생산성 패턴을 객관적으로 보게 됐다. "아, 내가 월요일에는 계획을 많이 세우지만 실제 실행률은 낮구나", "금요일이 가장 집중력이 떨어지는 시간이구나" 같은 인사이트들을 얻으면서, 이 앱이 정말 도움이 될 수 있겠다는 확신을 갖게 됐다.

앞으로의 여정

ToDoker는 단순한 할 일 관리 앱이 아니라, 개인 생산성의 AI 파트너가 되는 것이 목표다. 혼자 계획을 세우고 실행하는 모든 사람들이 "내가 잘하고 있나?"라는 불안감 대신 "오늘도 한 걸음 성장했네"라는 확신을 가질 수 있도록 돕고 싶다.

이 여정을 블로그를 통해 투명하게 공유하려고 한다. 성공도, 실패도, 그리고 그 과정에서 배우는 모든 것들을. 혼자 개발하지만 혼자가 아닌 기분으로 만들어가고 싶다.

처음부터 완벽할 필요는 없다: 개발자에게 필요한 7가지 마인드셋

Parse — Sun, 6 Jul 2025 13:55:41 +0900

시작하며

개발을 한지 6년차가 되었지만 아직도 완벽함을 추구하여 일을 시작하기를 주저할 때가 있습니다. 좀 더 튼튼한 제품을 만들 수 있었다는 장점은 있었지만, 많은 기회랑 시간이 든다는 점은 모든게 빠르게 바뀌는 현재에서 경쟁력을 갖기는 어렵다고 느꼈습니다. 유튜브 알고리즘을 통해 개발자 마인드셋 관련 영상을 봤는데 자극이되어서 공유하고자 합니다.

유튜브 영상 | It took me 10+ years to realize what I’ll tell you in 8 minutes

프로그래밍을 배우기 시작하면 누구나 한 번쯤은 이렇게 생각합니다.

“다른 개발자들은 다 알고 있는데, 왜 나만 이렇게 모르지?”

하지만 시간이 지나고 현업에 들어서면 깨닫게 됩니다. 정답은, 아무도 다 알지 못한다는 것입니다.

여기, 제가 코딩을 배우고 개발자로 일하면서 얻은 7가지 통찰을 공유합니다.

모든 것을 알 필요는 없다

처음에는 자바스크립트 문법 하나하나를 외우려 했습니다.

하지만 어느 순간 깨달았죠.

진짜 중요한 건 “찾는 법”과 “문제를 해결하는 능력”이다.

기본적인 걸 구글링하는 건 부끄러운 일이 아닙니다.

오히려 검색하고, 시도하고, 깨지는 과정 자체가 개발 그 자체입니다.

‍ 배우는 방법을 먼저 배우세요

튜토리얼만 보고 코딩을 배우려는 초보자들이 많습니다.

하지만 진짜 학습은 ‘소비’가 아닌 ‘창작’ 모드일 때 일어납니다.

“튜토리얼 1시간 = 실습 4시간”
“손가락이 키보드에 닿지 않으면, 뇌는 학습하지 않는다”

듣기만 해서는 언어를 못 배우듯, 코딩도 직접 써봐야 내 것이 됩니다.

완벽주의는 함정이다

한 줄의 변수명을 짓는 데 30분을 썼던 적이 있습니다.

하지만 돌아보면 그 시간은 실수를 두려워한 시간이었습니다.

완벽한 코드보다 작동하는 코드가 더 낫다

엉망이어도 동작하는 코드가, 아예 존재하지 않는 아름다운 코드보다 훨씬 낫습니다.

준비가 안 됐어도, 그냥 시작하세요

“지금은 준비가 안 됐어…”

이 말은 평생을 붙잡을 수 있는 핑계입니다.

자신감은 “준비”해서 생기는 게 아니라, “행동”하면서 생깁니다.

첫 프로젝트? 해보세요.

이력서 제출? 시도하세요.

두려워도 괜찮아요. 일단 해보는 거예요.

진짜 실력은 문제 해결 능력이다

코드를 잘 짜는 사람보다, 문제를 잘 푸는 사람이 실력자입니다.

디버깅은 실패가 아니라, 개발 그 자체입니다.

코딩은 탐정일과 비슷합니다.

단서를 찾아내고, 조합하고, 결국 문제를 해결해내는 일.

구문은 도구일 뿐입니다. 실력은 그 너머에 있습니다.

✨ 아무도 당신의 코드에 관심 없다

현실은 냉정합니다.

아무도 당신의 코드에 관심 없습니다.
코드가 무엇을 “하는지”에만 관심이 있죠.

고객도, 사용자도, 팀 리더도 결과만 봅니다.

깔끔하고 효율적이면 더 좋지만, 그보다 작동하는 코드가 먼저입니다.

허영심보다는 가치, 이게 진짜 개발자의 태도입니다.

번아웃은 현실이다. 당신의 에너지를 보호하세요

진짜 개발자는 24시간 코딩하는 사람이 아닙니다.

그건 비현실적이고, 위험한 신화입니다.

당신의 뇌는 배터리입니다.

잠을 자고, 쉬고, 자연을 느끼며 재충전하세요.

개발은 오래 달리는 마라톤입니다.

에너지를 지키는 것이 실력을 유지하는 비결입니다.

마무리

처음 개발을 시작했을 때는 몰랐지만, 지금은 이렇게 생각합니다.

개발은 “암기 과목”이 아니라 “생존 기술”입니다.
계속 배우고, 시도하고, 성장하면 됩니다.

완벽할 필요는 없습니다.

작동하면 일단 성공입니다.

당신은 잘하고 있습니다.

Java에서 “is”로 시작하는 Boolean 필드 이름 문제

Parse — Wed, 9 Apr 2025 21:37:38 +0900

Java에서 boolean 타입의 필드를 다룰 때 발생할 수 있는, 예상치 못한 문제와 그 해결 방법에 대해 이야기하고자 합니다. 필드 이름이 “is”로 시작할 경우 발생하는 getter와 setter 관련 문제를 중점적으로 다룰 예정입니다.

문제 상황

Java에서는 boolean 타입의 변수에 대한 getter 메소드를 is로 시작하는 이름으로 정의하는 것이 일반적입니다. 예를 들어, active라는 boolean 필드에 대해서는 isActive()라는 메소드를 사용하곤 합니다. 이는 JavaBeans 명세에서도 권장하는 방법입니다. 그런데, 문제는 필드 이름 자체가 isActive, isEnabled 같이 이미 ‘is’로 시작하는 경우가 종종 있다는 것입니다. 이 경우, Java의 일반적인 규칙에 따라 isIsActive(), isIsEnabled()와 같은 형태로 getter 메소드를 기대하게 되는데, 이는 분명 직관적이지 않습니다.

이런 문제는 특히 JSON이나 XML로 객체를 직렬화할 때, 또는 ORM 라이브러리를 사용할 때 자주 발생합니다. 객체의 필드를 자동으로 JSON 필드로 매핑하거나 데이터베이스 테이블에 매핑할 때, 이러한 규칙 때문에 예상치 못한 동작이 발생할 수 있습니다. 실제로 API로 isActive 값을 내려줬을 때, 예상했던 "is" 필드 이름이 아닌 active가 내려왔습니다.

원인 분석

이 문제의 원인은 JavaBeans 명세에서 boolean 필드의 getter가 ‘is’ 접두사를 사용하도록 규정하고 있기 때문입니다. 많은 Java 기반의 프레임워크와 라이브러리는 이 규칙을 따르며, 리플렉션을 통해 메소드 이름을 분석하고 객체를 자동으로 만들어 내곤 합니다. 따라서, 필드 이름이 ‘is’로 시작하는 경우, 이러한 프레임워크나 라이브러리가 올바른 getter나 setter 메소드를 찾지 못하고, 데이터 바인딩에 실패할 수 있습니다.

해결 방법

1. 필드명 변경

가장 간단하고 확실한 해결 방법은 ‘is’로 시작하는 필드 이름을 사용하지 않는 것입니다. 예를 들어, isBoolean 대신 booleanValue나 booleanFlag와 같이 명확하고 혼동이 없는 이름을 사용합니다.

2. 명시적 Getter/Setter 정의 (비추천)

만약 필드 이름을 변경할 수 없는 상황이라면, getter와 setter 메소드를 명시적으로 정의해야 합니다. 이를 통해 프레임워크나 라이브러리가 올바르게 메소드를 인식할 수 있도록 해야 합니다. 일관성과 가독성 측면에서 사용을 지양해야합니다.

public class BooleanExample {
    private boolean isBoolean;

    public boolean getIsBoolean() {
        return isBoolean;
    }

    public void setIsBoolean(boolean isBoolean) {
        this.isBoolean = isBoolean;
    }
}

3. 직렬화 어노테이션 사용

Jackson 같은 라이브러리를 사용할 때는 @JsonProperty 어노테이션을 활용하여 직렬화될 때 사용될 필드명을 직접 지정할 수 있습니다. 이 방법은 필드명과 메소드명 사이의 불일치를 해결하는 데 유용합니다.

public class BooleanExample {
    @JsonProperty("isBoolean")
    private boolean isBoolean;

    public boolean isBoolean() {
        return isBoolean;
    }

    public void setBoolean(boolean isBoolean) {
        this.isBoolean = isBoolean;
    }
}

마무리

이렇게 해서, boolean 필드명이 ‘is’로 시작할 때 발생할 수 있는 문제와 그 해결 방법에 대해 알아보았습니다. 이 포스트가 비슷한 문제를 겪고 계신 분들에게 도움이 되기를 바랍니다.

Read-tracker 크롬 확장프로그램 개발기 - (1)

Parse — Wed, 19 Mar 2025 20:17:44 +0900

Read-tracker 크롬 확장프로그램 개발기 - (1) 개발 배경과 아이디어

크롬 확장 프로그램을 만들게 된 계기

웹 서핑을 하다 보면 긴 글을 읽게 되는 경우가 많습니다. 특히 E-book을 읽을 때처럼 '내가 지금까지 얼마나 읽었고, 앞으로 얼마나 남았는지'를 확인하는 습관이 있다 보니, 웹에서도 같은 기능이 있으면 좋겠다는 생각이 들었습니다.

일부 웹사이트에서는 읽기 진행률을 시각적으로 보여주기도 하지만, 이는 특정 사이트에 한정된 기능이었습니다. 포탈마다 위치가 다르고 일관성이 없기 때문에, 다양한 웹사이트에서 공통적으로 사용할 수 있는 확장 프로그램을 만들고자 했습니다.

또한, 모바일에서는 화면 상단을 터치하면 자동으로 최상단으로 이동하는 기능이 기본 제공되지만, PC에서는 이런 기능이 없어 불편함을 느꼈습니다. 따라서 상단 이동 버튼 기능도 함께 추가하면 보다 편리한 사용자 경험을 제공할 수 있을 것이라 생각했습니다.

아이디어 기획 과정

Read-tracker를 개발하면서 가장 중요하게 고려한 부분은 사용자 경험(UX)과 실용성이었습니다. 따라서 다음과 같은 주요 기능을 구상했습니다.

주요 기능

읽기 진행률 표시: 현재 읽고 있는 위치를 %로 표시하여 가시성을 높임
읽은 시간 및 남은 시간 추정: 사용자의 평균 읽기 속도를 기반으로 남은 시간을 예측하여 제공
상단 이동 버튼: 클릭 한 번으로 페이지 최상단으로 이동하는 기능 추가

UX 고려 요소

크롬 확장 프로그램은 기존 웹페이지 위에 새로운 요소를 추가하기 때문에, 사용자에게 방해가 되지 않도록 UI를 설계해야 했습니다. 특히, 다음과 같은 UX 요소를 고려했습니다:

위치 조정 가능: 일부 웹사이트에서는 추가된 버튼이 기존 UI를 가릴 수 있기 때문에, 사용자가 드래그 앤 드롭으로 버튼 위치를 조정할 수 있도록 함
사이트별 활성화 설정: 특정 포탈에서는 기능이 필요하지 않을 수도 있기 때문에, 별도의 설정 페이지에서 사이트별로 기능을 On/Off할 수 있도록 구현
성취감: 다 읽었으면 축하해주는 이모지를 통해서 축하해해주기.

기술 스택 및 개발 환경

크롬 확장 프로그램을 개발하기 위해 기본적으로 HTML, CSS, JavaScript를 사용했습니다. 개발 도구로는 CursorAI를 활용하여 효율적으로 개발을 진행했습니다.

사용 기술 / 도구

사용기술

HTML / CSS / JavaScript: UI 및 기능 구현
Manifest V3: 보안 강화 및 최신 정책 적용

도구

Cursor : AI 기반 통합 개발 환경(IDE)

Manifest V3를 적용한 이유는 다음과 같습니다:

기존 Manifest V2의 보안 문제 해결
크롬 웹스토어 정책에 맞추어 향후 업데이트 유지보수 용이
백그라운드 스크립트 대신 서비스 워커를 사용하여 성능 최적화

마무리

이렇게 Read Tracker의 초기 아이디어와 개발 배경을 정리했습니다. 다음 2부에서는 실제 개발 과정에 대해 다룰 예정입니다.

기대해주세요!

유용하게 사용 중인 크롬 확장 프로그램 3가지

Parse — Sun, 16 Mar 2025 21:11:10 +0900

Read-tracker

웹 브라우징을 더욱 효율적으로 만들어주는 다양한 크롬 확장 프로그램이 있지만, 개인적으로 가장 유용하게 사용하고 있는 3가지를 정리해보았습니다. 개발자로서 업무 효율을 높이고, 글쓰기 보조 역할을 하며, 직접 개발한 확장 프로그램까지 포함하여 소개해드리겠습니다.

1. Vimium - 키보드만으로 웹 브라우징을 빠르게

F키를 눌러 클릭 가능한 요소를 단축키로 표시

Vimium 다운로드

개발자로서 마우스를 많이 사용하면 손목에 무리가 가는 경우가 많습니다. Vimium은 이러한 불편함을 해결해 주는 좋은 크롬 확장 프로그램 중 하나입니다. 이 확장 프로그램을 사용하면 웹 브라우징을 키보드만으로 컨트롤할 수 있습니다.

✨ 주요 기능

F 키를 누르면 모든 클릭 가능한 요소에 단축키가 표시되어 빠르게 조작 가능
J / K 키로 tab 이동
H / L 키로 뒤로 가기/앞으로 가기
Shift + X 키를 눌러 닫았던 탭을 다시 열기

마우스를 덜 사용하면서도 더욱 빠르고 효율적으로 웹 페이지를 탐색할 수 있어 개발자뿐만 아니라 파워 유저들에게도 추천드릴 만한 확장 프로그램입니다.

2. Grammarly - 영문 글쓰기 보조 AI

텍스트 박스에서 수정이 필요한 영문법 예시를 들어줌

Grammarly 다운로드

영어로 문서를 작성해야 하는 순간에 필수적으로 사용하는 크롬 확장 프로그램입니다. 문법과 철자를 자동으로 검사해 주며, 더 자연스럽고 세련된 표현을 추천해줍니다.

✨ 주요 기능

실시간 문법 및 철자 오류 수정
어휘 개선 및 문장 가독성 향상 제안
다양한 문서 스타일(비즈니스, 학술적 글쓰기 등)에 맞춘 조정 가능
이메일, 문서, 블로그 글 작성 시 자동 적용

영어로 이메일을 작성하거나 블로그 글을 작성할 때 상당히 유용하게 활용할 수 있는 도구로, 영문 작문 능력을 향상시키는 데도 큰 도움이 됩니다.

3. Read-tracker - 웹페이지 읽기 진행률 및 시간 추적

우측 하단에 읽기 진행률을 표시

Read Tracker 다운로드

제가 직접 개발한 크롬 확장 프로그램으로, 웹페이지에서 읽기 진행률을 시각적으로 확인하고 소요 시간을 측정할 수 있도록 제작하였습니다. e-book을 읽을 때 어느 정도 읽었는지 확인하는 기능을 웹페이지에서도 활용할 수 있도록 만들었습니다.

✨ 주요 기능

현재 읽고 있는 페이지의 진행률(%) 표시
읽은 시간 추적 및 남은 시간 예측 기능
한 번의 클릭으로 페이지 최상단으로 이동하는 'One-Tap Scroll to Top' 기능

모바일에서는 화면 상단을 터치하면 자동으로 페이지 최상단으로 이동할 수 있지만, PC에서는 별도의 버튼이 필요한 경우가 많습니다. 이 확장 프로그램을 통해 고정된 위치를 클릭하여 상단으로 이동하게 하여 웹사이트별로 일관된 조작 방식을 제공하며, 읽기 경험을 더욱 편리하게 만들었습니다.

마무리

이처럼 크롬 확장 프로그램을 활용하면 업무 생산성을 높이고, 보다 효율적인 웹 브라우징이 가능합니다. Vimium을 활용하면 키보드만으로 빠르게 탐색할 수 있고, Grammarly를 통해 문서를 매끄럽게 다듬을 수 있으며, Read-tracker로는 읽기 경험을 최적화할 수 있습니다. 앞으로도 더 좋은 확장 프로그램을 찾아보고, 필요하면 직접 개발해볼 계획입니다.

AI 시대 생존 전략 | 기적의 독서법

Parse — Wed, 19 Feb 2025 21:54:25 +0900

드로우앤드류 'AI 시대에 살아남을 기적의 독서법' 영상을 보고 인상 깊어 개인적을 생각을 보태서 글을 작성하려합니다.

현대 사회는 AI의 등장으로 급격히 변화하고 있습니다. 단순히 정보를 소비하는 것만으로는 경쟁력을 유지하기 어렵고, 이제는 긴 서사를 만들고 의미 있는 콘텐츠를 생산할 수 있는 능력이 필요합니다. 이러한 능력을 기르기 위해 가장 효과적인 방법 중 하나가 바로 독서입니다.

'도파민'이라는 키워드가 여기저기 자주 들릴 정도로 도파민이 넘치는 세상에서 독서는 유독 어렵게 다가옵니다.

독서의 어려움과 극복 방법

많은 사람들이 독서를 어려워하는 이유는 긴 러닝 타임과 올바른 독서 방법을 모르기 때문입니다. 이를 극복하기 위해서는 작게 시작하는 것이 중요합니다. 하루에 단 한 페이지를 읽고, 그중 마음에 드는 부분을 두 문장 정도 써보는 것으로 충분합니다. 이 습관이 점차 쌓이면 독서에 대한 거부감이 사라지고 자연스레 읽는 양이 늘어납니다.

특히 초보 독자는 처음부터 많은 양을 읽으려고 하기보다는 하루에 10페이지 정도만 읽고, 마음에 드는 내용 한두 가지를 메모하는 ‘전략적 독서법’을 활용하는 것이 효과적입니다. 이러한 방법은 단순히 정보를 입력하는 것이 아니라 장기 기억에 저장되도록 도와줍니다.

콘텐츠 생산자의 시선으로 독서하기

AI 시대에는 단순히 지식을 소비하는 것에서 벗어나 지식을 생산하는 사람이 되어야 합니다. 책을 읽을 때도 단순히 내용을 이해하는 데 그치지 않고, 콘텐츠 생산자의 시선으로 바라보아야 합니다. 예를 들어, 독서 중에 떠오른 생각이나 영감을 블로그에 글로 남기거나, 유튜브 영상을 제작해 공유하면 독서의 가치가 배가됩니다.

또한, 스터디 그룹을 활용하면 독서 습관을 꾸준히 유지하면서 다른 사람들과의 의견 교류를 통해 더 깊은 통찰력을 얻을 수 있습니다. 이러한 과정을 통해 단순히 지식을 습득하는 것을 넘어 자신의 생각을 구체화하고 이를 글쓰기나 말하기로 표현하는 능력이 길러집니다.

AI와 인간의 차별화된 능력

AI는 정보를 빠르게 검색하고 분석하는 데 뛰어난 도구지만, 인간만이 지닌 감성적 소통 능력과 창의성은 AI가 대신할 수 없습니다. 예를 들어, 법률 분야에서는 AI가 복잡한 법률 정보를 신속히 제공하지만, 최종적으로 의뢰인의 마음을 이해하고 공감하며 소통하는 것은 인간의 역할입니다.

독서의 진정한 가치

독서는 단순한 정보 습득을 넘어 다양한 경험을 간접적으로 체험하고, 미래에 대한 불안감을 해소하며, 자기 계발을 위한 아이디어를 얻을 수 있는 소중한 도구입니다. 또한, 독서를 통해 얻은 생각을 글쓰기나 말하기로 표현하면서 더 나은 자신으로 성장할 수 있습니다.

끊임없는 자기 변화의 중요성

AI 시대에는 ‘완성된 나’가 아니라 ‘계속 발전해 나가는 나’가 되어야 합니다. 이는 독서를 통해 끊임없이 새로운 지식을 접하고, 이를 통해 자신의 생각을 발전시키며, 나아가 이를 콘텐츠로 만들어 공유함으로써 실현할 수 있습니다. 결국, 독서는 AI 시대에도 변함없이 개인의 경쟁력을 높이는 핵심 도구로 남을 것입니다.

작은 습관으로 시작한 독서가 미래의 나를 더욱 빛나게 할 것입니다. 지금 바로 책을 한 페이지 펼쳐보세요!