[C/C++] 13. printf / scanf 문자 입출력

앞서 함수와 반복문의 기본 개념과 흐름 제어를 알아보았다. 이번 글에서는 콘솔 환경에서 데이터를 화면에 출력하고 사용자로부터 입력을 받는 표준 입출력 함수인 와 , 그리고 서식 지정자와 메모리 주소 전달 방식에 대해 정리한다. 프로그램 실행 시 나타나는 검은 창을 흔히 콘솔 창(Windows의 명령 프롬프트, Linux의 쉘)이라고 부른다. 콘솔은 컴퓨터와 사용자 간의 가장 기본적인 텍스트 기반 입출력 인터페이스이다. C/C++에서는 표준 라이브러리를 통해 이러한 콘솔 환경에 텍스트를 출력하거나 입력을 받아오는 함수를 기본 제공한다. - * (또는 ):* , 와 같은 함수는 직접 구현하지 않고 표준 입출력 헤더 파일을 포함(Include)하여 사용한다. 컴파일러가 번역하기 전, 전처리기(Preprocessor) 단계에서 해당 헤더를 소스 코드에 결합한다. 는 문자열을 콘솔 화면에 출력(Print Formatted)하는 함수다. 문자열 내에 특정 데이터를 원하는 위치에 끼워 넣기 위해 서식 지정자(치환 문자)를 사용한다. - * (Decimal):* 10진수 정수형 데이터를 출력할 때 사용한다. - * (Float):* 실수형 데이터를 출력할 때 사용한다. - 디버깅 도구로서의 활용: 중단점(Breakpoint)을 잡는 디버깅 외에도, 코드 중간중간 를 통해 변수의 변화나 반복문의 흐름을 콘솔 창에서 직관적으로 추적할 수 있다. 는 콘솔 창을 통해 사용자로부터 키보드 입력을 받아 지정한 변수에 저장하는 함수다. 1. 입력 대기(Blocking): 가 호출되면 프로그램은 사용자가 값을 입력하고 엔터(Enter)를 누를 때까지 실행을 멈추고 대기(무한 루프) 상태에 들어간다. 2. * (주소 연산자) 사용 이유:* 변수 이름 앞에 를 붙이는 것은 해당 변수의 메모리 시작 주소를 넘겨주겠다는 의미다. 함수 내부에서 외부 변수 의 실제 메모리 위치를 찾아가 직접 값을 덮어써야 하기 때문이다. 3. : 최신 Visual Studio 환경에서는 버퍼 오버플로우 보안 취약점을 방지하기 위해 표준 대신 안전 버전인 사용을 권장한다. 와 는 단순한 출력·입력 함수처럼 보이지만, 내부적으로는 매우 복잡한 저수준(Low-level) 메커니즘으로 동작한다. - 문자 및 문자열의 메모리 저장 구조 (ASCII 코드, 널 종료 문자 ) - 메모리 주소 체계와 포인터(Pointer)의 개념 - 스택 프레임(Stack Frame) 및 가변 인자(Variadic Arguments) 처리 방식 이러한 선행 개념들을 확실히 학습한 뒤, 추후 심화 단계에서 와 의 동작 원리를 메모리 관점에서 다시 상세히 분석할 예정이다. - 는 서식 지정자(, 등)를 통해 특정 위치에 데이터를 치환하여 콘솔에 출력한다. - 는 사용자 입력을 받을 때까지 실행을 대기하며, 입력값을 저장할 변수의 메모리 주소()를 요구한다. - 입출력 함수의 온전한 내부 동작 방식을 이해하기 위해서는 포인터와 메모리 구조에 대한 선행 학습이 필수적이다.

2026년 8월 31일

합격 통보를 받은 날, 기쁨보다 고민이 앞서는 이유

