하서망 블로그

25년도 하반기 현대 오토에버 개발자 합격 후기

리미32 — Tue, 13 Jan 2026 23:15:03 +0900

안녕하세요. 정말 오랜만에 작성합니다.

귀찮아서 미뤘는데 또 미루겠습니다. 곧 돌아올게요 뿅!

싸피 14기 합격 후기 ✨

리미32 — Mon, 29 Sep 2025 16:19:35 +0900

싸피 3개월차.. 합격후기 쓰려고 했던거 까먹고 지금 쓰기 시작했습니당

사실 어디까지 말해도 되는지 몰라서 조금 모호하게 작성했습니다ㅜ

싸피 하게 된 이유?!

자바나 알고리즘 강의를 들으면서 밥도 무료로 먹을 수 있고, 매달 100만원이 안정적으로 들어온다는 점에서 취준하기에 최적화된 환경이라 생각해서 싸피에 들어가기로 결심했습니다! 2025년 8월 졸업 예정이었기에 바로 14기에 지원했습니다.

싸피 서류 준비

사실 서류는 특별히 더 신경써서 준비하진 않았습니다!

내가 무엇이 부족하고 싸피에서 어떻게 채워나갈 수 있는지를 명확하게 작성하려고 했습니다.

면접에서 자소서를 바탕으로 질문이 들어올테니 구체적으로 작성하기 보다는 질문거리를 만드는 느낌으로 작성했습니다.

그렇지만 지피티 돌린 것처럼 추상적인 말은 아니었습니다.

싸피 준비하는 사람들이 모인 오픈카톡방이 있습니다. 거기에서 서로 자소서 피드백 주고 받더라구요!!! 혹시 서류 관련해서 피드백 주고받는거 하고 싶은 사람들은 싸피 준비 오픈카톡방에서 한 번 모집해보세요~~

코테

코테는 정~말~정~말~ 쉬웠습니다. 걱정했던게 아까울 만큼 쉬웠습니다. 알고리즘도 아니고 그냥 단순 구현 나왔어요!

개인적인 의견으로 실버 정도 난이도였습니다.

그렇지만 함정이 있어서 꼼꼼하게 보지 않으면 시간초과가 발생할 수 있습니다. 조심하세요!

저는 두 문제 다 풀었구 싸피 들어가서 확인하니 두 문제 다 맞았습니다!

저는 원래 코테 공부를 꾸준히 하고 있었습니다. 아마 싸피 코테 볼 당시에 플래티넘 5 찍었을거예요. 원래 코테 준비하던 분들이라면 분명 통과하실거예요~~

면접

면접 대비로 스터디 두 개를 진행했습니다! 하나는 대면, 다른 하나는 비대면이었어요.

스스로 말을 잘한다고 생각했는데 막상 면접 스터디를 하니까 어떤 부분이 부족한지 보이더라구요.

꼭 해보시는걸 추천합니다! 면접 스터디는 오픈채팅방에서 구했습니다 ㅎㅎ

싸피 면접 후기 찾아보니까 피티 면접과 인성 면접으로 이루어져있다고 하더라구요~

그래서 비슷하게 피티 면접과 인성 면접 둘 다 스터디에서 준비했습니다. 각자 기사를 하나씩 들고와서 그 기사를 읽고 주어진 질문에 대해서 본인의 생각을 이야기하는 방식으로 진행했습니다.

피티 면접 준비할 때 도움 많이 받은 영상입니다! 여기 영상에 나와있는 포맷대로 말하는 연습 많이 했어요.

https://youtu.be/DOvCIrwMPbQ?si=BYrH7uBrbPsAOt0b

인성 면접은 기본적인 질문들 여러개 뽑아서 거기에 대한 제 답변을 전부 적은 후에 계속해서 봤습니다.

다른 답변들은 안외웠는데 1분 자기소개만큼은 꼭 외워서 갔어요!!!

면접 답변할 때 " 결론+어떤 경험을 통해서 그렇게 생각했는지 " 포맷을 지켜서 대답하는 것을 중요하게 생각했습니다.

예시로,

협업 중 팀원간의 갈등이 생겼을 때 어떻게 대처할 것인지?

라는 질문에

저는 ~~를 중요하게 생각해서 ~~를 해왔습니다.

그래서 만약 갈등이 생기면 ~~ 하게 대처할 것 같습니다.

라고 이야기하기 보다는,

저는 ~~하게 대처하겠습니다.

실제로, ~~ 프로젝트 당시에 ~~~ 한 일이 있었습니다. 그때 ~~ 대처한 경험을 통해 ~~함을 알게되었습니다.

이런 느낌으로 대답하도록 노력했어용

면접 분위기는 좋았습니다 ㅎㅎ

결과 발표!

정말정말 떨렸습니다,,, 두구두구,,,

다행히도!! 서울 캠퍼스에 자바 전공반으로 합격했습니다~~

여행가서 혼자 산책하고 있었는데 발표나서!! 아주 기쁜 마음으로 나머지 여행을 즐겼습니다.

여기 정중앙에 저 있어요!!ㅋㅋㅋ

반장하고 있어서 입학식에 가서 사진 찍고 왔습니당~

☄️socket 서버가 계속 죽는 이유?!

리미32 — Mon, 8 Sep 2025 23:27:50 +0900

실시간 게임 듀오 매칭 서비스 겜구에서 소켓 부분은 nodejs 의 socket.io 라이브러리를 활용해서 개발했습니다.

어느날부터 계속해서 소켓 서버가 죽는 문제가 발생했습니다...

로그를 살펴보니, 매칭 객체를 제대로 초기화하지 않아서 생긴 문제였습니다.

1. socket.data.matching 객체 초기화 문제

기존에는 socket.data.matching=null으로 초기화했습니다.

이렇게 했더니 NullPointException이 발생해서.. 다음과 같이 resetMatchingObject 메서드를 만들어서 초기화를 진행했습니다.

