석수코딩교육

질문)
현재 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가 의도한 구조는?

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

✅ 요약 정리

Visual Studio에서 32비트 프로그램을 64비트로 마이그레이션하는 방법은 다음과 같습니다:

1. 프로젝트 설정 확인

• 기존 프로젝트가 32비트로 설정된 경우, 이를 64비트로 변경해야 합니다. 이를 위해 프로젝트 파일을 열고, 빌드 설정을 64비트로 변경합니다.

2. 프로젝트 속성 변경

• 프로젝트 우클릭 → 속성으로 이동합니다.
• **구성 관리(Configuration Manager)**로 가서, 활성(Active) 설정을 64비트로 변경합니다.
• 플랫폼(Platform) 옵션에서 x64를 선택합니다. 만약 x64 옵션이 없다면, 새로 만들기(Create New) 버튼을 클릭하여 x64를 추가해 줍니다.

3. 코드 변경

• 포인터 크기: 64비트에서 포인터는 64비트이므로, 포인터 크기와 관련된 코드가 있다면 이를 64비트에 맞게 조정해야 할 수 있습니다.
• 정수형 변수 크기: 32비트에서는 int나 long의 크기가 4바이트였으나, 64비트 시스템에서는 long의 크기가 8바이트일 수 있습니다. 이를 고려하여 코드 수정이 필요할 수 있습니다.
• DLL과 라이브러리 호환성: 사용하는 외부 라이브러리나 DLL이 64비트 버전으로 제공되는지 확인하고, 필요하다면 64비트 버전으로 교체합니다.

4. 빌드 및 디버깅

• 프로젝트가 64비트로 설정되었으면, 빌드(Build) 버튼을 눌러 64비트 애플리케이션으로 빌드합니다.
• 빌드가 성공한 후, **디버깅(Debugging)**을 통해 64비트 환경에서 제대로 동작하는지 확인합니다.

5. 종속성 확인

• 64비트 환경에서 사용하는 모든 외부 종속성(예: 외부 DLL, 라이브러리 등)이 64비트 버전과 호환되는지 확인합니다. 32비트 라이브러리와 64비트 애플리케이션은 호환되지 않습니다.

6. 테스트

• 애플리케이션이 예상대로 64비트 환경에서 잘 동작하는지 충분히 테스트합니다. 특히 메모리 처리나 성능 관련 부분에서 차이가 있을 수 있으므로, 세밀하게 검토해야 합니다.

위 단계를 따르면 기존 32비트 프로젝트를 64비트로 마이그레이션할 수 있습니다. 이 과정에서 발생할 수 있는 호환성 문제를 처리하기 위해, 코드 수정이 필요할 수 있다는 점을 염두에 두세요.

Visual Stuio에서 프로젝트를 만들어서 실행한 결과소스로만으로 Windows cmd창에서 같은 실행파일을 만들기

>dotnet new winforms -o DotWinFrm21
>cd DotWinFrm21
>dotnet add package ServiceStack
>dotnet add package Newtonsoft.Json
>dotnet add package ServiceStack.Redis
>dotnet add package Systehttp://m.Data.SQLite