며칠 전 면접을 보았던 금융 SI/SM 회사로부터 최종 합격 연락을 받았다. 입사일은 9월 1일 화요일. 함께 입사하는 동기가 한 명 있을 것이라는 이야기와 함께 등본, 대학 졸업 및 성적 증명서 등 입사 구비 서류를 안내받았다. 최근 채용 취소와 탈락을 연달아 겪으며 길고 불안한 터널을 지나온 만큼, 온 마음으로 기뻐해야 마땅한 순간이다. 하지만 핸드폰을 내려놓은 뒤 찾아온 감정은 후련한 기쁨보다 마음 한구석을 무겁게 짓누르는 복잡한 물음표였다. '이게 과연 나에게 최선의 선택일까?' 솔직히 고백하자면 나는 파견 형태의 SI/SM 환경을 가장 피하고 싶어 했다. 내 성향을 누구보다 잘 알고 있기 때문이다. 낯가림이 있고 소심한 편이라 프로젝트가 바뀔 때마다 낯선 환경에서 완전히 새로운 사람들과 부딪혀야 한다는 점이 큰 부담으로 다가왔다. 무엇보다 나는 한곳에 온전히 머물며 얻는 '소속감'을 중요하게 여기는 사람이다. 본사 사무실에 자리 잡은 '내 책상', 나만의 안정적인 공간에서 동료들과 유대감을 쌓으며 일하는 그림을 늘 그려왔다. 하지만 현실은 이상과 달랐다. 차갑게 얼어붙은 취업 시장에서 무작정 완벽한 회사를 기다리며 공백을 늘릴 수는 없는 노릇이다. 어떤 형태로든 실무에 뛰어들어 개발자로서 진짜 경력을 쌓는 것이 지금 당장 가장 현실적이고 필요한 선택이라는 생각도 든다. 결국 합격을 받아들이고 출근을 준비하기로 마음을 굳혔다. 두려움과 기대가 뒤섞인 채 9월의 시작을 앞두고 있다. 과연 몇 년 뒤 미래의 나는 지금의 이 선택을 어떻게 바라보게 될까? 치열하게 버텨내며 성장한 밑거름이라 여길까, 아니면 깊은 후회로 남게 될까. 아직 가보지 않은 길의 정답은 알 수 없다. 다만 분명한 것은 어떤 선택을 내렸든 그 결과를 '의미 있는 시간'으로 만드는 것은 결국 앞으로 내가 마주할 태도에 달려 있다는 점이다. 불안한 마음을 안고, 우선은 첫걸음을 내딛어 보려 한다.

2026년 8월 27일

금융 SI/SM 면접 후기

오늘 한 금융 SI/SM 기업의 면접을 다녀왔다. 최근 채용 취소와 최종 탈락 등으로 마음고생이 심했던 터라, 이번 면접은 스스로의 상태를 점검하고 앞으로의 방향을 다시 가늠해 보는 중요한 자리였다. 면접관으로 들어오신 팀장님(18년 차 개발자)께서 회사의 사업 구조와 금융 SI/SM의 현실적인 업무 환경을 정말 상세하게 설명해 주셨다. 금융 SI/SM 생태계에 대해 새롭게 배운 점 - 폐쇄망과 기술 스택: 금융권 특성상 보안이 엄격한 폐쇄망 환경에서 일하며, 넥사크로(Nexacro), 웹스퀘어, C언어 같은 레거시 기술과 배치(Batch) 처리가 여전히 핵심 축을 담당한다. - 프로젝트 단위의 파견 근무: 여의도, 서울역, 강남 등 주요 금융사 본사나 전산센터로 파견을 나가며, 규모가 큰 프로젝트(차세대 등)는 여러 회사의 인력이 모여 컨소시엄 형태로 진행된다. - 입사 후 교육 체계: 입사 시 약 4주간 프론트엔드 UI 플랫폼, 스프링 백엔드, 서버/DB 운영 및 C언어 레거시 관련 교육을 거쳐 프로젝트에 투입된다. 스스로에 대한 점검과 반성 면접 과정에서 그동안 나 스스로 가장 큰 걸림돌이라 여겼던 '신입치고 많은 나이'에 대해 팀장님께 여쭤보았다. 팀장님께서는 "전혀 문제 될 나이가 아니다"라며 내가 잘못 생각하고 있던 선입견을 짚어주셨다. 결과가 안 좋았던 원인을 나이 탓으로 돌리며 스스로를 위축시키고 있었던 것은 아닌지 되돌아보게 되었다.

