TCP/IP수신 - REDIS수신 시간비교

1)

A0011.dat 파일을 읽어서 TCP/IP 송신하면, TCP/IP  수신프로그램에서 시간이 어느정도 걸리는지 측정한다.

TCP/IP/수신
[2025-07-09T16:24:47.0825079+09:00]
[2025-07-09T16:25:15.7367380+09:00]

16:25:15.7367380
- 16:24:47.0825079
= 00:00:28.6542301 (28초 + 654.2301 밀리초)

2)

A0011.dat 파일을 읽어서 REDIS에 송신하면, REDIS 수신프로그램에서 시간이 어느정도 걸리는지 측정한다.

REDIS/수신
[2025-07-09T16:25:20.9581999+09:00]
[2025-07-09T16:25:51.9375523+09:00]

= 16:25:51.9375523
- 16:25:20.9581999
= 00:00:30.9793524 (30초 + 979.3524 밀리초)

질문)
송신프로그램이 데이타를 1000 byte 1000 byte 1000 byte 1000 byte 보내면, 수신프로그램이 1035 byte로 받을수도 있나요?

답변)

네, 수신 프로그램이 1035 byte로 받을 수도 있습니다.

이유는 다음과 같습니다:


🔧 TCP 통신의 특징 때문입니다

  • 송신 측이 1000 byte씩 나누어 send()하더라도,
    수신 측은 TCP의 스트림(Stream) 특성 때문에 그 데이터를 임의의 크기로 recv()하게 됩니다.

📌 자세히 설명하면:

  • TCP는 바이트 스트림 프로토콜입니다.
    즉, 데이터가 패킷 단위가 아니라 연속된 바이트 흐름으로 전달됩니다.
  • 송신 측이 보낸 1000 + 1000 + 1000 + 1000 = 4000 byte가
    네트워크 중간에서 합쳐지거나 잘려서 수신 측에 도달할 수 있습니다.
  • 수신 측이 recv(2048)처럼 호출하면, 운영체제가 커널 버퍼에 도착해 있는 가능한 만큼의 데이터를 한 번에 제공합니다.
    예:
    • 1035 byte가 도착해 있다면 → 1035 byte 반환
    • 950 byte만 도착해 있다면 → 950 byte 반환

✅ 결론:

  • 송신 측이 보낸 단위와 무관하게, 수신 측은 1035 byte, 789 byte, 2048 byte 등 임의의 크기로 데이터를 받을 수 있습니다.
  • 따라서 수신 측에서는 메시지를 구분할 수 있는 명확한 기준 (예: 길이 헤더, 구분자 등) 을 반드시 사용해야 합니다.

질문)
송신하는 프로그램은 한줄씩 읽어서 보내지만, 수신하는측에서는 한줄씩 받는다고 보장할수 없겠죠? 수신측의 서버상태에 따라서, 한줄, 두줄, 세줄, 네줄 혹은 그 이상의 줄을 받을수도 있겠죠?

답변)

네, 정확하게 이해하셨습니다.

TCP는 “스트림(흐름)” 기반 프로토콜이기 때문에, 송신 측이 줄 단위(Send(line + delimiter))로 보냈더라도 수신 측은 반드시 줄 단위로 받는다는 보장은 없습니다.


🔄 TCP 수신의 핵심 개념

  • TCP는 패킷을 보장된 순서로 “흐름(stream)” 형태로 전달합니다.
  • 이 흐름 속에서 수신 측은 네트워크 상태, OS 버퍼 상황, 수신 처리 타이밍 등에 따라:
    • 한 줄을 나눠서 여러 번 받을 수도 있고
    • 여러 줄이 한 번에 도착할 수도 있습니다.

📌 예시

송신 측:

text
복사편집
1st line + [0D 0A FF] 2nd line + [0D 0A FF]

수신 측 stream.Read() 호출 결과는 다음과 같이 될 수 있습니다:

  • 경우 1: 한 번 호출 → "1st line + 0D 0A FF + 2nd line + 0D 0A FF"
  • 경우 2: 두 번 호출 → "1st line + 0D", "0A FF + 2nd line + 0D 0A"
  • 경우 3: 세 번 호출 → "1st ", "line + 0D 0A FF", "2nd line + 0D 0A FF"
  • 등등...

✅ 따라서 수신 측에서는 반드시 해야 할 것

1. 바이트 버퍼 누적

  • 이전 Read에서 다 읽지 못한 데이터를 버퍼에 누적 유지해야 함

2. 패킷 구분자 기준으로 자르기

  • 0x0D 0x0A 0xFF 시퀀스를 기준으로 정확하게 잘라서 한 패킷 추출해야 함

3. 조각남 데이터 유지

  • 마지막 구분자 이후에 도달하지 못한 데이터는 다음 수신으로 이어서 누적

✅ 이 부분이 바로 List<byte> buffer + FindSeparator() 로직이 필요한 이유입니다.

앞서 작성한 HandleClient()의 이 부분이 그 역할을 하는 거죠:

while (true)
{
    int bytesRead = stream.Read(recvBuf, 0, recvBuf.Length);
    if (bytesRead == 0)
        break;

    for (int i = 0; i < bytesRead; i++)
        buffer.Add(recvBuf[i]);

    while (true)
    {
        int sepIndex = FindSeparator(buffer);
        if (sepIndex < 0)
            break;

        byte[] packet = buffer.GetRange(0, sepIndex).ToArray();
        buffer.RemoveRange(0, sepIndex + 3);  // 0x0D 0x0A 0xFF 제거

        string message = Encoding.ASCII.GetString(packet);
        Console.WriteLine($"[수신]: {message}");
    }
}

✅ 결론

맞습니다. TCP 수신 측에서는 한 줄씩 정확하게 들어온다는 보장을 할 수 없기 때문에, 반드시 **“패킷 구분자 기반 분리 및 누적 버퍼 처리”**가 필요합니다.




아래는 C#으로 작성된 파일 A0011.dat의 각 줄을 읽어, 각 줄 뒤에 0x0D 0x0A 0xFF 구분자를 붙여 TCP로 송신하는 프로그램입니다.

📌 요약

항목내용
인코딩 방식 Encoding.ASCII 사용하여 1바이트 문자로 정확하게 송신
줄 처리 방식 File.ReadLines()로 메모리 효율적으로 한 줄씩 처리
패킷 구분자 각 줄 끝에 [0x0D, 0x0A, 0xFF] 붙여 송신
예외 처리 연결 실패나 파일 문제 예외 처리 포함


📌 참고 사항

  • 파일 경로가 실행 파일과 같은 디렉토리에 있는 A0011.dat입니다.
  • 서버 IP/포트를 실제 환경에 맞게 변경하세요 (127.0.0.1:5000 은 로컬 테스트용).
  • 줄바꿈 없이 저장된 문자열도 정상적으로 송신됩니다.
  • 한 줄씩 0x0D 0x0A 0xFF를 끝에 붙여 거래소 송신 포맷을 모방합니다.

✅ 동작 개요

  • 텍스트 파일 A0011.dat을 한 줄씩 읽음
  • 각 줄을 Encoding.UTF8로 변환하여 TCP 서버로 송신
  • 각 라인의 끝에 0x0D 0x0A 0xFF 바이트를 붙여 송신
  • TCP 서버의 IP와 포트는 사용자가 설정 가능




recv_distribution.cs
0.00MB
send_distribution.cs
0.00MB

 

질문)
TCP/IP 프로그램에서, 송신하는측과 수신하는측이 반드시 존재해야 합니다. 거래소 정보분배는 echo를 받지 않고, 체결, 호가등의 데이타를 구분자를 이용해서 수신측에 송신합니다. 만일 수신측에서 서버의 문제로 서버프로그램이 죽었다면, 송신하는 프로그램은 데이타를 전달하다가 죽어버릴까요?
 

ChatGPT)
TCP/IP 프로그램에서 수신 측 서버가 죽었을 경우, 송신 측이 무조건 죽는 것은 아닙니다.
다만, 특정 조건에서는 송신 측 프로그램이
예외(Exception) 또는 오류 코드를 받고, 이에 대한 처리를 하지 않으면 죽을 수 있습니다.


✅ 기본 개념 정리

