보조기억장치

[programmers] 의상 - 해시, 조합론

hand-mk — Tue, 9 Jun 2026 18:13:59 +0900

1. 서론

해시 + 조합으로 금방 풀리겠지라고 접근했다가 고려하지 못한 케이스 때문에 시간을 오래 잡아 먹었던 문제이다.

문제: https://school.programmers.co.kr/learn/courses/30/lessons/42578

프로그래머스

SW개발자를 위한 평가, 교육의 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

2. 본론

이 문제의 핵심은

(1) 옷 여러벌을 같은 종류에서 고르면 안됨 (중복 x)

(2) 1, 2, ... n 가지 입는 경우의 수를 더해야 함 (조합)

으로 해시 + 조합론 을 활용한 문제풀이가 적합하다.

때문에 필자는 다음과 같이 구조를 짜보았다.

(1) n과 r 을 파라미터로 갖는 조합 함수 `comb()` 구현

(2) 입력 clothes 배열 for 문 조회 -> HashMap 카테고리 별 count 추가

(3) 1 ~ 카테고리 종류수 (HashMap.size()) 만큼 for 문 반복

(3.1.) `comb(총개수, i)` 결과에 합산

(3.2.) HashMap value > 1 이고, `comb(value, i)` 를 결과에서 뺌 - 같은 종류에서의 i 개 선택 제거

(4) return 결과

import java.util.*;

class Solution {
    public int solution(String[][] clothes) {
        int answer = 0;
        HashMap<String, Integer> hm = new HashMap<>();
        
        for (String[] arr : clothes){
            String kind = arr[1];
            int value = hm.getOrDefault(kind, 0);
            
            if (value == 0){
                hm.put(kind, 1);
            }else{
                int updated = value + 1;
                hm.put(kind, updated);    
            }
            
        }
        
        // 모든 옷 개수 산출
        int total = 0;
        
        for (int value : hm.values()){
            total += value;
        }
        
        // 종류 총 개수 산출
        int kindAmt = hm.size();
        
        // total 중에 1 -> 총 종류수까지 선택하는 조합 합산 
        for (int i=1; i<= kindAmt; i++){
            
            // 1개만 선택할 땐 조합 더하기
            if (i==1){
                answer += comb(total, i);
            } 
            
            // 1 이상 일 때는 value 가 1이상 (중복 가능성 있는 애들) 빼기
            else{
                answer += comb(total, i);
                
                for (int value : hm.values()){
                    if (value == 1 || value < i) continue;
                    
                    answer -= comb(value, i);
                }
            }
        }
                
        return answer;
    }
    
    public int comb(int n, int r){
        long child = 1; long momA = 1; long momB = 1;
        
        for (int i=n; i>0; i--){
            child *= i;
        }
        
        for (int j=r; j>0; j--){
            momA *= j;
        }
        
        for (int k=n-r; k>0; k--){
            momB *= k;
        }
        
        int result = (int) (child / (momA * momB));
        return result;
    }
}

이 로직에선 다음 케이스가 반영되지 못했다.

i = 3 일때, 동일 종류 2개 + 다른 종류 1개 케이스

ex. A | B | C -> A1, A2, C1 (x)

2 | 2 | 2

조합론을 활용한 접근법은 옳았으나, 뽑는 개수(r) 별로 더하는 방법이 적절하지 않았다.

문제 내에서 의류 종류 별로 독립적인 경우의 수 이기 때문에, 각 종류 별 경우의 수를 곱해주면 0개 ~ 최대 종류수 까지 뽑는 모든 경우의 수가 나오게 된다. 여기에 모든 종류에서 안뽑히는 경우를 한번 빼주면 된다.

import java.util.*;

class Solution {
    public int solution(String[][] clothes) {
        int answer = 1;
        HashMap<String, Integer> hm = new HashMap<>();
        
        for (String[] arr : clothes){
            String kind = arr[1];
            int value = hm.getOrDefault(kind, 0);
            
            if (value == 0){
                hm.put(kind, 1);
            }else{
                int updated = value + 1;
                hm.put(kind, updated);    
            }
            
        }
        
        for (int value : hm.values()){
            answer *= value + 1;
        }
                
        return answer -1;
    }
}

3. 결론

알고리즘 문제를 풀 때마다 처음 설계에서 부분 부분의 테스트 케이스가 틀릴 경우 반례만 찾게 되는거 같다. 우연히 맞아 떨어지는 설계를 하진 않았는지 검토하는 습관을 들여야 할 것 같다.

[TS] 실시간 채팅 시 권한 관리 개선

hand-mk — Fri, 17 Apr 2026 00:39:01 +0900

1. 서론

채팅 기능 개발을 하던 도중 문득 그런 생각이 들었다.
현재 플로우는 사용자가 공방에 제작 의뢰를 하면 DB에 채팅방이 생성되고 생성된 고유 id 값을 STOMP 채팅 시의 구독경로로 넣어야 한다.

여기서 의문점.

그럼 채팅을 보낼때마다 DB에서 조회를 해야 하는가?
그럼 채팅을 보낼때마다 DB에 채팅 내역을 저장해야 하는가?

2. 본론

1번 해결

일단 1번은 확실히 아닌 것 같다.

DB 조회 연산이 많아지면 서버가 느려지는것 정도는 어느정도 생각했고, 지금이야 테스트 하고 있어서 돌아가겠지만 사용자가 4명일 때 채팅만 해도 한번 채팅 주고 받을 때 조회 4번, 저장 4번 총 8번이 생긴다.

나의 생각은 이랬다.

'소켓을 연결할 때 커스텀 헤더에서 토큰 값을 추출하는데, 어짜피 채팅을 한번 하고 끊고 한번 하고 끊을 게 아니라면 소켓 연결 시에만 DB 조회를 해서 세션에 {user : ok} 이런식으로 저장해두고 세션에 user 키 유무만 확인하면 되지 않을까?'

StompHandler.java

@Slf4j
@RequiredArgsConstructor
@Component
@Order(Ordered.HIGHEST_PRECEDENCE + 99) // 스프링의 빈 순서를 지정하는 애노테이션으로, StompHandler 의 우선순위를 설정한다.
public class StompHandler implements ChannelInterceptor {
    private final JwtTokenProvider jwtTokenProvider;

    /**
     * preSend 는 메시지가 채널로 전송되기 전에 호출되는 메소드.
     * @param message payload + Headers
     * @param channel
     * @return
     */
    @Override
    public Message<?> preSend(Message<?> message, MessageChannel channel) {
        StompHeaderAccessor accessor = StompHeaderAccessor.wrap(message);
        // 메세지의 STOMP 헤더를 쉽게 접근하기 위한 유틸리티 클래스

        // websocket 연결시 헤더의 jwt token 유효성 검증
        if(StompCommand.CONNECT == accessor.getCommand()){
            log.info("[stomphandler] extract header");
            String token = accessor.getFirstNativeHeader("Authorization");
            log.info("[stomphandler] token : {}",token);
            if(!token.isEmpty()){
                token = token.replace("Bearer ","").trim();
                String nickName = jwtTokenProvider.getUserNickName(token);
                log.info("[stomphandler] nickname : {}",nickName);

                accessor.getSessionAttributes().put("senderNickname", nickName); // 기존 헤더에 nickname 정보를 추가해 저장한다.
            }else{
                throw new TokenNotFoundException("토큰이 필요합니다.");
            }

        }
        return message;
    }
}

accessor.getSessionAttributes().put("senderNickname", nickName); 이 부분에서 소켓 연결을 할 때 STOMP 세션 속성에 메세지 송신자의 닉네임을 저장해둔다.

ChatController.java

@MessageMapping("/gagu-chat/{roomNumber}") // mapping ex)/pub/gagu-chat/{roomNumber}
    public void sendMessage(RequestChatContentsDto message,
                                         SimpMessageHeaderAccessor accessor,
                                         @DestinationVariable Long roomNumber) throws Exception {

        log.info("[chat] room id : {}",roomNumber);

        String nickname = (String) accessor.getSessionAttributes().get("senderNickname");
        log.info("[chat] check memeber....");
        if (nickname == null) {
            throw new IllegalArgumentException("세션에 닉네임이 없습니다.");
        }

        Long sessionRoomId = (Long) accessor.getSessionAttributes().get("chatRoomId");

        if(sessionRoomId==null){ // 처음 메세지 보내는 경우
            log.info("[chat] chatting session is empty room id : {}, nickname : {}", roomNumber,nickname);
            User user = userRepository.findByNickName(nickname);
            if(user == null){
                throw new NotFoundUserException();
            }
            Optional<ChatRoom> foundChatRoomList = chatRoomRepository.findById(roomNumber);
            if(!foundChatRoomList.isEmpty()){
                ChatRoom chatRoom = foundChatRoomList.get();
                if(checkMember(chatRoom, user)){ // 채팅방 권한이 있다면
                    accessor.getSessionAttributes().putIfAbsent("chatRoomId", roomNumber);// 세션에 저장되어 있지 않을때, 세션에 저장
                    log.info("[chat] successfully put room id to session");
                }
                log.info("[chat] complete check member");
                Thread.sleep(1000); // 비동기적으로 메시지를 처리하기 위해서 1초 지연(옵션)
                log.info("[chat] question : {}", message.getContents());
                ResponseChatDto responseChatDto = chatService.sendContents(message,roomNumber,nickname);
                template.convertAndSend("/sub/chatroom/"+roomNumber,responseChatDto); // 구독하고 있는 채팅방에 전송
            }else{
                throw new ChatRoomNotFoundException();
            }
        }else{
            log.info("[chat] complete check member");
            Thread.sleep(1000); // 비동기적으로 메시지를 처리하기 위해서 1초 지연(옵션)
            log.info("[chat] question : {}", message.getContents());
            ResponseChatDto responseChatDto = chatService.sendContents(message,roomNumber,nickname);
            template.convertAndSend("/sub/chatroom/"+roomNumber,responseChatDto); // 구독하고 있는 채팅방에 전송
        }
    }