function resetMatchingObject(socket) {
    socket.data.matching = {
        gameMode: null,
        roomName: null,
        myMatchingInfo: null,
        matchingUuid: null,
        priorityTree: new PriorityTree(),
        highestPriorityNode: null
    };
}

그런데도 계속해서 서버가 죽는 에러가 또 발생했습니다.

다시 소켓 서버 로그를 살펴보았습니다..

2. import 오류

예외는 다음 세 가지에서 발생했습니다.

1. matching-fail

2. matching-not-found

3. matching-quit

해당 이벤트들의 공통점이라면, deleteMySocketFromMatching 메서드를 불러온다는 점입니다.

즉, 만들었던 resetMAtchingObject()에서 동일한 에러가 계속 발생했습니다.

로그에서는 PriorityTree가 스코프에 존재하지 않는 상태에서 resetMatchingObject()가 새 트리를 만들거나 초기화하려다가 예외가 발생하는 것이었습니다. 따라서, 이 예외(uncaughtException)를 처리하려다가 프로세스가 다운되는 것이었습니다.

다시 코드를 살펴보니 new Priority를 실행시키기 위한 라이브러리를 불러오지 않은 것이 문제였습니다.

3. 초기화 시점

matching reject, fail, quit 할 때 필요해서

매칭 객체를 matching-found 된 시점에서 초기화하면 안됨

resetMatchingObject 호출 위치 수정

4. matching-quit

매칭 다시하기 중에서 matching-quit 이벤트가 발생하면 제대로 처리가 안됨..

소켓은 살아있어서 matching-success-receiver가 오면 matching-success-sender가 발생하기 때문

지금 status를 FOUND일 때만 SUCCESS로 변경하게해서 매칭 성공이 되는 오류가 발생하지는 않지만,

matching-quit할 때 상태 소켓이 있다면, matching-fail을 보내주는 로직이 필요함

☄️ RefreshToken 수정 시 동시성 예외 (ObjectOptimisticLockingFailureException) 발생 해결하기

리미32 — Thu, 19 Jun 2025 17:00:32 +0900

예전부터 주구장창 이 에러가 discord back-monitoring 채널에 올라왔다. gamegoo 백앤드 서버는 back-git-pr, back-deploy, back-monitoring을 통해 Github, CICD, AWS를 연동해서 서버 상태를 확인한다. 에러가 발생할 경우 back-monitoring에 다음과 같이 에러 메세지가 올라온다.

예외 메시지를 보자마자 @Version 안 썼는데 왜... 동시성 오류가 났을까라는 생각이 들었다.

문제 원인 파악

문제의 중심은 로그인 시 발급되는 RefreshToken 저장 로직이었다.

   /**
     * 리프레시 토큰 생성
     *
     * @param member       로그인한 회원
     * @param refreshToken 리프레시토큰 정보
     */
    @Transactional
    public void addRefreshToken(Member member, String refreshToken) {
        // 이전에 있던 refreshToken 전부 지우기
        refreshTokenRepository.findByMember(member).ifPresent(refreshTokenRepository::delete);

        // refresh token DB에 저장하기
        refreshTokenRepository.save(RefreshToken.create(refreshToken, member));
    }

매우 단순한 로직이다.

이전 토큰이 있으면 삭제하고,
새 토큰을 저장한다.

그런데 동시성 예외가 터졌다.

게다가 내 RefreshToken 엔티티에는 @Version 필드가 아예 없다.

발생 이유

Hibernate는 delete 후 영향받은 row 수가 0이면 예외를 발생시킨다

즉, 기존 토큰이 있으면 삭제 후 새로 저장하는 방식이었다. 이 구조는 다음과 같은 경쟁 조건(Race Condition) 이 발생할 수 있다:

트랜잭션 A와 B가 거의 동시에 같은 회원에 대한 addRefreshToken()을 호출
둘 다 findByMember()로 동일한 토큰을 조회
A가 먼저 삭제 → B가 삭제 시도 시 이미 DB에서 제거된 상태
Hibernate는 삭제할 row가 없어 동시성 예외를 발생시킴

즉, 낙관적 락 없이도 동시성 오류가 발생할 수 있는 구조였던 것이다.

refresh 토큰이 있을 경우에만 삭제하도록 deleteRefreshToken() 메서드는 따로 만들어뒀지만 실제 호출은 하지 않고, addRefreshToken() 안에서 직접 삭제하고 다시 추가하는 로직이 들어가 있었다.

~~이거 내가 작성한 코드 맞아..? 네..~~

ifPresent는 그 순간만 확인하고, JPA의 delete()는 즉시 DB에 반영되지 않기 때문에, delete와 save를 하나의 트랜잭션에서 처리하더라도, 동시에 여러 요청이 들어오면 각 트랜잭션이 같은 엔티티를 삭제하려고 하면서 충돌이 날 수 있다.

코드

해결 전

@Transactional
 public void addRefreshToken(Member member, String refreshToken) {
        // 이전에 있던 refreshToken 전부 지우기
        refreshTokenRepository.findByMember(member).ifPresent(refreshTokenRepository::delete);

        // refresh token DB에 저장하기
        refreshTokenRepository.save(RefreshToken.create(refreshToken, member));
 }

해결 후

@Transactional
public void updateRefreshToken(Member member, String refreshToken) {
    refreshTokenRepository.findByMember(member)
        .ifPresentOrElse(
            existingToken -> {
                // 기존 토큰 업데이트
                existingToken.updateToken(refreshToken);
                refreshTokenRepository.save(existingToken); // 변경 감지를 명시적으로 반영
            },
            () -> {
                // 새 토큰 저장
                RefreshToken newToken = RefreshToken.create(refreshToken, member);
                refreshTokenRepository.save(newToken);
            }
        );
}

☄️ matching-found-sender 누락 원인 분석과 UUID 검증 로직 추가

리미32 — Wed, 18 Jun 2025 22:54:52 +0900

