석수코딩교육

질문)
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# 내부 함수 호출”은 아닙니다.

요약

질문)
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 컴파일) → 네이티브 코드 실행 → 결과 반환

결론

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

답변)

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

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

🔄 전환 이유

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에 데이터를 억지로 저장)

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

📎 MFC가 의도한 구조는?

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

✅ 요약 정리

질문)
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, 메모리 관리, 데이터 증발 방지 등 세심한 관리 필요

⚖️ 종합 비교

🔧 실제 적용 관점 제안

• 혼합 방식이 가장 효과적입니다.
  • 호가, 체결, 거래원 등 빈번하게 갱신되고 요청되는 실시간성 데이터는 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 기반 메시지 브로커 방식

✅ 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 기반 마이크로서비스 연동

✅ 결론 요약

✅ 부가 설명

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

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

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

답변)

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

✅ 요약 결론

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

✅ 주요 성능 차이 요인 비교

✅ 예시 비교 (성능 관점)

• 직접 구현 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

✅ 결론

**“처리할 데이터량이 많고, 유지보수나 확장성을 고려한다면 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칸...으로 늘어나게 설계합니다.
*/