accessor.getSessionAttributes().get("senderNickname"); 를 통해 소켓 연결 시 미리 넣어 두었던 송신자 닉네임을 확인한다.
메세지를 처음 보내는 경우에는 DB 조회를 해서 메세지 송신자가 채팅방에 속해 있는지 확인한다. 만약, 정상적으로 확인되면 {nickname : 방번호} 형식으로 세션에 넣고 만약 이미 세션에 닉네임을 키로 가진 채팅방 번호가 있을 때 DB 조회 없이 메세지를 전송한다.

이렇게 관리 하니 처음보다 훨씬 DB 조회 연산이 줄었다!

https://github.com/MinkeySon/GAGU-SERVER

[TS] 3D-랜더링 시 텍스처 파일 분리

hand-mk — Thu, 16 Apr 2026 23:35:18 +0900

에러 발견

이전에 2D 이미지 생성 후 3D glb 파일로 변환하는 기능을 구현했는데, 앱단에서 사용하는 라이브러리가 gltf 형식을 읽을 수 있어, 파일 형식을 변경하는데 텍스처 파일이 분리돼서 생성됐다. 때문에 색깔을 빼놓고 렌더링 되는 예외가 발생하였다.

해결

사용한 라이브러리는 Aspose 에서 참고하였고, 사실 이전에 obj 형식으로도 생성해서 연동을 시도해본 적이 있다. 해당 라이브러리에 obj 형식으로도 변환이 가능하니 필요에 따라 공식문서를 참고하면 좋을 듯 싶다.

Dependency
Dependency는 Aspose repository 에서 직접 불러와야 한다.

<repository>
<id>AsposeJavaAPI</id>
<name>Aspose Java API</name>
<url>https://repository.aspose.com/repo/</url>
</repository>

<dependency>
<groupId>com.aspose</groupId>
<artifactId>aspose-3d</artifactId>
<version>version of aspose-3d API</version>
<classifier>jdk17</classifier>
</dependency>

사용하는 방법은 그닥 어렵진 않았는데,

import com.aspose.threed;

Scene scene = Scene.fromFile("3d.glb");
scene.save("Output.3ds");

문제는 이렇게 save() 메서드만 사용하게 되면 텍스처 파일이 분리돼서 생성된다.

여기서는 buffer.bin 이라는 이름으로 생성되는데, 실제로 gltf 파일을 웹 viewer 로 보려고 하면

THREE.GLTFLoader: Failed to load buffer "buffer.bin". 라는 문구로 읽을 수 없다고 한다.
3D 를 클라이언트에서 보이게 할 때 Three.js 를 사용하게 되는데 이때 3D 랜더링 된 이미지와 텍스처 파일(색상, 각도, 그림자 등의 정보가 있는 파일)이 꼭 필요하다.

다행히 이미지 파일과 텍스처 파일을 합쳐서 생성하는 옵션을 줄 수 있는 GLTFSaveOptions 객체가 있었다.

GLTFSaveOptions opt = new GLTFSaveOptions(FileContentType.ASCII);

opt.EmbedAssets = true;

scene.Save("d:\\test.gltf", opt);

이렇게 생성 하게 되면 텍스처 정보를 담은 gltf 파일을 생성할 수 있다.

[항공] 기상 (METAR/SPECI, TAF) 공부

hand-mk — Thu, 16 Apr 2026 22:37:03 +0900

METAR vs TAF?

구분 METAR TAF

구분	METAR	TAF
목적	현재 관측된 실황 보고	미래 기상 예보
발행 주기	1시간(또는 30분)마다	하루 4회(6시간 간격)
유효 기간	발행 시점의 기상	보통 24~30시간 동안의 예보
내용	실제 관측값	예보(예상)값, 변화 그룹 포함
적용 범위	공항(ARP) 중심	공항 및 반경 8km 이내

METAR RKJY 200400Z 18007KT 150V240 9999 BKN025 27/21 Q1010
          NOSIG=
          
METAR RKJJ 200400Z 23006KT 9999 BKN025 27/24 Q1009 RMK CIG025
          SLP096 8/500 9/700=          

METAR RKTU 200400Z 26010G20KT 9999 SCT030 28/22 Q1008 RMK
          SLP077 8/500 9/300=

METAR/SPECI

{보고 형식} (METAR or SPECI) - [0]

METAR

METAR

매시 정시 보고 (1시간 마다)

SPECI

METAR 보고 후 특별한 보고 상황 야기된 기상일 때

{ICAO 비행장 코드} - [1]

RKJJ

{보고 일자 및 시간} - [2]

200700Z

utc 기준

→ 20일 07 시 00분 UTC

{풍향}{풍속}{단위} {변화 풍향}

18005KT // 바람이 180도(남쪽)에서 5노트로 불고 있음.

18007KT 150V240 // 바람이 180도에서 7노트로 불고 있는데, 풍향이 150도에서 240도 사이에서 가변적으로 변화함.

18007G20KT 150V240 // 바람이 180도에서 7노트로 불고, 순간 최대 풍속(돌풍)은 20노트까지 기록됨. 풍향은 150도~240도 사이에서 가변적.

풍향/풍속(Wind)

풍향 및 풍속을 5자리 숫자로 표현

풍향

북쪽 (North) 기준 10단위 표시 [:3]

180 = 180˚

풍속(kts 단위)

풍속의 세기

18005KT
- 북쪽 기준 + 180˚ ⇒ 남쪽에서 바람이 불어 오고 있음.
- 일반적인 풍속 5kts 로 불고 있음.
18007KT 150V240
- 시계 방향으로 변화 즉, 150˚는 남동쪽
- 북쪽 기준 + 180˚ ⇒ 남쪽에서 바람이 불어 오고 있음.
- V 가변 바람.
- 북쪽에서 (180˚) 7kts 불고 있고, 남동쪽(150˚)에서 남서쪽(240˚) 로 가변적으로 바람이 분다.
18007G20KT 150V240
- ‘G‘ 는 돌풍(Gust)
- 북쪽에서 (180˚) 7kts 불고 있고, 순간 최대 풍속은 20kts 이다. 남동쪽(150˚)에서 남서쪽(240˚) 로 가변적으로 바람이 분다.
VRB03KT
- VRB : 풍향이 일정하지 않을 때
VRB05G12KT
P99KT
- 강속일 때,

{시정}

대기 중에서 물체를 육안으로 식별할 수 있는 최대의 수평 거리

9999

또는

CAVOK - 시정이 10km 이상이고, 저층운이나 중요한 기상현상이 없음을 의미

시정치가 10km 이상인 경우 : ex) 9999 또는 CAVOK
시정치가 5000m 이상 10km 이하인 경우 : 1000m 단위 ex)3000
시정치가 800m 이상 5000m 미만인 경우 : 100m 단위 ex) 800
시정이 800m 이하인 경우 : 50m 단위로 사용
SM : ex) 5SM 5마일

{기압}

Q1013 or A2992 (Q 뒤에 숫자 4자리 또는 A 뒤에 숫자 4자리)

Q 고도 수정치 : QNH/기압 1013hpa
A altimeter setting : 29.92 inches

{구름 양}

코드	약어	의미(영문)	의미(한글)
0	SKC	Sky Clear	하늘에 구름 없음
1	FEW	Few	매우 조금
2	FEW	Scattered	조금
3	SCT	Broken	약간 흩어짐
4	SCT	약간 흩어짐	약간 흩어짐
5	BKN	대부분 흐림	대부분 흐림
6	BKN	대부분 흐림	대부분 흐림
7	OVC	거의 다 덮임	거의 다 덮임
8	OVC	완전히 덮임	완전히 덮임 (흐림)
9	VV	시계 제로	시계 제로

RMK + {보충정보}

- METAR RKTU 290800Z 31009KT 6000 -TSRA FEW018CB BKN060 23/16 Q1012 
RMK CIG060 SLP123 TS B00 SW 8/300 9/700=

- METAR RKNW 290800Z 02005KT 9999 SCT060 27/12 A2989 
RMK SLP116 8/500 9/400= 

- METAR RKTN 290800Z 18004KT 9999 BKN050 BKN100 24/15 Q1012 
RMK CIG050 SLP126 8/520 9/510=

- METAR RKJK 290755Z 33014KT 5SM HZ SCT050 24/13 A2992 
RMK AO2A SLPNO T02350128 $=

- METAR RKJK 300655Z 28010KT 7SM CLR 21/13 A2988 
RMK AO2A SLPNO T02130129 $=

NSW : 중요 일기 현상이 종료 될 때
NSC : 시정만 CAVOK 조건이 안될 경우
WR : 활주로가 젖어 있는 상태
SLR : 군데군데 눈이 녹아 물이 괴어 있는 상태
LSR : 눈이 엷게 쌓여 있음
PSR : 눈이 완전히 덮여 있음
IR : 얼음이 깔려 있음
RCR : 활주로 제동 상태를 표시
PKWIND 28045/15 : Peak Wind 45kts 가 15분 있었음
WSHFT 30 FROPA : 바람이 30분경에 전선통과로 변화되었음
RADAT : 빙결 고도 정보
T02350128 : T + [온도 부호][온도 3자리][이슬점 부호][이슬점 3자리]
- 0235 0128 ⇒ 온도 23.5도, 이슬점 12.8도
- 온도는 안해도 ㄱㅊ
SLP116 : 해면기압 1011.6 hpa
- SLPNO 일 경우, 기압계 고장 등으로 해면기압 값을 산출할 수 없을 때
AO1 : 강수현상을 측정 할 수 없는 자동 기상 관측소
AO2 : 강수현상을 측정 할 수 있는 자동 기상 관측소
FBL : Feeble/Light 약한 강도를 나타내는 약어

강수현상 구분

