최신글

CS

[CS 스터디] 1주차 운영체제 개요 + 프로세스 & 스레드

[1주차] 운영체제 개요 + 프로세스 & 스레드 컴퓨터 구성 요소 운영체제의 역할 커널(User Mode vs Kernel Mode) 프로세스의 구조 프로세스 vs 스레드 멀티프로세싱(Multiprocessing) 멀티스레딩(Multithreading) 컨텍스트 스위칭 🔵 컴퓨터 구성 요소: Top-Level View 컴퓨터 시스템은 CPU, 메모리, I/O 모듈이 System Bus 를 통해 연결되어 있으며, 운영체제는 이 자원들을 효율적으로 관리한다. 주요 구성 요소 CPU (Central Processing Unit) PC: 다음에 실행할 명령어의 주소 IR: 현재 실행 중인 명령어 MAR: 접근할 메모리 주소 MBR: 메모리에서 읽거나 쓸 데이터 I/O AR, I/O BR: 입출력 주소 및 버퍼 Execution Unit: 실제 연산 수행 Main Memory 명령어와 데이터를 저장하는 공간 주소를 통해 위치 지정 I/O Module CPU와 장치 간 데이터 전달 버퍼로 속도 차 조절 System Bus 주소 버스, 데이터 버스, 제어 버스로 구성 🔵 운영체제의 역할 운영체제는 하드웨어 자원(CPU, 메모리, 파일 등)을 효율적이고 안정적으로 관리하는 시스템 소프트웨어이다. 주요 역할은 다음과 같다: 프로세스 관리 운영체제는 여러 프로세스가 공정하게 CPU를 사용할 수 있도록 스케줄링하고, 상태를 추적하며, 컨텍스트 스위칭을 통해 프로세스를 전환한다. 프로세스 상태와 전이 New: 생성 중 Ready: 실행 준비 완료, 대기 중 Running: 명령어 실행 중 Blocked: 이벤트 대기 중 Exit: 종료됨 상태 전이 예시 Admit: New → Ready Dispatch: Ready → Running Timeout: Running → Ready Event Wait: Running → Blocked Event Occurs: Blocked → Ready Release: Running → Exit PCB (Process Control Block) 운영체제는 각 프로세스를 추적하기 위해 PCB를 사용한다. PCB는 다음 정보를 포함한다 운영체제의 프로세스 관리 구조 운영체제는 단순히 PCB 하나로만 프로세스를 관리하는 것이 아니라, 메모리 / 입출력 / 파일 시스템에 대한 정보를 포함한 다양한 제어 테이블을 함께 사용한다. 위 그림은 OS가 내부적으로 유지하는 Control Tables 구조를 나타낸 것이다. Memory Tables: 각 프로세스가 사용하는 메모리 영역과 접근 권한 정보 저장 I/O Tables: 어떤 장치를 어느 프로세스가 사용하는지 정보 기록 File Tables: 열려 있는 파일, 파일 포인터, 접근 모드 등 저장 Primary Process Table: 현재 실행 중인 모든 프로세스들의 PCB를 보관 이러한 구조는 링크드 리스트 형태로 구성되며, 운영체제가 동시에 실행 중인 프로세스를 효율적으로 관리하기 위해 사용된다. 각 프로세스는 독립된 Process Image를 가지고 있으며, 이는 코드, 데이터, 스택, PCB 정보를 포함한 프로세스의 전체 상태를 의미한다. 메모리 관리 운영체제는 프로세스마다 메모리 공간을 분리하고 보호하며, 가상 메모리를 통해 더 큰 주소 공간을 제공한다. 주소 변환(MAR, MBR) 프로세스 간 메모리 보호 물리 메모리 ↔ 가상 메모리 관리 파일 시스템 관리 운영체제는 파일 생성/삭제, 이름 지정, 접근 권한 등 파일 관련 기능을 제공한다. 파일 시스템은 디스크 상의 데이터에 대한 추상화 계층을 제공하며, 사용자가 파일을 디렉토리 구조로 관리할 수 있도록 한다. 🔵 커널(User Mode vs Kernel Mode) 커널이란? 커널은 운영체제의 핵심으로, 프로세스, 메모리, 파일, I/O 등의 자원을 직접 제어함 사용자 프로그램은 커널을 직접 조작할 수 없고, 시스템 콜(System Call) 을 통해 간접적으로 요청함 쉘(Shell)이란? 쉘은 사용자와 커널 사이의 인터페이스 사용자가 명령어를 입력하면, 쉘은 이를 시스템 콜로 번역해 커널에 전달함 크게 두 종류 - Command-line Shell: bash, zsh 등 - Graphical Shell: Windows Explorer, macOS Finder 등 GUI 기반 User Mode vs Kernel Mode 사용자 프로그램이 시스템 자원을 사용하려면 커널 모드로 전환이 필요함 커널의 주요 역할 커널은 항상 메모리에 상주하는 운영체제의 핵심이 되는 부분입니다. 컴퓨터 자원을 관리하는 자원 관리자로서 대표적으로 다음 4가지 기능을 가지고 있다. 커널은 사용자가 물리적인 하드웨어에 접근하고 사용할 수 있도록 하기 위한 목적을 가지고 있고, 사용자가 쉘(Shell)을 통해 입력한 명령어를 해석하여 하드웨어에 전달해주는 역할을 한다. 메모리 관리 각 프로그램이 어디에서, 무엇을, 얼마나 사용하는지를 추적하고. 메모리 자원을 할당하는 역할을 한다. 가상 메모리를 사용할 수 있도록 한다. 프로세스 관리 및 CPU 스케쥴링 사용자가 시스템에 로그인 함과 동시에 수많은 프로세스가 실행되는데, 커널은 CPU의 시간 자원을 배분하는 역할 - 어떤 프로세스가 언제, 얼마나 사용할지 - 을 하여 여러 개의 프로세스가 동시에 동작하는 것처럼 보이게 합니다. 디바이스 관리 컴퓨터에 연결된 장치들을 드라이버라는 매개체를 통해서 제어하고 관리한다. 시스템 콜 인터페이스 및 보안 시스템 콜을 제공하여 응용 프로그램 - 프로세스의 서비스 요청을 수신한다. 커널 구조 유형 시스템 콜 예시 fork() : 새로운 프로세스 생성 exec() : 다른 프로그램 실행 read(), write() : 파일 I/O kill() : 프로세스 종료 요청 🔵 프로세스의 구조 프로세스 vs 프로그램 프로그램: 하드디스크에 저장된 정적인 명령어 집합 프로세스: 실행 중인 프로그램, 메모리에 적재된 상태 하나의 컴퓨터에서 여러 프로세스가 동시에 실행될 수 있으며, 각 프로세스는 자신만의 코드, 데이터, 스택, 레지스터를 가진다. 프로세스는 메모리에 다음과 같은 형태로 구성된다. 이를 프로세스 이미지 (Process Image) 라고 하며, 운영체제는 이 전체 상태를 관리한다. 운영체제는 이 정보를 기반으로 프로세스를 메모리에 적재하고, 필요한 시점에 스케줄링/복원/삭제 등을 수행한다. 🔵 프로세스 vs 스레드 프로세스(Process) 자원 소유의 단위 (Unit of Resource Ownership) 스케줄링/실행의 단위 (Unit of Execution) 하나의 프로세스는 고유한 코드, 데이터, 스택, PCB를 가진다. 운영체제는 각 프로세스를 독립적으로 관리한다. 스레드(Thread) 실행의 단위만 분리됨 (Dispatching Unit) 자원은 프로세스와 공유, 스택은 스레드마다 개별 하나의 프로세스 내에서 여러 스레드가 생성되어 실행될 수 있음 즉, 자원은 프로세스 단위로 소유, 실행은 스레드 단위로 분화됨 프로세스 vs 스레드 비교 스레드의 장점과 단점 장점 자원 공유로 문맥 교환 비용이 작음 빠른 통신 및 협업 가능 (shared memory) 병렬 처리를 통해 멀티코어 활용 효율적 단점 동기화 문제(Race condition) 발생 가능 하나의 스레드 오류로 전체 프로세스가 중단될 수 있음 디버깅과 유지보수가 복잡함 🔵 멀티프로세싱(Multiprocessing) 여러 개의 프로세스를 생성하여 동시에 실행하는 방식 각 프로세스는 독립적인 주소 공간과 자원을 가짐 일반적으로 멀티코어 CPU에서 병렬 처리를 위해 사용됨 하나의 CPU에서 멀티프로세싱을 할 경우는 시분할 방식(time sharing), 멀티코어 CPU에서는 진짜 동시 실행(parallel execution)이 가능 🔵 멀티스레딩(Multithreading) 정의 하나의 프로세스 내에서 여러 실행 흐름(스레드) 을 가지는 것 각 스레드는 독립적인 실행 스택을 가지지만, 공통 주소 공간을 공유함 운영체제별 스레드 지원 방식 스레드의 구조 하나의 스레드는 다음 정보를 가짐 Execution State: running, ready 등 Thread Context: 스레드 실행 시 CPU 레지스터 저장 Execution Stack: 지역 변수 저장 Static Storage for Local Variables Memory/Resource 접근: 같은 프로세스의 스레드끼리는 공유 즉, 프로그램 코드/데이터는 공유하고, 스택과 context는 개별 멀티프로세싱 vs 멀티스레딩 멀티프로세싱 예시: 웹 서버에서 여러 클라이언트를 처리할 때, 아예 독립된 서버 인스턴스를 띄우는 방식 멀티스레딩 예시: 게임 프로그램에서 그래픽 처리, 사운드, 물리 엔진을 각각 스레드로 처리 싱글 스레드 vs 멀티 스레드 모델 Single Threaded Process - PCB + User Stack + Kernel Stack + User Address Space Multithreaded Process - 하나의 PCB + 여러 TCB + 각 스레드별 스택 - 코드/데이터/주소 공간은 공유됨 멀티스레드 프로세스는 PCB + TCB1 + TCB2 + ... 의 형태로 관리됨 🔵 컨텍스트 스위칭 컨텍스트 스위칭이란 CPU가 하나의 프로세스/스레드 실행을 중단하고, 다른 프로세스/스레드로 전환할 때의 작업 전체 이 과정에서 이전 작업의 상태(context)를 저장하고, 다음 작업의 상태를 복원하는 작업이 수행됨 컨텍스트 스위칭이 필요한 이유 멀티태스킹: 여러 작업을 동시에 실행하는 것처럼 보이게 하기 위해 시분할 시스템: 각 프로세스에 CPU 시간을 분배하기 위해 인터럽트 처리: I/O 이벤트가 발생하면 다른 프로세스로 전환 우선순위 변경: 더 중요한 프로세스를 우선 실행하기 위해 프로세스 컨텍스트 스위칭 과정 1. 현재 실행 중인 프로세스(p0)에 인터럽트 or 시스템 콜 발생 2. 운영체제가 p0의 실행 상태를 PCB0에 저장 3. 스케줄러가 다음 실행할 프로세스(p1)를 선택 4. p1의 실행 상태를 PCB1에서 복원 5. CPU 제어권을 p1에게 넘김 → p1 실행 시작 이후에도 p1이 인터럽트를 받으면 다시 p0 등으로 전환될 수 있음 컨텍스트 스위칭 시 저장되는 정보 프로그램 카운터 (PC) 레지스터 값 (R0~Rn) 스택 포인터 (SP) 프로세스 상태 메모리 관련 정보 (페이지 테이블 등) 컨텍스트 스위칭의 오버헤드 문맥 전환에는 시간과 자원이 소모됨 빈번한 스위칭은 오히려 성능 저하를 유발할 수 있음 스케줄링 알고리즘이 이를 효율적으로 조절해야 함 따라서, 운영체제는 스케줄링 알고리즘을 통해 스위칭 빈도와 시점을 최적화하려고 함

