진심전력개발일지

[VSC] 줄바꿈 문자 LF로 고정하는 법

qoi-31 — Sat, 25 Apr 2026 12:01:07 +0900

문제 상황

Pintos 프로젝트 시작

팀원 두 명은 macOS, 두 명은 Windows 사용

Docker Desktop + Dev Container를 통해 우분투, 리눅스 환경을 구축하고 프로젝트를 진행하기 때문에 OS 차이로 인한 문제는 생기지 않을 줄 알았다!

그 러 나 Pintos 테스트를 돌리는데 나만 팀원들과 다른 결과가 나오는 개최악 상황 발생.

Pintos가 그래도 구현은 되어있는 상태에서 최적화를 목표로 하는 프로젝트이기 때문에 간단한 테스트 케이스는 PASS가 나오는 것이 정상인데, 나는 모든 테스트 케이스가 FAIL 과 함께 Error 127이 떠 버렸다

원인

원인은 바로 줄바꿈 문자 때문이었다!

(macOS, Linux는 LF, Windows는 CRLF)

리눅스 컨테이너로 환경을 구축해둬도

윈도우에서 레포 클론 -> VSC가 CRLF로 저장 -> 그 파일을 도커가 볼륨 마운트해서 사용 -> 결국 컨테이너는 리눅스지만 파일은 이미 CRLF로 저장됨

결국 VSC 소스 컨트롤 패널에서도 모든 파일의 줄바꿈 문자 CRLF 변경으로 모든 파일이 변경되었다고 잡혀버리는 개최악 상황이 발생됨

이 상황을 어떻게 해결할 것인가.

303호 최교수님께 조언을 구했고, 아래 두 방법이 있다는 얘길 들었다...

1. 작업하면서 VSC 하단의 Editor End of Line 설정을 통해 매번 LF로 줄바꿈 문자를 바꿔준다

2. 깃 클론 자체를 윈도우가 아닌 도커 안에서 진행한다

1번? 개귀찮음 개최악 방법

2번? 사실뭔소린지이해를못햇떠염...

그래서 열심히 코덱스를 채찍질해서 완전 간단한 해결법을 찾아냈다!!

해결법

그냥 .gitattribute로 모든 파일의 eol을 LF로 고정시켜버린다.

.gitattribute 파일을 디렉토리 루트에 만들고 아래 내용을 복붙하면 끝~

* text=auto eol=lf

*.sh text eol=lf
Makefile text eol=lf
*.mk text eol=lf
*.c text eol=lf
*.h text eol=lf
*.S text eol=lf
*.s text eol=lf
*.py text eol=lf

[Git] 프로젝트를 새로운 Git 레포지토리에 업로드 하기

qoi-31 — Sat, 25 Apr 2026 11:35:51 +0900

이미 레포를 하나 파서 작업 중이던 프로젝트를 새로운 레포를 만들어 프로젝트 폴더를 통째로 옮겨야 하는 상황이 발생.

깃 명령어 몇 줄로 바로 업로드가 가능하다!

해결법

1. 원래 작업하던 프로젝트 폴더로 들어가서 .git 폴더를 지운다

2. 새로 만든 깃 레포를 클론

3. Git bash -> 새로 만든 깃 레포 클론 폴더 경로로 이동

4. 아래 순서대로 입력

git init

git remote add origin {새로 만든 레포 주소}

git add .

git commit -m "Clean start"

git push -u origin main
(= git push --set-upstream origin main)

참고

-u 명령어
-> --set-upstream의 단축어

--set-upstream 명령어

-> 현재 브랜치의 업스트림(기본) 원격 브랜치 설정

git push --set-upstream origin main
-> 로컬의 main 브랜치를 origin 원격 레포지토리의 main 브랜치와 연결
-> 그 연결을 기본 설정으로 지정한 후 변경 사항을 원격 레포로 push하는 작업 수행

origin main
명령어 -u를 사용하든, --set-upstream를 사용하든 반드시 브랜치를 origin main으로 해 줘야 한다!

그냥 main으로 push 해버리면 origin 원격 등록 및 GitHub origin/main 브랜치 생성은 되지만,
로컬 브랜치 main이 원격 origin/main을 추적하지 않는 상태가 됨!
-> Publish Branch 작업을 또 해 줘야 함

Publish Branch
현재 로컬 브랜치를 원격에 push
-> 그 브랜치를 upstream으로 연결
=> 로컬 main을 원격 main에 연결

upstream 설정이 제대로 되었다면

// terminal

git branch -vv
-> * main {커밋 해시값} [origin/main] {커밋 메세지}

[WIL] WEEK8

qoi-31 — Thu, 23 Apr 2026 15:03:05 +0900

누가 자꾸 이렇게 흔적을 남기고 가

그간 격조했습니다...

WEEK8 목표

팀 목표