TS : 뇌전, 천둥 번개
- BO : 뇌우가 언제 시작되는지
- ex) BOO : Thunderstrom Began at 관측소 기준 시각 00분
DR : 미미한 쏠림 현상으로 지상위로부터 2M 미만
SH : 소나기
MI : 농도가 낮은 현상
FZ : 착빙
BC : 여러 곳에 산재
BL : 날아가는 현상
PR : 부분적으로 일어나는 현상

강수형태

RA : 비
GR : 우박 덩어리 크기가 1/4인치 이상
DZ : 이슬비
GS : 눈싸라기 / 작은 알갱이 우박
SN : 눈
SG : 송이 눈
PL : 얼음 알갱이
IC : 수정빛 얼음 시정이 1~5KM 인 경우
UP : 미확인 자동관측 시스템에서만 사용

시정장애 요인

FG : 안개, 시정이 1000m 미만
HZ : 아지랑이, 시정이 5000m 이하인 경우
BR : 박무, 시정이 1000m 이상 5000m 미만
FU : 연무, 시정이 5000m 이하인 경우
PY : 분사무
VA : 화산재
SA : 황사, 시정이 5000m 이하인 경우
DU : 먼지, 시정이 5000m 이하인 경우

기타

SQ : 국지성 폭우나 눈
SS : 황사 폭풍
DS : 먼지 폭풍
PO : 황사 먼지 회오리 바람
FC : 용오름 현상

구름 종류 코드(ex. 8/300)

코드	의미(저층 구름)	참고
0	구름 없음
1	적운(공정적운)
2	적운(발달형)
3	적란운(뇌우성 구름)
4	층적운(적운에서 발달)
5	층적운(적운 아닌 것)
6	층운/조각층운(좋은 날씨)
7	조각적운/조각층운(나쁜 날씨)
8	적운+층적운
9	적란운(뇌우성 구름)

TAF

변화 지시자

	사용	비고
BECMG(Becoming)	특정기간 내 불특정 시간에 예상되는 규칙적 / 불규칙적 기상 변화를 표현하기 위해 사용	50% 이상 확률 일 때
TEMPO(Temporary)	특정기간 내 어느 시간에 예상되는 일시적 기상변화를 표현하기 위해 사용	50% 이상 확률 일 때
FM(From)	일련의 우세한 기상 현상이 뚜렷하게 변하여 다른 기상현상으로 변화할 것으로 예상 될 때 사용
PROB(Probably)	기상 현상의 변화에 대한 확신이 높지 않지만, 변화가 예상되는 기상 요소가 항공기 운항에 중대한 영향을 줄 것으로 예상 될 때 사용	30~40% 확률 일 때

[항공] 항공고시보 (NOTAM) 공부

hand-mk — Thu, 16 Apr 2026 22:31:56 +0900

항공관련시설, 업무, 절차 또는 장애요소, 항공기 운항관련자가 필수적으로 적시에 알아야할 지식 등의 신설, 상태 또는 변경과 관련된 정보를 포함하는 통신수단을 통해 배포되는 공고문을 말함

유효 기간

3개월, 장기간 유지 되려면 고시보에 보충판으로 고지해야함.

NOTAM 해석

GG RKZZNAXX
260706 RKRRYNYX
(C0910/25 NOTAMN  
Q)RKRR/QILXX/I/NBO/A/000/999/3324N12643E005
A)RKPD B)2505260705 C)2507310830
E)ILS LOC RWY 01 RESUMED NML OPS , REF AIP SUP 38/25)

{
  "ntm": "GG RKZZNAXX \\n260841 RKRRYNYX \\n(C0913/25 NOTAMN  \\nQ)RKRR/QMXLC/IV/BO/A/000/999/3727N12707E005 \\nA)RKSM B)2505281230 C)2505282000 \\nE)TWY C, TWY K(BTN G8 AND G10) CLSD DUE TO MAINT)"
}

{전문의 우선순위} {배포처}

GG RKZZNAXX

우선순위

SS
DD, FF
GG, KK

배포처

RKZZNAXX : 국내에서 배포하는 주소
RKZZNKXX : 국제로 배포하는 주소

{발행 날짜} {관제소 주소}

260706 RKRRYNYX

날짜

260706 : 26일 07시 06분 UTC

관제소 주소

RKRRYNYX : 대한민국 국토교통부 인천공항교통

{사용처 + 몇번째인지}/{년도} {발행종류}

(C0910/25 NOTAMN

→ 25년도 910번째 새로 발행된 일반 규칙, 항행용 항행 안전시설 및 통신 시설과 공항에 관한 국내 노탐이다.

사용처

발행종류

NOTAMN - New NOTAM (새로 발간)

NOTAMR - Replaces a previous NOTAM (다시 발간)

NOTAMC - Cancels a NOTAM(취소)

NOTAMS - SNOWTAM (눈 관련)

Q) {FIR} / {Q Code} / {IFR + VFR} / {목적} / {Scope(범위) A/000/999} {반경}

Q)RKRR/QILXX/I/NBO/A/000/999/3324N12643E005

→ RKRR 공역 노탐, 계기비행(IFR) 운항에만 적용, 항공기 운영자가 즉각적인 주의를 해야 하고, IFR 운항 시에 중요하다. 공항 관련 정보이며 0ft 에서 999fl 까지 적용됨.

목적

N : 항공기 운영자의 즉각적인 주의를 위해 선택됨.
B : 비행 전 정보 게시
O : IFR 운항 상 중요
M : 기타

Q-code Scope(범위)

Scope	의미(영문)	설명
A	Aerodrome	공항(비행장) 관련 정보. 활주로, 유도로, 계류장 등 지상 시설 및 공항 운영에 영향을 주는 사항.
E	En-route	항로(En-route) 관련 정보. 비행 중 항로상의 공역, 항행시설, 절차 등 운항 중간 단계에 영향을 주는 사항.
W	Navigation Warning	항행 경보(Navigation Warning). 공역 제한, 위험구역, 임시 비행 제한(TFR) 등 항로상 위험이나 제한에 관한 경보.

A){공항이나 FIR}

A)RKPD

RKRR : 인천비행정보구역 (FIR)

B, C) {시간}

B)2505260705 C)2507310830

B : NOTAM 적용되는 날짜 - 시간
- 25년 05월 26일 07:05 UTC 적용 시작
C : NOTAM 적용 종료되는 날짜 - 시간
- 25년 07월 31일 08:30 UTC 적용 만료

D) {변경 시에만}

D)25 2300-2359, 26 0000-1300 2300-2359, 27 0000-0200 0330-1300 
2300-2359, 28 29 0000-1300 2300-2359, 30 0000-1300

E) {Q Code 를 평문으로 설명}

E)ILS LOC RWY 01 RESUMED NML OPS , REF AIP SUP 38/25)

F,G) {하한, 상한}

F)SFC G)5000FT AMSL)

→ 지상부터 해발 5,000 피트까지 적용

SFC : Surface(지상 표면)
5000FT : 해발 5,000 피트

[항공] 비행계획서(FPL) 공부

hand-mk — Thu, 16 Apr 2026 22:27:03 +0900

AFTN : 항공고정통신망
ATN : 항공종합통신망
RKSIZPZX - 인천 항공교통관제센터(ATC)
RKRRZQZX - 한국 지역 항공교통관제시스템
ATC : 항공 교통 관제

예시 FPL

(FPL-SIA605-IS-A359/H-SDE1E2E3GHIJ2J3J5M1P2RWXYZ/LB1D1-RKSI1450-N0491F380 BOPTA2C BOPTA Z51 BEDES Y711 MUGUS Y742 SALMI/N0494F380Q11 TACLE/N0492F390 Q12 KABAM/M085F400 N892 MIGUG/N0489F400 N892 MELAS DCT MABAL-WSSS0543 WSAP-PBN/A1B1C1D1L1O1S2 NAV/RNP2 DAT/1FANS SUR/RSP180 DOF/250518REG/9VSHT EET/RJJJ0108 RCAA0123 RPHI0226 ZJSA0323 VVHM0331WSJC0437 WMFC0518 WSJC0534 WIIF0535 WSJC0540 SEL/FMLP CODE/76CD14 OPR/SIA PER/C RMK/ACASII EQUIPPED TCAS)

{
  "fpl": "(FPL-SIA605-IS-A359/H-SDE1E2E3GHIJ2J3J5M1P2RWXYZ/LB1D1-RKSI1450-N0491F380 BOPTA2C BOPTA Z51 BEDES Y711 MUGUS Y742 SALMI/N0494F380Q11 TACLE/N0492F390 Q12 KABAM/M085F400 N892 MIGUG/N0489F400 N892 MELAS DCT MABAL-WSSS0543 WSAP-PBN/A1B1C1D1L1O1S2 NAV/RNP2 DAT/1FANS SUR/RSP180 DOF/250518REG/9VSHT EET/RJJJ0108 RCAA0123 RPHI0226 ZJSA0323 VVHM0331WSJC0437 WMFC0518 WSJC0534 WIIF0535 WSJC0540 SEL/FMLP CODE/76CD14 OPR/SIA PER/C RMK/ACASII EQUIPPED TCAS)"
}

{전문 타입}-{항공기 식별번호}-{비행 종류}