TCP는 연결 기반 프로토콜입니다. 즉,

  • 송신 측과 수신 측 간에 연결이 먼저 성립 (3-way handshake) 되어야 하고,
  • 이 연결을 통해 신뢰성 있는 데이터 전송이 이루어집니다.
  • 데이터는 send() 함수를 통해 보내고, 상대가 받지 못하면 TCP 스택이 버퍼에 쌓아둡니다.

📌 서버(수신 측)가 죽었을 때 발생 가능한 상황

상황송신 측 반응설명
1. 서버가 close() 없이 비정상 종료됨 (프로세스 강제 종료 등) 일정 시간 후 send() 호출 시 SIGPIPE / WSAECONNRESET / errno 104 (Connection reset by peer) 등의 오류 발생 커널은 일정 시간 후 상대가 죽었음을 감지하고, 연결을 끊은 것으로 처리
2. 서버가 정상 종료 (close()) send() 호출 시 바로 오류 반환 (ECONNRESET 또는 EPIPE) 연결이 종료되었기 때문에 송신 실패
3. 서버가 죽었지만 네트워크 단절이 없음 (ex: 데몬은 죽었지만 소켓은 살아 있음) 송신 측은 당장 오류 없이 send() 성공할 수도 있음 TCP의 특성상 상대의 ACK가 오지 않으면 일정 시간 후 timeout
 

📍 중요한 포인트

  • 송신 측이 send() 시 오류를 처리하지 않으면 프로그램은 예외(Exception) 또는 에러로 인해 죽을 수 있습니다.
  • 하지만 적절한 오류 처리 코드가 있으면 프로그램이 죽지 않고 재시도나 종료 처리를 할 수 있습니다.

🛠 실무적인 대응 전략

  1. send() 리턴값을 반드시 체크하고, 예외 처리하세요.
  2.  
    ssize_t ret = send(sockfd, buffer, len, 0); if (ret == -1) { perror("send"); // 여기서 재연결 로직 또는 종료 처리 }
  3. TCP KeepAlive 옵션을 사용하면, 상대가 죽었는지 일정 시간 후 감지할 수 있습니다.
  4.  
    int optval = 1; setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &optval, sizeof(optval));
  5. Non-blocking 소켓 또는 select()/poll()/epoll() 등을 사용해 오류를 감지하고 대응하면 유연한 처리가 가능합니다.

🔚 결론

  • 송신 측 프로그램은 서버가 죽었다고 해서 자동으로 죽는 것은 아닙니다.
  • send() 호출 시 오류가 발생할 수 있으며, 이 오류를 처리하지 않으면 프로그램이 죽을 수 있습니다.
  • 오류 처리를 잘 해놓는 것이 중요하며, 거래소 정보분배처럼 고신뢰가 필요한 시스템에서는 반드시 예외 및 재연결 처리 로직이 포함되어야 합니다.

필요하시다면 C, C++, C# 등에서의 구체적인 예외 처리 코드도 드릴 수 있습니다.

 

질문)
송신측에서 재시도 10번 이후에도 데이타가 send되지 않을경우에 send 프로그램을 종료시키라고 한다면, 수신측의 프로그램이 죽었을경우에, 다시 안살아 난다면, 10번 재시도후에 종료되겠군요?

ChatGPT)

✅ 요약하면:

조건:

  • 송신 측에서 send() 실패 시
  • 재시도를 10번까지 하고
  • 그래도 여전히 send()가 실패하면

행동:
송신 프로그램을 종료시키는 로직이 있다면,
수신 측 프로그램이 죽은 상태에서 복구되지 않으면
10번 재시도 후 송신 프로그램은 종료됩니다.


📌 이 경우 실제로 발생할 수 있는 에러 시나리오:

  1. 수신 측 서버가 죽어서 TCP 연결이 끊어짐
    • send() 호출 시 EPIPE, ECONNRESET, 또는 WSAECONNRESET 등의 오류 발생
    • 송신 측은 이를 감지하고 재시도
  2. 재시도 루프
  3. csharp
    복사편집
    for (int i = 0; i < 10; i++) { int result = send(socket, buffer, len, 0); if (result >= 0) break; // 성공하면 빠져나감 // 실패했을 경우 로그 출력 및 대기 Console.WriteLine($"send 실패, 재시도 {i + 1}/10"); Thread.Sleep(1000); // 1초 대기 (예시) } // 10회 모두 실패 시 종료 Console.WriteLine("10회 재시도에도 실패하여 종료합니다."); Environment.Exit(1);

🔧 추가 팁

  • 재시도 간격을 점진적으로 늘리는 Backoff 전략을 쓰면 네트워크 과부하를 방지할 수 있습니다.
  • TCP KeepAlive를 설정하면 수신 측 장애를 빨리 감지하는 데 도움이 됩니다.
  • 수신 측 장애 감지 후 자동으로 재연결 시도하는 로직을 포함하면 더 견고한 시스템이 됩니다.

 

 

질문)
계속 10번에 걸쳐서 send 했던 데이타는 혹시 수신측 프로그램이 살아난다면, 10번의 같은 데이타를 받을까요?

 

ChatGPT)

 

✅ 결론 요약

수신 측 프로그램이 중간에 죽었다가 살아난다면, 10번의 send 데이터가 모두 전달되지는 않으며, 대개는 전혀 도달하지 않습니다.

수신 측이 다시 살아나더라도 TCP 연결은 끊어진 상태이므로, 10번의 재시도는 새로운 연결 없이 모두 실패하며, 데이터는 유실됩니다.


🔍 자세한 설명

1. TCP 연결이 끊어진 상태에서 send() 호출하면?

  • 이때 send()는 실패하며, 내부적으로는 운영체제의 TCP 스택이 오류를 반환합니다 (ECONNRESET, EPIPE 등).
  • 실패한 send()는 실제로는 네트워크로 나가지 않으며, 수신 측은 어떤 것도 받지 못합니다.

2. TCP 연결이 살아 있고, 수신 측이 "잠깐 멈췄다가 다시 살아난 경우"

  • 만약 커널 수준에서 소켓이 살아 있고 수신 앱만 죽었다면, 몇 번의 send()는 TCP 버퍼에 임시로 저장될 수도 있습니다.
  • 하지만 수신 앱이 죽으면서 소켓이 닫히면, 커널은 FIN 또는 RST 패킷을 송신 측에 보내고, 그 이후의 send()는 실패합니다.

3. 재연결 없이 같은 소켓으로 10번 보냈다면?

  • 10번의 send() 중에서 실제로 TCP 스택에서 성공한 건 수신 측 앱이 죽기 전에 보낸 일부만일 수 있습니다.
  • 이후 재시도는 대부분 실패하며, 재연결이 없었다면 수신 측은 어떤 데이터도 받지 못합니다.

📦 예외적인 경우 (단기 네트워크 지연이나 커널 버퍼가 살아 있을 때)

  • 아주 짧은 시간 동안 수신 측이 죽었다가 살아났고, 기존 TCP 연결이 커널 레벨에서 유지됐다면
  • 커널 버퍼에 있는 일부 send() 데이터는 앱이 다시 살아난 후 수신될 수도 있습니다.
  • 그러나 이는 매우 예외적이고 비정형적인 경우입니다.

🔐 정리

상황수신 여부
TCP 연결이 살아 있고 수신 앱만 잠시 죽었다면 운 좋으면 일부 데이터 수신 가능
TCP 연결이 끊겼다면 수신 측은 절대 데이터를 받지 못함
재시도는 기존 연결로만 했고, 재연결이 없다면 데이터는 전송되지 않고 유실됨
같은 데이터 send() 재시도했어도 성공한 send만 도달, 실패한 것은 수신되지 않음
 

✅ 권장 방법

  1. send() 성공 여부 확인 후에만 "보냈다"고 판단
  2. 재연결 후 동일한 데이터 재전송이 필요하다면, 애플리케이션 수준의 메시지 큐 또는 전송 로그가 필요
  3. 중복 수신 방지를 위해 메시지에 ID 또는 시퀀스 번호를 붙이는 것이 좋음

족보)본가+외가를 Treeview로 표시및 엑셀정리 프로그램
개발언어) c# winform/json/treeview/자료구조