2025년 03월 26일 14:27

프론트엔드

Next.js 마이그레이션: 서버 컴포넌트(SSC)와 클라이언트 컴포넌트(CSC) 선택하기

React 프로젝트를 리팩토링 하면서 Next.js로 마이그레이션을 하게 되었고, 처음으로 서버 사이드 컴포넌트(Server-side Component, SSC) 를 사용할 기회를 갖게 되었다. 기존 React에서는 React Query를 활용하여 서버의 부담을 줄이며 데이터를 관리해왔는데, Next.js에서도 기존처럼 React Query를 사용할 수 있을지 고민하게 되었다. SSC와 CSC의 차이 Next.js의 서버 컴포넌트(SSC) 와 클라이언트 컴포넌트(CSC) 는 동작 방식이 다르다. SSC(Server-side Component): 서버에서 데이터를 가져와 미리 렌더링하여 클라이언트에 전달함 → SEO 최적화 CSC(Client-side Component): 클라이언트에서 데이터를 가져오고, 동적으로 업데이트함 → 실시간 변화 가능 이전처럼 React Query를 사용하여 데이터를 가져오려 했지만, 만약 모든 데이터를 클라이언트에서 가져온다면 Next.js의 서버 렌더링 기능을 제대로 활용하지 못하게 된다. Next.js를 사용하면서 서버의 역할을 최대한 활용해야 한다는 점에서 React Query만을 사용할 수는 없었다. 서버 부담 문제와 캐싱 처음에는 페이지를 이동할 때마다 서버가 데이터를 불러오면 부담이 커질 것이라고 생각했다. 하지만 Next.js에서는 서버에서 데이터를 가져올 때 캐싱을 통해 성능을 최적화할 수 있는 방법이 있었다. 위와 같이 revalidate: 60을 설정하면 60초 동안 같은 요청을 반복하지 않고 캐싱된 데이터를 반환한다. 덕분에 SEO를 챙기면서도 서버의 부담을 줄일 수 있다. 어떤 데이터는 SSC, 어떤 데이터는 CSC로? 처음에는 서버와 직접적인 연관이 있는 것은 SSC로, 정적인 것은 CSC로 사용해야 한다고 생각했는데, 사실은 그 반대였다. ✔️ 서버 컴포넌트(SSC)를 사용해야 하는 경우 SEO가 중요한 데이터 (검색 엔진 노출 필요) 초기 렌더링이 빠른 것이 중요한 데이터 변경이 자주 일어나지 않는 데이터 페이지 구조를 구성하는 주요 데이터 ✅ 예시 블로그 글 목록 (게시글 리스트) 블로그 글 내용 (제목, 본문) 사용자 프로필 정보 (변경이 잦지 않은 경우) 카테고리 목록 ✔️ 클라이언트 컴포넌트(CSC)를 사용해야 하는 경우 실시간으로 변화하는 데이터 사용자와의 인터랙션이 필요한 데이터 페이지 내에서 상태 변화가 필요한 데이터 ✅ 예시 좋아요 개수, 댓글 검색 기능 (검색어 입력 시마다 데이터 변경) 무한 스크롤 (React Query의 useInfiniteQuery 활용) 사용자 설정 변경 결론: SSC와 CSC의 최적 조합 초기 데이터를 서버에서 받아와 렌더링해야 하는 경우 → SSC 사용 자주 변경되거나 사용자 인터랙션이 필요한 경우 → CSC + React Query 사용 서버 부담을 줄이기 위해 revalidate 로 캐싱 활용 Next.js 마이그레이션을 하면서 서버 컴포넌트와 클라이언트 컴포넌트를 적절히 나누는 것이 성능 최적화에 매우 중요하다는 것을 깨달았다. SEO가 필요한 데이터는 서버에서 미리 받아오고, 실시간 업데이트가 필요한 데이터는 클라이언트에서 관리하는 것이 핵심이다. 이를 잘 활용하면 서버 부담을 줄이면서도 빠른 렌더링을 유지할 수 있다.