(FPL-SIA605-IS

{전문 타입}-{항공기 식별번호}-{비행 종류}

비행계획서 제출	FPL	새 비행계획을 제출할 때 사용. 관제기관에 비행계획을 알리는 기본 메시지.	(FPL-EVA105-IS
변경 통보	CHG	이미 제출된 비행계획의 일부(항공기, 경로 등)를 변경할 때 사용.	(CHG-JNA262-RJFF0030-RKSI-DOF/250313-7/JNA262/A6147 -10/SDE2GHIJ3J4J7M3RWZ/LB1D1 -15/N0467F300 BEETL INVOK Z91 PSN Y782 BITUX Z53 BASEM Y685 GUKDO -18/PBN/A1B1C1D1L1O1S2T1 DAT/1FANS SUR/RSP180 260B DOF/250313 REG/HL8353 EET/RKRR0023 SEL/FMGS CODE/71C353 OPR/JNA RMK/TCAS II EQUIPPED) (CHG-CES2039-ZSQD0025-RKSI-DOF/250313-7/CES2039/A0111)
지연 통보 1가지	DLA	출발 예정 시간이 지연될 때 사용.	(DLA-KAL1806-RKPK0005-RKSS-DOF/250313)
취소 통보 1가지	CNL	이미 제출된 비행계획을 취소할 때 사용.	(CNL-CQH6239-ZSPD2300-RJBB-DOF/250312)
출발 통보 1가지	DEP	실제로 항공기가 출발했음을 알릴 때 사용.	(DEP-KAL1429/A7274-RKSI0009-RKPK-DOF/250312)
도착 통보 1가지	ARR	항공기가 목적지에 도착했음을 알릴 때 사용.	(ARR-VJC979-RKSI1810-VVPQ0026)
보충 비행계획	SPL	추가 정보가 필요할 때 제출하는 보충 비행계획서.	(SPL-ABCD1234 -N123AB -B737/M-SDE2E3FGHIJ1J2RWXYZ/S -RKSI1200 -N0450F350 DCT KMC DCT -RJTT0200 -DOF/250521 RMK/DESTINATION CHANGED FROM RJAA TO RJTT DUE WX)
도착예정 통보	EST	특정 지점(경계, 관제구역 등)에 도착 예정 시간을 알릴 때 사용.	(EST-CSZ673/A4453-ZSWX0047-LAMEN/0116-RJBB)

SIA605 : 항공기 식별 번호
IS : IFR

비행 규칙

코드	의미	설명	예시
I	IFR	계기비행방식 (Instrument Flight Rules)	대부분의 상업 항공편
V	VFR	시계비행방식 (Visual Flight Rules)	경비행기, 훈련비행 등
Y	IFR → VFR	처음 IFR로 시작 후 VFR 전환	훈련 비행 등
Z	VFR → IFR	처음 VFR로 시작 후 IFR 전환	비행 조건에 따라 변경되는 경우

비행 유형

코드	의미	설명	예시
S	Scheduled Air Service	정기 항공편	대한항공 KE123, 아시아나 OZ102 등
N	Non-scheduled Air Transport	비정기 항공 운항	전세기, 화물 전세기 등
G	General Aviation	일반 항공	개인용 비행기, 레저 비행 등
M	Military	군용	군 작전, 수송 등
X	Other	기타	특별 임무, 특수 작전 등 (별도 신고 필요)

{항공기 기종} / {항적 난류 강도(Wake Turblance)} - {장비(Equipment)} / {장비(Equipment)}

ex. -A359/H-SDE1E2E3GHIJ2J3J5M1P2RWXYZ/LB1D1

Wake-Turblacne - 항공기 날개 끝에 발생하는 소용돌이가 공기 중에 남는 현상
그래서 뒤에 따르는 항공기에 위험을 줄 수 있어 항적 간격을 결정할 때 중요함.

코드	범주	기준	예시 항공기
L	Light	≤ 7,000 kg (MTOW 기준)	Cessna 172, Piper PA-28
M	Medium	7,001 ~ 136,000 kg	B737, A320, Embraer E190
H	Heavy	> 136,000 kg	B777, A340, A350, B747
J	Super	특수 초대형 항공기	A380 전용

L → J 로 갈 수록 간격을 더 띄워야 함.

{출발공항}{출발시간 UTC 기준}

ex. -RKSI1450

Departure Aerodrome 과 출발 시간
RKSI : 인천공항 / 14:50분 출발

{순항속도 + 순항고도} {비행경로들} / {순항속도 + 순항고도 이면 앞선 비행 경로에서 속도 및 고도 변경}

ex. -N0491F380 BOPTA2C BOPTA Z51 BEDES Y711 MUGUS Y742 SALMI/N0494F380 Q11 TACLE/N0492F390 Q12 KABAM/M085F400 N892 MIGUG/N0489F400 N892 MELAS DCT MABAL

{순항속도 + 순항고도} {비행경로들} / {순항속도 + 순항고도 이면 앞선 비행 경로에서 속도 및 고도 변경}
N~~ : 순항속도(Crusing Speed) + 순항고도(Crusing Level)
- Crusing Speed : 항공기 상승 후 고도 도착하여 ‘순항’ 단계에서 유지하는 속도
- Crusing Level : 고도
- ex) N0491F380
  - N: 노트 (단위)

표기	의미	예시	해석
Nxxxx	노트(knots)	N0485	485노트
Kxxxx	km/h	K0830	830km/h
Mxxx	마하(Mach)	M082	마하 0.82

0491 : 속도 (491 노트 순항)
F : 비행고도(100피트 단위) → 38,000피트 고도

표기	의미	예시	해석
Fxxx	Flight Level (100ft 단위)	F380	FL380, 38,000피트
Axxx	Altitude (100ft 단위)	A045	4,500피트
Sxxxx	Metric level (10m 단위)	S1130	11,300미터
Mxxxx	Altitude (10m 단위)	M0840	8,400미터
VFR	시계비행고도	VFR	VFR 운항(고도 자유)

- rst : 38,000 피트에서 491 노트로 순항

{도착공항 + 소요시간} {대체 공항}

ex. -WSSS0543 WSAP

{도착공항 + 소요시간} {대체 공항}
WSSS0543 : 싱가포르 창이 공항까지 5:43분 소요
WSAP : 파야 레바 공항에 대체 착륙 가능
rst : 싱가포르 창이 공항까지 5:43분 소요 되며, 파야 레바 공항에 대신 착륙 할 수 있습니다.

DOF/{비행날짜}

ex. -PBN/A1B1C1D1L1O1S2 NAV/RNP2 DAT/1FANS SUR/RSP180 DOF/250518 REG/9VSHT EET/RJJJ0108 RCAA0123 RPHI0226 ZJSA0323 VVHM0331 WSJC0437 WMFC0518 WSJC0534 WIIF0535 WSJC0540 SEL/FMLP CODE/76CD14 OPR/SIA PER/C RMK/ACASII EQUIPPED TCAS)

PBN/{장비}
NAV/{장비}
DAT/{장비}
SUR/{장비스펙}
DOF/{비행날짜}
- 250518 : 25년 05월 18일
REG/{항공기 등록 부호}
- 차량 번호판 같은 느낌

[멋쟁이사자처럼] 전국 대학 연합 아이디어톤 1등 수상 회고

hand-mk — Fri, 10 Apr 2026 18:15:17 +0900

1. 서론

필자는 취업을 하면서 부트캠프와 같은 교육 프로그램을 이수해본 적이 없다.

대신, 학부생 시절 '멋쟁이사자처럼' 이라는 전국 대학 연합 IT 학술 동아리에 들어가 2년동안 활동했다. '멋쟁이사자처럼' 소위 말하는 '멋사' 는 연단위로 기수를 진행하고 매년 동아리에 참여한 학교들에 아이디어톤, 해커톤 참가 기회가 주어진다.

필자는 11기, 12기 활동을 했고 이 중 12기 아이디어톤에서 운좋게 1등을 수상하였다..!

블로그를 이관하면서 수상 회고록을 다시 작성 해본다.

2. 본론

2.1. 기획

공모전 주제는 다음과 같았다.

"IT 기술을 활용하여 현대인의 건강 (wellness) 문제를 해결할 수 있는 아이디어를 제시하시오.”

'현대인의 건강(wellness)' 이라는 단어를 봤을 때 많은 팀들이 신체 건강과 관련된 내용을 많이 다룰거라고 예상했다. 때문에 수상을 위해서라면 단순 신체 건강이 아닌 정신 건강 문제를 해결해야 한다고 생각했다. 호기롭게 여러 논문과 기사들을 스크랩하기 시작했으나, 보통 다양한게 아니였다... 그렇게 기획이 산으로 가는 중 공모전 경험이 많은 동기가 '사회와 연관된 공모전에서는 정부 정책을 봐야 한다' 고 팁을 주었다.

실제로 2024 정부 정책 보고서를 확인해보니

AI 갈등 관리 플랫폼을 구축 해서 집단간 갈등을 완화하는 것이 2024 정부의 목표였다.

'AI 를 접목한 갈등을 완화할 수 있는 플랫폼'

을 만드는 것을 목표로 하고 해당 아이디어톤 주제와 어떻게 연관을 지어서 기획 의도를 설명할지가 관건이였다. 갈등과 현대인 건강과의 연관관계를 증명하면 우리의 서비스가 공모전 주제에 부합하게 되는 것이였다.

이 과정에 정말 많은 시간을 투자하였고, 당시 정권 대립이 고조 됐던 탓이라 핫 키워드였던 확증 편향 현상과 연관지어 갈등의 원인과 이로 인한 정신적인 스트레스가 현대 정신 건강을 해한다는 결론으로 이어졌다.

이러한 추론과 뒷받침하는 근거는 대학이나 연구소 논문을 출처로 두었고, 발표자료에 모두 기입하였다..!

2.2. 예선 2차

예선 1차는 본교 내에서 대표팀을 선출하는 것이였는데, 아슬아슬한 차이로 우리팀이 올라갔다.

예선 2차는 멋쟁이사자처럼 대학이 조별로 묶어준 대학들끼리 진행하는 방식이였다. 필자를 포함한 각 학교 대표들이 초대된 톡방에서 예선 2차 진행 방식에 대해 정했고, 오프라인으로 진행하기로 결정했다.

각 학교 대표 분들이 꼼꼼하게 준비해주시고 배려해주셔서 원활히 진행할 수 있었다.

결과적으로 우리 학교가 본선에 올라갈 수 있었다!

2.3. 본선

본선 장소는 멋쟁이사자처럼 본사 서울 종로구 청진동 246번지 디타워에서 진행됐다.

