석수코딩교육

질문)
메모장에서 작성되어진 한글문서를 저장하는 방법은 여러가지입니다. 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. 인코딩별 상황

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. 요약

질문)
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 로 만들어진 프로젝트들은 계속 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칸...으로 늘어나게 설계합니다.
*/

질문)
1번 예시)

2번 예시)

답변)

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

💡 1번 예시 분석

🚫 문제점

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

💡 2번 예시 분석

✅ 올바른 구조

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

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

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

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

• 이 구조라면 한 번의 실행으로 여러 행을 삽입할 수 있습니다.
• 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세기에도 전쟁은 계속되고 있는데요, 과연 무엇을 위한 전쟁일까요?
위키백과에 의하면 음악 블로그 비평가들이 이 곡이 대해 "전쟁에 반대하는 캠페인에 사용하기에 흠집없이 매끄러운 노래로서도 완벽하다"는 찬사를 보냈습니다.

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

✅ 1. 채널 (Channel)

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

• 거래소와 증권사(또는 내부 시스템) 간의 데이터 전송 통로입니다.
• 실시간 시세, 주문 요청, 체결 통보 등 모든 메시지는 채널을 통해 오갑니다.
  
  -  주문요청 메세지 채널
  -  주문체결통보 메세지 채널
  -  실시간시세. 정보분배에 대한 메세지 채널
  
  
• 하나의 물리적 채널에 여러 논리 채널이 포함되어 데이터를 분류합니다.
  
  
  2. 논리적 채널 (Logical Channel)
  • 하나의 물리적 회선 내에서 구분된 데이터 흐름의 단위
  • 실시간 데이터의 유형별로 채널을 나눔
    (예: 체결 정보, 호가 정보, 지수 정보 등 각각 채널로 나눔)
    
    

예시:

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

🔹 위치상 순서:

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

✅ 2. 매칭 (Matching)

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

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

🔹 위치상 순서:

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

✅ 3. 매매정보 (Trade Information)

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

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

🔹 위치상 순서:

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

📌 전체 순서 요약

🎯 예시 흐름

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\로 위치로 가서 파일 실행,
그럼 알아서 투닥투닥 재부팅되고 팬속

 적용됨. 끝

Windows 11과 Windows 10의 차이는 주로 UI, 보안, 성능 최적화 등의 소프트웨어적인 부분이 크지만, 하드웨어 성능 및 운용 안정성에도 영향을 미칠 수 있는 몇 가지 변화가 있습니다.

✅ Windows 11이 하드웨어에 미치는 영향 및 개선점

1️⃣ CPU 및 메모리 효율성 향상 → 전력 소비 감소 및 발열 관리 개선

• Windows 11은 CPU 코어 스케줄링을 개선하여 작업을 더 효율적으로 배분합니다.
• Intel 12세대 이상 (Alder Lake) 및 AMD Ryzen 5000 이상에서 효율적인 스레드 배분이 이루어져 성능과 전력 소비가 최적화됨.
• 결과적으로 노트북에서는 배터리 수명이 늘어나고, 데스크탑에서는 발열과 소음이 줄어드는 효과를 기대할 수 있음.

📌 예시:

• Intel의 하이브리드 아키텍처(Performance Core + Efficient Core)를 활용한 스케줄링 최적화 → 성능 코어와 효율 코어의 배분이 더 효율적으로 동작.
• Windows 10에서는 모든 코어가 비효율적으로 동작할 가능성이 있지만, Windows 11에서는 작업을 적절히 배분하여 전력 소모가 줄고 CPU 발열이 감소함.

2️⃣ 스토리지 (SSD) 성능 향상 → 부팅 속도 및 로딩 시간 단축

• Windows 11은 NVMe SSD 및 DirectStorage API를 적극 활용하도록 설계됨.
• DirectStorage 기술은 CPU 부하를 줄이고 GPU가 직접 데이터를 처리할 수 있도록 지원 → 게임 및 앱 로딩 속도 대폭 향상.
• Windows 10에서도 일부 지원되지만, Windows 11에서 최적화가 더 잘 되어 있음.

📌 예시:

• 게임 로딩 속도 개선: DirectStorage를 지원하는 게임(예: 포르자 호라이즌 5, 마인크래프트 RTX)에서 로딩 속도가 30~40% 단축됨.
• 부팅 속도 개선: NVMe SSD 사용 시, Windows 11에서의 부팅 속도가 Windows 10보다 평균적으로 5~10% 빠름.

3️⃣ RAM 사용 최적화 → 백그라운드 프로세스 부담 감소

• Windows 11에서는 Foreground Performance Priority 기능이 적용됨.
• 즉, 현재 사용 중인 앱에 더 많은 리소스를 할당하고, 백그라운드 앱은 최소한의 리소스를 사용하도록 조정됨.
• 덕분에 RAM 사용량이 줄어들어 시스템이 보다 안정적으로 동작함.

📌 예시:

• 동일한 8GB RAM 환경에서, Windows 10은 약 4~5GB 사용, Windows 11은 3.5~4GB로 조금 더 가벼운 동작을 보임.
• 특히 멀티태스킹(여러 개의 창을 동시에 띄우는 작업)에서 성능이 향상됨.

4️⃣ 그래픽 성능 최적화 → 게임 및 멀티미디어 성능 개선

• Windows 11은 AutoHDR 및 개선된 GPU 스케줄링 기능을 제공하여 게임 및 영상 재생 품질이 향상됨.
• Windows 10에서는 HDR이 지원되지 않는 게임도 Windows 11에서는 AutoHDR로 자동 업스케일이 가능.
• 또한, 최신 DirectX 12 Ultimate을 기본 지원하여 RTX 기능, VRS(Variable Rate Shading) 등 GPU 성능을 극대화하는 기능을 활용 가능.