2026년 8월 25일

뒤늦은 후회와 뼈아픈 자책 속에서

유난히 마음이 무겁고 가라앉는 8월의 기록이다. Java 백엔드 개발 직무로 최종 합격 통보를 받았던 날, 그동안 밤새워 코딩하고 포트폴리오를 다듬었던 시간들이 보상받는 것 같아 안도감이 앞섰다. 하지만 그 안도감 뒤에 숨어 있던 나의 안일함이 결국 모든 것을 무너뜨렸다. 합격 통보를 받은 날은 8월 12일 수요일. 안내문에는 분명 인사기록카드 제출 기한이 당일(12일)로 명시되어 있었다. 하지만 다음 날 개인 사정으로 입사일을 24일로 미루는 요청을 드렸고, 인사담당자로부터 "24일로 변경하겠습니다. 24일에 뵙겠습니다."라는 회신을 받자 나는 내 편의대로 상황을 해석해 버렸다. 입사일이 미뤄졌으니 서류 제출도 자연스럽게 여유가 생긴 것이라며 멋대로 짐작했고, 서류를 바로 챙기지 않았다. 원래 입사 예정일이었던 8월 18일 화요일, 회사는 '인사기록카드 미제출'을 이유로 채용을 취소했다. 그 통보를 받은 순간 머리를 한 대 맞은 것 같았다. 엎친 데 덮친 격으로 준비하던 다른 회사의 2차 면접 탈락 소식까지 겹쳐오자, 모든 화살은 오롯이 나 자신을 향했다. '기한이 당일이라고 적혀 있었는데 왜 바로 내지 않았을까.' '입사일이 미뤄졌더라도 서류는 그 즉시 보냈어야 했는데, 왜 내 마음대로 유예됐다고 판단했을까.' 회사가 야속하다는 생각보다, 명확히 안내된 기한을 지키지 않은 내 불찰에 대한 후회가 훨씬 뼈아프게 다가왔다. 회사 입장에서는 첫 안내의 기한조차 지키지 않은 지원자에게 신뢰를 갖기 어려웠을 것이다. '따로 독촉이 없었으니 괜찮겠지' 하고 넘겨짚었던 나의 태만함과 미숙함이 결국 합격이라는 결과를 내 손으로 걷어차게 만든 셈이다. 돌이킬 수 없는 실수를 마주하는 일은 너무나 괴롭고 쓰리다. 하지만 이 뼈아픈 경험을 남 탓으로 돌리며 합리화하고 싶지는 않다. 마감 기한과 원칙의 무게, 그리고 사회에서의 소통은 내 짐작이 아니라 명확한 확인으로 이루어져야 한다는 것을 값비싸게 배웠다. 스스로 만든 실패를 온전히 인정하고 마음에 새긴다. 다시는 같은 실수를 반복하지 않도록, 더 꼼꼼하고 책임감 있는 태도로 다음을 준비해야겠다.

2026년 8월 20일

www.google.com을 접속할 때 웹 브라우저 요청 흐름을 설명해주세요.