- 출근
아침에 출근 찍고 단톡방에 보고하기!

- 코어 타임

금, 월~수: 303호 코칭실, 19:00 ~ 20:00
토: 2층 회의실, 21:00 ~ 23:00
(+ 시간 부족하면 교육장이나 외부에서 추가 진행)

금요일: 개념만
토요일: 개념 + 코드

- 공부 방식/순서

각자 11.4 소켓 인터페이스부터 CS:APP 교재 or 강의 영상으로 공부
금요일 코어 타임 전까지 11장 공부하고 각자 질문 만들기

학습 키워드와 관련된 큰 개념의 질문 가능
세부적인 질문도 가능

3. 각자의 질문 공유하고 합쳐보기

AI를 통해 중복된 질문 통합

4. 통합한 질문은 깃에 md 파일로 올리기

질문 바로 확인 및 깃 잔디 채우기 가능

개인 AI 활용 원칙

- 개념 학습에 최대한 AI 활용해 Top-Down 방식 학습하기

- 코드 구현에 최대한 AI 활용하지 않고 공부한 개념을 바탕으로 로직을 짜보기

일정에 의해 더이상 로직 고민할 시간이 없다면 그때 AI 도움을 받아 코드 작성하고, 코드를 완벽하게 이해하기

개인 핵심 역량 목표

- 네트워크 프로그래밍 개념을 확실히 하자

- 주어진 과제를 완벽하게 끝내자

WEEK8 공부한 내용

술렁... 술렁...

원랜 공부하면서 바로바로 주제별로 내용 정리해서 포스팅 했는데 요 몇 주는 도저히 그럴 기력도, 시간도 없었다!!

여유 생기면 하나씩 정리해서 올려야지...

[네트워크 프로그래밍]

- 클라이언트 - 서버 모델

- 스레드 풀

Helix씨의 아주 귀여운 그림과 함께하는 스레드 풀 학습 시간

[소켓 프로그래밍 및 파일 입출력]

- BSD 소켓

- File Descriptor(파일 디스크립터, 소켓 디스크립터)

- 소켓과 소켓 인터페이스(socket & bind & accept & connect & close)

- Datagram Socket VS Stream Socket

[웹 및 HTTP 프로토콜]

- 웹 서버

- Echo 서버

- Tiny 서버

- Proxy 서버

- HTTP(요청/응답 & 헤더 & 메소드 & 상태 코드 & HEAD 메소드)

[네트워크 구조와 인터넷 프로토콜]

- TCP

- IP

- DNS

WEEK8 목표 달성

팀 목표

- 출근
아침에 출근 찍고 단톡방에 보고 정말 정말 잘했음 굿.

- 코어 타임

지난 주부터 코어 타임 때 대체 뭘 해야할지 고민이 많았는데...

이번 주차는 다들 성향이 비슷(?)해서 그런지 스무~스 하게 잘할 수 있었다

어땠냐면, 코어 타임 때 궁금증 해소하다가 아파트 단자함까지 보고 있었음.

- 공부 방식/순서

각자 11.4 소켓 인터페이스부터 CS:APP 교재 or 강의 영상으로 공부
이렇게 진행하다가 내가 지금까지 탑다운 학습을 하고 있던 게 아니라는 것을 깨닫고...
코치님 커피챗 신청해서

제가지금까지했던학습방식은탑다운방식이아닌가요?!

하고 여쭤보고 왔다...
=> 결론: 아니었음. ~~이걸 정글 입소하고 한달 반이 지난 지금에서야 깨닫다니~~
금요일 코어 타임 전까지 11장 공부하고 각자 질문 만들기
첫 날 공부하고 질문 정말 열심히 했는데 아쉽게도 네트워크 프로그래밍 학습이 쉽지 않아... 질문 만들고 코어 타임 때 질문에 답하는 시간을 가질 수 없었다. 질문 만들 시간에 개념 하나라도 더 봐야 해 ^_ㅠ

WEEK8 새롭게 배운 점

- Top-Down 학습법

한달 반 동안 잘못된 탑다운 방식(사실 탑다운 방식도 아니었음.)으로 공부를 해 왔다는 사실을 알게 되었다.

어쩐지 매주 힘들고... 오전 4시까지 공부해도 진도를 따라갈 수 없고... 노력한 거에 비해 성과도 없고...

-> 이거 때문에 요 몇 주간 굉장히 우울띠. 했는데 사실 학습 방식부터 잘못되어있어서 그랬다는 걸 알게 되니까... 원인을 알게 되어서? 나름 후련하다.

커피챗으로 코치님과 대화 나눈 결과, 앞으로 어떻게 하면 좋을지 더 고민해보기로 했다.

지금까지의 방식을 싹 갈아엎어야 해서 막막하도다.

[지금까지 잘못되었던 나의 공부법]