문제 상황

프론트 개발자님으로부터 매칭 중 문제가 발생했다는 연락을 받았다.

디스코드 메세지

네트워크 탭

- sender(A)는 matching-fail 발생

- receiver(B)는 matching-found-success emit까지 완료

- 그러나 sender에게 matching-found-sender가 전송되지 않음

즉, receiver만 매칭 flow가 진행되었고 sender는 중간에 매칭이 진행되지 않는 상황이었다.

문제 확인

곧바로, 해당 시간대의 8080 Java Spring API 서버와 3000 NodeJS socket.io 서버 로그를 확인했다. 다음은 그 중 해당 에러와 관련된 로그만 캡쳐해온 사진이다.

3000번 소켓(NodeJS) 로그

API 서버(Spring) 로그

다음 UML은 각 매칭 flow를 figma에 그린 것이다. 다음 flow는 매칭 성공 flow의 일부분이다. 실시간 매칭 개발을 진행하며 각 상황마다 매칭 flow를 전부 그렸고, 매칭 성공 뿐만 아니라 다양한 실패 flow도 존재한다.

이 flow를 따라서 로그를 대조하며 각 단계가 올바르게 수행되고 있는지 확인했다. ~~(눈 빠지는줄..)~~

원인 분석

소켓 서버를 잘 살펴보니까 API 요청 보내는 19번에서 문제가 생기는 것을 발견함.

이때, api 서버 로그 살펴보았다.

에러는 refreshToken 관련 트랜잭션 에러만 계속 발생했다.

해당 시간대의 Java 서버 에러

소켓에서 요청된 API 로그를 찾았고, 해당 API에서 이상한 점을 발견했다.

이상이 있는 API 요청 로그

API 에서 sender matchingUuid랑 receiver matchingUuid가 같게 요청이 되었던 것이다!!!!!!!!!!!!!!!!

이를 확인하고 socket 서버 로그를 다시 확인했다.

로그 분석

6번 사용자(A) matchingUuid 는 c71a 8번(B) matchingUuid는 26acdb 이다.

#10) matching-found-receiver에서 senderMatchingInfo에 c71a가 들어가있는 것을 알 수 있다.

#15) 그런데, matching-found-success를 보면 sender가 갑자기 26acdb(B)로 지정되어있다. receiver도 26acdb로 동일!

결과

프론트에서 matching-found-success 보낼 때 자신의 matchingUuid를 senderMatchingUuid로 잘못 넣은 것으로 판단

서버에서는 senderUuid 검증 없이 그대로 받아서

결국 senderSocket = 자기 자신 → 상대방에게 메시지 못 보냄 → matching-found-sender 누락

해결

프론트에서 matching-found-success 이벤트 emit 시, sender Socket matchingUuid를 보내도록 수정

백에서 matching-found-success로 sender matchingUuid를 받을 때 제대로된 sender matchingUuid를 받았는지 확인하는 예외처리가 필요

1. 소켓 서버 : 프론트에서 온 sender Socket matchingUuid가 맞는지 검증

2. API 서버 : found API 발생 시, sender와 receiver matchingUuid가 동일할 경우 예외처리 응답 필요

☄️ GameStyle이 null로 들어올 때 발생한 매칭 오류 해결기

리미32 — Sat, 14 Jun 2025 14:16:47 +0900

안녕하세요! 열심히 서비스를 만들었지만,, 트러블슈팅도 많이 해봤지만,, 노션에만 정리하고 정작 블로그에 포스팅한 트러블 슈팅이 없다는 것을 깨닫고 하나씩 작성해보려합니다.

처음엔 단순한 매칭 실패처럼 보였는데, 깊이 파고들다 보니 null 처리 누락, DB 접근 예외, 컬렉션 수정 중 예외, 구조 분리 등

제법 복잡하고 중요한 문제들이 얽혀 있더라고요.

이번 글에서는 그 과정을 어떻게 추적하고, 해결했는지를 공유해보려 합니다.

문제 상황

매칭 요청을 보냈는데, 클라이언트에서는 응답이 오지 않고, 소켓 서버(3000번 포트)에서도 matching-started가 emit되지 않는 현상이 발생했습니다.

딱 봐도 어딘가 중간에 끊긴 것 같았죠.

그래서 API 서버 로그와 Docker 로그를 확인해봤습니다.

org.springframework.dao.InvalidDataAccessApiUsageException: The given id must not be null!
nested exception is java.lang.IllegalArgumentException: The given id must not be null!

딱 보니 findById(null)이 호출된 상황이더라고요.

JPA에서 ID가 null이면 IllegalArgumentException을 바로 던지기 때문에,

이게 전체 흐름을 막아버린 겁니다.

원인 1 - gameStyleIdList 내부에 null이 포함되어 있었음

매칭 요청에서 사용자의 게임 스타일 ID 리스트는 아래와 같이 전달됩니다.

{
  "gameStyleIdList": [1, null, null]
}

이 상태로 서버에 넘어오면, 다음 로직에서 문제가 터집니다:

gameStyleRepository.findById(null); // 여기서 예외 발생

Spring Data JPA는 findById()에 null을 넘기면

런타임에서 IllegalArgumentException을 발생시키고,

이 예외가 처리되지 않으면 전체 요청이 실패하게 됩니다.

해결 1 - null 필터링 처리

프론트엔드에서 gameStyleIdList를 구성할 때,

null 값은 미리 걸러주도록 필터링을 추가했습니다.

request.gameStyleIdList = request.gameStyleIdList.filter(item => item !== null);

이걸로 프론트 → 백으로 넘어오는 데이터 정합성이 어느 정도 확보됐고,

IllegalArgumentException은 더 이상 발생하지 않았습니다.

또 다른 문제

GameStyle 수정 API를 호출했더니 이번엔 서버에서 다음과 같은 예외가 터졌습니다:

java.util.ConcurrentModificationException