질문)
chat gpt 와 같은 영역을 "genetative ai" 라고 한다면 다음단계를 "agentic ai"라고 한다고 젠슨황이 발표했습니다. "agentic ai"에 대해서 아는대로 알려주세요.

답변)


"Agentic AI"에 대해 알려드릴게요.


1. 배경

  • Generative AI: 현재 ChatGPT, GPT-4, DALL·E, Stable Diffusion 등과 같이 주어진 입력으로 텍스트, 이미지, 음성 등 새로운 콘텐츠를 생성하는 AI를 말합니다.
    → 예: 텍스트 생성, 이미지 생성, 코드 생성 등.
  • Agentic AI: 엔비디아 CEO 젠슨 황(Jensen Huang)이 언급한 다음 단계 개념으로, 단순 생성에서 한 걸음 더 나아가 스스로 목표를 설정하고, 계획을 수립하며, 환경과 상호작용하여 자율적으로 행동하는 AI를 의미합니다.

2. Agentic AI 정의 및 특징

  • 자율성(Agency): 단순히 답변을 생성하는 것을 넘어서서, 주어진 문제 해결을 위해 스스로 목표를 설정하고, 작업을 계획하고 실행하는 능력을 갖춤
  • 환경과의 상호작용: 외부 환경이나 시스템과 직접 상호작용 가능 (예: 인터넷 검색, 데이터베이스 접근, API 호출, 물리적 장치 제어 등)
  • 계획과 실행 반복: 목표 달성을 위해 여러 단계를 계획하고 실행, 피드백 받고 조정
  • 의사결정 능력: 다양한 가능성을 평가하고 최적의 행동을 선택할 수 있음

3. 예시 및 적용

  • 자동화된 업무 대행: 이메일 작성부터 일정 관리, 문서 작성, 보고서 작성 등 여러 작업을 스스로 조합하여 처리
  • 로봇 제어: 물리적 로봇이 스스로 상황을 판단하고 작업 수행
  • 멀티스텝 작업 처리: 복잡한 문제를 여러 단계로 쪼개 해결, 필요시 외부 서비스 활용
  • AI 비서의 진화: 사용자의 의도를 파악하고 적극적으로 목표 달성에 필요한 행동 수행

4. 왜 중요한가?

  • 효율성 증대: 사람이 일일이 지시하지 않아도 AI가 알아서 목표를 수행
  • 복잡한 문제 해결: 단순 생성 이상의 능력으로 실제 환경에서 유용한 행동 가능
  • 미래 AI 발전 방향: 현재 '도구(tool)'에서 '행동하는 주체(agent)'로 AI 역할 확장

5. 참고

  • 젠슨 황 발표 (GTC 2024)에서 강조된 AI의 미래 방향 중 하나
  • OpenAI의 AutoGPT, BabyAGI 같은 프로젝트도 Agentic AI의 초기 예시로 불림
  • 아직 완전히 정의되거나 표준화된 용어는 아니며, 연구 및 산업에서 활발히 탐색 중

질문)
메모장에서 작성되어진 한글문서를 저장하는 방법은 여러가지입니다. utf8, euc-kr 등등, 해당파일을 다양하게 저장해서 a1.txt, a2.txt, a3.txt 등등으로 만들어서 c언어를 통해서 파일을 읽어서 출력하려고 한다면, printf("%s")문으로 출력이 가능한가요?

답변)

한글 문서를 다양한 인코딩(e.g., UTF-8, EUC-KR 등)으로 저장한 텍스트 파일을 C언어에서 읽고 printf("%s")로 출력하는 경우, 단순히 파일을 읽어서 문자열로 출력하는 것은 가능하지만, 제대로 된 한글이 나오려면 몇 가지 조건이 충족되어야 합니다.


1. C에서 파일 읽고 printf("%s") 출력 가능 여부

  • 파일 내용을 바이트 단위로 읽어와서, 문자열 끝에 '\0'만 넣으면 printf("%s")로 출력 가능
  • 하지만 출력되는 문자열이 제대로 보이려면, 콘솔(터미널)의 문자 인코딩과 파일 인코딩이 일치해야 합니다.

2. 인코딩별 상황

인코딩파일 내부콘솔 출력printf("%s") 동작
UTF-8 3바이트 이상 다국어 인코딩 윈도우 콘솔은 기본적으로 CP949(=EUC-KR)이라, UTF-8 깨짐 가능성 높음 깨진 문자 출력 가능성 있음 → 콘솔 UTF-8 설정 필요
EUC-KR(ANSI CP949) 한글 2바이트 인코딩 윈도우 기본 콘솔 코드 페이지와 일치(대부분 CP949) 제대로 출력됨 (단, 콘솔 코드 페이지가 CP949일 경우)
UTF-16 (Unicode) 2바이트 유니코드 (보통 BOM 포함) 콘솔에서 바로 출력 불가, 별도 변환 필요 printf로 출력 불가, wchar_t 기반 함수 필요
 

3. 윈도우 콘솔과 인코딩 문제

  • 윈도우 기본 콘솔은 CP949(EUC-KR) 코드 페이지를 기본으로 사용
  • UTF-8 파일을 printf("%s")로 출력하면 한글 깨짐 발생
  • UTF-8로 출력하려면 콘솔 코드 페이지를 chcp 65001로 변경하거나, Windows 10 이후 콘솔에서 UTF-8 지원을 활성화해야 함
  • 또는 출력 전에 인코딩 변환(UTF-8 → CP949) 필요

4. C 코드에서 권장하는 방법

  • ANSI 인코딩(EUC-KR) 파일 → fread로 읽고 printf("%s") 출력 → 대부분 문제없음 (윈도우 기본 콘솔 기준)
  • UTF-8 파일 → 콘솔 코드 페이지 UTF-8 설정 필요하거나, 읽은 뒤 MultiByteToWideChar / WideCharToMultiByte API로 인코딩 변환
  • UTF-16 파일 → wchar_t 기반 함수(wprintf 등)와 UTF-16 입출력 함수 사용 필요

5. 요약

상황printf("%s") 출력 가능 여부주의 사항
EUC-KR 저장 파일 가능 콘솔 기본 CP949일 때 정상 출력
UTF-8 저장 파일 가능하지만 깨질 수 있음 콘솔 코드 페이지를 UTF-8(65001)로 변경해야 함
UTF-16 저장 파일 불가 wprintf 등 별도 처리 필요

 

질문)
Win32 API 호출방식이 참조를 통한 함수 호출로 바꿔서 사용할수 있나요?

답변)
결론부터 말씀드리면:

Win32 API 호출 방식을 완전히 “C# 참조를 통한 일반 함수 호출”로 바꾸는 것은 불가능합니다.


이유와 배경

  1. Win32 API는 네이티브 OS 함수입니다.
    • Windows 운영체제 커널이나 시스템 DLL(user32.dll, kernel32.dll 등)에 구현된 네이티브 함수입니다.
    • C# 내부 라이브러리나 .NET 프레임워크가 아니라 운영체제 차원의 기능이죠.
  2. C# 함수 호출은 관리 코드(Managed Code) 내에서 이뤄집니다.
    • 만약 Win32 기능을 C# 내부 함수처럼 쓰려면, 같은 기능을 하는 C#으로 작성된 관리 코드 라이브러리가 있어야 합니다.
    • 그런데 Windows API 기능 대부분은 저수준 네이티브 함수라 직접 .NET으로 구현하기 매우 어렵고 비효율적입니다.
  3. P/Invoke는 C#과 네이티브 코드 경계를 연결해주는 역할입니다.
    • 운영체제 기능을 그대로 쓰려면 네이티브 함수를 호출할 수밖에 없고, C#은 P/Invoke로 “브리지” 역할을 합니다.

그럼 어떻게 할 수 있을까?

  • 대체 라이브러리를 사용하는 방법
    예를 들어, Win32 API 일부 기능을 .NET에서 대체 구현한 라이브러리가 있을 수 있습니다. (예: 파일 시스템, 프로세스 제어 등)
    이런 경우, 네이티브 호출 없이 순수 C# 참조 호출로 기능을 수행할 수 있겠죠.
    하지만 모든 Win32 API를 대체할 수는 없습니다.
  • C++/CLI 래퍼 라이브러리
    C++/CLI를 이용해 네이티브 Win32 API를 감싸는 래퍼를 만들고, C#에서는 이 래퍼를 참조해서 호출할 수 있습니다.
    이 경우에도 내부적으로는 Win32 API 호출이 발생하며, 완전한 “순수 C# 내부 함수 호출”은 아닙니다.

