석수코딩교육

족보)본가+외가를 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. 인코딩별 상황

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 로 프로젝트를 만들어서 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번은 보조용/백업용으로 남겨두는 하이브리드 구조가 실전에서는 가장 많이 채택됩니다.