원인 2 - Stream 반복 중 컬렉션 수정

기존에는 기존 게임 스타일을 지우기 위해 다음과 같은 코드를 쓰고 있었습니다.

member.getMemberGameStyleList().stream()
    .filter(mgs -> !requestGameStyleList.contains(mgs.getGameStyle()))
    .forEach(mgs -> {
        mgs.removeMember(member); // 양방향 연관관계 제거
        memberGameStyleRepository.delete(mgs);
    });

여기서 문제는 Stream으로 순회하면서 동시에 컬렉션을 수정하고 있다는 점입니다.

Java는 이런 상황에서 fail-fast 전략을 적용하고 있어서

ConcurrentModificationException이 발생하게 됩니다.

해결 2 - 제거 대상을 임시 리스트에 모아 한 번에 처리

삭제할 대상들을 먼저 toRemove 리스트에 모아두고, 그 리스트만 순회하면서 제거하는 방식으로 변경했습니다.

List<MemberGameStyle> toRemove = new ArrayList<>();

for (MemberGameStyle mgs : member.getMemberGameStyleList()) {
    if (!requestGameStyleList.contains(mgs.getGameStyle())) {
        toRemove.add(mgs);
    }
}

for (MemberGameStyle mgs : toRemove) {
    mgs.removeMember(member);
    memberGameStyleRepository.delete(mgs);
}

이제 컬렉션을 안전하게 수정할 수 있게 됐고, 예외도 발생하지 않게 되었습니다.

위의 수정 과정에서 느낀 건, MemberService 안에서 GameStyle 처리 로직이 너무 많은 책임을 가지고 있다는 점이었습니다.

그래서 MemberGameStyleService라는 전담 클래스로 분리했습니다.

변경 전

profileService.addMemberGameStyles()

변경 후

memberGameStyleService.updateGameStyle()

로직도 단계별로 명확하게 나눴습니다:

findRequestGameStyle()	요청으로 들어온 ID 리스트 → GameStyle Entity 변환
findCurrentMemberGameStyleList()	현재 DB에 존재하는 GameStyle 리스트 조회
removeUnnecessaryGameStyles()	현재에는 있지만 요청에는 없는 스타일 제거
addNewGameStyles()	요청에는 있지만 현재에 없는 스타일 추가

백앤드 성능 테스트 전, 기초 지식 정리!

리미32 — Sat, 14 Jun 2025 13:51:12 +0900

안녕하세요! API를 만들고, 서버를 운영하며 과연 제가 만든 API는 성능이 어떨까 궁금해졌습니다.

그래서!!! 성능테스트를 하기로 마음 먹었습니다.

오늘은 성능테스트에 대해서 공부한 겸, 공부한 내용을 정리해볼까합니다.

성능 테스트를 왜 할까?

개발을 하다 보면 “우리 서버는 몇 명까지 감당할 수 있을까?” “어떤 API가 병목일까?“와 같은 고민을 하게 됩니다.

이를 확인하기 위해 필요한 것이 바로 성능 테스트입니다.

성능을 어떻게 측정할까?

1. Latency (지연 시간)

요청자가 보낸 요청이 응답을 받을 때까지 걸리는 시간
예: 고속도로의 제한 속도에 비유할 수 있어요.

2. Throughput (처리량)

서버가 단위 시간 안에 처리한 요청의 수 (RPS: Request Per Second)
예: 고속도로 차선 수, 즉 동시에 몇 대의 차가 지나갈 수 있는지

테스트 도구 소개

1. wrk / wrk2

wrk -t4 -c10 -d5s http://localhost:8080/api/test

-t: 쓰레드 수
-c: 동시 접속 수
-d: 지속 시간
Latency, RPS 확인 가능
wrk2는 개선된 버전으로, 고정된 요청 속도 유지에 강점이 있음

2. JMeter (Apache)

다양한 프로토콜 지원 (HTTP, FTP, DB 등)
단점: 복잡한 UI, 메모리 많이 씀, 고성능 테스트 시 어려움

3. k6 (Grafana)

JavaScript 기반 스크립트
장점: 간결한 문법, 낮은 메모리 사용
단점: 대규모 트래픽 테스트는 유료 or Kubernetes 필요

4. nGrinder (네이버)

자바 유사 스크립트 지원, 한글 GUI
장점: 직관적이고 친절한 설계
단점: Controller/Agent 분리, IDE 미지원

실제 테스트 종류

테스트명 설명

스모크 테스트	최소 부하로 시스템 정상 동작 여부 확인
스파이크 테스트	갑작스러운 사용자 증가 시 안정성 확인
부하 테스트	목표 부하까지 시스템 성능 유지 여부 확인
스트레스 테스트	시스템 최대치를 초과한 상황에서의 동작 관찰
내구 테스트	장시간 일정 부하를 주어 시스템 안정성 확인
중단점 테스트	임계점까지 점진적 부하 증가로 한계점 측정

테스트는 계획 수립하기

1. 단건 성능 테스트

특정 API를 1회 실행
실행된 SQL 수, 각 쿼리 속도, 총 응답 시간 체크

2. 동시성 부하 테스트

API를 100~1000회 동시에 호출
평균/최대 응답 시간, 에러율, 리소스 고갈 여부 확인
DB connection pool, 서버 CPU 모니터링 (CloudWatch, Grafana 연동 추천)

3. DB 쿼리 자체 테스트

API 내 SQL을 직접 실행
인덱스 적용 여부, 쿼리 실행 계획(Explain), 복합 조건에서 성능 확인

4. 충돌 테스트 (동시성)

여러 API가 같은 데이터에 insert/update 시도
데이터 무결성, deadlock 발생 여부 검증

5. 시나리오 기반 통합 테스트

회원가입 → 로그인 → 데이터 저장 등 실 사용 흐름 전체 테스트
API 간 병목, 상호 영향 여부 분석

테스트 결과 분석하기