(본사가 꽤 이뻐서 사진 찍고 싶었는데.... 발표자는 맨 앞에 앉으라고 해서......ㅠ)

발표 순서는 제비뽑기로 발표자 한명씩 나와서 뽑았다...ㅎ

필자는 8번째 순서를 뽑았다..!

본사 오면서 지인들에게 연락을 많이 받았다.

많이 떨리냐는 질문을 많이 받았는데, 에이 뭐 1차 2차 예선 때 하던 것 처럼 하면 되는건데 왜 떨리냐. 라고 말을 했다.
발표 순서가 돼서 앞에 나가고 그 말을 한 걸 후회했다. 발표 직전까지 심장 bpm 이 120 이상 찍혀서 애플워치 알람이 한번 울렸고, 발표를 시작하고 나서부터는 별로 안떨렸다.

본선 발표 영상

영상엔 빠져 있지만 발표 후 심사 위원분들의 QnA 시간이 있다. 길진 않고 1-2개 정도 질문을 하신다.(안한 팀들도 있긴 했다.)

첫 번째 질문은 '감정 분석 기능은 어떻게 구현 했나요?' 라는 질문이였고 어느정도 생각 해 둔 답변이 있어서 나름 유연하게 답변했던 것 같다..

두 번째 질문은 '주요 타깃이 누구인가?' 에 대한 질문이였다.

개인적으로 두번째 질문이 제일 어려웠는데, 공공성을 띄는 서비스라 '이걸 타깃을 확정 지을 수 있나?' 라는 생각이 들었다. 그래서 답변은 '아직 잘 모르겠습니다..!' 라고 했지만, 지금와서 생각해보면 B2B 느낌으로 정부 부처를 대상으로 판다고 했다면 어땠을까라는 아쉬움이 든다..

모든 대학 발표를 마치고 잠깐의 쉬는 시간을 가졌다.

3등, 2등, 1등 순으로 발표가 진행됐는데, 2등까지 안나와서 올해도 떨어졌구나 하는 순간 우리 학교 이름이 1등 차례에 발표됐다..!

(놀라는 모습을 잘 담아주신 멋사 대학 관계자 분 감사합니다...)

부족한 실력에도 불구하고 좋은 평가를 받아서 너무 다행이다.

3. 결론

팀장을 맡아서 예선 탈락을 하면 어쩌나 라는 걱정도 많았다.

필자가 발표를 맡아서 이목이 집중됐지만 사실 팀원들이 부족한 부분을 묵묵히 채워나가줘서 이런 좋은 성과를 얻을 수 있었던 것 같다. 12기 우수 수료자로 선정 될 수 있었던 것도 이 프로젝트를 정성스럽게 준비한 결과라고 생각한다!

[AWS] AWS Certified Solutions Architect – Associate 자격증 취득 회고

hand-mk — Fri, 3 Apr 2026 17:00:07 +0900

1. 서론

최근 AWS SAA 자격증을 합격하였다 :)

필자는 글을 쓰고 있는 현재 SI 업계 개발자로 딱 1년째 일하고 있다. 부족한 실력에도 불구하고 인천국제공항 공사 발주 프로젝트를 2개 담당하고 있는데, 큰 문제 없이 수행하고 있어 감사하게도 긍정적인 평가를 받고 있다.

현재 회사 생활에서는 큰 부담이나 걱정이 없으나, 앞으로의 나의 기술적인 비전은 걱정되는건 사실이였다. SI 특성상 안정성을 추구하기 때문에 새로운 기술을 습득하기 어렵기 때문이다. 부족한 부분을 채워 나가보고자 2026 상반기 빅테크 채용공고들을 보았고, 많은 부분들이 부족하지만..ㅎ 크게 AI, 클라우드 경험과 영어 스펙이 부족하다고 느꼈다.

올해 첫 자격증으로는 클라우드를 공부해보고자 마음 먹었고 이를 준비하는 방법과 느낌점을 공유하고자 회고록을 작성해보고자 한다.

2. 본론

2.1. 왜 AWS SAA 였을까?

먼저 필자는 AWS, GCP, NCP 를 사이드 프로젝트 하면서 인스턴스 생성, 방화벽 설정 등 간단하게만 사용해본 경험이 있다. 그 중 AWS 가 가장 친밀하지 못했다.. 일단 개발 공부를 하면 'AWS 해킹썰' 하나씩은 갖고 있을거다. 본인도 마찬가지로 이유 없는 과금을 맞았던 경험이 있었고, 결국 어디서 돈이 새는지 못찾고 해당 계정을 비활성화 시켜둔 경험이 있다.

다시는 이런 바보같은 짓을 하고 싶지 않았고, 나 뿐만 아니라 모두에게 빈번하게 발생하는 일이라면 더더욱 많이 써보고 공부를 해야 하지 않을까라는 생각을 했다. (물론, 가고 싶은 회사들에서도 요구하는 역량이라는 것이 가장 크다)

좋은 기회로 개발자 지인 추천을 통해 AWS 한국사용자모임-AWSKRUG 에 들어갈 수 있었고, 타이밍이 좋게 여기서 AWS SAA 자격증 취득 스터디가 새로 생겼다. 실무에서 클라우드를 사용하지도 않아 노베이스인 내 입장에선 좋은 기회라고 생각이 들어 고민없이 스터디에 참여했다.

2.2. SAA 스터디 - AWSKRUG 자격증 소모임

AWSKRUG 자격증 소모임은 첫 오프라인 OT 를 제외하곤 모두 온라인으로 진행된다고 하여 직장인인 나에겐 더더욱 좋은 소모임이였다. 오프라인 OT 는 테헤란로에 있는 AWS Korea 본사에서 이뤄졌고, meetup.com 을 통해 신청 할 수 있었다.

엘리베이터 내리자마자 AWS 로고가 반겨주는데, 가슴이 웅장해진다..

입장할 때 출입증을 나눠준다. 사진으로 남기진 못했는데, 여러 다과가 준비돼 있었고 Nespresso 캡슐커피 & 머신이 있어 무한대로 먹을 수 있었다. 전반적인 스터디 일정을 30분 가량 설명해주시고 김선우 멘토님께서 '이런 느낌으로 나올꺼에요!' 일깨워주시기 위해 만드신 25문제 웹앱 모의고사를 풀어보는 시간도 가졌다.

나 제외하고 대략 30명 정도 오셨다. 재학생도 있긴 했지만 거의 대부분 직장 퇴근하고 오셔서 대단하다고 생각이 들었다.

오프라인 OT 이후 본격적인 자격증 스터디가 시작됐다.

자격증은 3월 내 취득을 목표로 준비했고, 김선우 멘토님께서 정적 페이지에 Lambda 기반 스터디 기록 웹을 배포해주셔서 여기에 공부한 내용을 기록했다.

2.3. 개인 학습 방법

소모임에서는 AWS SkillBuilder 를 먼저 공부해보고, 추가적인 내용은 외부 강의나 블로그를 참고하여 공부하는 것을 추천했다.

https://skillbuilder.aws/category/exam-prep/solutions-architect-associate-SAA-C03

AWS Skill Builder

skillbuilder.aws

여기에서 필터를 적용하여 무료 플랜 교육을 듣고, 문제를 풀어볼 수 있다.

본격적인 서비스 공부에 앞서 아래 링크에 있는 Official Practice Question Set: AWS Certified Solutions Architect - Associate 를 한번 풀어보는 걸 추천한다. SAA 시험과 유사하게 나오는데, 이 시험을 70% 이상 맞출 수 있으면 바로 시험 보러 간다고 될 수준이다.

https://skillbuilder.aws/learn/6NV91XYP1P/official-practice-question-set-aws-certified-solutions-architect--associate-saac03--/C4X6F66JQX

AWS Skill Builder

skillbuilder.aws

나의 결과는.... 처참했다..ㅎ

물론 오답을 정리하고 조오금은 나아졌지만, 솔직히 처음 풀 때 맞췄던 5문제도 제대로 알고 푼 건 아닌거 같다.

위기감을 느껴 SkillBuilder 에 있는 강의들을 들어봤다. 솔직히 온프레미스 환경에서 일하고 있는 나에겐 어려웠다.

서비스에 대해 '이걸 어디에 쓰는지', '왜 쓰는지', 정리된 내용이 아니였고 '시험에서 이런 서비스들이 나오니 공부하세요.' 의 느낌이 강했다. 그래서 찾게 된게 가장 유명한 Udemy 강의다.

https://www.udemy.com/course/best-aws-certified-solutions-architect-associate/?srsltid=AfmBOoqhEgHDqlrLNx2a5sLzkztiVJgF9zXae8qZ8piVJDTypUi5BnsP

【한글자막】 AWS Certified Solutions Architect Associate시험합격! 2025

[2023년 3월]: AWS UI 변경 및 시험 내용 변경에 맞춰 강의 내용이 업데이트 되었습니다! (SAA-C03) <ul><li>AWS 초보도 학습할 수 있는 친절한 강의!<

www.udemy.com

사람들 후기가 많아 별 고민 없이 결제해서 퇴근하고 주중에 최소 2시간씩, 주말에는 4시간씩 들었다.

본 강의에서는 단순 AWS 서비스에 대해 줄줄줄 설명만 하는게 아니라 간단하게 실습하는 영상이 있다. 때문에, 나같이 온프레미스에서 개발을 하고 있고 클라우드에 대한 지식이 전무한 분들에게 매우 추천한다.

Udemy 강의를 전부 듣고, 이전보단 AWS 서비스들에 대해 넓게 이해할 수 있었지만 워낙 서비스들이 많았기에 시험을 패스할 수 있겠다란 확신이 없었다. 그래서 찾아보니 유명한 dump 문제 사이트를 찾을 수 있었다.

https://free-braindumps.com/amazon/free-saa-c03-braindumps/page-2

Free SAA-C03 Practice Questions & AI Tutor | Free-Braindumps.com