ex) 네트워크 프로그래밍: CS:APP 11장

그 중 과제 구현을 위해 중점적으로 봐야 하는 부분은 11.4장

-> 내가 11.1부터 보지 않고 11.4부터 공부를 시작하면 11.1~11.3의 내용을 모르고 학습을 시작하는 거고, 이 앞 부분은 AI를 통해 메꿔나가면서 학습을 하는 거니 탑다운이다!

이렇게 되면 결국 11.4부터 11.10까지 책의 내용을 차례대로 보는 것과 다를 바가 없어짐

-> 전체 내용을 모르고 세부 내용부터 쌓아가는 것!

-> 게다가 책은 목차가 정해져 있기 때문에 저자는 11장을 1장부터 10장까지의 내용을 다 알고 본다는 전제 하에 설명을 한다!

-> 결국 이렇게 공부하면 정글 기간 내에 다 못보는 건 당연하다...

=> 그렇기 때문에 내가 매주 주어진 분량을 공부하고 과제를 하는 데 시간이 오래 걸렸던 거고, 오전 4시까지 남아서 해도 진도가 빠르게 나가지 않았던 거고, 결국 팀원들과의 학습 진도 차이가 생겨버린 것.

애초에 탑다운 방식으로 공부하면 함께 공부하는 사람들 사이에 학습 진도 차이라는 게 생기면 안 된다!!!!!

-> 다같이 더 깊게 공부하는 부분이 다를 순 있어도, 처음부터 전체적인 그림을 바라보고 깊게 공부하는 것이기 때문에 모든 사람이 전체 그림을 알고 있어야 하는 게 맞다...

WEEK9 계획

WEEK9부터 Pintos 주차 시작!1인분만 하자 제발...!!!!!!!!!!!!!!!!!!!!!!!!!!

짧은 TMI

스타벅스 바삭 피스타치오 초콜릿 프라푸치노

스타벅스 바삭 피스타치오 초콜릿 프라푸치노 이거 진짜 요물이다.

Helix의 은총이야,,,

쉬림프 알리오올리오, 왓더버거 통다리어쩌구&치킨박스, 토핑몬스터 페페로니 & 더블치즈피자

이번 주 배달음식 ~.~

왓더버거 완전 처음 먹어봤는데 여기 소스가 정말 맛있네요

통닭다리살 너무 맛있었음

개풍냉면

코치님 추천 맛집!

1시 반 좀 지나서 도착했는데 앞에 대기가 9팀이나 있었다....

수료하고 대천 가면 바로 물비빔을 먹고 싶을 정도로 물비빔을 너무 먹고 싶었는데 물비빔을 먹을 수 있게 되었다 ㄷㄷ.

맛있었어욤.

식당 밥

식당 밥은 항상 야무지지만 싱겁게 먹는 나에겐 너무 짜다...

일요일 = 코노/피시방 가는 날.

용인은 정말 좋은 도시다.
왜냐면 코노들이 점수 100점 나오면 보너스 1곡을 준다...

보너스 달달하다

---

WEEK8 학습 기록

요 며칠 퇴근할 때 너무 피곤해서 제정신이 아니었다보니... 퇴실 찍는 걸 깜빡해서 결석이 되어버렸다. 두 번이나...! ㅜㅜ

Windows11 Docker + DevContainer Ubuntu 환경 구축

qoi-31 — Wed, 22 Apr 2026 16:53:40 +0900

Docker Desktop 설치

https://www.docker.com/products/docker-desktop/

Docker Desktop: The #1 Containerization Tool for Developers | Docker

Docker Desktop is collaborative containerization software for developers. Get started and download Docker Desktop today on Mac, Windows, or Linux.

www.docker.com

도커 공식 홈페이지에서 Windows 설치 파일 다운

설치

설치 확인

로그인

devcontainer 설정 추가(Dockerfile 사용 기준)

프로젝트 루트에 .devcontainer 폴더 생성

-> 폴더 내부에 devcontainer.json 파일 생성

-> 폴더 내부에 Dockerfile 생성

동적 메모리 할당

qoi-31 — Thu, 9 Apr 2026 01:02:45 +0900

동적 메모리 할당의 개념

프로그램 실행 중(Runtime)에 필요한 만큼의 메모리를 요청하여 할당받는 방식. 스택(Stack) 영역이 아닌 힙(Heap) 영역을 사용하며, 컴파일 타임에 크기가 결정되는 정적 할당과 달리 유연한 메모리 관리가 가능하다.

언어별 동적 할당 방식

C 언어

가장 원시적인 형태의 메모리 제어를 제공한다.

함수: malloc(), calloc(), realloc(), free()
특징: 할당받은 메모리는 void* 타입을 반환하므로 형변환이 필요하며, 사용 후 반드시 free()를 통해 수동으로 해제해야 한다. 하지 않을 경우 메모리 누수(Memory Leak)가 발생한다.