성능 테스트를 통해 우리가 궁금한 건 결국 “서버가 얼마나 많은 요청을 어느 속도로 안정적으로 처리할 수 있는가?”입니다.

예를 들어,

Throughput이 낮아지면 병목 지점이 발생했다는 뜻!
Latency가 증가하면 사용자가 대기하게 됩니다.

예시 결과 해석

“100명의 사용자가 5초 동안 요청을 보내자, 평균 응답 시간은 210ms, 최대 응답 시간은 740ms였다.”
→ 최대 지연 시간이 300ms 이상이면 사용자 이탈률이 높아진다고 알려져 있으므로, 개선 필요!

서버 성능을 올리려면?

서버 대수 늘리기
- nginx, mongoDB는 고성능 서버 → 병목은 주로 nodejs 서버
- 요청을 처리하는 부분을 더 늘려야 한다.
코드 최적화
- 불필요한 로직 제거
- 비효율적인 쿼리 개선

테스트 계획 세우기

1. 응답 시간 목표 설정

최대 0.3초 (300ms)를 넘지 않게 하자!
1초 이상 지연 → 이탈률 7%
3초 이상 지연 → 이탈률 40%

2. 최대 사용자 수 추정

예: 평소 100명 접속 → 200명도 문제 없이 처리 가능하도록 여유 있게!

API 성능 테스트는 단순히 수치로 끝나는 것이 아니라, 실제 서비스 품질을 결정짓는 중요한 작업입니다.

어떤 테스트를, 어떤 도구로, 어떤 기준으로 진행할지 명확히 정하고
결과를 바탕으로 병목을 찾아 개선하는 과정까지가 성능 테스트의 핵심입니다.

다들 API 성능 측정 파이팅입니다!

모빌리티란?

리미32 — Thu, 12 Jun 2025 22:57:06 +0900

모빌리티

모빌리티 == 이동성
교통수단에 IT가 접목된 것
사전적 의미 : 어디든 자유롭게 이동할 수 있다는 것
단순한 교통수단을 넘어 도시 인프라, 에너지, 데이터 기술과 맞물린다.
키워드
- 전기화
- 자율화
- 연결성
ex) 킥보드 : 모바일 폰으로 킥보드를 예약하고, GPS 기반으로 위치 정보를 알 수 있도록 되어있다.

주요기술

1. 자율주행

사람의 개입 없이 차량이 스스로 주행하는 기술

차량이 스스로 인지→판단→제어하는 능력을 갖는 것

장점

교통사고 감소 (인간 오류 제거)
운전 시간 절약
노인·장애인 등 교통 약자 지원 가능

단점

윤리적 문제 (사고 시 책임 소재)
도심 환경에서의 인식 오류
인프라 부족 및 법·제도 미비

해결 방안

고정밀 지도와 AI의 강화학습 결합, 윤리 기준 마련, 시범지역 확대 통한 실증 강화

단계 명칭 설명

Level 0	비자동화 (No Automation)	모든 운전 제어를 사람이 함. (예: 경고음, 크루즈 컨트롤도 X)
Level 1	운전자 보조 (Driver Assistance)	특정 기능만 자동화 (예: 어댑티브 크루즈 컨트롤, 조향 또는 가감속 중 하나만) → 운전자는 항상 제어 유지
Level 2	부분 자동화 (Partial Automation)	조향 + 가감속 동시 자동 제어 가능 (예: 현대 HDA, 테슬라 Autopilot) → 운전자가 항상 감시하고 개입 가능해야 함
Level 3	조건부 자동화 (Conditional Automation)	일부 조건 하에서 차량이 전부 제어 (예: 고속도로) → 필요시 운전자가 즉시 개입해야 함 (예: 현대 레벨3 인증 G90)
Level 4	고도 자동화 (High Automation)	특정 구역(지정 구간) 내에서는 운전자 없이도 완전 자율주행 가능 → 외부 조건만 맞으면 사람 개입 없이 운행 가능 (예: Waymo 자율주행 택시)
Level 5	완전 자동화 (Full Automation)	모든 도로·모든 조건에서 사람이 아예 필요 없음 → 핸들, 페달 없는 차량 가능 → 현재는 연구·실험 단계

2. 전기차

전기차는 내연기관(휘발유/디젤) 대신 배터리와 전기 모터로 움직이는 차량

전기차는 친환경성과 경제성에서 큰 장점을 지니고 있지만, 충전 인프라와 배터리 관련 문제를 해결하는 것이 보급 확대의 핵심 과제이다.

장점

탄소 배출 감소
연료비 절감
유지보수 비용 절감

단점

충전 인프라 부족
배터리 원자재의 환경 문제
주행거리와 충전시간에 대한 불안

해결 방안

초고속 충전 기술 개발, 재활용 가능한 배터리 연구, 정부의 인프라 투자 확대

3. MaaS (Mobility as a Service)

다양한 교통수단을 하나의 통합된 플랫폼에서 이용할 수 있도록 하는 개념이다.

대중교통, 택시, 자전거, 킥보드, 카셰어링 등을 하나의 앱이나 서비스에서 예약,결제,경로 안내까지 원스톱으로 제공하는 방식이다.

핵심 요소로는 통합 플랫폼, 개인 맞춤형 경로 제공, 정산 및 과금 통합이 있다.

예시

한국
1. 카카오T, 서울지하철 앱 연동
2. 아직 완전한 MaaS는 아니다.
핀란드
1. Whim 앱
2. 세계 최초의 MaaS 상용 서비스
3. 버스, 트램, 택시, 렌터카, 공유자전거 모두 통합

장점

통합된 교통 수단 이용 가능 (앱 하나로 택시+지하철+버스 등)
개인 차량 소유 부담 감소
도시 혼잡 해소 및 환경 개선

단점

초기 투자비용 큼
데이터 프라이버시 우려
공공·민간 협업 문제

해결 방안

공공기관 주도 표준화 및 민간 협력, 데이터 보안 프레임워크 마련, 사용자 중심 UX 개선