Hay! I’m your AI study assistant for the SAA-C03 exam. Ask me anything about the exam or the questions on this page, and I’ll break it down so it actually makes sense. You want it in a different language? Just say it.

free-braindumps.com

다른 분들은 600문제, 800 문제를 푸신 분들도 계셨는데, 애초에 준비기간이 3주였던 나로썬 100문제가 최선이였다.

확실히 문제들을 접해보니, 처음보는 서비스들이 꽤 있었고 오답을 정리하면서 부족한 지식들을 채워나갔다.

2.4. 시험 당일

필자는 SRTC 에서 시험을 봤다. 오전 9시가 시험 시작이라 8시 30분에 도착했는데, 보안 서약서 작성하고 희망하면 바로 시험 응시 할 수 있다고 해서 바로 시험장으로 들어갔다.

https://maps.app.goo.gl/b4KnUybt6RiX6R7y7

SRTC · TGL 402호 KR 서울특별시 강남구 봉은사로 303 경복빌딩 4F

★★★★☆ · 교육 테스트 서비스

www.google.com

시험장 내부는 독서실 같은 느낌이였고, 책상에 모니터가 보인다. 화면에 보이는 버튼을 누르면 시험에 응시할 수 있다. 오전 시험이라 사람들이 많이 없을 줄 알았는데, 생각보다 많이 있었다. 대략 15명정도..?

시험장에 대한 걱정이 많았는데, 깨끗하고 시험을 보기엔 모자람이 없는 공간이였다. 특히 시험 감독관님들이 친절하게 응대해 주셔서 맘편히 시험을 응시할 수 있었다.

2.5. 결과 발표

결과는 당일 저녁 8시쯤 나왔다.

사실, 시험 보고 나오면서 70%는 다시 봐야지... 생각하고 있었다. 15문제 정도 플래그를 걸어뒀는데 사실상 처음보는 서비스들이였다. 65문제 중에 15문제는 채점이 안되는 문제라고 해도 불안했다.

더군다나, 응시 후 5시간 이내로 메일로 결과 알려준다고 했는데 저녁 시간까지 안와서 '떨어졌구나..' 싶었다. 혹시나 하는 마음으로 https://cp.certmetrics.com/ 에 들어가서 확인해보니 합격 결과가 나와있었다.

749점으로 간당간당하긴 했다..

섹션별로 성적을 간략하게 보여주는데, 도메인 2에서 공부가 부족했던 것 같다. HA 관련 아키텍처를 좀 더 고민하고 공부해야겠다.

3. 결론

물론 자격증 취득이 목적이였긴 하지만, 강의 실습을 통해 왜 클라우드가 좋은지를 몸소 느꼈던 경험이였다. 로드밸런싱 실습을 할 때 버튼 딸깍으로 ALB 를 만들고, AMI, Auto-Scailing 이 적용된 EC2 인스턴스 여러개를 단 몇초만에 생성하여 물리적인 서버 없이 운영환경을 만들 수 있다는 점이 가장 큰 장점인 것 같다.

또한, AWS 에는 일반적으로 알고있는 EC2 서비스 외에 좋은 서비스가 너무 많다. 그런 서비스들이 운영 오버헤드를 줄임으로써 개발자가 오로지 프러덕팅에만 집중 할 수 있는게 또 하나의 장점인 것 같다. 이래서 AWS AWS 하는구나.... 서비스 운영 환경에 가서 내 지식을 토대로 기여해보고 싶은 생각이 더 확고해졌다..!

마지막으로 ALB 연습하다가 녹화한 영상으로 마무리..

[MCP] Claude + IntelliJ IDEA 2025.2.4 (Ultimate Edition) 연동

hand-mk — Mon, 23 Feb 2026 16:18:31 +0900

1. 서론

최근 MCP 가 개발 업계에서 매우 핫하다. 필자의 경우 Gemini 유료 구독 (3.1 Pro Model) 를 사용하여 개발을 했으나, 프롬프트에 단순히 입력하고 답변받는 구조에 지쳤다. 그래서 Claude 로 갈아타서 MCP 서버 구성을 진행해보고자 하였고 그 중 IntelliJ 연동을 첫번째로 진행하였다. 이에 관한 내용이다.

2. 본론

2.1. MCP 란?

`MCP(Model Context Protocol)` 는 AI 를 외부 시스템에 연결하기 위한 일종의 프로토콜이다. 우리가 흔히 얘기하던 HTTP 프로토콜과 같이 AI 를 다른 응용프로그램이나 서버에 연동하는 프로토콜이다.

MCP를 사용하면 Claude나 ChatGPT와 같은 AI 를 단순히 프롬프트를 웹에서 입력하고 답변 받는것이 아닌, 로컬에 있는 파일에 접근 가능하게끔 할 수 있어 일일이 복붙을 안해도 된다. 뿐만 아니라, 다른 서버에 연동 (ex. Slack, Gmail 등) 하여 업무를 시킬 수 도 있다.

더 자세한 내용은 공식문서를 확인하면 이해할 수 있다.

https://modelcontextprotocol.io/docs/getting-started/intro

What is the Model Context Protocol (MCP)? - Model Context Protocol

What is the Model Context Protocol (MCP)?

modelcontextprotocol.io

2.2. Claude Desktop 설치

https://claude.com/download

Download Claude | Claude

Download Claude for desktop and mobile. Access AI assistance natively on Mac, Windows, iOS, and Android across all your devices.

claude.com

공식 홈페이지에서 해당하는 OS 에 맞게 설치하면 된다.

2.3. IntelliJ Plugin MCP Server 설치

Claude 에서 IntelliJ 에 연동을 하려면 `MCP Server` 플러그인을 설치해야 한다.

IntelliJ 상에서 다음과 같이 입력해 Setting > Plugins 창을 연다.

# 윈도우
Ctrl + Alt + S

# 맥
Command +

상단에 MCP Server 를 입력하여 해당 플러그인을 설치한다.

해당 플러그인을 설치하면 Settings 왼쪽 탭에 MCP Server 가 생긴걸 확인할 수 있다.

`Enable MCP Server` 체크 > Clients Auto-Configuration 하위 Claude App `Auto-Configure` 클릭

하면 오른쪽에 초론색 체크표시가 뜬다. 이러면 사실상 연동이 끝이다.

이전 레거시 IntelliJ 의 경우 자동으로 claude_desktop_config.json 업데이트가 안된다고 알고있다.
해당 방법으로 되지 않을 경우, 수동으로 json 파일을 수정해줘야 한다.

2.4. MCP 연동 확인 방법

연동을 확인하는 방법은 `Claude Desktop` 앱 상에서 확인 가능하다.

왼쪽 하단 설정 > 커넥터 > 연동된 환경 확인 가능하다.

2.5. 연동안됨?

처음엔 상기 내용으로 했을 때 연동이 되지 않았다.

여러 글들을 보니, 왼쪽 하단 설정 > 개발자 > 구성 편집 을 눌러 ` claude_desktop_config.json` 을 확인해보라고 했다.

필자의 경우 애초에 AppData\Roaming\Claude 경로가 없다고 떴다.

종종 이런일이 발생할 수 있다고 한다. 이럴땐 그냥 삽질하지 말고 지웠다가 다시 설치하면 자동으로 해당 경로에 파일이 생성된다.

연동이 잘 되면, 실제로 설정 json 파일에 다음과 같이 자동으로 jetbrains mcpServers 설정이 들어가 있어야 한다.

이제 연동 잘 됐는지 실제로 프롬프트를 넣어보면 프로젝트를 읽어 분석하고 답변해주는걸 확인할 수 있다.

[비동기 이벤트 처리] Inotify + RabbitMQ를 활용한 실시간 파일 감지 및 비동기 처리 파이프라인 구축

hand-mk — Fri, 9 Jan 2026 17:06:56 +0900

1. 서론

회사에서 폐쇄망 운영 환경의 SI 사업에 투입됐다.

본 사업의 목표는 일 평균 10만건 데이터를 송수신 하는 인터페이스를 구축 및 고도화 하는 것이다. 보안상 상세하게 기재하진 못하지만 간단하게 운영환경을 기술하자면, 총 3대의 서버 (Rocky Linux 9.5) 가 구동된다. 물리적인 서버 3대가 있는 이유는 서버 이중화 와 예비 서버 용도이다. 이 3대 중 한 1대만 Active 상태를 유지하고 해당 서버를 통해 항공 데이터(.txt) 가 송수신된다.

데이터 양은 하루 평균 10만건이다. 또한, 데이터 종류가 8가지이고 데이터 종류별로 타깃 단위 시스템에 매핑해서 송수신 해야 하는데 이 단위 시스템 수만 118개이다.... ㄷㄷ 처음엔 막막했지만 다행히 이 중 15개 시스템에만 연계가 되게끔 인터페이스를 구현하면 된다는 얘기를 듣고 조금 괜찮아졌다.

개발이 마무리 된 시점에서 연계 시스템을 구축하면서 겪었던 문제와 고민했던 내용을 기록해보고자 블로그에 작성해보고자 한다.

2. 본론

데이터 양을 보고 예전 <GAGU> 사이드 플젝에서 채팅 기능 구현할 때 사용했던 `RabbitMQ` 를 무조건 사용해야겠다고 생각이 들었다. 문제는 '실시간으로 데이터를 어떻게 감지하냐' 였다. 실시간으로 데이터를 감지 하는 내용을 얘기 하기 전에 송수신 과정에서의 요구사항에 대해 이해가 필요할 것 같다.

발주처에서 요구하는 송수신 과정은 다음과 같이 이루어 진다.