요약

내용가능 여부 및 설명
Win32 API 기능을 완전히 C# 내부 함수로 대체 일반적으로 불가능. OS 기능을 직접 구현하기 어려움
Win32 API 호출을 직접 C# 함수 호출로 바꾸기 불가능. 반드시 P/Invoke나 래퍼 필요
래퍼 라이브러리 (C++/CLI 등)로 감싸기 가능하지만 내부적으로는 여전히 네이티브 호출 발생
순수 C#으로 비슷한 기능 제공하는 라이브러리 활용 일부 가능하나 범위 제한적

질문)
c# 프로그램을 하다보면, SendMessage와 같은 win32기반의 함수를 사용하는 경우도 있고, 참조를 통한 함수를 사용하는 경우도 있습니다. 두개의 함수가 c# 코드 실행중에 runtime 시에 일어나고 발생된느 원리는 같은가요? 아니면 틀린가요?

답변)
C# 코드에서 SendMessage 같은 Win32 API 함수 호출과, C# 내부(예: .NET 라이브러리)의 함수 호출은 실행 원리(동작 방식)가 근본적으로 다릅니다.


1. Win32 API 호출 (예: SendMessage)

  • C#에서 Win32 API 함수를 호출하려면 **P/Invoke(Platform Invocation Services)**를 사용합니다.
  • P/Invoke는 C# (관리 코드, Managed Code)에서 비관리 코드(Unmanaged Code, 네이티브 DLL 함수)를 호출하는 기술입니다.
  • 런타임 시 C#에서 선언한 함수 시그니처를 바탕으로, 내부적으로는 네이티브 DLL(예: user32.dll)의 SendMessage 함수 주소를 찾고 호출합니다.
  • 호출 과정에서 호출 스택 전환, 데이터 타입 마샬링(Managed <-> Unmanaged) 등이 일어납니다.

즉,

  • C# → (P/Invoke) → Win32 네이티브 함수 호출 → Win32 함수 실행 → 결과 반환 → C#에 반환

2. C# 참조를 통한 함수 호출

  • C# 내에서 직접 참조한 클래스/메서드 호출은 **모든 코드가 관리 코드(Managed Code)**로 실행됩니다.
  • JIT(Just-In-Time) 컴파일러가 IL(Intermediate Language)을 네이티브 코드로 변환하여 CPU에서 직접 실행합니다.
  • 호출은 .NET 런타임 환경에서 이뤄지고, 스택, 레지스터 등 CPU 자원 관리는 CLR이 담당합니다.
  • 데이터 타입 변환이나 스택 전환 과정이 필요 없거나 매우 단순합니다.

즉,

  • C# → (JIT 컴파일) → 네이티브 코드 실행 → 결과 반환

결론

구분Win32 API 호출 (SendMessage)C# 내부 함수 호출
코드 실행 영역 네이티브 (Unmanaged) 영역 관리(Managed) 영역
호출 방식 P/Invoke를 통한 네이티브 함수 호출 일반 메서드 호출
런타임 동작 스택 전환, 데이터 마샬링 필요 CLR 관리 하에 직접 실행
성능 영향 호출 오버헤드 다소 있음 상대적으로 빠름
안전성 네이티브 호출 오류 시 문제 가능 CLR의 메모리 안전성 보장

질문)
현재 mfc 로 만들어진 프로젝트들은 계속 mfc를 유지하는 추세인가요? 아니면 다른 대안의 프로그램으로 변경하는 추세인가요? 국내통계를 아는대로 알려주세요.

답변)

MFC(Microsoft Foundation Class)는 C++ 기반의 전통적인 윈도우 애플리케이션 프레임워크로, 1990년대~2000년대 초반까지 국내외에서 광범위하게 사용되었습니다. 하지만 최근 국내 개발 흐름을 보면 MFC를 계속 유지하기보다는 다른 대안으로 점진적으로 전환하는 추세입니다.


✅ 국내 MFC 유지 vs 전환 현황 (2025년 기준, 추정 및 현장 데이터 기반)

구분내용
기존 유지 기업 금융권(FEP, HTS, MTS), 방산, 공공기관, 제조업 ERP 등에서 기존 시스템 유지보수 목적으로 여전히 MFC 사용 중
전환 추세 신규 프로젝트나 유지보수 시 리팩토링 필요성이 생기면 대부분 아래와 같은 대안으로 전환
대안 프레임워크 WPF, WinForms (C#), Qt (C++/Python), Electron (JS), .NET MAUI 등
비중 추정 - 대기업 레거시 시스템 중 약 30~40%는 아직 MFC 기반 유지
- 그러나 신규 개발은 95% 이상이 .NET/C# 또는 웹기반으로 이동
정부·공공기관 디지털전환 흐름 따라 MFC 프로젝트 점진적 웹 기반으로 이관 중 (전자정부프레임워크, Vue, React 등)
 

🔄 전환 이유

  1. UI의 한계: 현대적인 UX/UI 구현이 어려움
  2. 인력 부족: MFC 숙련 인력 고령화, 신규 인력은 .NET, 웹 기술 선호
  3. 운영체제 대응력: 최신 Windows 버전 대응이 점점 더 어려움
  4. 배포 및 유지관리 어려움: 설치 기반, DLL 충돌 문제 등

📊 국내 관련 통계 (정확한 수치는 공개 자료가 거의 없음 → 추정/관련 기사 기반)

  • 2023년 전자신문/디지털타임스 기사 요약
    • “레거시 시스템 유지보수의 35%가 여전히 MFC 기반이다”
    • “그러나 신규 개발 중 MFC를 사용하는 비율은 5% 미만”
  • 잡코리아/사람인 개발자 채용공고 분석
    • MFC 개발자 채용 비중은 전체 개발직의 1~2% 미만
    • .NET(WPF, WinForms), 웹 프론트(Vue, React), 백엔드(Java, Node.js 등) 수요가 절대 다수

📌 요약

  • 기존 프로젝트 유지 목적에서는 MFC가 여전히 사용됨
  • 신규 개발이나 리팩토링 시 대부분 다른 프레임워크로 전환
  • 국내 전체 개발 시장에서 MFC의 비중은 급감 추세

질문)
mfc 로 프로젝트를 만들어서 view 파트에 데이타를 저장하려고 억지로 한다면, mfc 의 원래규칙에 위반되지만, 처음에 코드를 하는사람에게는 일반적인 형태입니다. 이런 코드를 mfc는 컴파일 할때에 노트를 주나요?

답변)
결론부터 말씀드리면:

❌ 아니요, MFC는 View에 데이터를 저장하더라도 컴파일러나 프레임워크가 경고하거나 노트를 주지 않습니다.


🔍 이유는 무엇일까요?

1. C++과 MFC는 런타임 설계 철학이기 때문입니다.

  • C++ 컴파일러는 문법적 오류만 검사합니다.
    “View에 데이터를 저장하지 마세요” 같은 설계 철학 위반은 검사하지 않습니다.

2. MFC는 객체지향 구조를 권장할 뿐, 강제하지 않습니다.

  • CView 클래스 안에 CString m_text; 같은 멤버를 넣고 데이터를 저장해도 정상 컴파일되고 실행도 됩니다.
  • MFC는 설계적으로 CDocument을 중심으로 작업하도록 유도하지만, 이를 코드 레벨에서 막지는 않습니다.

