블로그하는개발자

한 X 게시물(2026-10-15)은 "Microsoft가 최근 WSL 3.0을 출시했으며, Windows에서 에이전트를 가장 안전하게 돌리는 방법은 WSL 안에 두는 것"이라고 주장합니다. 이 글에서는 해당 주장을 그대로 사실로 받아들이지 않고, Microsoft 공식 문서와 릴리스 기록으로 확인한 내용을 WSL 2 기준으로 정리했습니다.

WSL이란 무엇이며 어떻게 동작하나요?

1. 실제 Linux 커널: WSL 버전 비교 문서에 따르면 WSL 2는 경량 유틸리티 VM 안에서 실제 Linux 커널을 실행합니다. 이 커널은 Microsoft가 최신 안정 브랜치를 기반으로 빌드하며 일반 업데이트로 관리됩니다.
2. 시스템 콜 호환성: 같은 문서에서 WSL 2는 전체 시스템 콜 호환성과 systemd를 지원한다고 설명합니다. 따라서 Linux 바이너리와 Docker 계열 도구를 별도 변환 없이 사용하실 수 있습니다.
3. 편집기는 Windows, 터미널은 Linux: VS Code WSL 튜토리얼에 따르면 WSL 확장은 VS Code를 클라이언트(Windows의 UI)와 서버(WSL 안의 코드, Git, 플러그인)로 나눕니다. 에이전트 실행도 서버 쪽, 즉 WSL 안에서 이루어집니다.

Windows에서 직접 돌리는 것보다 WSL에서 AI 에이전트가 더 안정적인 이유는 무엇일까요?

1. Linux 셸과 도구 전제: 에이전트가 실행하는 CLI 명령과 스크립트는 Bash, / 구분자의 POSIX 경로, 실행 비트(chmod +x), 대소문자를 구분하는 파일 이름, Linux 패키지 관리자를 전제로 작성된 경우가 많습니다.
2. 시스템 콜 호환성: 전체 시스템 콜이 호환되므로 Linux 바이너리와 Docker 계열 도구가 변환 계층 없이 동작합니다.
3. Windows 홈 디렉터리와 분리된 작업 공간: 에이전트를 WSL 안에서 돌리면 작업 환경이 Windows 홈 디렉터리와 분리됩니다. 하지만 WSL에서도 /mnt/c로 Windows 드라이브에 접근할 수 있으므로 보안 샌드박스는 아닙니다.
4. Linux 파일시스템의 동작 확인: 아래는 에이전트가 기대하는 Linux 파일시스템의 동작을 확인한 결과입니다. WSL이 아닌 일반 Linux 박스에서 실행했습니다.

   실제 실행 결과 (Linux 6.12, WSL 아님)

   $ uname -sr
   Linux 6.12.94+
   $ touch readme.md README.md && ls
   README.md
   readme.md
   $ printf '#!/bin/sh\necho ok\n' > run.sh && chmod +x run.sh && ls -l run.sh
   -rwxr-xr-x run.sh
   $ ./run.sh
   ok

5. 결과 해석: Linux 파일시스템에서는 readme.md와 README.md가 서로 다른 파일로 만들어지고, 실행 비트도 그대로 적용되었습니다. 반면 Windows 드라이브(기본 NTFS)는 기본적으로 파일 이름의 대소문자를 구분하지 않습니다.

프로젝트 파일은 어디에 두고 네트워크는 어떻게 사용하나요?

1. 파일 위치: WSL 파일시스템 문서는 Linux 명령줄에서 작업할 때 가장 빠른 속도를 위해 파일을 WSL 파일시스템에 저장하라고 안내합니다. Windows 드라이브는 /mnt/c/...로 보이며, WSL 2에서 OS 경계를 넘나드는 파일 접근은 성능 면에서 불리합니다.
2. Windows에서 Linux 파일 보기: 파일 탐색기 주소창에 \\wsl$를 입력하시면 Linux 파일을 확인하실 수 있습니다.
3. 네트워크: WSL 네트워킹 문서에 따르면 기본 모드는 NAT이며, Microsoft는 Mirrored 네트워킹 모드를 사용해 보도록 권장합니다. Linux에서 띄운 애플리케이션은 Windows에서 localhost로 접근하실 수 있습니다.

WSL 설치와 실행 환경 설정에는 어떤 명령어가 필요할까요?

1. 설치:

   wsl --install

2. 설치된 배포판과 WSL 버전 확인:

   wsl -l -v

3. WSL 패키지와 커널 업데이트:

   wsl --update

4. WSL 터미널에서 VS Code 연결:

   code .

자주 묻는 질문: "WSL 3.0"이 새로 나왔을까요?

A post on X (2026-10-15) claims that Microsoft recently released "WSL 3.0" and that the safest way to run agents on Windows is to put them inside WSL. This post does not take that claim at face value; it summarizes what Microsoft's official docs and release records confirm, on a WSL 2 basis.

What is WSL and how does it work?

1. A real Linux kernel: According to the WSL version comparison doc, WSL 2 runs an actual Linux kernel inside a lightweight utility VM. Microsoft builds that kernel from the latest stable branch and services it through regular updates.
2. System call compatibility: The same doc describes full system call compatibility and systemd support, so Linux binaries and Docker-style tooling work without a translation layer.
3. Editor on Windows, terminal on Linux: Per the VS Code WSL tutorial, the WSL extension splits VS Code into a client (the UI on Windows) and a server (code, Git, and plugins inside WSL). Agent execution happens on the server side, inside WSL.

Why do AI agents run more reliably inside WSL than directly on Windows?

1. Linux shell and tooling assumptions: CLI commands and scripts run by agents are often written for Bash, POSIX paths with /, execute bits (chmod +x), case-sensitive file names, and Linux package managers.
2. System call compatibility: With full syscall compatibility, Linux binaries and Docker-style tooling run without a translation layer.
3. A workspace separate from your Windows home: Running the agent in WSL keeps its working environment apart from your Windows home directory. But WSL can still access Windows drives through /mnt/c, so it is not a security sandbox.
4. Checking Linux filesystem behavior: Below is the Linux filesystem behavior agents expect, run on a plain Linux box, not WSL.

   actual output (native Linux, not WSL)

   $ uname -sr
   Linux 6.12.94+
   $ touch readme.md README.md && ls
   README.md
   readme.md
   $ printf '#!/bin/sh\necho ok\n' > run.sh && chmod +x run.sh && ls -l run.sh
   -rwxr-xr-x run.sh
   $ ./run.sh
   ok

5. Reading the result: On the Linux filesystem, readme.md and README.md were created as two distinct files, and the execute bit took effect. Windows drives (NTFS by default), by contrast, are case-insensitive for file names by default.

Where should project files live, and how does networking work?

1. File location: The WSL filesystems doc advises storing files in the WSL file system for the fastest performance when working in a Linux command line. Windows drives appear at /mnt/c/..., and cross-OS file access is slower in WSL 2.
2. Viewing Linux files from Windows: Type \\wsl$ into the File Explorer address bar to browse your Linux files.
3. Networking: According to the WSL networking doc, the default mode is NAT, and Microsoft recommends trying Mirrored networking mode. Applications running in Linux are reachable from Windows via localhost.

What commands do you need to install WSL and set up the environment?

1. Install:

   wsl --install

2. List installed distributions and WSL versions:

   wsl -l -v

3. Update the WSL package and kernel:

   wsl --update

4. Open VS Code connected to WSL, from a WSL terminal:

   code .

FAQ: Was "WSL 3.0" newly released?

이 글은 x86_64 호스트의 Debian GNU/Linux 13(trixie) 환경에서 직접 진행한 크로스 컴파일 빌드와 실행 결과를 바탕으로 작성했습니다. 동일한 패키지 이름이 Ubuntu에도 존재하지만, 실제 실행 테스트는 Debian에서 수행했습니다.

크로스 컴파일이란? 왜 보드에서 직접 빌드하지 않나?

1. 호스트와 타깃: 호스트는 빌드를 수행하는 개발 PC(이 글에서는 Debian 13, x86_64)를 가리키며, 타깃은 빌드된 바이너리가 실제로 동작할 임베디드 보드(ARM aarch64)를 의미합니다.
2. 보드에서 직접 빌드하지 않는 이유: 임베디드 보드는 CPU 연산 성능이 낮아 컴파일 속도가 느리고, RAM과 플래시 저장공간이 제한적이어서 규모가 큰 소스 코드와 중간 오브젝트 파일을 감당하기 어렵기 때문입니다.
3. 툴체인의 구성: 크로스 컴파일러(gcc), 어셈블러와 링커(binutils), 그리고 타깃용 C 라이브러리와 헤더 파일(sysroot)로 구성됩니다. Debian 시스템에서는 타깃 라이브러리가 /usr/aarch64-linux-gnu에 설치되며, 이후 QEMU 실행 시 -L 옵션으로 이 경로를 지정하는 이유가 여기에 있습니다.
4. 이름 읽는 법: aarch64-linux-gnu-gcc는 아키텍처(aarch64) - 운영체제(linux) - ABI/libc(gnu, 즉 glibc) - 도구(gcc) 순서로 구성됩니다. 32비트 ARM 하드 플로트용 대응 도구로는 arm-linux-gnueabihf-gcc가 있으며, 이 글에서는 설명상 언급만 하고 실행하지는 않았습니다.