웹 브라우저 주소창에 URL을 입력하여 원하는 웹페이지가 화면에 뜨기까지의 과정은 단순해 보이지만, 실제로는 네트워크 통신(DNS, TCP, HTTP)과 브라우저의 렌더링 엔진이 유기적으로 mesh되어 작동하는 복합적인 프로세스다. CS 면접에서 이 질문은 각 계층별 핵심 개념(IP 변환, 연결 수립, 데이터 송수신, 화면 그리기)을 시간순으로 매끄럽게 연결하여 설명할 수 있는지를 평가하는 대표적인 질문이다. 사용자가 을 입력하면 브라우저는 가장 먼저 목적지 서버의 실제 IP 주소를 찾는다. - 캐시 확인: 브라우저 캐시, OS 캐시, 라우터 캐시, ISP DNS 캐시 순으로 요청한 도메인에 매핑된 IP 주소가 있는지 확인한다. - DNS 질의 (DNS Query): 캐시에 정보가 없다면 Local DNS 서버를 시작으로 Root DNS, TLD(.com) DNS, Authoritative DNS 서버를 거치는 재귀적/반복적 질의를 수행하여 최종 IP 주소를 획득한다. 획득한 IP 주소를 바탕으로 클라이언트(브라우저)와 구글 서버 간의 신뢰성 있는 전송 통로를 개설한다. - SYN: 클라이언트가 서버에 연결 요청 패킷(SYN)을 보낸다. - SYN + ACK: 서버가 요청을 수락하며 확인 응답(ACK)과 함께 연결 요청(SYN)을 보낸다. - ACK: 클라이언트가 최종 확인 응답(ACK)을 보내며 TCP 연결을 완료한다. (HTTPS 접속 시 이 단계 직후 TLS/SSL Handshake가 추가로 진행되어 암호화 키를 교환한다.) TCP 연결이 확립되면 실제 데이터를 주고받는 통신을 진행한다. - HTTP 요청 전송: 브라우저는 GET 메서드, 요청 헤더(User-Agent, Accept 등), 쿠키 등을 포함한 HTTP Request 패킷을 생성하여 서버로 보낸다. - 서버 처리 및 응답: 구글 서버는 요청을 처리한 뒤 상태 코드(예: )와 응답 헤더, 그리고 요청한 HTML 데이터(Body)를 담아 HTTP Response를 반환한다. 응답받은 데이터를 기반으로 브라우저 엔진이 화면을 구성한다. 1. 파싱 (Parsing): 수신한 HTML을 파싱하여 DOM 트리를 생성하고, CSS를 파싱하여 CSSOM 트리를 생성한다. 2. 렌더 트리 구축 (Render Tree Construction): DOM과 CSSOM을 결합하여 실제 화면에 표시될 요소들로 구성된 Render Tree를 만든다. 3. 레이아웃 (Layout / Reflow): 각 노드의 정확한 위치와 크기를 계산한다. 4. 페인트 (Paint / Repaint): 계산된 레이아웃을 바탕으로 화면에 실제 피셀을 그린다. 5. 자바스크립트 실행: HTML 파싱 중 태그를 만나면 파싱을 중단하고 JS 엔진에 제어권을 넘겨 스크립트를 실행한 뒤 파싱을 재개한다. 데이터 전송 및 렌더링이 완료되고 통신을 종료해야 하는 시점이 되면 4-Way Handshake ( $\rightarrow$ $\rightarrow$ $\rightarrow$ ) 과정을 거쳐 TCP 연결을 안전하게 해제한다. (단, HTTP Keep-Alive 설정에 따라 연결을 유지하고 재사용할 수도 있다.) 이처럼 웹 브라우저 요청 흐름은 단순한 데이터 조회가 아니라 [DNS를 통한 IP 확보] $\rightarrow$ [TCP/TLS를 통한 안전한 통신 통로 개설] $\rightarrow$ [HTTP를 통한 데이터 교환] $\rightarrow$ [렌더링 파이프라인을 통한 화면 시각화]라는 일련의 구조화된 과정으로 구성된다. 면접 답변 시 단순 단결성 요약에 그치지 않고, 캐시의 사용 여부, 핸드셰이크를 통한 연결 생애주기, 브라우저 렌더링 엔진의 구체적인 단계까지 파이프라인 형태로 연결 지어 설명하는 것이 높은 평가를 받는 핵심 포인트다. 웹 동작 원리는 네트워크 기초와 브라우저 파싱 원리가 종합적으로 다뤄지는 영역이다. 기본 흐름을 파악한 후에는 계층별 세부 동작(TLS 암호화 과정, Repaint/Reflow 차이, Keep-Alive 메커니즘 등)으로 확장하여 심도 있게 대비하는 것을 추천한다.

2026년 8월 6일

Gyulog