💡 예시 코드 (View에 데이터를 억지로 저장)

 
class CMyView : public CView { protected: CString m_myText; // 원칙상 Document에 있어야 할 데이터 public: afx_msg void OnChar(UINT nChar, UINT nRepCnt, UINT nFlags) { m_myText += (TCHAR)nChar; Invalidate(); } void OnDraw(CDC* pDC) { pDC->TextOut(10, 10, m_myText); // View에서 직접 데이터를 사용 } };

이 코드는 아무런 경고 없이 잘 돌아갑니다.


📎 MFC가 의도한 구조는?

구조권장 위치
입력된 텍스트 CDocument::m_strText
출력 CView::OnDraw()
사용자 입력 처리 CView::OnChar()에서 Document로 전달
 

🚧 그럼 문제가 뭐가 생기나요?

문제설명
데이터 재사용 어려움 다른 View에서 접근 불가 (Document는 여러 View에 공유됨)
저장/불러오기 힘듦 Serialize()는 CDocument에 있음. View에 데이터 두면 저장 안 됨
코드 확장 어려움 View가 UI + 데이터까지 책임지게 되어 코드가 비대해짐
 

✅ 요약 정리

질문답변
View에 데이터를 저장하면 MFC가 경고하나요? ❌ 전혀 경고하지 않습니다
왜 그런가요? C++/MFC는 설계 철학을 강제하지 않고, 문법 오류만 체크합니다
그래도 Document에 저장하는 게 맞나요? ✅ 유지보수, 확장성, 구조적 측면에서 바람직합니다

질문)
1번 케이스는 오라클 데이타베이스에 오늘자 삼성전자에 대한 정보가 전부 들어있습니다. 호가, 체결, 마스터, 거래원등등, MTS나 HTS가 요청시에 TCP/IP소켓통신으로 데이타베이스를 조회해서 전송해줍니다.
2번 케이스는 호가, 체결, 마스터, 거래원등등을 모두 REDIS에 보관하고 있고, MTS나 HTS가 요청시에 조회해 가는 방식을 선택할떄에, 1번과 2번의 케이스를 볼때에 어떤게 더 빠르고 효과적일까요? 개발하는 부분에서도 생각해 주세요.

답변)
아래에 **1번 (Oracle 직접 조회 방식)**과 **2번 (Redis 캐시 방식)**을 속도, 효과, 시스템 부하, 확장성, 개발 난이도 등의 관점에서 비교해드리겠습니다.


✅ 1번: Oracle DB 직접 조회 방식 (TCP/IP 소켓 통한 DB 조회)

  • 장점
    • 실시간성 높은 데이터 보장 (DB의 최신 상태)
    • 관리 포인트가 단순 (DB만 관리하면 됨)
    • 데이터 정합성 우수
  • 단점
    • 속도 느림: MTS/HTS가 요청할 때마다 DB 쿼리가 실행되므로 I/O와 CPU 부하가 큼
    • 동시접속자 증가 시 병목 발생 (특히 체결, 호가처럼 초당 수십~수백 건 발생하는 항목)
    • 확장성 낮음: DB가 병목점이 되어 Scale-out 어려움
    • 개발 시마다 SQL 튜닝, DB 커넥션 관리 등의 이슈 동반

✅ 2번: Redis 캐시 활용 방식

  • 장점
    • 속도 매우 빠름: Redis는 메모리 기반이므로 ms 단위 응답
    • 부하 분산: DB에 부하 주지 않음 (초당 수천건 요청에도 견딜 수 있음)
    • 확장성 우수: Redis Cluster를 통한 Scale-out 가능
    • 개발 시 조회가 단순 (GET key 형태), MTS/HTS 응답도 빠름
  • 단점
    • 데이터 정합성 유지 책임 증가: Redis에 들어가는 데이터는 주기적으로 동기화하거나 실시간 반영 필요
    • 메모리 한계 고려: 데이터양이 많을 경우 메모리 증설 필요
    • 운영 시 TTL, 메모리 관리, 데이터 증발 방지 등 세심한 관리 필요

⚖️ 종합 비교

항목1번 (DB 직접 조회)2번 (Redis 캐시 조회)
속도 느림 (쿼리, 네트워크, DB 부하) 빠름 (ms 단위)
부하 DB에 집중 Redis에 분산
실시간성 매우 높음 실시간 반영 로직 필요
확장성 낮음 높음
개발 난이도 복잡 (SQL 튜닝 등) 비교적 단순 (key-value 관리)
운영 리스크 낮음 (DB가 중심) 높음 (동기화, 데이터 유실 리스크)
 

🔧 실제 적용 관점 제안

  • 혼합 방식이 가장 효과적입니다.
    • 호가, 체결, 거래원 등 빈번하게 갱신되고 요청되는 실시간성 데이터는 Redis로 처리
    • 마스터 정보 등 변경이 적고 정확성이 중요한 정보는 Oracle에서 직접 조회
    • Redis에 저장된 데이터는 별도 프로세스나 CDC 방식으로 Oracle에서 실시간 동기화

✅ 개발자가 고려할 핵심 포인트

  • Redis 키 설계를 잘 해야 함 (주식코드:데이터유형:시점 같은 구조)
  • TTL 및 Expire 정책을 세밀히 설정해야 함
  • 데이터 갱신 로직 (DB → Redis) 설계 필요 (Kafka, Trigger, CDC 등 활용)
  • Fallback 전략도 필요: Redis 장애 시 DB 조회로 전환

결론

MTS/HTS의 성능과 응답속도를 중시하고 동시접속자가 많다면2번 Redis 방식이 절대적으로 유리합니다.
단, 안정성과 정합성을 동시에 고려해야 하므로 1번은 보조용/백업용으로 남겨두는 하이브리드 구조가 실전에서는 가장 많이 채택됩니다.

질문)
최근들어서 HTS나 MTS클라이언트에서 데이타의 송수신과정을 REDIS를 활용하는 예가 많다고 합니다. 실제 TCP/IP소켓통신으로 HTS나 MTS클라이언트와 서버를 만드는것보다 효과적일까요?

답변)

요즘 HTS (Home Trading System), MTS (Mobile Trading System)에서 Redis를 활용한 송수신 처리가 많아진 배경과, 그것이 기존의 TCP/IP 소켓 통신 구조보다 왜 더 효과적일 수 있는지를 설명드리겠습니다.


✅ 요약 결론

단순한 요청/응답 구조만 있는 경우엔 TCP/IP 소켓 통신이 빠를 수 있지만,
HTS/MTS처럼 다수의 실시간 데이터, 멀티 프로세스, 비동기처리, 병렬성이 중요한 시스템에서는
Redis를 중간 브로커로 활용하는 방식이 구조적으로 훨씬 효과적입니다.


✅ 비교: 전통적인 TCP/IP vs Redis 기반 메시지 브로커 방식

항목전통 TCP/IP 직접통신Redis 활용 구조
통신 구조 클라이언트 ↔ 서버 직접 연결 클라이언트 ↔ Redis ↔ 서버
연결 수 각 클라이언트마다 연결 필요 Redis와만 연결 유지
병렬성 직접 구현 필요 (epoll, 스레드 등) Redis가 Pub/Sub, Stream 지원
확장성 서버 부하 증가 시 수평 확장 어려움 Redis Cluster로 손쉬운 분산처리
데이터 공유 프로세스 간 공유 어려움 (IPC 필요) Redis가 공유 메모리 역할
복잡성 낮음 (단일 시스템이면) 구조는 조금 복잡하지만 확장성 우수
장애 대응 직접 로직 작성 필요 Redis Sentinel, AOF 등 내장 기능 있음
 

✅ HTS/MTS에서 Redis가 활용되는 실제 이유

  1. 🔁 Pub/Sub 또는 Stream으로 실시간 시세 브로드캐스팅
    • 서버가 1번 계산하면, Redis가 다수 클라이언트에게 푸시
    • 예: "삼성전자 현재가 83,400원"을 Redis가 10만 명에게 전송
  2. 🧵 멀티 프로세스 간 데이터 공유
    • 주문 처리기, 체결 처리기, 시세 처리기 등 여러 프로세스가 Redis를 통해 데이터를 교환
    • LPOP, XREAD, BRPOP 등으로 안정적 큐 역할
  3. ⚙️ 비동기 처리와 부하 분산
    • 클라이언트가 요청한 주문을 Redis에 넣으면, 백엔드 프로세스가 꺼내 처리
    • 이때 서버는 즉시 응답 가능 → 빠른 체감 속도 제공
  4. 📈 통계, 로그, 알람 등 다양한 활용
    • Redis는 단순 캐시를 넘어서, 지표 수집/모니터링에도 활용