2025년 03월 19일 08:12

프론트엔드

스파게티 코드 갱생시키기 프로젝트

🔴 개관 저는 프로그래밍을 할 때 단순히 돌아가기만 하면 된다는 접근보다, 가독성과 코드의 효율성을 더욱 중요하게 여깁니다. 처음 React Native로 프로젝트를 진행했을 때, React와 달리 데이터를 저장하고 사용하기 위해 복잡한 코드를 작성해야 했던 경험이 있습니다. 당시에는 효율성보다는 기능 구현에 초점을 맞췄기 때문에 코드가 비효율적이었습니다. 초보자라면 누구나 겪을 문제라고 생각합니다. 그러나 이번에 React Native로 두 번째 프로젝트를 진행하며, 비효율적인 AsyncStorage의 저장 및 조회 코드를 모듈화하여 재사용성과 유지보수성을 높이겠다고 계획했습니다. 🔴 첫 번째 React Native 프로젝트: 완전한 스파게티 코드 오랜만에 캡스톤에서 진행했던 프로젝트의 코드를 꺼내보았습니다. React Native를 처음 사용해보는거라서 아주 스파게티 코드입니다. 지금 생각하면 아주 끔찍한 코드입니다. 서버에서 오는 응답에 따른 두번의 Alert 코드와 그 Alert을 감싸고있는 AsyncStorage 함수의 모습입니다.... 초반에는 기능 구현에만 집중했기 때문에 비효율적인 코드가 발생하였습니다. 저는 여기서 Alert나 AsyncStorage에 대한 모듈화가 필요하다고 생각하였지만 기간이 빡빡하기도 하였고, 저의 실력 문제;;로 진행하지는 못하였습니다. 🔴 두번째 React Native 프로젝트: 코드 모듈화 사실 첫번째 어플리케이션을 리팩토링하자! 하는 마음이 지금도 남아있지만.... AI 서버와 백엔드 서버가 다 내려갔기 때문에 리팩토링, 유지보수 한다고 해도 돌아간다는 보장이 없습니다. 모듈화의 기회는 두번째 프로젝트에서 달성할 수 있었습니다. 저는 제일 문제된다고 생각한 것이 AsyncStorage 함수와 Alert 함수라고 생각했습니다. 그래서 프로젝트에 Utils 폴더를 만들어 전역적으로 이 함수들을 관리하기로 결심했습니다. Alert 컴포넌트 코드를 먼저 보여드리겠습니다. 확인 버튼이 있는 알림창과 확인, 취소 버튼이 있는 알림창 컴포넌트를 만들었습니다. 두 파일로 나눠서 만들까 하다가 Utils/component 폴더 내부에 또 Alert 폴더를 만들기 싫어서 한 파일만 임포트하면 두 Alert 컴포넌트 접근 가능해서 위의 이유로 한 파일에 합쳐 작성했습니다. 아래 코드는 위 컴포넌트 사용 예시입니다. 치매 진단지를 서버로 제출하는 함수인데, 서버에서 오는 응답 코드에 따라 다른 Alert 컴포넌트를 띄우거나 탭을 이동하는 코드입니다. 물론! 저 함수에 title, message, onPress 세 개의 파라미터가 들어가기 때문에 모듈화를 시켜 사용한다고 해도 여전히 코드가 어지럽고 길긴 합니다. ~~하지만 제 실력으로는 최선이었습니다.~~ 하지만 모듈화를 안하고 사용했다면? 진짜 아찔합니다. 다음으로는 절 힘들게했던 AsyncStorage 함수입니다. React와는 다르게 ReactNative에서는 async가 필요해서 코드가 굉장히 복잡해졌습니다. 여기서 흠은 console을 띄웠다는 점인데요.. 다음은 에러가 나온다고 하면 Alert창을 띄우거나.. 다시 시도하거나 하는 방식을 해봐야겠습니다. Storage 싱글톤 객체를 만들어서 내부에 네가지 메서드를 넣었습니다. 한창 정보처리기사 공부할때 디자인패턴이 나오길래 신나했던 기억이 납니다.. 주로 사용했던 메서드는 setItem과 getItem 입니다. 위에는 아까 봤던 Alert 컴포넌트와 Storage 의 setItem 메서드가 결합된 코드입니다. 엄청 깨끗해지고 가독성도 좋아졌습니다. (맞나..?) 🔴 결론 저는 캡스톤에서 처음으로 React Native를 사용해봤습니다. 기간이 부족했기 떄문에 몸통박치기 수준이 아니고 몸통 갈아넣기 정도로 일단 써보자 마인드였는데요 만약에 프론트가 저 혼자가 아니고 여러명이서 진행했다면 프론트끼리 머리채잡고 싸웠을수도 있습니다. 이런 스파게티 코드는 물론 개발 진행에 있어서 굉장히 불가피하다고 생각합니다. 하지만 계속해서 코드를 리팩토링하고 유지보수한다면 전보다는 실력이 10%정도.. 아님 1%라도 성장하는 것 같습니다. 요즘 저는 리팩토링을 진행했다고는 하지만 지금보면 발싸개같은 코드를 다시 보면서.. React 디자인패턴 공부에 박차를 가해야겠다는 생각이 듭니다.... 저의 시행착오가 여러분들에게 도움이 되셨으면 좋겠습니다.