4. 커넥티드 카(Connected Car)

인터넷과 실시간으로 연결된 차량

차량이 다른 차량(V2V), 인프라(V2I), 네트워크(V2N), 사람(V2P)등과 통신하며, 정보를 주고 받고 판단하여 동작하는 것이 핵심이다.

기술 요소 설명

V2X (Vehicle to Everything)	차량과 주변 요소(차량, 인프라, 보행자 등) 간 통신 기술
5G/6G 통신	초저지연·고속 통신으로 실시간 정보 전달
OTA (Over-the-Air) 업데이트	차량 소프트웨어를 원격으로 업데이트
IoT 플랫폼 연동	스마트홈, 스마트시티와 연계 가능
클라우드·빅데이터	주행 패턴, 교통상황 데이터 분석 및 활용
음성 인식 / AI 비서	차량 내 음성 제어 및 인포테인먼트 제공

장점

실시간 교통·안전 정보 제공: 사고, 정체 구간 회피 가능
차량 상태 모니터링: 고장 예측, 정비 시기 알림
편의성 향상: 스마트폰으로 시동/공조 제어, 주차 위치 확인 등
OTA 업데이트: 서비스 센터 방문 없이 기능 업그레이드
자율주행과의 연계성↑: V2X는 자율주행의 핵심 기반

단점

개인 정보 보호 문제: 운전 위치, 패턴, 음성 정보 등 민감 데이터 수집
사이버 보안 리스크: 해킹 시 차량 제어 가능성 존재
표준화 부족: 제조사·국가별 통신 규격 상이

1. 배경

개념: IT와 AI, 통신, IoT 등을 결합한 현대 교통 생태계로, 개인·공유·자율주행·도심항공(UAM) 등 다양한 이동수단과 서비스를 포함합니다 .
도입 배경: 도시화 확대, 환경규제 강화, 5G·AI·IoT 기반 기술 발달로 전통적인 개인차 중심 이동에서 벗어나 공유·친환경·연결 이동으로 전환 추세 .
장점:
- 환경친화: 전기화·수소화·자전거/스쿠터 통한 탄소 저감 .
- 편의성 개선: 실시간 호출·통합예약 기반 Mobility‑as‑a‑Service(MaaS) .
- 효율성 향상: 자율주행과 V2X 통신을 통한 교통체계 최적화 및 인프라 비용 절감 .

2. 활용 분야

퍼스널 모빌리티: 전기 스쿠터·전자 자전거 등 개인형 이동 수단 .
공유 모빌리티: 라이드헤일링(Uber 등)·공유 스쿠터/자전거 등 .
자율주행차량: 각 단계(L1~L5) 수준의 자율주행 기술 적용 차량 .
도심항공(UAM)/eVTOL: 도심 항공 이동수단 및 항공택시 연구·실용화 추진 .
대중교통 인프라: 스마트 신호·철도(V2X 기반)·스마트 주차·전기차 충전망 등 .

3. 리스크

안전 문제: 퍼스널 모빌리티 사고, 공유 스쿠터 충돌, EV 화재 위험 등 .
법·제도 규제 미비: 도로교통법상 정의·운행노선·자율주행·UAM 법적 공백 존재 .
사이버 보안·프라이버시: V2X·MaaS의 개인정보 유출 및 해킹 취약성 .
산업 확산 장애: 기술뿐 아니라 정치/산업/법률 이해관계 충돌로 서비스 확장 차질 .
인프라·배터리 과제: EV 화재 대응, 배터리 안전 인증, 충전 인프라 안정성 부족 .

4. 극복 방안

제도 개선
- 퍼스널 모빌리티 도로 이용 기준, 자율주행/UAM 운행 규제 정비 .
- EV 배터리 인증 제도, 충전기 표준화, 화재 예방 대응책 수립 .
보안 강화
- 차량·교통시스템에 보안·프라이버시 준수 체계(암호화, 개인정보관리) 도입 .
인프라 확충
- 스마트 주차·전기차 충전·수소 충전소·도로 인프라 스마트화 .
산업 협력 및 기업 혁신
- 울산 수소도시 등 지자체-기업-연구기관 협업, UL 배터리 테스트센터 설립 등 공공·민간 협력 강화 .
기술 신뢰성 확보
- 자율주행·eVTOL 신뢰성 시험, V2X 네트워크 안정성 확보, 리던던시 중심 개발 .

5. 출처 및 최신 동향

EV·자율주행 투자 확대: 현대·기아 등, 2025년 EV 등에 16.7 조원 추가 투자 .
EV 화재 대책 강화: 배터리 인증 확대, 화재 방지 충전소 법제화 .
UAM 도심 항공 상용화: 2025~2028년 우버에어, 현대호 등 시범 운영 → 상용화 .
자율주행·V2X 급성장: 2024년부터 자율차 시장 연평균 29% 성장 예상 .
퍼스널·마이크로 모빌리티 성장: 한국 시장 2024년 약 3.5억 달러, 2035년까지 18억 규모 예측 .
데이터 및 보안 규제 강화: MaaS 개인정보 보호, 사이버 보안 정책·법 강화 움직임 .

블록체인과 NFT, 그리고 Web3의 이해

리미32 — Wed, 11 Jun 2025 21:46:12 +0900

1. 블록체인의 등장 배경

중앙 집중형 시스템은 오랜 기간 주요 서비스 구조로 사용되어 왔지만, 다음과 같은 구조적 문제를 안고 있었습니다.

보안 취약성 → 단일 서버가 공격당하거나 장애가 발생할 경우 전체 시스템이 마비됨
투명성 부족 → 데이터의 처리 방식이나 이력이 일반 사용자에게 공개되지 않아 신뢰에 한계가 있음
신뢰 비용 → 거래나 검증 시 제3자(은행, 기관 등)의 개입이 필요하여 수수료와 절차가 증가