✅ Redis가 성능도 뛰어난 이유

  • C로 만들어진 단일 스레드 event loop 구조 (굉장히 빠름)
  • 키 기반 접근은 대부분 O(1)
  • 평균 레이턴시: < 1ms, 초당 수십만 건 처리 가능
  • CPU 및 I/O 병목에 강하고, 데이터 구조 다양함 (list, set, stream 등)

✅ 실제 도입 사례

  • 국내 금융사: 키움증권, NH투자증권 등에서 Redis 기반 실시간 푸시 처리 적용
  • 해외: Robinhood, Binance 등도 Redis 기반 마이크로서비스 연동

✅ 결론 요약

상황추천 방식
단일 시스템, 트래픽 적고 구조 단순함 TCP/IP 직접 통신
수많은 클라이언트, 시세/주문/체결 등 비동기 시스템 Redis 활용 구조 강력 추천
 

✅ 부가 설명

Redis를 사용한다고 해서 TCP를 쓰지 않는 건 아닙니다.
보통 구조는 이렇게 됩니다:

markdown
복사편집
HTS/MTS ↔ (TCP) ↔ 프론트 서버 ↔ (Redis로 데이터 전송) ↔ 백엔드 처리기 ↕ 실시간 시세 시스템

즉, TCP는 입출구용, Redis는 내부 데이터 전달 및 공유용으로 조화롭게 사용됩니다.

질문)
TCP/IP 소켓통신으로 KEY를 요청했을떄에, VALUE를 클라이언트에 송신해주는 프로그램이 있습니다. REDIS를 이용해서 KEY를 POP한다면, 두개의 프로그램의 통신속도는 얼마나 차이가 있을까요? 성능적으로 거의 유사하다고 볼수 있을까요?

답변)

좋은 질문입니다. TCP/IP 소켓 통신 기반의 직접 구현된 키-값 서버와 Redis의 key pop을 비교하는 질문인데요, 성능 비교는 사용 방식과 구조에 따라 달라지며, 다음과 같은 관점으로 설명할 수 있습니다.


✅ 요약 결론

"성능적으로 거의 유사하다고 볼 수는 없습니다."
Redis는 고성능이지만, 상황에 따라 직접 구현한 TCP 서버가 더 빠를 수도, 느릴 수도 있습니다.
다만 일반적으로는 Redis가 더 최적화되어 있고 병목이 적은 구조입니다.


✅ 주요 성능 차이 요인 비교

항목직접 구현 TCP 서버Redis
처리 속도 단순 로직이면 빠를 수 있음 고도로 최적화됨 (C언어 기반)
데이터 구조 단순 배열이나 맵 사용 가능 다양한 자료구조 + Lock-free 처리
POP 처리 직접 메모리 pop → 빠름 LPOP, SPOP 등 atomic 명령 지원
동시성 직접 스레드/epoll 등 구현 필요 단일 스레드 기반 + event loop
안정성/확장성 직접 구현시 취약 가능성 수많은 테스트와 실제 적용 사례
 

✅ 예시 비교 (성능 관점)

  • 직접 구현 TCP 소켓 서버
    • 단일 연결에서 key에 해당하는 값을 메모리에서 직접 pop 하는 구조
    • key 탐색 + 값 반환이 수 μs (마이크로초) 단위
    • 예) std::unordered_map 사용 시 평균 100~300ns
  • Redis (로컬에 띄운 경우)
    • LPOP, GET 등의 명령은 평균적으로 1μs~5μs 정도의 속도를 보임
    • 네트워크 지연 무시하면, 내부 처리 속도는 상당히 빠름
    • redis-benchmark 결과: 100,000 ops/sec 이상 (싱글 스레드 기준)

✅ 어떤 경우에 유사한 성능일까?

  • 단순한 메모리 구조 (map, 배열)에 키/값만 존재할 경우
  • 클라이언트 수가 적고, 동시성이나 보안이 중요하지 않은 환경
  • 네트워크 지연이 지배적인 구조 (데이터 1개 주고받는데 1ms 이상)라면, 처리 속도 차이가 체감되지 않음

✅ 언제 Redis가 훨씬 유리한가?

  • 다수의 클라이언트가 동시에 pop 요청 시
  • 자료구조 관리, 동기화, atomic 처리가 필요한 경우
  • 장애복구, 데이터 지속성(RDB, AOF), 클러스터링 같은 부가기능이 필요할 때
  • 고부하, 실시간 응답을 요구하는 환경 (예: 게임 서버, 실시간 분석)

✅ 실제 벤치마크를 원할 경우

직접 다음과 같은 방법으로 비교할 수 있습니다:

  • C언어로 구현한 TCP 서버: gettimeofday() 또는 clock_gettime()으로 round-trip 시간 측정
  • Redis:
  • bash
    복사편집
    redis-cli --latency -n 1000 redis-benchmark -t lpop,get -n 100000 -c 50

✅ 결론

상황추천 방식
극한의 단순함, 최대 성능 원함 직접 구현 TCP 서버
일반적인 안정성, 확장성, 기능성 고려 Redis
 

**“처리할 데이터량이 많고, 유지보수나 확장성을 고려한다면 Redis 사용이 훨씬 유리”**하며,
“극히 단순하고 제어권이 필요한 로직만 있다면 C로 직접 구현한 서버도 빠릅니다.”

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define INITIAL_CAPACITY 4

typedef struct {
    char** items;
    int size;
    int capacity;
} StringList;

char* strdup(const char* s) {
    char* copy = malloc(strlen(s) + 1);
    if (copy) strcpy(copy, s);
    return copy;
}

// 초기화 함수
void initList(StringList* list) {
    list->size = 0;
    list->capacity = INITIAL_CAPACITY;
    list->items = (char**)malloc(sizeof(char*) * list->capacity);
}

// 메모리 해제 함수
void freeList(StringList* list) {
    for (int i = 0; i < list->size; i++) {
        free(list->items[i]); // strdup한 문자열 해제
    }
    free(list->items);
}

// Add 함수 (C#의 List<string>.Add("...")와 유사)
void add(StringList* list, const char* str) {
    if (list->size >= list->capacity) {
        list->capacity *= 2;
        list->items = (char**)realloc(list->items, sizeof(char*) * list->capacity);
    }
    list->items[list->size++] = strdup(str); // strdup은 문자열 복사
}

// 출력 함수

#if(0)
void printList(const StringList* list) {
    for (int i = 0; i < list->size; i++) {
        printf("[%d] %s\n", i, list->items[i]);
    }
}
#endif
#if(1)
void printList(const StringList* list) {
    printf("총 요소 수: %d개\n", list->size);
    printf("현재 확보된 메모리 용량 (capacity): %d개\n", list->capacity);
    for (int i = 0; i < list->size; i++) {
        printf("[%d] %s\n", i, list->items[i]);
    }
}
#endif
int main() {
    StringList myList;
    initList(&myList);

    add(&myList, "apple");
    add(&myList, "banana");
    add(&myList, "cherry");
    add(&myList, "strawberry");
    add(&myList, "banana");
    add(&myList, "watermelon");
    add(&myList, "apple");
    add(&myList, "banana");
    add(&myList, "cherry");
    add(&myList, "strawberry");
    add(&myList, "banana");
    add(&myList, "watermelon");

    printList(&myList);

    freeList(&myList);
    return 0;
}
/*
INITIAL_CAPACITY는 동적 배열을 처음 만들 때, 메모리를 얼마나 확보할지를 정해주는 초기 크기입니다.

 왜 필요한가요
C에서 배열은 고정된 크기이므로, 가변적으로 데이터를 추가하려면 처음에 최소한의 공간을 확보해야 합니다.
INITIAL_CAPACITY는 다음과 같은 이유로 중요합니다:

1. 메모리 할당을 위한 기준
malloc() 또는 realloc()으로 items 배열의 메모리를 할당할 때, 처음에는 몇 개의 문자열을 저장할 수 있게 할지 기준이 필요합니다.
2. 성능 최적화
처음부터 매번 1개씩만 공간을 늘리면, 문자열을 하나 추가할 때마다 realloc()이 발생해 성능이 매우 떨어집니다.
그래서 보통 2배씩 확장하는 방식(예: 4 → 8 → 16 ...)을 사용하는데, 그 출발점이 INITIAL_CAPACITY입니다.
3. 가독성과 유지보수
하드코딩된 숫자(4, 8 등)를 직접 쓰기보다는, INITIAL_CAPACITY처럼 이름을 붙이면 코드의 의미를 이해하기 쉽고 나중에 변경하기도 쉽습니다.

예를 들어 보면
#define INITIAL_CAPACITY 4
이렇게 하면, 처음 malloc() 할 때 4칸짜리 char* 배열을 만들고, 그 이후 추가가 생기면 8칸, 16칸...으로 늘어나게 설계합니다.
*/