1. 시스템 내 FDS (File Delivery System) 에 송신 하고자 하는 파일 삽입 -> Gateway 의 /*/temp 디렉토리로 파일 전송

2. /temp 디렉토리에서 해당 데이터 바디 값이 MDD 를 준수하였는지 유효성 검증 후 /succ 또는 /fail 폴더로 이동

3. /succ 디렉토리로 들어오는 데이터만 연계 시스템으로 전송 (.txt 파일 생성)

º 보안상 문제로 System A, System B 로 정의
º System A 를 기준으로 송수신 정의됨

다행히 1번과 2번은 레거시 FDS 시스템에 종속적이여서 바꾸기 힘들다고 해서 /succ 파일에 들어오는 데이터만 문제없이 연계하면 되는 상황이였다.

필자가 이러한 요구사항을 구현하기 위한 시나리오는 다음과 같다.

1. 메시지 및 타깃 시스템별 데이터를 담는 Queue 생성

2. /*/succ 로 들어오는 데이터를 실시간으로 감지 (단, 중복으로 데이터를 감지하면 안됨)

3. 실시간으로 감지된 데이터를 정의된 라우팅 키로 Queue 에 삽입

4. Queue 에 적재된 데이터를 타깃 시스템에서 비동기로 처리

이 시나리오에서의 핵심은 실시간 감지였다..!

그래서 리눅스 환경과 호환이 잘 되는 디렉토리 이벤트 감지 서비스를 부지런히 찾아보았고, 이 과정에서 Polling 감지, Telegraf 사용, Inotify 커널 이벤트 라는 방법들을 직접 사용해보고 비교해보았다.

2.1. 신규 데이터 실시간 감지

2.1.1. polling (full-scan) - 성능 이슈 염려하여 기각

일단 가장 간단하게 '구현만' 할 수 있는 방법은 polling 방식이 있을 것 같았다.

주기적으로 `linux date(서버 현재 시각)`과 파일 생성시간을 비교하여 최신 일자일 경우 신규 데이터로 감지하는 것이다.

이렇게 되면 스케줄러로 주기적으로 현재 시간과 +- 오차 시간을 적용하여 비교 후 처리 할텐데, 예외 상황이 많을 것 같았다. 스케줄러가 동작하지 않거나 지연이 됐을 때 데이터가 누락되는 현상이 발생할 수 있고, polling 으로 불필요한 조회 연산을 지속적으로 호출하게끔 되어 해당 방법은 소거하였다.

2.1.2. Telegraf - Queue 삽입까지 너무 오래걸려서 기각

모니터링 시스템 구현 관련 라이브러리를 찾던 중 `Telegraf` + `Grafana` 조합을 많이들 사용한다는 것을 알게 되었고, 이 중 `Telegraf` 에 실시간 감지 기능이 내장돼 있다는 걸 확인했다.

`Telegraf`는 `InfluxData`에서 개발하였으며 데이터베이스나 서버의 데이터 (디렉토리도 가능) 를 수집하는 Agent 역할을 한다. Docker hub 에도 공식 이미지가 있고, `telegraf.conf` 라는 설정 파일로 Agent 를 조작하는 느낌이라 설정이 간편했다.

https://hub.docker.com/_/telegraf

telegraf - Official Image | Docker Hub

Quick reference Supported tags and respective Dockerfile links Quick reference (cont.) What is telegraf? Telegraf is an open source agent for collecting, processing, aggregating, and writing metrics. Based on a plugin system to enable developers in the com

hub.docker.com

테스트 용으로 해당 디렉토리에 새로 생성 + 이동 됐을 때 로그로 바디 값을 출력하는 설정을 주었다.

telegraf.conf

[agent]

# 데이터 수집 주기
interval = "10s" 

# 수집된 데이터 처리 주기
flush_interval = "10s"

[[inputs.tail]] # 파일 내용 추적 섹션

# 감시할 파일 경로
files = ["/watch-data/*.txt"]

# 파일 새로 생겼을 때 조작
from_beginning = true

# 파일 안에 있는 값 그대로 사용
data_format = "value"

# 데이터 타입 지정
data_type = "string"
name_override = "txtfile_monitor"

[[outputs.file]]

# 파일 바디 값 출력
files = ["stdout"]
data_format="json"

이후 Docker hub 에 기재돼 있는대로 container 구동을 하였다.

docker run -d --name telegraf
  -v {telegraf.conf 실제 경로}:/etc/telegraf/telegraf.conf:ro \
  -v {타겟 디렉토리 경로}:/watch-data \
  telegraf

테스트는 다음과 같이 진행했고, 데이터의 바디값이 정상적으로 출력됨을 확인했다.

1. 새로운 txt 생성

2. /test 폴더 mv 명령어로 이동

3. 로그 확인

이후 단순 출력하는 부분을 RabbitMQ Queue 로 삽입 되게끔 수정하여 테스트 했을 때, 정상적으로 삽입되어 원하는 기능을 테스트 해볼 수 있었다.

[agent]
interval = "10s"
flush_interval = "10s"
metric_batch_size = 1

[[inputs.tail]]
files = ["/watch-data/*.txt"]
from_beginning = true
data_format = "value"
data_type = "string"
name_override = "txtfile_monitor"

[[outputs.amqp]] # rabbitMQ 로 삽입
brokers = ["amqp://guest:guest@{서버 IP}:5672"]
data_format = "json"
exchange = "test.exchange"
exchange_type = "direct"
routing_key = "test.routing.key"
delivery_mode = "persistent"
exchange_durability = "durable"

다만 아쉬운건 이벤트 감지는 즉각적으로 일어나지만, Queue 까지 가기까지의 시간이 너무 오래 걸렸다.

단순히 데이터 1건을 이벤트 감지하고 Queue 에 삽입하는데 10초가 소요됐다.

이유는 `Telegraf` 가 `Node-exporter` 처럼 메트릭 수집 도구 용도로 만들어졌기 때문이다. 어떤 데이터가 들어오든 내부적으로 `Telegraf Metric` 이라는 타입의 데이터로 변환한다.

`데이터 읽기` -> `Telegraf Metric 변환` -> `버퍼에 저장` -> `Output 플러그인에서 다시 JSON으로 변환` -> `전송`

단순히 데이터를 감지하고 Queue 에 삽입하는 것이 아닌 앞단에 데이터 변환 과정이 있어 오래 걸린다고 한다..

이 과정을 커스텀 하는 것이 어려워 보였고, 만약 10만건이 동시에 몰렸을 때 수행된다고 한다면 병목현상이 발생할 것 같았다.

또 다른 문제는 Queue 에 보낼 때이다. '하나 보낼 때 오래걸리면, 대량을 묶어서 보내면 되지 않나?' 라고 생각이 들 수 있다.

`Telegraf` 는 효율성을 위해 기본적으로 데이터를 Batch 로 묶어 보낸다. 그래서 앞선 `Telegraf.conf` 에서 `metric_batch_size = 1` 로 설정을 할 수 있고 만약 전송 성능을 향상 시키려면 이 값을 높이면 된다.

만약 1000개를 한 배치로 보내는데 이 중 100번째 데이터가 문제가 있다고 하면 데이터 정합성 문제가 발생할 수 있겠다 싶었다.

이러 저러한 이유로 `Telegraf` 도 아쉽게 기각됐다.

2.1.3. Linux Inotify - 제일 적합

`Telegraf` 를 떠나보내고.. 지친 상태로 README.md 를 읽던 중 Telegraf 가 Linux-Inotify 기반으로 만들어진 것을 알게 됐다.

https://github.com/influxdata/telegraf/blob/master/plugins/inputs/tail/README.md

telegraf/plugins/inputs/tail/README.md at master · influxdata/telegraf

Agent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data. - influxdata/telegraf

github.com

(이래서 README.md 를 잘 읽어야.....)

이러한 이유로 Inotify 를 써보게 됐다.

`Inotify` 는 리눅스 커널에 내장된 파일 시스템 감시 서브시스템으로 별도의 설치가 필요 없지만, 이를 특정 디렉토리를 감시하게끔 커스텀하고 RabbitMQ 와 연동하기 위해선 `inotify-tools` 패키지를 써야 된다고 한다.

Linux 내장 기능이기 때문에, Docker 기본 이미지는 가벼운 Linux 이미지를 사용하였고 관련된 패키지들을 빌드할 때 설치하였다.

Dockerfile

# 1. Alpine Linux 기반
FROM alpine:3.18

# 2. inotify-tools, python3, pip 설치
RUN apk add --no-cache inotify-tools python3 py3-pip

# Python 전용 RabbitMQ 통신 프로토콜 라이브러리 패키지
RUN pip3 install pika --break-system-packages

# 이벤트 발생시 RabbitMQ Queue 삽입 로직
COPY publisher.py /publisher.py

# Inotify-tools 스크립트
COPY watch-and-publish.sh /watch-and-publish.sh
RUN chmod +x /watch-and-publish.sh

# 실행
CMD ["/watch-and-publish.sh"]

`Dockerfile` 에 있는 `/watch-and-publish.sh` 가 `inotify-tools` 를 사용해 특정 디렉토리에 신규 파일 생성 이벤트를 감지하는 스크립트고, `publisher.py` 가 Linux - RabbitMQ 서버 간 연동을 해주는 파이썬 코드다.

watch-and-publish.sh

WATCH_DIR_INSIDE_CONTAINER=${WATCH_DIR:-"/data"}

echo ">>> File Watcher started."
echo ">>> Watching: $WATCH_DIR_INSIDE_CONTAINER"
echo ">>> Target RabbitMQ: $RMQ_HOST (AMQP)"

inotifywait -m -q -e close_write -e moved_to --format '%w%f' "$WATCH_DIR_INSIDE_CONTAINER" | \
python3 -u /publisher.py

여기에서 inotifywait이 특정 디렉토리를 관측하다가, 이동 이벤트를 감지하면 해당 파일 경로를 stdout 하고 파이프 구조를 통해 publisher.py 이 stdin으로 받는 구조다. 결국 python 에는 이벤트가 감지된 파일 경로가 들어간다.

publisher.py

import sys
import os
import pika
import json
import time
import select