C++

객체 지향에 최적화된 연산자를 제공한다.

연산자: new, delete (배열은 new[], delete[])
특징: malloc과 달리 호출 시 생성자(Constructor)를 자동으로 실행하며, 해제 시 소멸자(Destructor)를 호출한다. 최근에는 스마트 포인터(unique_ptr, shared_ptr)를 사용하여 수동 해제의 위험을 줄이는 추세다.

Python

개발자가 직접 메모리를 할당하거나 해제하지 않는다.

방식: 모든 것이 객체이며, 참조 횟수 계산(Reference Counting)과 가비지 컬렉터(Garbage Collector, GC)가 메모리를 자동으로 관리한다.
특징: 편리하지만 메모리 해제 시점을 정확히 통제하기 어려워 실시간성이 중요한 게임 엔진 로직에서는 C++보다 불리할 수 있다.

정적 할당 vs 동적 할당 비교

구분	정적 할당 (Static Allocation)	동적 할당 (Dynamic Allocation)
할당 시점	컴파일 타임 (Compile-time)	런타임 (Runtime)
메모리 영역	Stack / Data 영역	Heap 영역
크기 결정	고정됨 (변경 불가)	가변적 (실행 중 변경 가능)
해제 시점	함수 종료 시 자동 해제	개발자가 명시적으로 해제 필요
장점	속도가 빠르고 관리가 자동임	메모리를 효율적으로 사용 가능
단점	메모리 낭비가 생길 수 있음	할당/해제 오버헤드 및 누수 위험

면접 핵심 질문: 왜 게임 프로그래밍에서 중요한가?

1. 단편화(Fragmentation) 문제

동적 할당을 반복하면 메모리 사이사이에 빈 공간이 생기는 외부 단편화가 발생한다. 총 여유 메모리는 충분해도 연속된 큰 블록을 잡지 못해 할당에 실패할 수 있다. 게임에서는 이를 방지하기 위해 메모리 풀(Memory Pool) 기법을 자주 사용한다.

2. 성능 오버헤드

new나 malloc은 운영체제(OS)에 메모리를 요청하는 시스템 콜을 동반하므로 비용이 비싸다. 매 프레임 발생하는 총알 객체나 이펙트 등을 동적 할당하면 프레임 드랍의 원인이 된다.

3. 메모리 누수(Memory Leak)

포인터를 잃어버려 해제할 수 없는 메모리가 쌓이면 결국 게임이 크래시(Crash)된다. C++ 개발자에게 메모리 수명 관리 능력이 필수적인 이유다.

이해를 돕는 비유: 식당 예약 시스템

정적 할당 (Stack): 학교 급식. 학생 수만큼 미리 식판과 자리가 세팅되어 있다. 빠르고 질서 정연하지만, 갑자기 손님이 더 와도 자리를 늘릴 수 없다.
동적 할당 (Heap): 자유로운 레스토랑. 손님이 올 때마다 빈 테이블을 찾아 안내한다. 손님이 원하는 만큼 자리를 붙일 수 있지만, 웨이터가 자리를 치워주지 않으면(free) 다음 손님이 앉지 못해 가게가 금방 꽉 차버린다.
메모리 단편화: 레스토랑에 2인석은 많은데 테이블들이 흩어져 있어 8인 단체 손님을 받지 못하는 상황과 같다.

시간 복잡도 분석

할당/해제: 일반적으로 $O(1)$에 가깝게 설계되어 있으나, 적절한 빈 공간을 찾는 탐색 알고리즘에 따라 최악의 경우 $O(N)$이 될 수 있다.
접근: 포인터를 통한 직접 접근이므로 $O(1)$이다.

주의사항 (CS 포인트)

Dangling Pointer: 메모리를 해제한 후에도 해당 주소를 여전히 가리키고 있는 포인터. 접근 시 정의되지 않은 동작(UB)을 유발하므로 해제 후 반드시 nullptr로 초기화해야 한다.
Double Free: 이미 해제한 메모리를 다시 해제하려고 할 때 발생하는 에러. 시스템 안정성에 치명적이다.

C Pointer(*, &)

qoi-31 — Thu, 9 Apr 2026 00:56:04 +0900

C언어 포인터 개념 (*, &)

포인터는 C언어의 핵심이자 메모리에 직접 접근할 수 있는 강력한 도구다. 게임 클라이언트 및 엔진 레벨에서는 성능 최적화와 메모리 관리를 위해 포인터의 이해가 필수적이다.

1. 포인터의 기본 개념

포인터는 메모리 주소를 저장하는 변수다. 일반적인 변수가 '값'을 저장한다면, 포인터 변수는 그 값이 위치한 '메모리 상의 주소'를 저장한다.

주소 연산자 (&)