질문)
1번 예시)

foreach (KeyValuePair<string, apmmultipleredismanager> redis in _redises)</string, apmmultipleredismanager>
{
    query = "insert all ";
    query = makeInsertString(query, redis.Value.Symbol);
    query += " SELECT * FROM DUAL";
    redis.Value.SendExeQuery(currentHandle, 2, 7, MetaData.APP_TYPE.QUERY.ToString(), query);
}



2번 예시)

query = "insert all ";
foreach (KeyValuePair<string, apmmultipleredismanager> redis in _redises)</string, apmmultipleredismanager>
{
    query = makeInsertString(query, redis.Value.Symbol);
}
query += " SELECT * FROM DUAL";    
redis.Value.SendExeQuery(currentHandle, 2, 7, MetaData.APP_TYPE.QUERY.ToString(), query);




답변)

INSERT ALL 구문을 사용할 때 중요한 것은 INSERT ALL과 INTO 절의 위치입니다. 두 가지 예시를 비교하며 올바른 구문을 설명하겠습니다.


💡 1번 예시 분석

foreach (KeyValuePair<string, APMMultipleRedisManager> redis in _redises) { query = "insert all "; query = makeInsertString(query, redis.Value.Symbol); query += " SELECT * FROM DUAL"; redis.Value.SendExeQuery(currentHandle, 2, 7, MetaData.APP_TYPE.QUERY.ToString(), query); }

🚫 문제점

  • 문법 오류: INSERT ALL 다음에 바로 SELECT가 오면 안 됩니다.
  • 반복 문제: foreach 루프 안에서 INSERT ALL을 시작하고 바로 SELECT * FROM DUAL을 붙이면, 하나의 INSERT ALL 구문에 여러 행을 넣지 못합니다.
  • 비효율: 루프마다 매번 단일 INSERT를 실행하는 형태가 됩니다.

💡 2번 예시 분석

query = "insert all "; foreach (KeyValuePair<string, APMMultipleRedisManager> redis in _redises) { query = makeInsertString(query, redis.Value.Symbol); } query += " SELECT * FROM DUAL"; redis.Value.SendExeQuery(currentHandle, 2, 7, MetaData.APP_TYPE.QUERY.ToString(), query);

✅ 올바른 구조

  • 루프 안에서 makeInsertString으로 여러 INTO 절을 만들고, 루프가 끝난 후에 SELECT * FROM DUAL을 붙입니다.
  • 하나의 INSERT ALL 구문으로 여러 행을 한꺼번에 삽입할 수 있습니다.

💡 결론: 2번 예시가 맞습니다!

👉 올바른 SQL 예시 (예상 형태)

루프가 완료된 후의 쿼리는 다음과 같은 형태가 됩니다:

INSERT ALL
INTO my_table (col1, col2) VALUES ('A', 1)
INTO my_table (col1, col2) VALUES ('B', 2)
INTO my_table (col1, col2) VALUES ('C', 3)
SELECT * FROM DUAL;
  • 이 구조라면 한 번의 실행으로 여러 행을 삽입할 수 있습니다.
  • INSERT ALL 구문은 하나의 트랜잭션으로 처리되므로 성능상 유리합니다.

2번 구조로 작성하는 것이 성능과 문법 면에서 적절합니다.
혹시 makeInsertString 함수의 내부 구조도 확인이 필요하다면 알려주세요!

 

그린 데이 - 21 Guns
Green Day 트리오 밴드

이 곡은 빌보드 핫100 차트에서 22위로 정점을 찍으며 상업적으로 엄청난 성공을 거두었는데요, 이들이 2005년에 발표한
"Wake Me Up When September Ends" 이후로 최고 차트 싱글이 되었습니다.
이 곡은 영화 "트랜스포머: 패자의 역습 (Revenge of the Fallen)"에서도 등장한 곡이며, 2010년에 "최고의 록 퍼포먼스 (Best RockPerformance)" 의 그래미상 후보에 올랐습니다.

전쟁에 대한 반대 캠페인송:
이 곡이 수록된 앨범 제목이 "21st Century Breakdown (21세기의 붕괴)"입니다.
제목만으로 말이 필요없는 가사입니다. 아이러니하게도 21세기에도 전쟁은 계속되고 있는데요, 과연 무엇을 위한 전쟁일까요?
위키백과에 의하면 음악 블로그 비평가들이 이 곡이 대해 "전쟁에 반대하는 캠페인에 사용하기에 흠집없이 매끄러운 노래로서도 완벽하다"는 찬사를 보냈습니다.

 

Do you know what's worth fightin' for
When it's not worth dyin' for?
Does it take your breath away
And you feel yourself suffocatin'?
Does the pain weigh out the pride
And you look for a place to hide?
Did someone break your heart inside?
You're in ruins

One, twenty-one guns
Lay down your arms, give up the fight
One, twenty-one guns
Throw up your arms, into the sky
You and I

When you're at the end of the road
And you lost all sense of control
And your thoughts have taken their toll
When your mind breaks the spirit of your soul
Your faith walks on broken glass
And the hangover doesn't pass
Nothing's ever built to last
You're in ruins

One, twenty-one guns
Lay down your arms, give up the fight
One, twenty-one guns
Throw up your arms, into the sky
You and I

Did you try to live on your own
When you burned down the house and home?
Did you stand too close to the fire
Like a liar looking for forgiveness from a stone?

When it's time to live and let die
And you can't get another try
Somethin' inside this heart has died
You're in ruins

One, twenty-one guns
Lay down your arms, give up the fight
One, twenty-one guns
Throw up your arms, into the sky

You and I
목숨을 바칠 필요도 없는데,
무엇을 위해 싸우는지 알고 있기나 하나요?
당신을 숨막히게 하거나
질식시킬 것 같은 기분인가요?
그런 고통이 당신의 자존심을 짓눌러서
어디 숨을 곳을 찾고 있나요?
누가 당신의 마음을 깊히 다치게 했나요?
당신은 망가집니다.

한 발, 스물 한 발
무기를 내려 놓고, 전쟁을 그만 해요.
한 발, 스물 한 발
무기를 던져 버려, 하늘을 향해.
당신과 내가 (그만 두자)

당신이 가는 길의 끝자락에 몰렸을 때에
당신은 모든 통제력을 잃게 되죠.
그로 인해 신성한 당신의 영혼을 깨트리면
당신의 생각들은 커다란 피해를 입어요.
당신의 신념은 깨진 유리 위를 걷게 되며,
그 후유증은 사라지지 않아요.
(전쟁으로) 영원한 것은 없어요.
당신은 망가집니다.

한 발, 스물 한 발
무기를 내려 놓고, 전쟁을 그만 해요.
한 발, 스물 한 발
무기를 던져 버려, 하늘을 향해.
당신과 내가 (그만 두자)

내 집과 고향을 다 태우면서
혼자만 살아 보려고 하셨나요?
아직도 불(전쟁)에 무척 가까이 있으면서
죽은 사람의 묘비 앞에서 거짓말장이 처럼 있을건가요?

이제 받아들일 때가 되었어요.
이 가슴 속에서 뭔가 죽었는데,
또 다른 시도를 하면 안됩니다.
당신은 망가집니다.

한 발, 스물 한 발
무기를 내려 놓고, 전쟁을 그만 해요.
한 발, 스물 한 발
무기를 던져 버려, 하늘을 향해.

당신과 내가 (그만 두자)

**"채널, 매칭, 매매정보"**는 거래소 시스템 내에서의 데이터 흐름 또는 기능적 순서를 잘 설명하는 키워드들인데요, 각각의 의미와 함께 실제 발생 순서에 맞춰 설명해볼게요.