2024년 10월 23일 08:15

취준

[취준] 카카오모빌리티 2024 주니어 개발자 영입

🟡 서류 카카오모빌리티 2024 주니어 개발자 영입 채용 공고가 떠서 지원하게 되었습니다. 9/19에 채용 공고를 확인했고, 마침 이력서와 포트폴리오가 준비되어 있어서 바로 지원하게 되었습니다. 이력서: https://resume.minjae-dev.com 포트폴리오: https://portfolio.minjae-dev.com 저는 Frontend Engineer 파트로 지원을 하였고 자기소개서는 필수가 아니어서 자기소개서는 제출하지 않았습니다! 많이 준비가 되지 않았다고 생각했는데, 감사하게도 서류 합격 메일이 도착했습니다. 백엔드 파트는 거의 다 붙여준 것 같았고, 프론트엔드 파트는 떨어지신 분이 몇 있으신 듯 했습니다. 🟡 온라인 코딩테스트 서류 합격 다음주인 10/5에 온라인 코딩테스트를 수행하였습니다. 코딩테스트는 코딜리티에서 진행하였고, 따로 캠은 키지 않았습니다. 140분동안 진행되었으며, 총 3문제가 출제되었습니다. 1, 3번 문제는 기본적인 알고리즘 문제였고, 2번 문제는 React 문제였습니다. 제가 알고리즘은 좀 약했기에 React로 하는 코딩테스트는 저에게 기회라고 느껴졌습니다. 알고리즘 문제는 난이도가 평이했으며, React 문제는 생각보다 난이도가 있었다고 생각이 듭니다. 제가 사용해 보지 않았던 React hook이 나와서 처음에 좀 헤맸지만 그래도 어찌저찌 풀었던 기억이 있습니다. 알고리즘은 2문제 다 풀었고, React는 요구사항을 모두 다 지키지는 못했지만 한 개의 요구사항를 제외하고 모두 accept가 떴습니다. 🟡 2차 코딩테스트 10/13 2차 코딩테스트를 보고 왔습니다. 한양대학교 HIT관에서 진행하였으며, 170분 동안 3문제를 풀어야 했습니다. 총 240명이서 테스트를 치뤘는데, 프론트엔드, 데이터사이언스, MLOps 포지션으로 구성되었습니다. 백엔드는 전 타임에 240명이 보았다고 합니다. 문제 유형은 React 1문제, 알고리즘 2문제였습니다. 저는 알고리즘은 자신 없었기 때문에 알고리즘은 풀 시도조차 하지 않았고, 2시간 50분동안 React 문제에만 집중하였습니다. 그래서 떨어졌습니다 ㅜㅜ 아깝지도 않음 다음에 코테 고수되면 또보자 모빌리티야~~