변수 앞에 붙여 해당 변수의 시작 주소값을 추출한다.
C++의 참조자(Reference)와 기호는 같으나 포인터 문맥에서는 주소 추출의 기능을 수행한다.

역참조 연산자 (*)

포인터 변수 앞에 붙여 해당 주소에 저장된 값에 접근한다.
"이 주소로 가서 데이터를 읽거나 써라"라는 의미다.

2. 언어별 포인터와 메모리 접근

C / C++

직접 제어: 메모리 주소에 직접 접근하고 연산할 수 있다.
포인터 연산: ptr + 1과 같은 연산이 가능하며, 이는 자료형의 크기만큼 주소를 이동시킨다.
유연성과 위험성: 메모리 누수(Memory Leak)나 댕글링 포인터(Dangling Pointer) 문제가 발생할 수 있어 수동 관리가 중요하다.
C++의 차이점: C++에서는 포인터 외에도 &를 이용한 참조자(Reference)를 지원하여 포인터의 위험성을 일부 완화한다.

Python

추상화: C언어 스타일의 명시적인 포인터 개념이 없다.
모든 것이 객체: 모든 변수는 객체에 대한 참조(Reference)를 저장한다. 내부적으로는 포인터를 사용하지만 개발자가 직접 주소를 계산하거나 역참조 연산자를 사용할 수 없다.
가비지 컬렉터(GC): 메모리 할당과 해제를 언어 차원에서 자동으로 관리한다.

3. 포인터의 성능과 시간 복잡도

구분	내용	비고
접근 속도	O(1)	주소를 알고 있다면 즉시 데이터에 접근 가능
공간 효율	시스템 아키텍처 의존	32bit는 4byte, 64bit는 8byte 고정 크기
데이터 전달	값 복사 vs 주소 전달	대규모 구조체 전달 시 주소만 넘기는 것이 압도적으로 유리

4. 면접 핵심 질문 대비 (CS 포인트)

Call by Value vs Call by Address (Pointer)

Call by Value: 인자로 전달되는 값을 복사한다. 함수 내부에서 값을 바꿔도 원본은 변하지 않는다. 복사 비용이 발생한다.
Call by Address: 주소값을 복사하여 전달한다. 함수 내부에서 주소를 통해 원본 데이터에 직접 접근하므로 원본 수정이 가능하다. 큰 데이터를 다룰 때 성능상 이점이 크다.

포인터와 배열의 차이

배열: 이름 자체가 첫 번째 요소의 주소를 나타내는 상수 포인터와 유사하다. 할당된 메모리 크기를 유지한다.
포인터: 주소값을 변경할 수 있는 변수다. 배열의 시작 주소를 담을 수 있지만, sizeof 연산 시 배열 전체 크기가 아닌 포인터 자체의 크기(8byte 등)만 반환한다.

왜 게임 프로그래밍에서 포인터가 중요한가?

게임은 실시간으로 방대한 데이터를 처리해야 한다. 수만 개의 오브젝트 데이터를 매 프레임 복사(Call by Value)하는 것은 성능 재앙을 초래한다. 포인터를 통해 데이터의 위치만 전달함으로써 메모리 대역폭을 절약하고 CPU 캐시 효율을 극대화할 수 있다.

5. 포인터 비유: 보물찾기 지도

포인터를 이해하기 가장 쉬운 비유는 '지도'와 '보물'이다.

변수: 보물 상자 그 자체.
값: 보물 상자 안에 든 금괴.
주소 (&): 보물 상자가 묻혀 있는 위도와 경도.
포인터: 위도와 경도가 적혀 있는 지도(쪽지).
역참조 (*): 지도를 보고 해당 좌표로 찾아가서 상자를 열어보는 행위.

만약 친구에게 보물을 보여주고 싶을 때, 무거운 보물 상자를 통째로 들고 가는 것(Call by Value)보다 좌표가 적힌 종이 한 장을 건네주는 것(Call by Address)이 훨씬 효율적인 것과 같다.

[VSC] C 소스 코드 실행 파일 이름 변경

qoi-31 — Fri, 3 Apr 2026 13:48:24 +0900

"${fileDirname}/${fileBasenameNoExtension}"

VSC 환경에서 C 소스 코드를 빌드/디버깅 할 경우, C 소스 코드와 동일한 이름의 실행 파일이 생성된다

어차피 C 소스 코드를 빌드할 때마다 자동으로 생성되기 때문에 삭제해도 괜찮지만 용량 + 깃허브 백업 등의 문제로 우선 .gitignore를 통해 깃허브에 올라가지 않도록 하고 싶었다

.gitignore를 깔끔하게 작성하기 위해 모든 C 소스 코드의 실행 파일 이름을 main으로 통일하자!

1. tasks.json 파일 수정

