AI에게 "개발자는 대체된다"고 말해봤다

AI 뉴스에서 또 익숙한 소리가 들린다. 대규모 인력 감소, AI가 개발자를 대체한다, 컴퓨터 공학의 종말... 신입 채용이 씨가 말랐다는 이야기까지. 이런 소식을 접할 때마다 나는 스스로를 이렇게 생각하며 안정시키곤 했다."개발자는 원래 사람을 대체하기 위해 일하는 사람들이고, 결국 자기 자신을 대체하기 위한 기술을 만드는 사람들이다." 하지만 이제는 정말 눈에띄게 개발자 공고가 사라지고 실제로 AI로 인해 이전과 다른 수준으로 높아진 생산성을 체감하게 되면서 안정적이였던 마음이 흔들리기 시작했다. "정말 이제 나는 대체될 운명인가?"라고 생각하며 다시 걱정에 파도에 휩쓸리곤 했다.갑작스럽게 시작된 AI와의 토론걱정만 하고 있을 수는 없었다. 불안할수록 정면으로 마주하며 부딪쳐야 된다고 생각했다. 그래..

• format_list_bulleted 카테고리 없음
• · 2026. 2. 28.

토비의 스프링 정복하기 12편 - 왜 @Transactional 한 줄이면 되는걸까?

백엔드 개발을 하면서 트랜잭션을 직접 제어하는 코드를 작성해본 개발자는 많지 않을 것입니다. @Transactional 하나면 트랜잭션이 생성되고, 메서드가 끝나는 시점에 자동으로 종료되니까요. 개발자는 그 안에서 비즈니스 로직에만 집중하면 됩니다.하지만 이 추상화가 때로는 함정이 되기도 합니다. private 메서드에 @Transactional을 선언하거나, 같은 클래스 내부에서 @Transactional 메서드를 호출하는 self-invocation으로 인해 트랜잭션이 의도대로 동작하지 않는 경험, 한 번쯤 해보셨을 겁니다.이 글에서는 @Transactional에 숨어있는 AOP의 동작 원리를, 수동 프록시에서 시작해 현대 스프링에 이르기까지의 진화 과정을 통해 추적해보겠습니다."마법" 뒤에 숨겨진 ..

• format_list_bulleted spring
• · 2026. 2. 18.

토비의 스프링 정복하기 11편 - 프록시가 나오게 된 이유

프록시와 Mock프록시(AOP)와 Mock(@MockitoBean)은 목적은 다릅니다. 하나는 부가기능을 끼워넣기 위해, 다른 하나는 테스트 격리를 위해 존재합니다. 하지만 구조적으로는 놀라울 정도로 닮아있습니다.[클라이언트] → [대리 객체] → [실제 타겟]AOP 프록시: 트랜잭션, 로깅 등 부가기능을 가진 대리 객체가 타겟을 감싼다.@MockitoBean: 테스트용 가짜 객체가 스프링 컨텍스트에서 실제 빈을 대신한다.두 경우 모두 클라이언트(호출자)는 대리 객체의 존재를 알 수 없습니다. 개발자들은 프록시를 통해 호출한 쪽에서 대리 객체를 통해 실제 객체를 숨기려고 했을까요? 1단계: 수동 프록시 — 가장 원시적인 대리 객체AOP 관점: 데코레이터 패턴프록시를 구현하는 가장 직관적인 방법은 인터페이..

• format_list_bulleted spring
• · 2026. 2. 10.

토비의 스프링 정복하기 10편 - 비즈니스 로직을 기술로부터 독립시키기

[Spring] 트랜잭션 서비스 추상화토비의 스프링에서 나오는 트랜잭션 서비스의 추상화는 지금까지도 활용되고 있으며 스프링부트 환경에서도 가장 중요한 핵심 아키텍처로 활용되고 있습니다. 과거의 복잡한 트랜잭션 코드가 어떻게 @Transactional이라는 하나의 어노테이션으로 관리할 수 있게 되었는지 살펴보도록 하겠습니다.1. 트랜잭션의 시작: 원자성(Atomicity)DB는 단일 SQL에 대해서는 트랜잭션을 보장하지만, 여러 작업을 하나의 단위로 묶는 것은 애플리케이션의 역활입니다. 이 역활은 AI의 개발을 위임하더라도 트랜잭션의 범위 만큼은 백엔드 개발자가 직접 검토해야할 정도로 중요한 작업니다. 예: 은행 송금 로직출금 계좌에서 돈을 뺀다. (UPDATE)-- 여기서 예외 발생! --입금 계좌에 돈..

• format_list_bulleted spring
• · 2026. 2. 7.

토비의 스프링 정복하기 9편 - 서비스의 추상화

@Servicepublic class ReservationService { public int calculateFinalPrice(int originalPrice, String discountType) { int finalPrice = originalPrice; // 문제 1: 문자열로 타입 구분 → 오타 위험, 타입 안전성 없음 // 문제 2: 모든 할인 로직이 한 곳에 뭉쳐있음 // 문제 3: 매직 넘버(1000, 0.1) 직접 사용 // 문제 4: 정책 추가될 때마다 if문 계속 추가해야 함 (OCP 위반) if (discountType.equals("AMOUNT")) { ..

• format_list_bulleted spring
• · 2026. 2. 3.

AI와 토론하며 설계한 SSE 실시간 조회 시스템

1. 개요이번에 개발하는 프로젝트 요구사항에 실시간으로 기기의 정보를 받아와 관리자 화면에 보여줘야하는 요구사항이 있어 실시간성 기술이 필요한 기술을 사용하게 되었습니다. 제미나이와 토론하며 얻은 지식과 기술적 결정의 배경을 정리해, 비슷한 고민을 하는 분들과 나누고자 합니다.2. 기존에 웹 소켓을 사용했던 배경AWS 웹소켓은 수만 개의 커넥션을 직접 관리해 줍니다. 애플리케이션 서버는 연결 시 커넥션 정보만 저장하면, 이벤트 기반으로 쉽게 데이터를 전달할 수 있어요. 커넥션 리소스도 AWS가 처리하므로 서버 부담과 유지보수 비용이 모두 줄어듭니다. 이런 장점 덕분에 기존 애플리케이션은 소켓으로 실시간 조회를 제공했습니다. 하지만 IDC 환경에서는 상황이 다릅니다. AWS가 제공하던 기능을 직접 만들고..

• format_list_bulleted spring/SpringBoot
• · 2026. 2. 1.