✅ 1. 채널 (Channel)

📡 데이터가 오가는 경로 또는 통신선로

  • 거래소와 증권사(또는 내부 시스템) 간의 데이터 전송 통로입니다.
  • 실시간 시세, 주문 요청, 체결 통보 등 모든 메시지는 채널을 통해 오갑니다.

    -  주문요청 메세지 채널
    -  주문체결통보 메세지 채널
    -  실시간시세. 정보분배에 대한 메세지 채널

  • 하나의 물리적 채널에 여러 논리 채널이 포함되어 데이터를 분류합니다.


    2. 논리적 채널 (Logical Channel)
    • 하나의 물리적 회선 내에서 구분된 데이터 흐름의 단위
    • 실시간 데이터의 유형별로 채널을 나눔
      (예: 체결 정보, 호가 정보, 지수 정보 등 각각 채널로 나눔)

예시:

채널 번호용도
100번 채널 코스피 체결 정보
101번 채널 코스닥 체결 정보
110번 채널 지수 정보
120번 채널 호가 정보


  • 1. 물리적 채널 (Physical Channel)
    • 거래소와 증권사 간에 구성된 전용 회선 또는 네트워크 연결을 말함
    • 주로 전용망, VPN, MPLS 회선 등으로 구성
    • FEP 시스템이나 RDS 송수신 시스템이 이 물리적 채널을 통해 데이터를 송수신함
    예시:
    • 채널 1: 실시간 시세(RDS) 송출용
    • 채널 2: 주문/체결 요청 전송용 (OEP, EFP 등)



 

🔹 위치상 순서:

데이터가 흘러가는 "통로"이므로 항상 처음에 존재함.


✅ 2. 매칭 (Matching)

⚖️ 주문과 주문이 만나서 체결되는 과정

  • 투자자가 주문(매수/매도)을 넣으면, 거래소의 **매칭 엔진(Matching Engine)**에서 이를 처리합니다.
  • 가격/시간 우선 원칙에 따라 상대 주문과 자동으로 매칭됩니다.
  • 매칭이 되면 체결이 발생하고, 그 결과가 다음 단계로 넘어감.

🔹 위치상 순서:

채널을 통해 주문이 들어온 뒤, 두 번째 단계에서 처리됨.


✅ 3. 매매정보 (Trade Information)

📊 매칭 결과로 생성된 체결 정보

  • 어떤 종목이 얼마에, 몇 주가, 언제 체결되었는지를 담은 정보입니다.
  • 이 정보는 거래소의 RDS 시스템 등을 통해 실시간으로 외부로 송출됩니다.
  • 또한 거래소 내부 시스템이나 정산 시스템에도 기록됩니다.

🔹 위치상 순서:

매칭이 완료된 뒤, 마지막 단계에서 생성/송출됨.


📌 전체 순서 요약

[1] 채널: 데이터가 흐르는 통로  
     ↓  
[2] 매칭: 주문이 만나서 체결됨  
     ↓  
[3] 매매정보: 체결 결과가 실시간 전송됨

 


🎯 예시 흐름

단계설명
1. 채널을 통해 주문 도착 증권사에서 거래소로 매수 주문 전송
2. 매칭 엔진에서 주문 매칭 기존 매도 주문과 가격이 일치하여 체결
3. 매매정보 생성 및 전송 체결 시각, 수량, 가격 정보가 채널을 통해 다시 전송됨

REQUEST)
windows10 제어판에서 전원및 절전에서 추가전원 설정에서 고급전원관리옵션설정에서
프로세서전원관리에서 최대프로세서 상태를 100% 에서 80%로 줄이면, 미니 데스크탑의 팬소음을 줄일수 있나요?

  1. CPU 클럭 제한
    • 최대 프로세서 상태를 80%로 설정하면 CPU가 최고 속도로 작동하지 않고, 일정 수준에서 성능이 제한됩니다.
    • 이로 인해 CPU 발열이 줄어들고, 쿨링 팬이 고속으로 작동할 필요가 적어져 팬 소음이 감소할 수 있습니다.
  2. 전력 소비 감소
    • CPU가 100% 성능을 유지하려면 더 많은 전력을 소비하고, 이에 따라 발열이 증가합니다.
    • 80%로 제한하면 전력 소비가 줄어들면서 발열도 줄고, 팬 속도가 낮아질 가능성이 큽니다.
  3. 팬 소음 감소
    • CPU 온도가 낮아지면 팬이 천천히 돌거나, 심한 경우에는 아예 작동을 멈추는 경우도 있습니다.
    • 특히, 작은 크기의 미니 데스크탑은 발열 관리가 어려워 팬이 자주 빠르게 돌지만, CPU 제한을 걸면 소음이 확실히 줄어듭니다.

🔹 주의할 점

성능 저하 가능성

  • CPU 성능이 제한되므로, 고성능이 필요한 작업(예: 게임, 영상 편집, AI 모델 실행 등)에서 속도가 느려질 수 있습니다.
  • 단순 웹서핑이나 문서 작업 등은 큰 차이가 없을 가능성이 큽니다.

노트북에서는 배터리 절약 효과도 있음

  • 노트북의 경우, 이 설정을 적용하면 배터리 사용 시간이 증가하는 장점도 있습니다.

설정 후 온도 확인 추천

  • CPU 온도가 실제로 얼마나 낮아지는지 HWMonitor 같은 프로그램으로 확인해 보면 좋습니다.


Information)


https://www.genmachinepc.com/download-ren-series/

Ren 7 Series)Ren 7 Series)Ren 7 Series)Ren 7 Series)Ren 7 Series)Ren 7 Series)Ren 7 Series)Ren 7 Series)

GenMachine AMD 라이젠 7 4800H 미니 PC - 16GB 램 + 512GB SSD, DDR4 최대, 와이파이 6(2.4Gbps), RTL8852, 일상 사용을 위한 컴팩트 데스크탑 게이밍 PC, 통합 그래픽

Ex)
GenMachine Mini PC Ren4000 4500U AMD Ryzen5 4500U GPU DDR4 3200MHz RAM WiFi6 NUC

Especially)

Driver to significantly improve fan noise issues
 
~50도이하: 1단 무소음급
~60도이하: 2단 적당히 조용한소음
60도이상~: 3단 꽤 거슬리는소음 <<여기부터 고통의 시작
80도이상~: 4단 이륙

단계였었는데 패치후에는,

~70도이하: 1단 무소음급
70도이상~: 2단 적당히 조용한소음

대부분 2단 소음까지만 남 (어쩌다 3단소음 들릴때가 간혹있음)
하지만 당연히 풍량이 매우 약해졌으므로 발열도 미쳐서 70~80도 자주넘기고 스로틀링 팍팍 걸려주심
근데 어차피 소음때문에 성능제한하고 쓸거면 그냥 패치하고 온도제한 80~85도정도 걸어두는게
성능 소음에서 모든면에서 훨씬 나아보임
참고로 젠머신보드에 AN2P 쿨러로도 테스트해봤는데 잘됨.
보드도 거의 같으니 AN2P에서도 잘될거같긴한데 해보진 않아서 장담은 못함

안에 설명 파일도 있는거 같은데 뭔가 복잡해보임
테스트결과 단순히 바이오스를 덮어씌우거나 윈도 재설치하는 것만으로는
팬속이 원래대로 복구되지 않음

주의! 이 툴은 젠머신 ren4000 5000 7000 전용임 (4500u 4700u 5625u 5700u 5600h 5800u 5800h 7530u 7730u 등)
7840hs는 해당없음.

체크썸 확인결과 ren4000 5000 7000 모두 동일한 파일

https://www.genmachinepc.com/download/tools-ren/

Tools - Ren - GenMachine
Driver to significantly improve fan noise issues

http://www.genmachinepc.com

 

다운받고 압축풀면 확장자없는 근본없는 파일이 나오는데
이게 자동압축풀림 파일이라 뒤에 .exe 확장자를 붙여주고,
C:\ 위치에 옮겨두고,
cmd 관리자나 파워쉘 관리자 권한으로 cd\로 위치로 가서 파일 실행,
그럼 알아서 투닥투닥 재부팅되고 팬속

 적용됨. 끝

 

readme.txt
0.00MB

+ Recent posts