📌 예시:

• DirectX 12 Ultimate이 적용된 게임(예: Cyberpunk 2077, MS Flight Simulator)에서 프레임 향상 효과
• Windows 10 대비 AutoHDR이 활성화된 게임에서 색감 개선 및 휘도 향상

5️⃣ 배터리 최적화 → 노트북 사용자에게 유리

• Windows 11은 전력 관리 알고리즘을 개선하여 배터리 소모량을 줄임.
• 배터리 수명이 최대 10~15% 증가할 수 있음.
• CPU와 RAM, SSD 사용량이 줄어들면서 저발열 설계가 강화됨.

📌 예시:

• 동일한 하드웨어에서 Windows 10 대비 Windows 11에서 1~2시간 배터리 수명 증가 확인됨.

❗ 하드웨어 업그레이드 없이도 Windows 11로 성능 향상을 기대할 수 있는가?

가능한 부분이 있음.

• 최신 CPU 및 SSD를 사용할 경우 Windows 11에서 더 효율적으로 동작함.
• DirectStorage, AutoHDR, 전력 최적화 등의 기능으로 체감 성능이 Windows 10보다 나아질 수 있음.
• 하지만 Windows 10에서 이미 최적화가 잘 되어 있다면 체감 차이가 크지는 않을 수도 있음.

💡 결론: Windows 11이 하드웨어에 미치는 주요 영향

✔ CPU 및 전력 효율 최적화 → 발열 및 소음 감소 🚀
✔ SSD & NVMe 성능 향상 → 부팅 및 로딩 속도 개선 ⚡
✔ RAM 사용 최적화 → 시스템 안정성 향상 🖥
✔ GPU 성능 개선 → 게임 및 멀티미디어 성능 향상 🎮
✔ 배터리 최적화 → 노트북 사용 시간 증가 🔋

❓ 업그레이드 추천 여부

• 최신 하드웨어 사용 중이라면 → Windows 11로 업그레이드하는 것이 유리함.
• 구형 하드웨어(특히 TPM 2.0이 없는 경우) → Windows 10 유지하는 것이 좋음.
• 게임을 자주 한다면? → DirectStorage와 AutoHDR을 활용할 수 있어 Windows 11이 유리함.
• 노트북 사용자라면? → 배터리 절약 효과로 인해 Windows 11이 더 유용할 가능성이 높음.

💡 Windows 10에서도 만족스러운 성능이라면 급하게 Windows 11로 업그레이드할 필요는 없지만, 최신 하드웨어를 활용한다면 Windows 11이 더 나은 선택이 될 수 있음. 😊

실시간 데이타를 3가지의 클라이언트에서 수신받는 케이스
1. WPF(Windows Presentation Foundation)는 마이크로소프트에서 제공하는 데스크톱 GUI 프레임워크로, 윈도우 기반 응용 프로그램의 사용자 인터페이스를 표시

2. FORM
3. WEB.BROWSER

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

www.genmachinepc.com

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

BLPOP과 BRPOP은 Redis의 blocking list operations으로, 특정 리스트에서 데이터가 들어올 때까지 기다리는 명령어입니다. 하지만 두 명령어 사이에는 중요한 차이가 있습니다.

🔹 BLPOP (Blocking Left Pop)   (우리가 원하는것)

• 왼쪽(head)에서 요소를 꺼냅니다.
• 데이터가 없으면 지정된 시간(초) 동안 블로킹(대기)합니다.
• 여러 개의 리스트를 지정하면 먼저 데이터가 들어온 리스트에서 값을 꺼냅니다.

📌 사용 예제:

• mylist의 왼쪽(head) 에서 데이터를 가져오며, 없으면 10초 동안 대기합니다.

🔹 BRPOP (Blocking Right Pop)

• 오른쪽(tail)에서 요소를 꺼냅니다.
• BLPOP과 동일하게 데이터가 없으면 지정된 시간 동안 대기합니다.
• 여러 개의 리스트를 지정하면 먼저 데이터가 들어온 리스트에서 값을 꺼냅니다.

📌 사용 예제:

• mylist의 오른쪽(tail) 에서 데이터를 가져오며, 없으면 10초 동안 대기합니다.

✅ BLPOP vs. BRPOP 차이 정리

• BLPOP은 큐(FIFO) 방식과 유사
• BRPOP은 스택(LIFO) 방식과 유사

🛠 실전 예제 (Python)

Redis의 BLPOP과 BRPOP을 Python에서 실행하는 예제입니다.

BLPOP 예제 (왼쪽에서 꺼내기)

BRPOP 예제 (오른쪽에서 꺼내기)

🔥 BLPOP, BRPOP 사용 시 주의할 점

1. 리스트가 비어 있으면 블로킹되므로, timeout을 설정하는 것이 좋습니다.
2. 멀티 리스트 지원: 여러 개의 리스트를 지정하면 가장 먼저 데이터가 들어온 리스트에서 값을 꺼냅니다.
    

   BLPOP list1 list2 list3 10
   • list1, list2, list3 중 가장 먼저 데이터가 들어온 리스트에서 값을 꺼냄
3. 비동기 처리: BLPOP과 BRPOP은 블로킹 호출이므로, 비동기 처리가 필요한 경우 BRPOPLPUSH나 XREADGROUP을 고려하세요.

🚀 언제 BLPOP과 BRPOP을 사용할까?

✅ 요약:

• FIFO 방식이 필요하면 BLPOP 사용
• LIFO 방식이 필요하면 BRPOP 사용
• Blocking(대기) 방식으로 비동기 처리를 원할 때 유용함