이러한 문제를 해결하기 위한 대안으로 블록체인 기술이 제안되었으며, 비트코인의 핵심 기술로 전 세계적으로 주목을 받기 시작했습니다.

2. 블록체인의 개념

데이터를 일정한 크기의 블록 단위로 묶고, 이를 시간 순서대로 연결하여 분산 저장하는 데이터베이스 구조

네트워크 참여자 전체가 동일한 원장(장부)을 보유하며,
각 블록은 해시(Hash)로 연결되어 있어 데이터 변경이 사실상 불가능합니다.

3. 블록체인의 주요 특징과 장점

✅ 탈중앙화(Decentralization): 중앙 서버 없이도 참여자 간 직접 거래 가능
✅ 투명성(Transparency): 누구나 거래 내역을 열람할 수 있어 조작 위험 감소
✅ 불변성(Immutability): 한 번 기록된 데이터는 변경할 수 없음
✅ 추적 가능성(Traceability): 거래 이력이 시간 순서대로 저장되어 추적 용이
✅ 보안성(Security): 해시 암호화, 디지털 서명, 합의 알고리즘으로 위·변조 방지

4. 블록체인의 활용 사례

금융	비트코인, 이더리움 등 디지털 자산, 리플 기반의 송금 시스템, CBDC(중앙은행 디지털 화폐)
공공 행정	전자 투표 시스템, 토지 등기, 주민등록·병무 기록의 무결성 검증
유통/물류	식품·의약품 유통 경로 추적, 원산지 인증
저작권/인증	NFT를 통한 디지털 창작물의 소유권 및 진위 보장
의료	환자의 진료기록을 안전하게 공유하고 접근 권한 제어
AI 융합	AI 학습 데이터 변경 이력 추적, Deepfake 방지용 콘텐츠 검증 시스템

5. 블록체인의 한계와 리스크

❌ 확장성 문제: TPS(Transaction per Second)가 낮음 (예: 비트코인 약 7건/초, 이더리움 약 30건/초)
❌ 에너지 소비 과다: PoW 방식은 전력 소모가 매우 큼
❌ 합의 지연 및 수수료 폭등: 네트워크 혼잡 시 처리 속도 저하 및 수수료 상승
❌ 스마트 계약의 불안정성: 버그 발생 시 되돌리기 어려움 (예: DAO 해킹 사건)
❌ 규제 미비: 법적 기준과 글로벌 합의 부족으로 인해 혼란 발생 가능

6. 극복 방안

확장성 해결 → 샤딩(Sharding), 레이어2 솔루션(L2 Rollups), 이더리움 2.0의 PoS 전환
에너지 절감 → PoW에서 PoS로의 전환을 통해 에너지 효율 대폭 향상
스마트 계약 보안 강화 → 정기적인 코드 감시, 버그 바운티 프로그램 도입

7. PoW vs PoS

구분PoW (Proof of Work)PoS (Proof of Stake)

블록 생성 방식	수학 퍼즐을 푼 채굴자(Miner)가 블록 생성	코인을 스테이킹한 검증자가 블록 생성
특징	연산 경쟁 필요, 보안성 높음	에너지 효율 우수, 처리 속도 빠름
에너지 소비	매우 높음	매우 낮음
대표 사례	비트코인	이더리움 2.0

PoS가 PoW보다 빠른 이유
PoW는 모든 노드가 동시에 복잡한 문제를 풀어야 하며, 가장 먼저 푼 노드만 보상을 받습니다. 반면 PoS는 네트워크가 지분율과 무작위성을 고려하여 미리 정한 검증자에게 블록 생성 권한을 위임하기 때문에 속도가 빠르고 자원 낭비가 없습니다.

8. NFT (Non-Fungible Token)

개념

NFT는 대체 불가능한 디지털 자산으로, 각 토큰은 고유한 값과 메타데이터를 가짐
일반 암호화폐(비트코인 등)는 동질성이 있지만, NFT는 각각 유일하며 교환 불가능

장점

✅ 소유권 증명: 블록체인 기반으로 소유자를 명확하게 기록
✅ 진위성 확보: 원본 여부 확인 가능
✅ 희소성 부여: 복제 불가능한 디지털 자산 생성
✅ 2차 수익 가능: 재판매 시 창작자에게 로열티 제공

활용 사례

분야활용 예시

예술/콘텐츠	디지털 아트, 음악, 밈, 사진, 영상 등 거래
게임	캐릭터, 아이템을 NFT화하여 거래(P2E 게임 경제 핵심 요소)

리스크

❌ 가격 거품: 투기 수단으로 변질될 위험
❌ 환경 문제: PoW 기반 NFT 발행 시 에너지 소비 과다
❌ 플랫폼 종속: 특정 플랫폼 종료 시 접근 제한 우려

극복 방안

PoS 기반 NFT 플랫폼 도입

9. 샤딩(Sharding) 기술

블록체인의 확장성 문제를 해결하기 위한 핵심 기술 중 하나

데이터를 작은 단위(샤드)로 나누어 병렬 처리
각 샤드는 독립적으로 트랜잭션을 처리함으로써 전체 TPS 향상

장점

✅ 처리 속도 향상
✅ 시스템 부하 분산

단점

❌ 샤드 간 상태 공유가 복잡
❌ 일관성 유지가 어려울 수 있음

10. Deepfake 방지와 블록체인

AI로 생성된 허위 콘텐츠(Deepfake 등)의 진위를 확인하기 위해 블록체인 기술이 활용됩니다.

구조

콘텐츠 원본 생성 시 해시값을 블록체인에 기록
유통 중인 콘텐츠의 해시값과 비교
동일한 해시인지 여부로 진본성 검증 가능

→ Deepfake, 합성 이미지 등 AI 기반 위조물의 진위 판별 가능

11. Web3와 블록체인

Web의 발전

시대특징