ARM용 gcc는 어떻게 설치하고 첫 빌드를 하나?

1. 패키지 설치: 아래 명령으로 필요한 패키지를 설치했으며, 의존성에 따라 qemu-user-binfmt 패키지가 함께 설치되었습니다.

   실제 실행 결과 (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ sudo apt install gcc-aarch64-linux-gnu qemu-user

2. 설치된 버전 확인:

   실제 실행 결과 (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ aarch64-linux-gnu-gcc --version
   aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0
   
   $ qemu-aarch64 --version
   qemu-aarch64 version 10.0.13 (Debian 1:10.0.13+ds-0+deb13u1)

3. 예제 소스 hello.c:

   #include <stdio.h>
   int main(void) {
       printf("Hello from aarch64!\n");
       return 0;
   }

4. 첫 크로스 컴파일과 아키텍처 확인: 빌드 후 file 명령으로 확인하면 ARM aarch64 아키텍처용 동적 링크 바이너리이며, 프로그램 인터프리터로 /lib/ld-linux-aarch64.so.1을 참조하고 있음을 알 수 있습니다.

   실제 실행 결과 (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ aarch64-linux-gnu-gcc hello.c -o hello
   $ file hello
   hello: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=877dd7a0…, for GNU/Linux 3.7.0, not stripped

5. 호스트 바이너리와 인터프리터 비교: 호스트 gcc로 빌드한 바이너리는 x86-64용이며 인터프리터 역시 /lib64/ld-linux-x86-64.so.2로 다릅니다. ARM 바이너리가 요청하는 동적 인터프리터 경로는 readelf -l 명령으로도 명확하게 확인하실 수 있습니다.

   실제 실행 결과 (Debian 13, gcc 14.2, QEMU 10.0.13)

   # 호스트 gcc로 빌드한 x86 바이너리 비교
   $ file hello-x86
   hello-x86: ELF 64-bit LSB pie executable, x86-64, ... interpreter /lib64/ld-linux-x86-64.so.2
   
   # ARM 바이너리의 프로그램 인터프리터 확인
   $ aarch64-linux-gnu-readelf -l hello
   [Requesting program interpreter: /lib/ld-linux-aarch64.so.1]

빌드한 ARM 바이너리는 PC에서 어떻게 실행해 보나?

1. QEMU 유저 모드의 원리: QEMU 유저 모드 공식 문서에 따르면, 다른 CPU용으로 빌드된 리눅스 바이너리를 실행할 때 시스템 콜을 가로채 호스트 커널로 전달해 주는 방식입니다. 공식 문서에서는 이를 엔디안과 32/64비트 매개변수 크기를 조정한 뒤 호스트 시스템 콜을 호출하는 "generic system call translator"라고 정의합니다. 전체 운영체제를 가상화하는 시스템 에뮬레이션과 달리 가볍게 동작합니다. 실행 시 ELF 인터프리터 프리픽스를 지정하는 -L path 옵션을 사용하며, QEMU_STRACE 환경변수를 설정하면 호출되는 시스템 콜 내역을 직접 확인하실 수 있습니다.
2. 호스트에서 직접 실행하면 실패합니다: x86_64 커널은 ARM 바이너리의 기계어 명령을 직접 해석하지 못합니다. 커널에 binfmt_misc가 등록되어 있다면(Debian의 qemu-user-binfmt 패키지) ./hello로 직접 실행할 수 있지만, 이번 실행 환경은 binfmt_misc가 마운트되지 않은 컨테이너였으므로 다음과 같이 실행 오류가 발생했습니다.

   실제 실행 결과 (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ ./hello
   bash: line 1: ./hello: cannot execute binary file: Exec format error

3. qemu-aarch64만 붙이면 동적 링커 오류가 납니다: 호스트의 /lib 경로에는 ARM용 동적 링커가 존재하지 않기 때문입니다.

   실제 실행 결과 (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ qemu-aarch64 ./hello
   qemu-aarch64: Could not open '/lib/ld-linux-aarch64.so.1': No such file or directory

4. -L로 sysroot를 지정하면 실행됩니다: Debian 환경에서는 /usr/aarch64-linux-gnu 경로에 ARM용 동적 링커와 표준 C 라이브러리가 설치되어 있으므로, -L 옵션으로 이 경로를 지정하면 정상 실행됩니다.

   실제 실행 결과 (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ qemu-aarch64 -L /usr/aarch64-linux-gnu ./hello
   Hello from aarch64!

5. 정적 링크로 빌드하면 -L이 필요 없습니다: -static 옵션으로 빌드하면 필요한 라이브러리가 바이너리 내부에 포함되어 외부 동적 링커를 참조하지 않으므로 추가 경로 지정 없이 바로 실행됩니다.

   실제 실행 결과 (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ aarch64-linux-gnu-gcc -static hello.c -o hello-static
   $ file hello-static
   hello-static: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=424b08be…, for GNU/Linux 3.7.0, not stripped
   $ qemu-aarch64 ./hello-static
   Hello from aarch64!

크로스 컴파일할 때 자주 막히는 곳은?

This post is based on actual build and run results on an x86_64 host running Debian GNU/Linux 13 (trixie). While the same package names exist on Ubuntu, the steps shown here were tested directly on Debian.

What is cross-compiling? Why not build directly on the target board?

1. Host vs. Target: The host is the PC performing the compilation (Debian 13, x86_64 in this guide), while the target is the embedded board (ARM aarch64) where the binary actually executes.
2. Why not build directly on the board: Embedded boards have constrained CPU power, making compilation slow. In addition, restricted RAM and flash storage make it difficult to accommodate large source trees and intermediate build artifacts.
3. Components of a toolchain: A toolchain consists of the cross-compiler (gcc), assembler and linker (binutils), and target C library headers and binaries (sysroot). On Debian, target libraries reside under /usr/aarch64-linux-gnu, which explains why QEMU's -L flag points to this directory.
4. Deconstructing the toolchain tuple: In aarch64-linux-gnu-gcc, the naming convention denotes architecture (aarch64) - operating system (linux) - ABI/libc (gnu, indicating glibc) - tool (gcc). The 32-bit ARM hard-float equivalent is arm-linux-gnueabihf-gcc, mentioned here for reference only (not executed).

How do you install ARM gcc and perform the first build?

1. Package installation: Install the required packages via apt; the qemu-user-binfmt package is automatically pulled in as a dependency.

   actual output (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ sudo apt install gcc-aarch64-linux-gnu qemu-user

2. Checking installed versions:

   actual output (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ aarch64-linux-gnu-gcc --version
   aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0
   
   $ qemu-aarch64 --version
   qemu-aarch64 version 10.0.13 (Debian 1:10.0.13+ds-0+deb13u1)

3. Example source code (hello.c):

   #include <stdio.h>
   int main(void) {
       printf("Hello from aarch64!\n");
       return 0;
   }

4. First cross-compilation and binary inspection: Inspecting the resulting binary with file confirms that it is an ARM aarch64 dynamically linked ELF executable requesting /lib/ld-linux-aarch64.so.1 as its program interpreter.

   actual output (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ aarch64-linux-gnu-gcc hello.c -o hello
   $ file hello
   hello: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, BuildID[sha1]=877dd7a0…, for GNU/Linux 3.7.0, not stripped

5. Comparing against a host binary and verifying the interpreter: A binary built with the host gcc targets x86-64 and uses /lib64/ld-linux-x86-64.so.2. The program interpreter requested by the ARM binary can also be inspected directly with readelf -l.

   actual output (Debian 13, gcc 14.2, QEMU 10.0.13)

   # x86 binary built with the host gcc, for comparison
   $ file hello-x86
   hello-x86: ELF 64-bit LSB pie executable, x86-64, ... interpreter /lib64/ld-linux-x86-64.so.2
   
   # check the ARM binary's program interpreter
   $ aarch64-linux-gnu-readelf -l hello
   [Requesting program interpreter: /lib/ld-linux-aarch64.so.1]

How do you run the built ARM binary on a PC?

1. How QEMU user mode works: According to the QEMU user-mode documentation, user-mode emulation runs Linux processes compiled for another CPU architecture by intercepting and passing their system calls to the host kernel. The official documentation defines it as a "generic system call translator" that adjusts endianness and 32/64-bit parameter sizes before invoking equivalent host syscalls. Unlike full system emulation, it does not virtualize an entire operating system. Key options include -L path to specify the ELF interpreter prefix, while the QEMU_STRACE environment variable logs syscall activity for debugging.
2. Direct execution on the host fails: An x86_64 kernel cannot parse or execute ARM instructions directly. If the kernel has binfmt_misc registered (via the Debian qemu-user-binfmt package), direct execution with ./hello is possible; however, because this session ran in a container without binfmt_misc mounted, execution resulted in an explicit format error.

   actual output (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ ./hello
   bash: line 1: ./hello: cannot execute binary file: Exec format error

3. Running plain qemu-aarch64 triggers a dynamic linker error: Without a sysroot prefix, QEMU looks for the ARM dynamic linker in the host's /lib directory, where it does not exist.

   actual output (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ qemu-aarch64 ./hello
   qemu-aarch64: Could not open '/lib/ld-linux-aarch64.so.1': No such file or directory

4. Supplying the target sysroot with -L executes successfully: Because Debian installs the ARM dynamic linker and C library under /usr/aarch64-linux-gnu, passing that prefix via -L resolves all runtime dependencies.

   actual output (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ qemu-aarch64 -L /usr/aarch64-linux-gnu ./hello
   Hello from aarch64!

5. Statically linked binaries run without -L: Compiling with the -static flag embeds all required library code into the binary. Because it has no external dependencies or dynamic interpreter requirements, it runs directly under QEMU without extra path arguments.

   actual output (Debian 13, gcc 14.2, QEMU 10.0.13)

   $ aarch64-linux-gnu-gcc -static hello.c -o hello-static
   $ file hello-static
   hello-static: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=424b08be…, for GNU/Linux 3.7.0, not stripped
   $ qemu-aarch64 ./hello-static
   Hello from aarch64!

What are the common pitfalls in cross-compiling?

이 글에서는 g++ 14.2와 clang 19.1.7로 직접 컴파일한 결과를 바탕으로 explicit이 무엇을 막고 무엇을 허용하는지 정리해 드립니다. 암시적 변환 규칙 자체는 C++ 정수 승격 규칙 글을 참고해 주시기 바랍니다.

C++ explicit이란? 변환 생성자는 무엇인가?

1. 공식 정의: cppreference에서는 explicit을 "Specifies that a constructor or conversion function (since C++11) or deduction guide (since C++17) is explicit, that is, it cannot be used for implicit conversions and copy-initialization."라고 설명합니다.
2. 변환 생성자: cppreference의 변환 생성자 문서에 따르면 explicit 없이 선언된 생성자가 변환 생성자입니다. C++11 이전에는 기본값이 없는 단일 매개변수를 갖는 생성자를 가리켰으나, C++11부터는 매개변수가 여러 개인 non-explicit 생성자도 복사 리스트 초기화에 참여합니다. 예를 들어 A a4 = {4, 5};는 허용되지만, 생성자가 explicit으로 선언된 경우 B b4 = {4, 5};는 컴파일 에러가 발생합니다.
3. explicit 생성자일 때의 동작: B b1 = 1;과 같은 암시적 변환 및 복사 초기화는 컴파일 에러가 발생합니다. 반면 B b2(2);, B b3{4, 5};와 같은 직접 초기화나 명시적 캐스트 (B)1은 문제없이 컴파일됩니다. 또한 explicit operator bool이 정의되어 있다면 if (b2)처럼 조건식 맥락에서는 유효하지만, bool nb1 = b2;처럼 암시적으로 변환할 때는 에러가 발생하며, static_cast<bool>(b2)처럼 명시적으로 캐스팅해야 정상 동작합니다.

explicit을 붙이지 않으면 어떤 버그가 생기나?

1. 실제 버그 재현 (b.cpp): 아래는 non-explicit 생성자를 사용한 예제입니다. g++ 14.2 -std=c++20 -Wall -Wextra 환경에서 경고 없이 컴파일되고 정상 실행되었습니다.

   #include <cstdio>
   struct Buffer { Buffer(int size) : size(size) {} int size; };
   void resize(Buffer b) { std::printf("Buffer size = %d\n", b.size); }
   int main() { int count = 3; resize(count); }

   실행 결과는 다음과 같습니다.

   Buffer size = 3

   코드 어디에서도 Buffer 객체를 명시적으로 생성하지 않았지만, int 타입 변수인 count가 Buffer로 조용히 변환되어 전달되었습니다.
2. 표준 라이브러리의 설계: std::vector<int> v = 10;이 컴파일되지 않는 이유도 이와 같습니다. 크기를 인자로 받는 vector 생성자가 explicit으로 선언되어 있어 정수 하나로 원소 10개짜리 컨테이너가 의도치 않게 암시적으로 만들어지는 것을 방지합니다.
3. 실제 컴파일 결과: g++ (Debian 14.2.0-19) 14.2.0과 Debian clang 19.1.7에서 -std=c++20 -fsyntax-only 옵션으로 컴파일한 a.cpp입니다.

   #include <memory>
   #include <vector>
   struct Meters { explicit Meters(int v) : value(v) {} int value; };
   void f(Meters m) {}
   int main() {
       Meters a{5};      // OK: direct-initialization
       f(Meters{5});     // OK
       Meters b = 5;     // error
       f(5);             // error
       std::vector<int> v = 10;  // error
       std::unique_ptr<int> p = std::make_unique<int>(1);
       if (p) {}         // OK: explicit operator bool in a condition
       bool ok = p;      // error
   }

   g++ 14.2의 에러 출력입니다.

   a.cpp:8:16: error: conversion from ‘int’ to non-scalar type ‘Meters’ requested
   a.cpp:9:7: error: could not convert ‘5’ from ‘int’ to ‘Meters’
   a.cpp:10:26: error: conversion from ‘int’ to non-scalar type ‘std::vector<int>’ requested
   a.cpp:13:15: error: cannot convert ‘std::unique_ptr<int>’ to ‘bool’ in initialization

   clang 19.1.7의 출력(첫 에러와 관련 노트 포함)입니다.

   a.cpp:8:12: error: no viable conversion from 'int' to 'Meters'
   a.cpp:3:26: note: explicit constructor is not a candidate
   a.cpp:9:5: error: no matching function for call to 'f'
   a.cpp:10:22: error: no viable conversion from 'int' to 'std::vector<int>'

4. 컴파일러가 실제로 어떻게 변환하는지 확인하려면: C++ Insights 활용법 글에서 컴파일러가 임시 객체를 생성하는 과정을 직접 확인하실 수 있습니다.

explicit은 언제 붙이고 언제 빼야 하나?

1. 기본 원칙: 단일 인자 생성자는 원칙적으로 explicit 지정을 우선적으로 고려합니다.
2. 생략해도 되는 경우: std::string의 const char* 생성자는 non-explicit으로 선언되어 있어 std::string s = "abc";와 같은 자연스러운 변환이 가능합니다.
3. explicit operator bool(): if (p), while (p)와 같은 조건문 맥락에서의 평가만 허용하고, bool ok = p;나 int x = p;와 같은 의도치 않은 암시적 변환은 방지합니다. 명시적 변환이 필요할 때는 static_cast<bool>(p)를 사용하실 수 있습니다. 위 a.cpp의 std::unique_ptr가 대표적인 예입니다.
4. C++20 조건부 explicit(bool): explicit(expression)은 컴파일 타임 상수 bool 표현식이 true일 때만 explicit으로 동작하며, 기능 테스트 매크로는 __cpp_conditional_explicit(201806L)입니다. 아래는 g++ 14.2 -std=c++20으로 컴파일한 c.cpp입니다.

   template <class T> struct Wrap {
       template <class U> explicit(!std::is_convertible_v<U, T>) Wrap(U u) : t(u) {}
       T t;
   };
   struct S { explicit S(int) {} };
   int main() { Wrap<long> a = 1; Wrap<S> b = 1; }

   실제 컴파일 에러는 다음 한 줄뿐이었습니다.

   c.cpp:7:44: error: conversion from ‘int’ to non-scalar type ‘Wrap<S>’ requested

   int는 long으로 암시적 변환이 가능하므로 조건식이 false가 되어 explicit(false)로 평가되며, 그 결과 Wrap<long> a = 1;은 문제없이 컴파일됩니다. 반면 S의 생성자는 explicit이어서 int에서 S로의 암시적 변환이 불가능하므로 조건식이 true가 되어 explicit(true)로 동작하며, 오직 Wrap<S> b = 1;만 컴파일 에러로 차단됩니다.

생성자 자체의 기본 개념은 C++ 복사 생성자와 이동 생성자 기본 글에 자세히 정리되어 있습니다.

면접에서 explicit은 어떻게 답하나?

This post examines what explicit blocks and what it permits, based on real compiler output from g++ 14.2 and clang 19.1.7. For the general rules governing implicit conversions, refer to the C++ integer promotion post (Korean).

What is C++ explicit? What is a converting constructor?

1. Official definition: cppreference specifies that explicit "Specifies that a constructor or conversion function (since C++11) or deduction guide (since C++17) is explicit, that is, it cannot be used for implicit conversions and copy-initialization."
2. Converting constructor: According to the cppreference page on converting constructors, a constructor declared without explicit is a converting constructor. Prior to C++11, this referred to a constructor with a single non-default parameter. Since C++11, multi-argument non-explicit constructors also participate in copy-list-initialization. For example, A a4 = {4, 5}; compiles, but if the constructor is marked explicit, B b4 = {4, 5}; produces a compile error.
3. Behavior with an explicit constructor: Copy-initialization such as B b1 = 1; triggers a compile error. Direct-initialization such as B b2(2); and B b3{4, 5};, as well as explicit casts like (B)1, are valid. Similarly, with an explicit operator bool, evaluating the object in a condition like if (b2) works, whereas an implicit conversion like bool nb1 = b2; fails with a compile error; explicit casting with static_cast<bool>(b2) is required.

What bugs can happen without explicit?

1. A real bug demo (b.cpp): The following example uses a non-explicit constructor. Under g++ 14.2 -std=c++20 -Wall -Wextra, it compiled cleanly without warnings and executed:

   #include <cstdio>
   struct Buffer { Buffer(int size) : size(size) {} int size; };
   void resize(Buffer b) { std::printf("Buffer size = %d\n", b.size); }
   int main() { int count = 3; resize(count); }

   The output is:

   Buffer size = 3

   No statement explicitly created a Buffer, yet the int variable count was silently converted into one.
2. Standard library design: This is precisely why std::vector<int> v = 10; does not compile. The size-taking constructor of std::vector is declared explicit, preventing a single integer from unintentionally initializing a 10-element container.
3. Actual compile output: Here is a.cpp, compiled using g++ (Debian 14.2.0-19) 14.2.0 and Debian clang 19.1.7 with -std=c++20 -fsyntax-only:

   #include <memory>
   #include <vector>
   struct Meters { explicit Meters(int v) : value(v) {} int value; };
   void f(Meters m) {}
   int main() {
       Meters a{5};      // OK: direct-initialization
       f(Meters{5});     // OK
       Meters b = 5;     // error
       f(5);             // error
       std::vector<int> v = 10;  // error
       std::unique_ptr<int> p = std::make_unique<int>(1);
       if (p) {}         // OK: explicit operator bool in a condition
       bool ok = p;      // error
   }

   g++ 14.2 error output:

   a.cpp:8:16: error: conversion from ‘int’ to non-scalar type ‘Meters’ requested
   a.cpp:9:7: error: could not convert ‘5’ from ‘int’ to ‘Meters’
   a.cpp:10:26: error: conversion from ‘int’ to non-scalar type ‘std::vector<int>’ requested
   a.cpp:13:15: error: cannot convert ‘std::unique_ptr<int>’ to ‘bool’ in initialization

   clang 19.1.7 output (first error and notes):

   a.cpp:8:12: error: no viable conversion from 'int' to 'Meters'
   a.cpp:3:26: note: explicit constructor is not a candidate
   a.cpp:9:5: error: no matching function for call to 'f'
   a.cpp:10:22: error: no viable conversion from 'int' to 'std::vector<int>'

4. Inspecting compiler-generated conversions: To see how the compiler instantiates temporary objects under the hood, visit the C++ Insights post (Korean).

When should you use or omit explicit?

1. Default rule: For single-argument constructors, default to marking them explicit.
2. When it is fine to omit: The const char* constructor of std::string is non-explicit, which allows std::string s = "abc"; to work naturally.
3. explicit operator bool(): It enables boolean checks in conditional contexts such as if (p) and while (p) while preventing unintended implicit conversions like bool ok = p; and int x = p;. Explicit conversions using static_cast<bool>(p) remain available. The std::unique_ptr in a.cpp above is an example.
4. C++20 conditional explicit(bool): explicit(expression) makes the constructor explicit only when the constant bool expression evaluates to true; the feature-test macro is __cpp_conditional_explicit (201806L). Below is c.cpp, compiled with g++ 14.2 -std=c++20:

   template <class T> struct Wrap {
       template <class U> explicit(!std::is_convertible_v<U, T>) Wrap(U u) : t(u) {}
       T t;
   };
   struct S { explicit S(int) {} };
   int main() { Wrap<long> a = 1; Wrap<S> b = 1; }

   The only compile error was this single line:

   c.cpp:7:44: error: conversion from ‘int’ to non-scalar type ‘Wrap<S>’ requested

   Because int converts implicitly to long, the condition evaluates to explicit(false), and Wrap<long> a = 1; compiles without issue. In contrast, S has an explicit constructor, so int cannot implicitly convert to S; the condition evaluates to explicit(true), blocking only Wrap<S> b = 1;.

For the fundamentals of constructors themselves, see the copy and move constructor basics post (Korean).

How do you answer explicit questions in an interview?

최근 유럽 슈퍼마켓 냉장 설비가 원격으로 조작돼 자동 제상이 켜진 사건이 Hacker News 토론에서 화제가 되었습니다. 이 글에서는 특정 사건을 분석하기보다는, 임베디드 개발자가 임베디드 IoT 보안 관점에서 알아두어야 할 핵심 방어 원칙을 정리해 드립니다.

임베디드 IoT 보안이란? 임베디드 기기는 PC와 무엇이 다른가?

1. 긴 수명 주기: 일반 PC와 달리 산업용·상업용 컨트롤러는 한 번 설치되면 현장에서 오랫동안 계속 가동됩니다. 이에 따라 제품 출시 당시의 보안 수준이 취약한 상태 그대로 장기간 유지되기 쉽습니다.
2. 어려운 업데이트: 디스플레이나 입력 장치가 없고 현장 곳곳에 흩어져 있어 소프트웨어 패치 적용이 까다롭습니다. 원격 업데이트 체계가 미흡하면 사소한 업데이트 실패도 곧바로 현장 출동으로 이어집니다.
3. 물리적 분산 배치: 통제된 전산실이 아니라 천장, 배전반, 실외기 등 일상적인 감시가 닿지 않는 열악한 현장에 분산 설치됩니다.
4. 물리적 영향: 데이터 연산이나 표시에 그치지 않고 냉각기, 히터, 밸브, 모터 같은 물리 설비를 직접 구동합니다. 침해 사고가 발생하면 곧바로 설비 오동작이나 물리적 피해로 직결될 수 있습니다.
5. 규제 동향: EU Cyber Resilience Act(CRA) 공식 페이지에 따르면 이 법은 2024년 12월 10일에 발효되었으며, 주요 의무는 2027년 12월 11일부터, 적극적으로 악용되는 취약점에 대한 제조업체의 보고 의무는 2026년 9월 11일부터 적용됩니다.

임베디드 기기는 주로 어떤 경로로 뚫리나?

6. 일반적인 공격 흐름: HN 토론에 따르면, 원격 공격자는 인터넷 전체를 스캔해 기기를 찾아주는 검색 엔진 등으로 공용 인터넷에 열린 관리 화면을 먼저 식별하고, 인증이 없거나 우회할 수 있는 취약한 인터페이스를 노립니다. 본문에서는 방어 원칙에 집중하며, 공격 재현 방법이나 세부 익스플로잇 코드는 다루지 않습니다.
7. OWASP IoT Top 10 매핑: OWASP Internet of Things 프로젝트의 2018년 판(2018 Edition) 기준 목록과 대조해 보면 다음과 같은 취약점에 해당합니다.
   • I1 Weak, Guessable, or Hardcoded Passwords: 공통 기본 비밀번호, 날짜 등으로 만들어진 예측 가능한 백도어 및 서비스 코드
   • I2 Insecure Network Services: 방화벽 없이 공용 인터넷에 그대로 열려 있는 불필요한 네트워크 서비스
   • I3 Insecure Ecosystem Interfaces: 인증 없이 노출된 관리 API, 인증 우회가 가능한 엔드포인트
   • I4 Lack of Secure Update Mechanism: 서명 검증이 없는 펌웨어 업데이트 체계, 패치되지 않은 채 방치된 펌웨어
   • I5 Use of Insecure or Outdated Components: 취약점이 알려진 오래된 커널 및 구형 라이브러리 등 안전하지 않은 컴포넌트 사용
   • 나머지 항목: I6 Insufficient Privacy Protection, I7 Insecure Data Transfer and Storage, I8 Lack of Device Management, I9 Insecure Default Settings, I10 Lack of Physical Hardening
8. 취약점이 연쇄적으로 작용하는 경우: 인터넷 노출(I2), 기본 설정 방치(I9), 기본 또는 예측 가능한 비밀번호(I1), 인증 우회(I3)가 결합되면, 원격 공격자가 관리 화면에 진입하여 설비를 직접 조작하는 명령까지 내릴 수 있게 됩니다. 단일 결함 자체보다 여러 기본 설정 미비가 이어지는 취약점 체인이 더 위험할 수 있습니다.

개발자는 설계할 때 무엇을 막아야 하나?

9. 기기별 고유 초기 비밀번호와 변경 강제: 제품군 전체에 동일한 기본 비밀번호를 사용하지 않고 기기마다 고유한 초기 비밀번호를 부여하며, 첫 부팅 시 관리자 비밀번호를 재설정하기 전에는 주요 기능이 동작하지 않도록 강제합니다(I1, I9 대응).
10. 관리 인터페이스의 인터넷 직접 노출 차단: 웹 관리 UI나 원격 셸을 0.0.0.0에 열지 않고 127.0.0.1 또는 전용 관리망 인터페이스에만 바인딩합니다. 외부 접근은 반드시 VPN과 방화벽 뒤로 격리합니다(I2 대응).
11. 읽기와 쓰기 권한 분리: 센서 측정값은 모니터링 서버로 한 방향으로만 전달하고, 필요한 경우 데이터 다이오드(Data Diode) 같은 물리적·논리적 단방향 링크를 구성합니다. 설비를 직접 조작하는 쓰기(제어) 권한은 현장 직접 접속이나 엄격히 인증된 내부망으로 한정합니다.
12. 서명된 펌웨어 업데이트와 알림: 암호화 서명이 검증된 펌웨어만 플래시에 기록되도록 제한하고, 새로운 보안 업데이트가 있을 때 관리자에게 명확히 알립니다(I4 대응).
13. 최소 권한 원칙과 로깅: 시스템 데몬에는 운영에 필요한 최소한의 권한만 부여하고, 외부 접속 시도와 인증 성공·실패 이벤트를 로그로 기록하여 추적성을 유지합니다.

현장 기기에서 펌웨어 오동작이나 비정상 종료를 디버깅할 때는 임베디드 리눅스 gdb 크래시 분석 글도 함께 참고하실 수 있습니다.

운영 중인 기기는 어떻게 점검하나? (체크리스트)

14. 열려 있는 외부 노출 포트 확인: 리눅스 기기 내부에서 ss -tlnp를 실행해 어떤 프로세스가 어느 IP 주소와 포트에서 대기(LISTEN)하는지 확인합니다. 기기 외부에서 스캔할 때는 반드시 본인이 점검 권한을 가진 네트워크에서, 자체 스캐너로만 진행해야 합니다.
15. 기본 계정 및 테스트 계정 제거: 출하 시 기본으로 포함된 테스트 계정이나 제조사 공통 비밀번호를 완전히 삭제하거나 비활성화합니다.
16. 펌웨어 버전 대조: 운영 중인 펌웨어 버전을 제조사의 최신 보안 권고(Advisories)와 정기적으로 대조합니다.
17. 원격 접속 로그 정기 검토: 반복되는 인증 실패 기록이나 허가되지 않은 외부 IP에서의 접근 시도가 없는지 시스템 로그를 면밀히 점검합니다.
18. 실제 출력 확인 (iproute2-6.15.0 ss): 로컬 환경에서 테스트용 HTTP 서버 두 개를 실행해 0.0.0.0과 127.0.0.1의 차이를 직접 확인한 실제 출력입니다. 하나는 0.0.0.0, 다른 하나는 127.0.0.1에 바인딩했습니다.

    python3 -m http.server 18080 --bind 0.0.0.0 &
    python3 -m http.server 18081 --bind 127.0.0.1 &
    ss -tln

    이 두 포트만 걸러낸 실제 출력 결과는 다음과 같습니다.

    State  Recv-Q Send-Q Local Address:Port  Peer Address:Port
    LISTEN 0      5          127.0.0.1:18081      0.0.0.0:*
    LISTEN 0      5            0.0.0.0:18080      0.0.0.0:*

19. 출력 결과 해석: 0.0.0.0:18080은 기기의 모든 네트워크 인터페이스에서 연결 요청을 수신 대기한다는 뜻이므로, 방화벽이 없다면 외부 네트워크 어디서든 직접 접근할 수 있어 위험합니다. 반면 127.0.0.1:18081은 루프백 인터페이스에만 바인딩되어 해당 기기 내부에서만 접근할 수 있습니다. 따라서 불필요한 서비스는 종료하거나 바인딩 주소를 127.0.0.1로 제한해야 하며, 실행 중인 구체적인 프로세스는 ss -tlnp 명령으로 확인할 수 있습니다.

임베디드 리눅스 툴체인 구성과 빌드 환경에 대한 내용은 이후 다룰 「크로스 컴파일이란?」 글을 참고하시기 바랍니다.

A recent incident where supermarket refrigeration systems across Europe were remotely triggered into automatic defrosting was discussed in a Hacker News thread. Rather than analyzing that specific incident, this post outlines the general defensive principles that embedded developers can apply to safeguard connected devices.

What is embedded IoT security? How do embedded devices differ from PCs?

1. Long lifecycle: Unlike conventional PCs, industrial and commercial controllers often remain active in the field for years once installed. The security posture established at product launch often persists unchanged throughout the device's operational life.
2. Difficult update process: These devices rarely have screens, keyboards, or accessible input interfaces, and they are dispersed across remote sites. If the remote update mechanism is unreliable, an update failure often necessitates an on-site service visit.
3. Physically distributed deployment: Rather than residing in climate-controlled server rooms with physical access controls, devices are mounted in ceilings, electrical switchboards, or outdoor compressor units, making regular physical monitoring impractical.
4. Direct physical impact: Embedded controllers do not merely process or display data; they directly actuate chillers, heaters, valves, and motors. A security breach can directly trigger physical equipment malfunction or operational disruptions.
5. Regulatory landscape: According to the official EU Cyber Resilience Act (CRA) portal, the regulation entered into force on 10 December 2024. Its core obligations take effect on 11 December 2027, while mandatory reporting of actively exploited vulnerabilities applies earlier, as of 11 September 2026.

How are embedded devices primarily compromised?

6. Common attack vectors: According to discussions on Hacker News, remote attackers typically use internet-wide device scanning engines to discover management web interfaces exposed directly to the public internet, subsequently targeting interfaces that lack authentication or feature authentication bypass flaws. This post focuses on defensive posture and does not cover exploit reproduction or attack payloads.
7. Mapping to the OWASP IoT Top 10 (2018 Edition): Aligning these common attack paths with the 2018 edition of the OWASP Internet of Things Project highlights several key categories:
   • I1 Weak, Guessable, or Hardcoded Passwords: Shared factory default credentials, or predictable service codes derived from timestamps or static patterns.
   • I2 Insecure Network Services: Unnecessary listening network services exposed directly to the public internet without firewall protection.
   • I3 Insecure Ecosystem Interfaces: Management APIs accessible without authentication, or endpoints vulnerable to authentication bypass.
   • I4 Lack of Secure Update Mechanism: Firmware updates accepted without cryptographic signature verification, or devices left unpatched.
   • I5 Use of Insecure or Outdated Components: Outdated kernels, vulnerable third-party libraries, and deprecated software components.
   • Remaining categories: I6 Insufficient Privacy Protection, I7 Insecure Data Transfer and Storage, I8 Lack of Device Management, I9 Insecure Default Settings, and I10 Lack of Physical Hardening.
8. Chained vulnerabilities: When direct internet exposure (I2), insecure default settings (I9), and default credentials (I1) or an authentication bypass (I3) coincide, an external attacker can gain administrative access and dispatch control commands directly to operating equipment. A chain of weak defaults is often more dangerous than any single flaw.

What must developers prevent during the design phase?

9. Per-device unique initial passwords with forced change: Avoid universal factory passwords across product lines. Require administrators to configure a new password during initial setup before operational features become active (mitigating I1 and I9).
10. Prevent internet exposure of management interfaces: Never bind administrative web consoles or management shells to 0.0.0.0. Restrict listening sockets to 127.0.0.1 or a dedicated internal management network, placing all remote management access strictly behind a VPN and firewall (mitigating I2).
11. Architectural separation of telemetry and control: Send sensor measurements outward to telemetry servers over one-way connections, employing data diodes or unidirectional gateways where appropriate. Restrict write commands that operate physical actuators strictly to local on-site interfaces or tightly authenticated internal management networks.
12. Cryptographically signed firmware updates and user alerts: Ensure the bootloader and update daemon verify digital signatures before writing firmware images to flash memory, and provide clear notifications when security patches are released (mitigating I4).
13. Principle of least privilege and comprehensive logging: Execute background daemons with minimal operating system privileges, and record all external connection attempts and authentication events to facilitate security audits.

When debugging firmware misbehavior or abnormal exits on a field device, the post on embedded Linux gdb crash analysis (Korean) may also help.

How should operational devices be audited? (Checklist)

14. Check listening ports and network sockets: Run ss -tlnp on the Linux device to see which process is listening on which address. When checking from outside the device, use your own scanner and only test networks you are authorized to evaluate.
15. Remove default and test accounts: Purge test accounts and shared default passwords that shipped with the device.
16. Compare firmware versions: Cross-reference the current firmware version against published vendor security bulletins and advisories.
17. Review remote-access logs: Inspect authentication logs for repeated login failures or connection requests from unfamiliar external IP addresses.
18. Actual output (iproute2 6.15 ss): Two local HTTP test servers show the difference between binding to 0.0.0.0 and 127.0.0.1: one bound to 0.0.0.0, the other to 127.0.0.1.

    python3 -m http.server 18080 --bind 0.0.0.0 &
    python3 -m http.server 18081 --bind 127.0.0.1 &
    ss -tln

    The actual output, filtered to these two ports:

    State  Recv-Q Send-Q Local Address:Port  Peer Address:Port
    LISTEN 0      5          127.0.0.1:18081      0.0.0.0:*
    LISTEN 0      5            0.0.0.0:18080      0.0.0.0:*

19. Reading the output: 0.0.0.0:18080 means it accepts connections on every interface of the device, so without a firewall it is reachable from anywhere on the network. 127.0.0.1:18081 is reachable only from the device itself. Turn off unnecessary services or change their bind address to 127.0.0.1, and use ss -tlnp to identify which process owns each listening socket.

For toolchain setup and compilation workflows, see the upcoming post "What is cross-compilation?" (Korean title: 「크로스 컴파일이란?」).

이 글에는 제휴 링크가 포함되어 있으며, 링크를 통해 가입하시면 운영자에게 수수료가 발생할 수 있습니다. 구독 할인 경로에 대한 자세한 안내는 GoingBus 허브 글에서 확인하실 수 있습니다.

ChatGPT Plus와 SuperGrok 공식 가격은 어디서 확인할까?

한 줄 답: ChatGPT Plus 싸게 이용하는 방법을 찾으시더라도, 기준이 되는 공식 요금과 SuperGrok 가격은 각 서비스의 공식 웹페이지에서 직접 확인하시는 것이 가장 정확합니다.

• ChatGPT Plus: Plus는 월 $20입니다(발행일 기준, OpenAI 도움말 센터). 요금제 비교는 chatgpt.com/pricing에서 확인하실 수 있습니다. OpenAI 도움말에 따르면 Plus는 월 단위로 결제되며 연간 결제 옵션은 제공되지 않습니다. 공식 요금제 FAQ에는 개인 사용을 전제로 한 플랜("Go, Free, and Plus plans are designed to be used by individuals")이라고 명시되어 있습니다.
• SuperGrok: x.ai/grok 공식 안내 페이지에서 높은 사용 한도와 다중 에이전트 추론("Upgrade to SuperGrok for higher limits and multi-agent reasoning")을 내세우고 있으며, "Get SuperGrok" 구독 버튼이 있습니다. 이 페이지에는 금액이 표시되어 있지 않아 이 글에는 SuperGrok 금액을 적지 않았습니다.
• 요금제 이름 변화: 발행일 기준 SuperGrok이라는 이름은 x.ai/grok 페이지에는 그대로 보이지만, x.ai/pricing 요금 페이지에는 보이지 않고 Free·Plus·Premium·Super·Ultra 요금제로 표시됩니다.
• 유의할 점: 요금은 접속 지역이나 세금에 따라 달라질 수 있습니다. 결제 전 공식 페이지의 최신 표기를 반드시 확인하시기 바랍니다.

ChatGPT Plus 요금제 상세 설명과 구체적인 활용법은 앞서 정리한 ChatGPT Plus 요금·쓰는 법 글을 참고해 주시기 바랍니다.

VPN으로 우회가입하면 왜 어려울까?

한 줄 답: 결제 승인, 계정 유지, 이용 약관 등 여러 단계에서 막힐 위험이 크기 때문입니다. 본 글에서는 우회 가입 방법을 안내하지 않으며, 이용 시 맞닥뜨릴 수 있는 난점만 전달해 드립니다.

• 결제 승인 거절: 결제 수단에 등록된 국가 정보와 접속 지역이 일치하지 않으면 결제 승인이 거절될 수 있습니다.
• 계정 제한 가능성: 접속 환경과 결제 정보의 불일치가 감지되면 계정이 제한될 수 있으며, 기존 대화 내역에 접근하기 어려워질 수 있습니다.
• 약관 위반 위험: 비정상적인 우회 경로는 서비스 이용 약관상 문제가 될 수 있습니다. 구체적인 규정은 각 서비스의 공식 이용 약관을 확인하셔야 합니다.
• 환불·지원 어려움: 변칙적인 경로로 가입한 경우 결제 오류나 서비스 장애가 발생하더라도 정상적인 환불이나 공식 고객지원을 받기 어려워질 수 있습니다.

위 내용은 발생할 수 있는 주요 위험을 정리한 것이며, 실제 제재 여부와 조치 수위는 각 서비스 운영 정책에 따라 결정됩니다.

공식 결제가 부담스럽다면 어떤 대안이 있을까?

한 줄 답: 구독 비용 부담을 덜어주는 제3자 플랫폼 공유 경로가 대안으로 꼽히지만, 공식 서비스가 아니라는 점과 주의사항을 충분히 고려하신 후 판단하셔야 합니다.

• 해당 경로는 OpenAI나 xAI에서 직접 운영하는 공식 플랜이 아니며 제3자 플랫폼을 통해 제공됩니다.
• 계정을 공유하는 구조일 경우 개인 사용을 원칙으로 하는 서비스 이용 약관과 충돌할 소지가 있습니다.
• 공유 계정 환경에서는 보안과 개인정보 보호를 위해 민감한 업무 자료나 개인적인 대화 내용을 다루지 않는 것이 안전합니다.
• 제공 조건이나 이용 요금은 플랫폼 상황에 따라 달라질 수 있습니다.

구체적인 이용 방식과 주의사항은 글 맨 아래 허브 글에 정리해 두었습니다.

자주 묻는 질문은?

구독 할인 경로의 구체적인 이용 절차와 주의사항은 GoingBus 허브 글에서 자세히 확인하실 수 있습니다.

This post contains an affiliate link; the author may earn a commission if you sign up through it. For details on subscription discount routes, see the GoingBus hub post.

Where can you check the official prices for ChatGPT Plus and SuperGrok?

Short answer: Even when looking for ways to get ChatGPT Plus for less, the official website for each service is always the most accurate place to check current baseline rates.

• ChatGPT Plus: Plus is $20/month (as of the publish date, OpenAI Help Center). Plan comparisons are at chatgpt.com/pricing. According to the OpenAI Help Center, Plus is billed monthly with no annual billing option. The official pricing FAQ also notes that "Go, Free, and Plus plans are designed to be used by individuals," meaning Plus is intended strictly for personal use.
• SuperGrok: The official x.ai/grok page invites users to "Upgrade to SuperGrok for higher limits and multi-agent reasoning." and has a "Get SuperGrok" button. That page shows no amount, so this post gives no SuperGrok price.
• Plan name change: As of the publish date, the SuperGrok name still appears on the x.ai/grok page, but the x.ai/pricing page does not show it and lists Free, Plus, Premium, Super and Ultra plans instead.
• Important note: Prices can differ by region and local taxes, so always check the latest figures on the official pages before purchasing.

For a detailed breakdown of the ChatGPT Plus plan and features, see our earlier guide: ChatGPT Plus pricing and usage.

Why are VPN signups hard?

Short answer: Because you risk running into roadblocks at payment processing, account verification, and terms-of-service enforcement. This guide does not provide signup instructions, but outlines the practical hurdles involved.

• Declined payment processing: Payments are often rejected when the billing country of your payment method does not match your connection region.
• Account restriction risk: A mismatch between your connection details and billing profile can trigger account reviews or restrictions, potentially locking you out of your chat history.
• Terms-of-service issues: Attempting to bypass regional restrictions can be problematic under each platform's terms of service. Review the official terms of each provider for exact rules.
• Harder refunds and support: If issues arise with an account created through irregular channels, getting official support or a refund can become much harder.

These points represent potential risks, and actual enforcement measures depend on each service provider's policies.

If official payment feels like a burden, what alternatives are there?

Short answer: Third-party subscription-sharing platforms are often considered as alternatives, but you should weigh the trade-offs and non-official nature of these services carefully before deciding.

• These options are offered by third-party platforms rather than directly by OpenAI or xAI.
• Shared account arrangements may conflict with terms of service designed around individual use.
• For privacy and security, avoid handling confidential work materials or sensitive conversations on shared accounts.
• Availability, platform terms, and pricing structures can change at any time.

Specific usage instructions and key precautions are detailed in the hub post at the bottom of this article.

What are the frequently asked questions?

To learn more about how subscription discount routes work and what to consider, continue reading in the GoingBus hub post.

이 글은 온라인으로 진행되는 평가를 준비하면서 정리한 학습 방법과, 온라인 감독 시험 환경을 점검하는 일반적인 체크리스트를 한 편으로 묶은 것입니다. 시험마다 운영 방식이 다르므로, 환경 점검과 관련된 내용은 일반적인 준비 사항으로만 참고해 주시기 바랍니다.

AI 기초 개념과 학습 범위는 어떻게 정리했을까?

1. 학습 범위의 순서: AI 기본기 → 머신러닝(지도·비지도·강화학습, 과적합, 데이터 분할) → 딥러닝 → 트랜스포머와 LLM → LLM의 한계(할루시네이션) → 임베딩과 RAG → 에이전트와 외부 도구 → AI 반도체·윤리·보안 순으로 공부했고, 부족한 주제는 필요할 때마다 추가하여 보완했습니다.
2. 지도학습: 정답(라벨)이 포함된 데이터를 바탕으로 입력과 출력 사이의 대응 관계를 학습하는 방식입니다.
3. 비지도학습: 정답 라벨 없이 데이터 자체에 내재된 패턴이나 군집을 찾아내는 방식입니다.
4. 강화학습: 주어진 환경 안에서 시행착오를 거치며 보상을 극대화하는 최적의 행동 방식을 익히는 방법입니다.
5. 과적합: 학습 데이터를 지나치게 암기하여 새로운 데이터가 주어졌을 때 예측이나 처리 성능이 떨어지는 현상입니다.
6. 데이터 누수: 평가나 정답 영역의 정보가 학습 과정에 미리 흘러 들어가 실제보다 점수가 더 좋게 나타나는 현상입니다. 예를 들어 전체 데이터셋에 전처리를 먼저 적용한 뒤 학습용과 평가용으로 분할하면 데이터 누수가 발생할 수 있습니다.
7. 개념을 이해하는 방식: 복잡한 수학 공식에 매몰되기보다 일상적인 쉬운 언어와 직관적인 예시를 먼저 활용했고, AI 반도체 관점에서 데이터와 연산의 흐름을 짚어 보며 전체적인 구조를 파악했습니다.

개념을 온전히 익히는 공부 루프는 어떻게 구성했을까?

1. 짧은 설명: 핵심 개념을 일상적인 쉬운 표현으로 간결하게 풀어 정리합니다.
2. 퀴즈 풀기: 개념을 제대로 이해했는지 스스로 점검할 수 있는 문제를 풀어 봅니다.
3. 내 답 먼저 쓰기: 해설을 확인하기 전에 나만의 논리와 언어로 답안을 먼저 작성합니다.
4. 해설과 비교 및 토론: 내 답과 모범 해설의 차이를 꼼꼼히 비교하고, 왜 다른 결론이 나왔는지 논리적으로 짚어 봅니다.
5. 실습: 실제 작업 환경에서 해당 개념을 직접 적용하고 다루어 봅니다.
6. 핵심 요약: 마지막으로 새롭게 알게 된 핵심 내용을 몇 줄로 압축하여 정리합니다.

이 루프를 실천하면서 가장 엄격하게 지킨 원칙은 바로 해설이나 정답을 먼저 보지 않는다는 점이었습니다. 먼저 스스로 고민하고 답을 적어 보는 습관이 사고력을 단련하고 개념을 온전히 내 것으로 만드는 데 큰 밑거름이 되었습니다.

AI에게 작업을 맡길 때 어떤 4단계 루틴을 적용했을까?

1. 범위·기준·근거·형식 명확화: 참조할 자료와 작업 범위(범위), 무엇을 올바른 완료 기준으로 삼을지(기준), 각 주장의 바탕이 되는 출처 위치(근거), 결과를 도출할 단일 출력 포맷(형식)을 사전에 분명하게 제시합니다. 공통 자료가 주어지면 먼저 정독하여 기준표와 핵심 과제를 파악합니다.
2. 조건 쪼개기: 복합적인 요구사항은 단일 조건들로 분리하여 전달하고, 결과물은 조건별로 하나의 열을 배정한 표 형태로 요청합니다. 이렇게 구성하면 누락된 조건이 빈칸이나 처리 실패 열로 즉시 식별됩니다. 특정 열을 제외하라고 지시할 때는 대체하여 사용할 기준값도 함께 명시합니다.
3. 검산하기: 행 개수가 일치하는지 대조하고(예: 전체 − 중복 = 최종), 반례 탐색을 요청하며, 경계값을 대입하여 결과를 확인합니다. "결과 숫자만 출력하라"고 요구하기보다는 처리 과정을 먼저 서술하게 한 뒤 마지막 줄에 최종 결과를 제시하도록 설정합니다.
4. 일반적인 작업 원칙: 파일을 첨부하는 것만으로 충분하다고 넘겨짚지 말고, 필요한 모든 조건을 명확한 글로 적어 전달합니다. 중복 데이터 처리 규칙은 사전에 정해 두며, 다뤄야 할 자료의 분량이 방대하다면 각 영역을 동일한 표 규격으로 요약한 다음 최종 병합합니다.

실전 감각을 기르기 위해 어떤 환경과 도구로 연습했을까?

1. 실제와 동일한 환경에서 연습: 실제 평가에서 사용할 동일한 기기, 브라우저, 책상 조건에서 직접 작업을 수행해 보았습니다. 단순히 눈으로만 읽은 내용은 직접 실행해 볼 때 생각지 못한 빈틈이 드러나기 마련입니다.
2. 직접 제작한 개인 연습용 페이지: 앞서 정리한 작업 습관(자료 요약, 조건별 교차 검증, 표 정리 등)을 몸에 익히고자, 스스로 구상한 가상의 연습 상황을 담은 작은 개인 웹페이지를 만들어 훈련했습니다. 이는 일반적인 작업 역량을 기르고자 개인적으로 고안한 도구일 뿐이며, 특정 시험을 본떠 만든 것이 아닙니다. 이 글에서는 링크를 따로 걸지 않습니다.

온라인 감독 앱 모니토(Monito)는 사전에 어떻게 준비해야 할까?

1. 서비스 소개: 모니토는 온라인 시험 감독 서비스로, 공식 웹사이트에 따르면 화면 공유, 웹캠, 스마트폰을 활용하여 응시자의 정면, 측면, 모니터 화면까지 다각도로 확인합니다. 아울러 응시 영상은 녹화되어 보관된다고 안내되어 있습니다.
2. 이용 방식: 시험 초대를 받은 사용자를 위한 앱이므로, 초대받은 시험 링크를 통해 이용합니다. App Store 모니토앱 안내에 기재된 기본 이용 순서는 다음과 같습니다.
   • 초대받은 시험 링크에 접속한 뒤 화면에 나타나는 QR 코드를 스마트폰으로 스캔하여 연결합니다.
   • 화면 안내에 따라 시험 전 준비 절차를 순서대로 진행합니다.
   • 시험이 종료될 때까지 앱을 종료하지 않고 계속 실행 상태로 유지합니다.
3. 필수 권한 및 사양: 응시자 녹화를 위한 카메라 권한과 녹화 중 음성 확인을 위한 마이크 권한이 필요하며, App Store 기준 iOS 16.4 이상 환경이 요구됩니다.
4. 사전 확인 필수 사항: 시험마다 구체적인 운영 절차가 다를 수 있으므로, 세부적인 설치 및 환경 점검 방법은 응시하시는 시험의 공식 안내를 반드시 최우선으로 확인해 주시기 바랍니다.

스마트폰 설정과 PC 환경은 어떻게 점검할까?

1. 스마트폰 거치대: App Store 주의사항에 명시된 바와 같이, 스마트폰의 위치를 안정적으로 고정할 수 있는 거치대(스탠드)를 사전에 마련합니다.
2. 방해 금지 모드: 통화나 일반 문자 수신 시 영상 감독이 중단될 수 있으므로 사전에 방해 금지 모드를 활성화합니다.
3. 긴급 알림 외 알림 비활성화: 재난 문자 등 긴급 안내 수신으로도 영상 감독이 멈출 수 있어, 필수적인 긴급 알림 외의 일반 알림 항목은 미리 꺼 둘 것을 권장하고 있습니다.
4. 충전기 상시 연결: 지속적인 영상 녹화로 배터리 소모가 빠르게 발생하므로 시험 시작 전에 충전기를 반드시 연결해 둡니다.
5. PC 점검(일반 권고): 이는 모니토 공식 사양이 아닌 일반적인 사전 준비 사항입니다. 시험 안내서가 지정한 브라우저를 최신 버전으로 업데이트하고, 시험과 무관한 백그라운드 프로그램은 모두 종료하며, 웹캠·마이크·화면 공유 권한이 정상 허용되어 있는지 재확인하고 노트북 전원 케이블을 연결합니다.
6. 네트워크 환경(일반 권고): 유선 인터넷이나 안정적인 와이파이를 확보하고, 시험 규정상 허용되는 경우에 한해서만 모바일 핫스팟 등 비상 대안을 점검합니다.
7. 사전 환경 테스트 참여: 주최 측에서 사전에 환경 테스트 기회를 제공한다면 반드시 참여하여 기기와 네트워크 설정을 사전 검증합니다.

스마트 안경 관련 주의사항과 종합 체크리스트는 무엇일까?

최근 국내 시험에서 스마트 안경을 이용한 부정행위가 적발됐다는 뉴시스 보도가 있었습니다(시험장 시험 사례). 이는 온라인 시험이 아닌 오프라인 시험장 사례이지만, 온라인 감독 시험에서도 안경 상태 확인을 요청받을 수 있으므로 미리 보여 줄 준비를 해 두는 것이 좋습니다.

1. 모니토 앱을 공식 스토어에서 사전에 설치하고 카메라와 마이크 권한을 허용합니다(App Store 기준 iOS 16.4 이상).
2. 웹캠과 스마트폰 거치대의 위치를 설정합니다. 배치 방법은 응시하는 시험의 안내를 따릅니다.
3. 사전 환경 테스트가 제공되는 경우 빠짐없이 참여하여 확인합니다.
4. 브라우저 및 PC: 시험 안내서가 권장하는 브라우저를 최신으로 업데이트하고, 불필요한 프로그램을 종료하며, 화면 공유 권한을 확인합니다.
5. 네트워크: 끊김 없는 유선 또는 무선 연결을 확보하고, 규정상 허용되는 범위 내에서 비상 통신 수단을 점검합니다.
6. 전원 충전: 스마트폰(App Store 권장)과 노트북 모두 충전 케이블을 안정적으로 연결해 둡니다.
7. 스마트폰 알림 제어: 방해 금지 모드를 켜고, 필수가 아닌 알림은 모두 비활성화합니다.
8. 안경 점검: 안경을 착용한다면 요청을 받으면 카메라에 바로 보여 줄 수 있도록 준비합니다.
9. 시험 당일: 일정보다 여유 있게 접속을 완료하고, 시험이 완전히 끝날 때까지 앱을 정상 실행 상태로 유지합니다.

정직한 응시와 공식 안내 준수가 왜 가장 중요할까?

1. 부정행위는 절대 시도하지 않습니다: 어떠한 형태의 부정행위 시도도 시험 무효 및 실격 처리 등 심각한 제재와 불이익으로 이어질 수 있습니다.
2. 시험 환경을 꼼꼼히 점검합니다: 응시 기기, 거치대 각도, 네트워크, 알림 상태를 사전에 세팅해 두면 불필요한 의심이나 기술적인 결함을 사전에 방지할 수 있습니다.
3. 공식 안내 사항을 최우선으로 따릅니다: 시험마다 세부적인 감독 규정과 환경 기준이 상이하므로, 반드시 본인이 응시하는 시험의 공식 안내 지침을 정확히 확인하고 준수해 주시기 바랍니다.

This post brings together the study routine I developed while preparing for an online assessment along with a general checklist for verifying an online proctored exam environment. Because testing procedures vary across organizations, please use the second half strictly as general preparation guidance.

How did I organize AI fundamentals and study scope?

1. Progression of study topics: AI fundamentals → machine learning (supervised, unsupervised, and reinforcement learning; overfitting; train/val/test data splits) → deep learning → Transformers and LLMs → LLM limitations (hallucination) → embeddings and RAG → agents and external tools → AI chips, ethics, and security. I added focused review sessions whenever I encountered weak areas.
2. Supervised learning: Learning the mapping relationship between inputs and outputs using datasets that provide ground-truth labels.
3. Unsupervised learning: Discovering underlying patterns, structures, or groupings within data without pre-existing labels.
4. Reinforcement learning: Learning optimal action strategies through trial and error within an environment to maximize cumulative reward.
5. Overfitting: Memorizing training data so rigidly that the model fails to generalize effectively to new, unseen data.
6. Data leakage: Information from the test or target dataset inadvertently leaking into the training pipeline, causing evaluation metrics to appear artificially inflated. For instance, applying data preprocessing across the entire dataset before splitting it into training and evaluation sets can cause this issue.
7. Core approach to comprehension: Rather than getting bogged down in heavy mathematical formulas, I prioritized intuitive explanations and relatable everyday examples, while examining compute structures from an AI-chip perspective to grasp the overall architecture.

What study loop did I use to really learn the concepts?

1. Short explanation: Break down the core concept into simple, everyday language.
2. Quiz yourself: Tackle questions designed to evaluate whether you truly grasp the underlying principles.
3. Write your own answer first: Articulate your reasoning and write out a complete answer before opening the official explanation.
4. Compare and discuss: Identify divergences between your answer and the provided solution, analyzing why the differences occurred.
5. Hands-on practice: Apply the concept directly in an actual working environment.
6. Key summary: Distill what you learned into a few concise bullet points or lines.

The single most crucial habit throughout this cycle was never looking at the answer or explanation beforehand. Committing your own thoughts to writing first is what builds genuine analytical problem-solving ability.

What 4-step routine do I use when giving AI a task?

1. Define scope, criteria, evidence, and format clearly: Specify the exact source material and boundaries (scope), define what constitutes an accurate or completed deliverable (criteria), require explicit citations pointing to where in the material each claim originates (evidence), and designate a single uniform structure for the response (format). If reference materials are provided, review them thoroughly first to identify shared tables and baseline objectives.
2. Break conditions into atomic units: Deconstruct compound requirements into discrete individual items and request responses in a tabular format featuring dedicated columns for each condition. This immediately exposes unmet conditions as empty or failing cells. When instructing the model to ignore a specific column, always designate the alternative value or metric to use instead.
3. Verify and cross-check: Reconcile row counts (for example: total items − duplicates = final count), request counterexamples, and test boundary conditions. Instead of asking for "the final number only," instruct the AI to explain its step-by-step reasoning first and output the final result on the last line.
4. General operational principles: Never assume that simply attaching files provides sufficient context—explicitly state every condition in written text. Establish duplicate-handling rules upfront, and if dealing with large documents, summarize each section into a standardized table format before merging the datasets.

How did I practise under realistic conditions?

1. Practice in a realistic environment: I conducted exercises on the identical machine, browser, and workspace configuration intended for the actual evaluation. Passive reading frequently conceals operational gaps that only active hands-on execution reveals.
2. Personal practice web page: To drill the key operational habits described above (summarizing materials, cross-checking conditions, and organizing tabular outputs), I created a small personal web page containing fictional practice scenarios I authored myself. This was solely an independent practice tool developed to cultivate general competence, not a recreation of any specific exam. I am not linking it in this post.

How should you set up the Monito proctoring app in advance?

1. Service overview: Monito is an online exam proctoring service. According to its official website, it monitors the test taker's front view, side view, and computer screen simultaneously through screen sharing, a webcam, and a mobile smartphone. The platform also notes that exam sessions are recorded and archived.
2. Access procedure: Because the application is strictly designed for invited participants, access is granted exclusively through your designated exam link. According to the App Store listing for the Monito app, the setup steps are:
   • Open your invited exam link on your computer and scan the displayed QR code with your smartphone to connect.
   • Follow the step-by-step on-screen setup instructions before the exam begins.
   • Keep the application actively running on your smartphone without closing it until the entire exam concludes.
3. Required permissions and system specifications: Camera access (to monitor the test taker) and microphone access (for audio monitoring during recording) are required. The App Store notes that iOS 16.4 or later is required.
4. Essential verification: Testing and proctoring workflows differ across organizations. Be sure to consult the official guidelines provided by your specific exam organizer for precise installation and testing instructions.

How should you check your smartphone setup and hardware environment?

1. Smartphone stand: In accordance with App Store guidelines, prepare a stable phone stand or mount to keep your smartphone firmly in position throughout the session.
2. Do Not Disturb mode: Incoming phone calls or text messages can interrupt video proctoring, so make sure to turn on Do Not Disturb mode beforehand.
3. Silence non-essential notifications: Emergency alerts or disaster broadcasts can disrupt video monitoring streams; the listing recommends disabling non-critical notification categories other than essential alerts.
4. Connect charging cables: Continuous video recording causes rapid battery consumption, making it essential to connect your phone to a charger prior to the session.
5. PC verification (general guidance): Note that this is general operational advice rather than official Monito documentation. Update the web browser specified by your exam guide to the latest version, close all background applications unrelated to the exam, verify camera, microphone, and screen-sharing permissions, and keep your laptop plugged into wall power.
6. Network stability (general guidance): Establish a reliable wired Ethernet connection or a stable Wi-Fi network. Prepare backup alternatives, such as a mobile hotspot, only if explicitly permitted by the exam guidelines.
7. Pre-exam environment check: If the exam administrator provides an advance system testing window, participate without fail to validate your hardware and network setup.

What about smart glasses, and what is the full checklist?

There has been a recent Newsis report covering instances where test takers using smart glasses were caught cheating during in-person exams in Korea (an on-site exam venue incident). While that case took place at an in-person venue rather than online, online proctored exams may also include eyewear inspection protocols, so be prepared to show your glasses to the camera if requested.

1. Install the Monito app from the official application store in advance and grant camera and microphone permissions (iOS 16.4 or later per the App Store).
2. Position your webcam and smartphone stand properly, following your own exam's instructions for placement.
3. Participate in the pre-exam environment test if one is made available by the organizers.
4. Browser and PC: Update the browser specified by your exam guidelines, close unrelated background programs, and verify screen-sharing authorization.
5. Network: Secure a dependable connection and prepare a verified backup plan if permitted under testing regulations.
6. Power management: Connect reliable chargers to both your smartphone (as recommended by the App Store) and your laptop.
7. Smartphone notification controls: Turn on Do Not Disturb mode and disable non-essential notification types.
8. Eyewear check: If you wear glasses, be prepared to hold them up to the camera if you are asked.
9. Exam day readiness: Log in well ahead of time and ensure the application remains open and active until the exam finishes.

Why do honesty and the official instructions matter most?

1. Never attempt to cheat: Any form of cheating or unauthorized assistance can trigger immediate disqualification, exam cancellation, and severe disciplinary consequences.
2. Review your environment thoroughly: Verifying your devices, mount positioning, network connection, and notification settings ahead of time prevents technical errors and avoids unnecessary suspicion.
3. Always adhere to official instructions first: Because proctoring rules, technical constraints, and monitoring setups differ across institutions, always consult and follow the official testing guidelines provided by your exam administrators.