VSC -> Ctrl + Shift + P -> tasks.json 파일 열기

아래와 같이 json 파일 내용을 수정

{
    "version": "2.0.0",
    "tasks": [
        {
            "type": "shell",
            "label": "C/C++: gcc build active file",
            "command": "/usr/bin/gcc",
            "args": [
                "-g",
                "${file}",
                "-o",
                "${fileDirname}/main"
            ],
            "options": {
                "cwd": "${fileDirname}"
            },
            "problemMatcher": [
                "$gcc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "detail": "컴파일러: /usr/bin/gcc"
        }
    ]
}

"${fileDirname}/${fileBasenameNoExtension}"

-> 이 부분 때문에 C 소스 코드의 이름과 동일한 이름으로 실행 파일이 생성되었던 것!

"${fileDirname}/main"

-> 이렇게 /main으로 바꿔주면 항상 main 이라는 이름으로 실행 파일이 생성된다

launch: program '/workspaces/...' dose not exist 오류

tasks.json 파일만 수정하면 빌드 과정에서 위와 같은 오류가 발생

-> 디버거가 실행 파일을 C 소스 코드 이름과 동일한 이름으로 찾고 있어서 실행이 불가능

반드시 launch.json 파일도 함께 수정해야 한다!

2. launch.json 파일 수정

VSC -> Ctrl + Shift + P -> launch.json 파일 열기

아래와 같이 json 파일 내용을 수정

{
    "configurations": [
        {
            "type": "cppdbg",
            "request": "launch",
            "name": "Debug C Program",
            "program": "${fileDirname}/main",
            "args": [],
            "stopAtEntry": false,
            "cwd": "${fileDirname}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "C/C++: gcc build active file"
        }
    ],
    "version": "0.2.0"
}

"program": "${fileDirname}/${fileBasenameNoExtension}"

-> 이 부분 때문에 C 소스 코드의 이름과 동일한 이름으로 실행 파일을 찾았던 것!

"program": "${fileDirname}/main"

-> 이렇게 /main으로 바꿔주면 항상 main 이라는 이름을 가진 실행 파일을 찾게 된다

tasks.json과 launch.json 파일을 모두 수정하고 다시 빌드해보면 사진과 같이 main이라는 이름을 가진 실행 파일이 생성된다

3. .gitignore 추가

.gitignore 파일 생성 -> 챗지피티가 만들어준 gitignore 파일 내용을 복붙

# =========================
#   C 빌드 결과물
# =========================
a.out
main
*.out
*.exe
*.elf

# 오브젝트 파일
*.o
*.obj

# 라이브러리
*.a
*.so
*.so.*
*.dll

# 디버그 파일
*.dSYM/
*.su
*.idb
*.pdb

# =========================
#   CMake (혹시 사용할 경우)
# =========================
CMakeFiles/
CMakeCache.txt
cmake_install.cmake
Makefile

# =========================
#   VSCode 설정
# =========================
.vscode/*
!.vscode/settings.json
!.vscode/tasks.json
!.vscode/launch.json
!.vscode/extensions.json

# =========================
#   Linux 임시 파일
# =========================
*~
*.swp
*.swo

# =========================
#   기타
# =========================
*.log
*.zip
*.tar
*.tar.gz
*.rar

git rm --cached main

이미 main이라는 이름의 실행 파일이 깃허브에 올라가 있는지 확인 후 제거

trigraph ??! ignored, use -trigraphs to enable [-Wtrigraphs] 해결

qoi-31 — Fri, 3 Apr 2026 11:40:52 +0900

환경

Visual Studio Code(VSC) + Docker + Ubuntu

발생 문제

printf("%s??!", id);

trigraph ??! ignored, use -trigraphs to enable [-Wtrigraphs]

trigraph ??! ignored 오류 문구 + 빌드 불가능

발생 원인

C언어 trigraph에 의해 경고 발생 -> VSC + Docker + Ubuntu 환경이라 GCC가 경고를 에러처럼 취급 -> 빌드 실패

trigraph(삼중자)

컴파일러가 해당 문장 부호 문자로 대체하는 두 개의 연속된 물음표로 시작하는 세 문자의 시퀀스

-> 특정 문장 부호 문자에 대한 편리한 그래픽 표현을 포함하지 않는 문자 집합이 사용되는 C 소스 파일에서 사용할 수 있다

C 소스 프로그램의 소스 문자 집합: 7비트 ASCII 문자 집합에 포함되지만 ISO 646-1983 고정 코드 집합의 상위 집합

-> trigraph 시퀀스를 사용하면 C 프로그램을 ISO(International Standards Organizatoin) 고정 코드 집합만을 사용해 쓸 수 있음

C++ 17, Visual C++에선 trigraph 사용 불가능

trigraph	문장 부호 문자
??=	#
??(	[
??/	\
??)	]
??'	^
??<	{
??!	\|
??>	}
??-	~

trigraph는 항상 단일 소스 문자로 처리됨

trigraph 변환은 문자열 리터럴 및 문자 상수에서 이스케이프 문자를 인식하기 전 첫 번째 변환 단계에서 발생

해결법

printf("%s??""!", id);

or 

printf("%s?\?!", id);

??! 사이에 따옴표나 \(백슬래시 이스케이프 문자)를 넣어 trigraph 로 해석되지 않게 함

-> 문자 이스케이프 시퀀스 \?가 trigraph와 비슷한 문자 시퀀스가 잘못 해석되는 것을 방지함

[WIL] WEEK5

qoi-31 — Thu, 2 Apr 2026 17:58:56 +0900

한 마디

WEEK5 목표

팀 목표

- 코어 타임

매일 오후 9시 ~ 11시 코칭실

basic 문제 랜덤 발표

리트코드 30분 1 문제 풀이

- CSAPP 개념 정리
각자 진행

화요일 퀴즈 풀이 이후 코어 타임 때 개념 공유

개인 AI 활용 원칙

- 알고리즘 문제 풀이(basic, 난이도 하 구간)
1문제 당 1시간 이상 자력으로 풀이 진행

- 알고리즘 문제 풀이(난이도 중 구간 이상)
1문제 당 2시간 이상 자력으로 풀이 진행

- 자력으로 풀이 진행하는 시간 이상으로 문제 풀이 진행에 어려움이 있을 때
사용해야 하는 알고리즘/자료구조 등 힌트 요청에 AI 활용

- AI가 제공하는 힌트 관련 개념 학습 및 이해
최대한 구글링 활용, 어려움이 있을 때만 AI 활용

- 오류 분석
최대한 구글링 활용

- 문제 풀이 이후 자력으로 다른 사람의 답 코드 이해
어려움이 있을 때만 AI 활용

- AI를 통한 정답 코드 생성
절대 불가

개인 핵심 역량 목표

1. 문제해결 : 주어진 문제를 정의하고 논리적으로 해결하는 능력
알고리즘 기초 문제(basic)를 파이썬으로 AI 도움 없이 풀기

2. 구현 : 설계된 내용을 실제로 동작하는 코드로 작성
백준 브론즈5 수준의 문제를 파이썬으로 AI, 구글링 도움 없이 구현하기

3. 품질 : 버그 없는 안정적인 코드 및 테스트 작성
알고리즘 기초 문제(basic), 난이도 하 구간 모든 테스트 케이스 통과하기

4. 유지보수 : 가독성이 좋고 수정이 용이한 코드 작성
변수, 함수 네이밍 신경 써서 가독성 좋은 코드 작성하기

5. 협업 : 팀원과 소통하며 시너지를 내는 과정
코어 타임 코드 리뷰 적극적으로 참여하고, 코어 타임 외에도 팀원들에게 질문 많이 하기

6. 태도 : 자기주도적인 학습과 과제에 대한 몰입(집요함)
파이썬 및 알고리즘 관련 부족한 부분 정리해서 개인 시간에도 추가 학습하기

7. AI 활용 : AI 도구를 활용하여 생산성을 극대화하는 능력
문제 풀이 중 정해진 시간을 넘길 때까지 풀이에 어려움이 있다면 AI 힌트를 활용해 효율성을 높이기

8. 학습 민첩성 : 새로운 기술이나 개념을 빠르게 습득하는 능력
8시간 미만으로 파이썬 기본 문법을 빠르게 습득하기

WEEK5 공부한 내용

WEEK5 목표 달성

팀 목표

- 목표1
자세한 설명

- 목표2
자세한 설명

- 목표3
자세한 설명

WEEK5 새롭게 배운 점

- title

설명

- title

설명

WEEK6 계획

---

짧은 TMI

---

WEEK5 학습 기록

[CS:APP] 1.3 컴파일 시스템이 어떻게 동작하는지 이해하는 것은 중요하다

qoi-31 — Sun, 29 Mar 2026 01:23:26 +0900

컴파일 시스템이 어떻게 동작하는지 이해해야 하는 중요한 이유

1. 프로그램 성능 최적화

최신 컴파일러들은 복잡한 도구로 우수한 코드를 생성

-> C 프로그램 작성 시 올바른 판단을 하기 위해 기계어 수준 코드에 대한 기본적인 이해 및 컴파일러가 C 문장을 어떻게 기계어 코드로 번역하는지 이해 필요

ex)

- switch문은 if-else문을 연속해서 사용하는 것보다 항상 효율적일까?

- 함수 호출 시 발생하는 오버헤드는 얼마나 될까?

* 함수 호출 오버헤드: 함수 호출 시 실제 로직 실행 외에 필요한 매개변수 전달, 반환 주소 저장, 스택 프레임 생성 등의 부가 작업에 소요되는 시간과 메모리 비용(작은 함수 반복 호출/재귀 함수 사용 시 심화)

- while 루프는 for 루프보다 효율적일까?

- 포인터 참조가 배열 인덱스보다 효율적일까?

- 합계를 지역변수에 저장하면 참조형태로 넘겨받은 인자를 사용하는 것보다 왜 루프가 더 빨리 실행될까?

- 수식 연산시 괄호를 단순히 재배치 하기만 해도 함수가 더 빨리 실행되는 이유는 뭘까?

2. 링크 에러 이해

가장 당혹스러운 프로그래밍 에러는 링커의 동작과 관련이 있음

ex)

- 링커가 어떤 참조를 풀어낼 수 없다고 할 땐 무엇을 의미할까?

* 링커: 컴파일러가 생성한 기계어(목적 코드)들을 서로 연결시켜주는 프로그램

- 정적변수와 전역변수의 차이는 무엇일까?

- 각기 다른 파일에 동일한 이름의 두 개의 전역변수를 정의한다면 무슨 일이 일어날까?

- 정적 라이브러리와 동적 라이브러리의 차이는 무엇일까?

- 컴파일 명령을 쉘에서 입력할 때 명령어 라인의 라이브러리들의 순서는 무슨 의미가 있을까?

* 쉘(Shell): User가 명령어 기반으로 운영체제에 쉽게 접근할 수 있도록 만들어준 인터페이스

- 왜 링커와 관련된 에러들은 실행하기 전까지는 나타나지 않을까?

3. 보안 약점(security hole) 피하기

buffer overflow 취약성은 오랫동안 인터넷과 네트워크 상의 보안 약점의 주요 원인으로 설명됨

-> 프로그래머들이 신뢰할 수 없는 곳에서 획득한 데이터의 양과 형태를 주의 깊게 제한해야 할 필요를 인식하지 못하기 때문에 생겨남

안전한 프로그래밍을 배우는 첫 단계

=> 프로그램 스택에 데이터와 제어 정보가 저장되는 방식 때문에 생겨나는 영향을 이해하는 것

진심전력개발일지

[VSC] 줄바꿈 문자 LF로 고정하는 법

문제 상황

원인

해결법

[Git] 프로젝트를 새로운 Git 레포지토리에 업로드 하기

해결법

참고

[WIL] WEEK8

WEEK8 목표

팀 목표

개인 AI 활용 원칙

개인 핵심 역량 목표

WEEK8 공부한 내용

[네트워크 프로그래밍]

[소켓 프로그래밍 및 파일 입출력]

[웹 및 HTTP 프로토콜]

[네트워크 구조와 인터넷 프로토콜]

WEEK8 목표 달성

팀 목표

WEEK8 새롭게 배운 점

- Top-Down 학습법

WEEK9 계획

짧은 TMI

WEEK8 학습 기록

Windows11 Docker + DevContainer Ubuntu 환경 구축

Docker Desktop 설치

devcontainer 설정 추가(Dockerfile 사용 기준)

동적 메모리 할당

동적 메모리 할당의 개념

언어별 동적 할당 방식

C 언어

C++

Python

정적 할당 vs 동적 할당 비교

면접 핵심 질문: 왜 게임 프로그래밍에서 중요한가?

1. 단편화(Fragmentation) 문제

2. 성능 오버헤드

3. 메모리 누수(Memory Leak)

이해를 돕는 비유: 식당 예약 시스템

시간 복잡도 분석

주의사항 (CS 포인트)

C Pointer(*, &)

C언어 포인터 개념 (*, &)

1. 포인터의 기본 개념

주소 연산자 (&)

역참조 연산자 (*)

2. 언어별 포인터와 메모리 접근

C / C++

Python

3. 포인터의 성능과 시간 복잡도

4. 면접 핵심 질문 대비 (CS 포인트)

Call by Value vs Call by Address (Pointer)

포인터와 배열의 차이

왜 게임 프로그래밍에서 포인터가 중요한가?

5. 포인터 비유: 보물찾기 지도

[VSC] C 소스 코드 실행 파일 이름 변경

1. tasks.json 파일 수정

launch: program '/workspaces/...' dose not exist 오류

2. launch.json 파일 수정

3. .gitignore 추가

trigraph ??! ignored, use -trigraphs to enable [-Wtrigraphs] 해결

환경

발생 문제

발생 원인

trigraph(삼중자)

해결법

[WIL] WEEK5

WEEK5 목표

팀 목표

개인 AI 활용 원칙

개인 핵심 역량 목표

WEEK5 공부한 내용

[CSAPP]

[알고리즘 기초]

[알고리즘 이론]

[코딩 테스트]

WEEK5 목표 달성

팀 목표

WEEK5 새롭게 배운 점