Web 1.0	읽기(Read) 중심의 정적 웹 (예: HTML 게시판)
Web 2.0	쓰기(Read & Write) 중심의 플랫폼 웹 (SNS, YouTube 등)
Web 3.0	사용자가 데이터와 자산을 소유하는 분산형 웹

Web3의 핵심

사용자 중심의 데이터 소유 및 통제
스마트 계약, 탈중앙화 애플리케이션(DApp), 토큰 기반 경제 구조

Web3 + 블록체인의 시너지

장점설명

탈중앙화	중앙 서버 없이도 서비스 제공 가능
사용자 자율성	데이터/자산의 소유권을 사용자에게
보안성	해킹 및 위조에 강한 분산 구조

블록체인은 단순한 암호화폐를 넘어, 신뢰 기반의 디지털 사회 인프라로 자리잡고 있습니다.

NFT, Web3, 샤딩, PoS 등의 기술과 융합되며, 새로운 경제 구조와 거버넌스를 만들어 가고 있습니다.

✅ 확장성 문제는 어떻게 해결할 것인가?
✅ 에너지 소비와 환경 문제는 어떻게 조율할 것인가?
✅ 규제와 사회적 수용성은 어떻게 확보할 것인가?

5G 알아보기

리미32 — Tue, 10 Jun 2025 18:40:46 +0900

1. 배경 (도입 · 개념 · 장점)

개념:
5G는 4G LTE의 다음 세대 이동통신 기술로, 초고속, 초저지연, 초연결을 핵심으로 합니다.
도입 배경:또한, LTE의 속도·지연 한계를 넘기 위해 고안되었습니다.
데이터 사용량 급증, IoT/자율주행/스마트팩토리 등 차세대 서비스 요구 대응을 위해 등장.
장점:
- 속도: 최대 10Gbps 이상으로 LTE(1Gbps 이하) 대비 10배 이상 빠름
- 지연시간: 1~10ms 수준으로, 실시간성이 중요한 자율주행/원격수술 등에 적합
- 동시접속성: 수많은 기기 연결 가능 → 스마트시티, 산업 IoT 기반 확보

2. 활용

자율주행차: 실시간 교통정보·센서 데이터 공유 (초저지연 필수)
스마트팩토리: 로봇 제어 및 자동화에 안정적인 고속 연결 제공
원격진료/수술: 지연 없는 영상과 제어로 원격 시술 가능
AR/VR 콘텐츠: 고용량 콘텐츠의 빠른 전송으로 몰입도 향상
스마트시티: 수많은 센서와 연결된 도시 인프라 구성 (교통/보안/환경 등)

3. 리스크

체감 성능 부족:
- NSA(Non-Standalone) 구조: 실제로는 LTE와 혼합된 구조로 체감 속도는 LTE+α 수준
- 5G 이론속도 대비 실제속도(300~700Mbps)는 낮은 편
5G 커버리지 부족:
- 고주파수(28GHz 등)는 직진성이 강하고 도달거리가 짧아 건물 내부/지하에서 신호 약함
- 커버리지 미비로 LTE fallback 현상 빈번
킬러 서비스 부재:
- 대중적으로 5G만의 전용 서비스(자율주행, 스마트팩토리 등) 확산이 느림
- 일반 사용자는 웹서핑, 영상 시청 등 LTE로도 충분히 가능한 용도만 활용 중
구축 비용이 매우 높음
전파 범위가 짧고 직진성이 강함. 특히 실내 커버리지가 약함

4. 극복 방안

SA(Standalone) 방식 확대:
- LTE망 없이 완전한 5G 네트워크 구축 → 지연 감소 및 전용 서비스 가능
인프라 투자 확대:
- 기지국 밀도 확충 및 실내 커버리지 보완 필요 (특히 고주파 대역)
킬러 서비스 발굴:
- XR(확장현실), 메타버스, B2B 서비스 중심으로 5G 특화 콘텐츠 개발·보급
정책 및 주파수 정책 개선:
- 주파수 재할당 시 사업자의 투자 유인 확보, 공정 경쟁 환경 조성

5. 출처 및 최신 동향

6G 개발 착수: 2030년 상용화 목표, 5G보다 10배 이상 속도/0.1ms 지연 추구
3GPP: 5G 표준을 수립하는 글로벌 통신 표준 기구
주파수 재할당: 기간 만료 후, 국가가 재조정 (요금, 대역폭 등)
한국 통신사들: NSA 방식에서 SA 방식으로 점진적 전환 중

5G가 LTE와 별 차이없게 느껴지는 이유

1. NSA(Non-Standalone) 방식

한국의 초기 5G는 기존 LTE망에 5G 안테나만 붙인 형태(NSA)였다.
데이터는 5G로 보내지만 제어신호는 LTE망이 처리합니다.
이 때문에 실제 체감 속도나 지연은 LTE+α 정도에 불과하다.

2. 실제 체감 속도 차이가 크지 않음

5G 속도는 이론상 수 Gbps지만, 실제 도심에서도 300~700Mbps 수준.
LTE도 최적 환경에서는 100~200Mbps를 낼 수 있어, 체감 차이가 작거나 없음.

3. 5G 커버리지 부족

5G는 고주파(28GHz 등)를 써서 도달 거리와 관통성이 낮다.
건물 내부, 지하철 등에서는 LTE fallback 현상이 많음 → 실질적으로 LTE 사용.

4. 킬러 서비스 부재

자율주행, AR/VR, 스마트팩토리 같은 5G 전용 서비스가 아직 일반 사용자에겐 제한적
대부분 웹서핑, 유튜브, 인스타 → LTE로도 충분히 가능한 활동

3G	3세대 (2000년대 초)	수 Mbps	수백 ms
LTE (4G)	4세대 (2010년대 초)	수백 Mbps ~ 1 Gbps	50~100ms
5G	5세대 (2020년대 초)	10 Gbps 이상	1~10ms
6G	6세대 (예상: 2028~30년)	100 Gbps 이상	0.1ms 이하