# 환경 변수 설정
RMQ_HOST = os.environ.get('RMQ_HOST', 'localhost')
RMQ_PORT = int(os.environ.get('RMQ_PORT', 5672))
RMQ_USER = os.environ.get('RMQ_USER', 'guest')
RMQ_PASS = os.environ.get('RMQ_PASS', 'guest')
EXCHANGE = os.environ.get('RMQ_EXCHANGE', 'file.events')
ROUTING_KEY = os.environ.get('RMQ_ROUTING_KEY', 'file.new')

def connect_to_rabbitmq():
    """RabbitMQ 연결 생성 및 채널 반환"""
    credentials = pika.PlainCredentials(RMQ_USER, RMQ_PASS)
    parameters = pika.ConnectionParameters(
        host=RMQ_HOST,
        port=RMQ_PORT,
        credentials=credentials,
        heartbeat=60,
        blocked_connection_timeout=300
    )

    while True:
        try:
            print(f">>> Connecting to {RMQ_HOST}:{RMQ_PORT}...")
            connection = pika.BlockingConnection(parameters)
            channel = connection.channel()
            channel.exchange_declare(exchange=EXCHANGE, exchange_type='direct', durable=True)
            # channel.confirm_delivery()
            print(">>> Connection established.")
            return connection, channel
        except Exception as e:
            print(f"!!! Connection failed: {e}. Retrying in 5 seconds...", file=sys.stderr)
            time.sleep(5)

# 초기 연결
connection, channel = connect_to_rabbitmq()
input_buffer = ""
count = 0

print(">>> Waiting for input...")

try:
    while True:
        try:
            # 평상시 Heartbeat 처리
            if connection and connection.is_open:
                connection.process_data_events()
            
            rlist, _, _ = select.select([sys.stdin], [], [], 1.0)
        except Exception as e:
            print(f"!!! Connection lost during idle: {e}. Reconnecting...", file=sys.stderr)
            connection, channel = connect_to_rabbitmq()
            continue

        if rlist:
            try:
                # [최적화 1] 버퍼 크기 1MB 유지
                chunk = os.read(sys.stdin.fileno(), 1024 * 1024)
                if not chunk:
                    break 
                input_buffer += chunk.decode('utf-8')
            except OSError:
                break

            if '\n' in input_buffer:
                parts = input_buffer.split('\n')
                
                # 마지막 요소는 '완전하지 않은 줄'일 수 있으므로 버퍼에 남겨둠
                # 예: "file1\nfile2\nfi" -> parts=["file1", "file2", "fi"]
                # lines_to_process = ["file1", "file2"]
                # input_buffer = "fi"
                lines_to_process = parts[:-1]
                input_buffer = parts[-1]

                for file_path in lines_to_process:
                    file_path = file_path.strip()
                    if not file_path:
                        continue

                    # 파일 읽기 및 전송
                    try:
                        with open(file_path, 'r', encoding='utf-8') as f:
                            content = f.read()
                    except Exception as e:
                        print(f"Error reading file {file_path}: {e}", file=sys.stderr)
                        continue

                    payload = {
                        "filePath": file_path,
                        "fileContent": content
                    }
                    body = json.dumps(payload)

                    # 전송 재시도 루프 (안정성)
                    while True:
                        try:
                            channel.basic_publish(
                                exchange=EXCHANGE,
                                routing_key=ROUTING_KEY,
                                body=body,
                                properties=pika.BasicProperties(
                                    delivery_mode=2,
                                    content_type='application/json'
                                )
                            )
                            
                            # RabbitMQ 네트워크 막힘 방지
                            # 1000개 보낼 때마다 RabbitMQ와 신호 교환 (ACK 처리)
                            count += 1
                            if count % 1000 == 0:
                                connection.process_data_events()
                                print(f"Processed {count} files. Last: {file_path}")
                            
                            break
                        except Exception as e:
                            print(f"!!! Failed to send {file_path}: {e}. Reconnecting...", file=sys.stderr)
                            try:
                                if connection and connection.is_open:
                                    connection.close()
                            except:
                                pass
                            connection, channel = connect_to_rabbitmq()

except KeyboardInterrupt:
    print("Stopping...")
finally:
    if connection and connection.is_open:
        connection.close()

`publisher.py` 에서 stdin 으로 받은 파일명으로 직접 읽어서 해당 바디값을 페이로드로 Queue 에 삽입하는 구조다.

이렇게 스트립트들을 구성하고 docker container 로 구동시켰다.

그리고 발주처에서 제공한 파일들을 mv 명령어로 이동 됐을 때 Queue 에 정상적으로 삽입 되는 걸 확인 할 수 있었다..!

2.1.4. 부하 테스트 후 개선

앞서 기술했다시피 꽤 대량의 데이터가 송수신된다. 그렇기 때문에 부하테스트를 해보기로 했고, 발주처에서 정의한 부하 정도는 3천건이라고 얘기하긴 했지만 필자는 발주처에서 제공한 데이터 전부를 넣어보고 부하테스트를 진행하였다.

20781 건을 동시에 감시 디렉토리로 이동하는 테스트를 진행했고, 결과는 처참했다ㅋㅋㅋㅋㅋㅋ

초당 약 148건의 속도로 삽입됐는데 약 2분정도? 소요됐다. 근데 데이터는 2,465 건 누락됐다..ㅎ

지금은 웃으면서 쓰지만 당시에 매우 식은땀이 났다. 이대로 가면 중요한 항공 데이터를 내가 날려먹는 상황이 나온다는 생각에 AI 의 힘을 빌렸다.

AI 가 알려준 문제로는 크게 3가지였다.

1. 동기 ACK 대기: 데이터 하나 송신 후 제대로 갔는지 체크하는 대기 시간 발생하여 대량 전송 시 병목현상 발생

2. readLine(): readline()은 한 줄씩 시스템콜을 발생시켜 대량 입력 시 I/O 오버헤드가 큼.

3. max_queued_events: inotify 이벤트 큐에 적재할 수 있는 최대 이벤트 수가 기본 값으로 2만건 수용이 안됨.

이를 해결 하기 위해서 다음과 같은 개선 사항을 알려줬다.

1. 동기 ACK 대기 제거 (Publisher Confirm 비활성화)

pika 패키지의 confirm_delivery()는 메시지를 1건 보낼 때마다 RabbitMQ broker가 "잘 받았어"라고 응답(ACK)을 줄 때까지 기다리는 기능이다. 비유하자면 택배를 보내는데, 한 박스 보내고 → 상대방이 "받았습니다" 전화할 때까지 기다리고 → 다음 박스 보내고 → 또 전화 기다리고… 이걸 2만번 반복하는 셈이다.

# Before: 매 건마다 broker ACK를 동기적으로 기다림
channel.confirm_delivery()

# After: ACK 대기 없이 연속 전송 (fire-and-forget)
# channel.confirm_delivery()

이걸 끄면 택배를 쉬지 않고 연속으로 보내는 것과 같다. 대신 1000건마다 process_data_events()로 broker와 상태를 한번씩 확인하여 연결이 막히지 않게 했다. 참고로 confirm을 꺼도 TCP 연결 위에서 AMQP 프로토콜로 통신하기 때문에 메시지가 broker에 도달하는 것 자체는 보장된다.

2. readline() → os.read() 청크 단위 읽기

sys.stdin.readline()은 파이프에서 데이터를 한 줄씩 읽는다. 파일 경로가 2만건 들어오면 시스템콜이 2만번 발생한다.

# Before: readline() - 한 줄씩 읽기
# 파이프에 "file1\nfile2\nfile3\n..." 이 들어오면
#   1번째 시스템콜 → "file1\n" 획득
#   2번째 시스템콜 → "file2\n" 획득
#   3번째 시스템콜 → "file3\n" 획득
#   ... 2만번 반복

line = sys.stdin.readline()

# After: os.read() - 1MB를 한번에 읽기
# 파이프에 "file1\nfile2\nfile3\n..." 이 들어오면
#   1번째 시스템콜 → "file1\nfile2\nfile3\n...file800\n" 한번에 획득
#   직접 \n 기준으로 split해서 처리

chunk = os.read(sys.stdin.fileno(), 1024 * 1024)

마트에서 장바구니 없이 물건 하나 집고 계산하고, 다시 하나 집고 계산하는 것(readline)과, 카트에 한번에 담아서 한번에 계산하는 것(os.read)의 차이다. 시스템콜 횟수가 줄어드니 당연히 빨라진다.

3. max_queued_events 파라미터 변경

max_queued_events는 inotify 이벤트 큐에 적재할 수 있는 최대 이벤트 수(건수)다. 기본값은 16,384건인데, 2만건을 한번에 mv하면 이 큐가 넘쳐서 초과분 이벤트가 버려진다. 2,465건이 누락된 원인이 바로 이것이다.

# 기본값 확인
cat /proc/sys/fs/inotify/max_queued_events
# 16384

# 영구 적용 (reboot 후에도 유지)
echo "fs.inotify.max_queued_events = 49152" | sudo tee /etc/sysctl.d/99-inotify.conf
sudo sysctl -p /etc/sysctl.d/99-inotify.conf

이 설정은 호스트 커널 레벨 파라미터이므로, Docker 컨테이너 안이 아니라 호스트 서버에서 실행해야 한다. 컨테이너는 호스트 커널을 공유하기 때문에 호스트에서 변경하면 컨테이너에도 적용된다.

다시 테스트 해봤을 때 초당 2520건 삽입 되는 걸 확인 할 수 있었고, 데이터 누락없이 10초만에 모두 Queue 에 삽입 된 걸 볼 수 있었다. 대략 2분 -> 10초로 감소된 셈이다!

3. 마무리

누군가에겐 간단한 문제였을 수 있지만.. 처음 실시간 연계 파이프라인을 구축해보는 입장에서 꽤 어려웠고, 그만큼 많이 고민하면서 시스템 설계를 하였다. 이런 경험들이 쌓여서 다음 유사한 케이스에선 좀 더 삽질을 덜 해서 더욱 탄탄한 구조를 만들 수 있음 좋겠다!