2024년 10월 10일 08:25

React Native

React Native 카카오 로그인(iOS)

React Native 카카오 로그인 적용하기 kakao developers 애플리케이션 등록하기 🟡 내 애플리케이션 추가하기 kakao developers 홈페이지에 들어가주세요. 회원가입을 완료 한 후 내 애플리케이션 > 애플리케이션 추가하기 버튼을 눌러줍니다. 애플리케이션 등록을 완료해줍니다. 🟡 Bundle Identifier 설정하기 XCode에 설정되어 있는 Bundle Identifier를 확인해주세요. 등록한 애플리케이션에 들어가 내 애플리케이션 > 앱 설정 > 플랫폼 탭에 들어갑니다. 번들 ID를 Bundle Identifier와 똑같이 설정해주세요. 🟡 네이티브 앱 키 발급받기 내 애플리케이션 > 앱 설정 > 앱 키 탭에 들어갑니다. info.plist에 활용됩니다. 네이티브 앱 키를 복사해주세요. 🟡 동의항목 설정하기 내 애플리케이션 > 제품 설정 > 카카오 로그인 > 동의 항목 탭에 들어갑니다. 사용하려는 개인정보의 상태를 사용으로 바꿔주세요. 라이브러리 설치하기 react-native-kakao-login 라이브러리를 사용했습니다. info.plist 수정하기 ios/프로젝트명/info.plist 파일에 아래의 코드를 추가해주세요. 네이티브 앱 키는 1번에서 복사한 키로 대체하세요. AppDelegate.mm 파일 수정하기 ios/AppDelegate.mm 파일에 아래의 코드를 추가해주세요. SwiftBridge 파일 생성하기 XCode에서 ios/프로젝트.xcworkspace 파일을 열어주세요. SwiftBridge.swift 파일을 생성합니다. ⭐️ Swift Bridging Header를 추가하겠냐는 문구가 나오면 꼭 확인을 눌러줍니다. SwiftBridge, [프로젝트명]-Bridging-Header.h 두 개의 파일이 생성됩니다. 예제 코드

2024년 08월 10일 19:08