🧭
이 페이지의 목표: 초급 입문자가 특정 언어나 AI 도구 사용법만 외우지 않고, 소프트웨어가 만들어지고 검증·배포되는 전체 흐름을 이해하도록 돕습니다. AI는 개발자를 대신하는 자동 정답기가 아니라 설명·초안·검토·자동화를 돕는 협업 도구로 사용합니다.
1. 처음 시작하는 개발자를 위한 학습 지도
먼저 이해해야 할 개발의 전체 흐름
소프트웨어 개발은 보통 아래 순서로 진행됩니다.
- 문제 정의: 누구의 어떤 문제를 해결할지 정합니다.
- 요구사항 설계: 입력, 처리, 출력, 예외 상황을 명확히 합니다.
- 구현: 코드를 작은 기능 단위로 작성합니다.
- 검증: 실행, 디버깅, 테스트, 코드 리뷰로 오류를 찾습니다.
- 협업: Git과 문서로 변경 이유와 작업 이력을 공유합니다.
- 배포·운영: 동일한 실행 환경을 만들고 로그·장애·보안을 관리합니다.
- 개선: 사용자 피드백과 운영 데이터를 반영합니다.
📌
입문 단계의 목표는 모든 기술을 깊게 아는 것이 아닙니다. 코드를 읽고 수정하고, 오류를 재현하고, 변경을 기록하고, 다른 사람에게 실행 방법을 설명할 수 있는 상태가 1차 목표입니다.
권장 개발 환경
| 도구 | 역할 | 입문자가 익힐 항목 | 학습 사이트 |
|---|---|---|---|
| VS Code | 코드 편집·실행·디버깅 | 폴더 열기, 확장 기능, 터미널, 검색, 중단점, Source Control | VS Code 시작하기 |
| Terminal | 운영체제와 개발 도구를 명령으로 제어 | 현재 경로, 파일·폴더 이동, 명령 실행, 환경 변수, 종료 코드 | VS Code Terminal |
| Git | 코드 변경 이력 관리 | init, clone, status, add, commit, branch, merge, pull, push | Pro Git 한국어판 |
| GitHub | 원격 저장소와 협업 | repository, issue, branch, pull request, review, merge conflict | GitHub Hello World · GitHub Skills |
기본 Bash 터미널 명령어
Bash는 명령어를 해석해 운영체제에 전달하는 Shell입니다. 명령을 실행하기 전에 현재 위치와 대상 경로를 확인하는 습관이 중요합니다.
| 명령어 | 용도 | 예시 |
|---|---|---|
pwd | 현재 작업 중인 경로 확인 | pwd |
ls | 현재 폴더의 파일·폴더 목록 확인 | ls -la |
cd | 다른 폴더로 이동 | cd project, cd .., cd ~ |
mkdir | 새 폴더 생성 | mkdir my-app |
touch | 빈 파일 생성 또는 수정 시간 갱신 | touch README.md |
cp | 파일·폴더 복사 | cp app.py app_backup.py, cp -r src src_backup |
mv | 파일·폴더 이동 또는 이름 변경 | mv old.txt new.txt |
rm | 파일·폴더 삭제 | rm file.txt, rm -r old-folder |
cat | 파일 내용을 한 번에 출력 | cat README.md |
less | 긴 파일을 페이지 단위로 확인 | less server.log |
head / tail | 파일의 처음·마지막 부분 확인 | head -n 20 app.log, tail -f app.log |
echo | 문자열이나 변수 값 출력 | echo "Hello", echo $PATH |
grep | 텍스트에서 패턴 검색 | grep -n "ERROR" app.log |
find | 조건에 맞는 파일·폴더 검색 | find . -name "*.py" |
which | 실행되는 명령어의 위치 확인 | which python |
history | 이전에 실행한 명령 확인 | history |
clear | 터미널 화면 정리 | clear |
man | 명령어 설명서 열기 | man ls |
chmod | 파일 실행·읽기·쓰기 권한 변경 | chmod +x deploy.sh |
curl | URL에 HTTP 요청 전송 | curl https://api.example.com |
| 표현 | 의미 | 예시 |
|---|---|---|
. | 현재 폴더 | python ./app.py |
.. | 상위 폴더 | cd .. |
~ | 사용자 홈 폴더 | cd ~/projects |
* | 여러 문자와 일치하는 wildcard | ls *.py |
> | 출력을 파일에 새로 저장 | echo "hello" > output.txt |
>> | 출력을 파일 끝에 추가 | echo "next" >> output.txt |
| ` | ` | 앞 명령의 출력을 다음 명령의 입력으로 전달 |
&& | 앞 명령이 성공하면 다음 명령 실행 | npm install && npm test |
Ctrl+C | 실행 중인 프로세스 중단 | 개발 서버 종료 |
Ctrl+L | 화면 정리 | clear와 유사 |
↑ / ↓ | 이전·다음 명령 탐색 | 긴 명령 재사용 |
⚠️
rm으로 삭제한 파일은 휴지통으로 이동하지 않습니다. 특히 rm -r, rm -f, 관리자 권한 명령을 실행하기 전에는 pwd와 ls로 대상 경로를 다시 확인하세요. 인터넷에서 복사한 명령은 의미를 이해한 후 실행합니다.
자주 사용하는 Git 명령어
| 단계 | 명령어 | 용도·예시 |
|---|---|---|
| 최초 설정 | git config --global user.name "이름" | commit 작성자 이름 설정 |
| 최초 설정 | git config --global user.email "email@example.com" | commit 작성자 이메일 설정 |
| 시작 | git init | 현재 폴더를 새 Git 저장소로 초기화 |
| 시작 | git clone <URL> | 원격 저장소를 로컬에 복제 |
| 확인 | git status | 변경·추적·staging 상태 확인 |
| 확인 | git diff | 아직 staging하지 않은 변경 내용 확인 |
| 확인 | git log --oneline --graph --all | commit 이력을 간결한 그래프로 확인 |
| 저장 | git add <파일> | 특정 파일을 staging area에 추가 |
| 저장 | git add . | 현재 폴더 아래 변경을 모두 staging |
| 저장 | git commit -m "메시지" | staging된 변경을 이력으로 저장 |
| 브랜치 | git branch | 로컬 branch 목록 확인 |
| 브랜치 | git switch -c feature/login | 새 branch 생성 후 이동 |
| 브랜치 | git switch main | 기존 branch로 이동 |
| 병합 | git merge feature/login | 현재 branch에 다른 branch의 변경 병합 |
| 원격 | git remote -v | 연결된 원격 저장소 확인 |
| 원격 | git fetch origin | 원격 변경 이력만 내려받기 |
| 원격 | git pull origin main | 원격 변경을 내려받아 현재 branch에 반영 |
| 원격 | git push -u origin feature/login | branch를 최초 push하고 upstream 설정 |
| 원격 | git push | 이후 현재 branch의 commit을 원격에 전송 |
| 되돌리기 | git restore <파일> | commit 전 작업 폴더의 변경 취소 |
| 되돌리기 | git restore --staged <파일> | staging만 취소하고 파일 변경은 유지 |
| 임시 보관 | git stash | commit하지 않은 변경을 임시 보관 |
| 임시 보관 | git stash pop | 임시 보관한 변경을 다시 적용 |
# 1. 원격 변경 확인·반영
git switch main
git pull origin main
# 2. 기능 브랜치 생성
git switch -c feature/task-create
# 3. 작업 상태와 변경 확인
git status
git diff
# 4. 검증 후 commit
git add .
git commit -m "feat: add task creation"
# 5. 원격 branch에 push
git push -u origin feature/task-create
# 6. GitHub에서 Pull Request 생성 및 리뷰💡
Git 작업의 기본 원칙은 status 확인 → diff 검토 → add → commit → push입니다. git add .를 실행하기 전에 git status와 git diff로 API Key, 빌드 결과물, 불필요한 파일이 포함되지 않았는지 확인하세요.
⚠️
초급 단계에서는 git reset --hard, git clean -fd, 강제 push(git push --force)를 사용하지 않는 편이 안전합니다. 이미 공유한 commit을 취소할 때는 이력을 보존하는 git revert <commit>을 우선 검토하세요.
12주 입문 로드맵
| 단계 | 학습 주제 | 최소 산출물 |
|---|---|---|
| 1~2주 | VS Code, Terminal, 파일·폴더, Git 기초 | 로컬 프로젝트를 GitHub 저장소에 올리기 |
| 3~4주 | 변수, 조건문, 반복문, 함수, 자료구조, 예외 처리 | 콘솔 기반 미니 프로그램 |
| 5~6주 | HTML·CSS·JavaScript 또는 선택 언어의 애플리케이션 기초 | 입력을 받아 결과를 보여주는 작은 앱 |
| 7~8주 | HTTP, REST API, JSON, Postman, SQL | 외부 API 호출과 데이터 저장·조회 |
| 9~10주 | 디버깅, 단위 테스트, 로그, 보안 기초 | 실패 테스트와 오류 처리 추가 |
| 11~12주 | Docker, CI/CD, README, AI 보조 개발 | 다른 환경에서 재현 가능한 최종 프로젝트 |
roadmap.sh의 Absolute Beginners·Computer Science 로드맵은 전체 학습 범위를 점검하는 용도로 활용하되, 모든 항목을 순서대로 완주하려고 하기보다 현재 프로젝트에 필요한 부분부터 학습합니다.
2. 초급 IT 개발자가 반드시 알아야 할 기본 소양
프로그래밍과 문제 해결
| 개념 | 꼭 알아야 하는 이유 | 입문 기준 |
|---|---|---|
| 변수·자료형 | 데이터가 어떤 형태로 저장·처리되는지 결정 | 문자열, 숫자, 불리언, null을 구분합니다. |
| 조건·반복 | 프로그램의 판단과 반복 작업을 표현 | 정상 흐름과 예외 흐름을 나눕니다. |
| 함수·모듈 | 코드를 작게 나누고 재사용 | 입력, 출력, 부작용을 설명합니다. |
| 자료구조 | 데이터를 목적에 맞게 조직 | 배열·리스트, 객체·딕셔너리, 집합의 차이를 압니다. |
| 예외 처리 | 실패를 숨기지 않고 통제 | 오류를 기록하고 호출자에게 의미 있게 전달합니다. |
| 추상화·분리 | 복잡도를 관리하고 변경 영향을 줄임 | 화면, 비즈니스 로직, 데이터 처리를 분리합니다. |
첫 언어는 정답이 없지만, 자동화·데이터·AI 활용까지 고려하면 Python 공식 튜토리얼이 좋은 출발점입니다. 웹 개발이 목표라면 MDN Learn Web Development의 구조화된 입문 과정을 권장합니다.
웹·네트워크·HTTP
클라이언트와 서버는 네트워크를 통해 요청(Request)과 응답(Response)을 주고받습니다. 초급 개발자는 다음 항목을 직접 설명할 수 있어야 합니다.
- URL·URI, 도메인, IP, 포트, DNS의 역할
- HTTP 메서드: GET, POST, PUT·PATCH, DELETE
- 상태 코드: 2xx 성공, 4xx 클라이언트 오류, 5xx 서버 오류
- Header와 Body, Content-Type, JSON
- Cookie, Session, Token 기반 인증의 차이
- HTTPS와 암호화된 전송이 필요한 이유
- 동기·비동기 처리와 요청 시간 초과(Timeout)
참고: MDN HTTP 가이드 · MDN Web API
데이터베이스·SQL·API
| 영역 | 핵심 개념 | 실습 목표 | 사이트 |
|---|---|---|---|
| 관계형 DB | table, row, column, primary key, foreign key, relation | 데이터 중복을 줄이고 관계를 표현 | SQLBolt |
| SQL | SELECT, WHERE, JOIN, GROUP BY, INSERT, UPDATE, DELETE | 필요한 데이터를 안전하게 조회·변경 | SQLBolt Interactive Lessons |
| API | endpoint, parameter, request·response schema, authentication | API 명세를 읽고 요청을 재현 | Postman Docs |
| 데이터 형식 | JSON, CSV, 날짜·시간, 인코딩 | 형식 불일치와 null 오류를 진단 | MDN JSON |
💡
API 오류가 나면 “안 된다”에서 멈추지 말고 요청 URL → 메서드 → 인증 → 헤더 → 본문 → 상태 코드 → 응답 메시지 순서로 확인합니다.
Git·GitHub 협업
Git은 단순 백업 도구가 아니라 변경을 설명하는 협업 언어입니다.
- 하나의 commit에는 하나의 논리적 변경을 담습니다.
- commit 메시지에는 “무엇”뿐 아니라 필요하면 “왜”를 기록합니다.
- 기능마다 branch를 만들고 Pull Request로 변경을 제안합니다.
- 코드 리뷰에서는 사람을 평가하지 않고 코드의 정확성·가독성·보안·테스트를 검토합니다.
- merge conflict는 어느 변경이 최종 의도인지 확인해 직접 해결합니다.
실습: GitHub Pull Request 빠른 시작 · Pull Request Review
디버깅·테스트·품질
| 구분 | 확인할 질문 | 기본 도구·기법 |
|---|---|---|
| 재현 | 어떤 입력과 환경에서 실패하는가? | 최소 재현 절차, 버전·환경 기록 |
| 관찰 | 실제 값과 실행 흐름은 무엇인가? | 로그, VS Code debugger, breakpoint |
| 가설 | 어느 계층에서 잘못되었는가? | 입력·처리·출력을 나눠 확인 |
| 테스트 | 수정 후 다시 깨지지 않는가? | 단위 테스트, 통합 테스트, 경계값·예외 테스트 |
| 정적 품질 | 실행 전 발견할 문제는 없는가? | formatter, linter, type checker |
AI가 생성한 코드도 반드시 직접 실행하고 테스트해야 합니다. 정상 입력만 확인하지 말고 빈 값, 잘못된 형식, 권한 부족, 네트워크 실패, 매우 큰 입력을 함께 검증합니다.
실행 환경·Docker·CI/CD
- 의존성(Dependency): 프로젝트가 사용하는 라이브러리와 버전을 고정합니다.
- 환경 변수(Environment Variable): 환경별 설정을 코드와 분리합니다.
- Container: 애플리케이션과 실행 환경을 묶어 재현성을 높입니다.
- Image: 컨테이너를 만들기 위한 불변 템플릿입니다.
- CI: 변경마다 빌드·테스트·검사를 자동 수행합니다.
- CD: 검증된 변경을 배포 환경에 전달합니다.
학습: Docker Get Started · Docker Compose · GitHub Actions 이해하기
보안·개인정보·오픈소스
초급 단계부터 아래 원칙을 기본값으로 적용합니다.
- 사용자 입력과 외부 데이터는 신뢰하지 않고 검증합니다.
- 인증(Authentication)과 인가(Authorization)를 구분합니다.
- API Key, 비밀번호, Token을 코드·프롬프트·Git 저장소에 넣지 않습니다.
- SQL은 문자열 결합 대신 parameterized query를 사용합니다.
- 라이브러리 출처·라이선스·취약점·유지보수 상태를 확인합니다.
- 로그에 비밀번호, Token, 개인정보를 남기지 않습니다.
- 최소 권한(Least Privilege)과 안전한 기본값을 사용합니다.
참고: OWASP Top 10:2025 · OWASP Cheat Sheet Series · OWASP Developer Guide
문서화·커뮤니케이션
좋은 개발자는 코드를 작성하는 사람을 넘어, 의도와 상태를 전달하는 사람입니다.
- README: 프로젝트 목적, 설치, 실행, 테스트, 환경 변수, 알려진 제약
- Issue: 현재 문제, 재현 절차, 기대 결과, 실제 결과, 환경
- Pull Request: 변경 목적, 주요 내용, 검증 방법, 영향 범위
- API 문서: endpoint, 인증, 요청·응답 예시, 오류 코드
- 의사결정 기록: 선택한 대안과 포기한 대안, 판단 이유
3. AI를 IT 개발 업무에 접목하는 방법
꼭 알아야 할 AI 개념
| 개념 | 쉬운 설명 | 개발자가 주의할 점 |
|---|---|---|
| LLM | 많은 텍스트·코드 패턴을 바탕으로 다음 내용을 생성하는 모델 | 사실·코드의 정확성을 보장하지 않습니다. |
| Token | 모델이 입력과 출력을 처리하는 단위 | 긴 대화·코드는 비용과 문맥 한도를 소모합니다. |
| Context | AI가 답변할 때 참고하는 현재 정보 | 관련 파일·오류·요구사항만 선별해 제공합니다. |
| Prompt | 목표·조건·입력·출력 형식을 지정하는 지시 | 모호한 요청보다 완료 기준이 있는 작업 지시가 좋습니다. |
| Hallucination | 존재하지 않는 API·사실·원인을 그럴듯하게 생성 | 공식 문서 확인, 실행, 테스트로 검증합니다. |
| RAG | 외부 문서를 검색해 관련 내용을 문맥으로 제공 | 문서 최신성·권한·검색 품질이 답변 품질을 좌우합니다. |
| Tool Calling | AI가 API·검색·코드 실행 같은 도구를 호출 | 권한, 입력 검증, 실패 처리, 감사 로그가 필요합니다. |
| Agent | 목표 달성을 위해 여러 단계와 도구 호출을 수행 | 자율 범위와 승인 지점을 제한해야 합니다. |
| Embedding | 텍스트 의미를 숫자 벡터로 표현 | 의미 검색에 유용하지만 정확한 키워드·권한 필터를 대체하지 않습니다. |
AI·LLM 내부 동작을 시각적으로 이해하는 시뮬레이션
🧠
가중치(Weight)는 학습 과정에서 조정되는 수치형 parameter입니다. 연결선 하나의 가중치를 따로 해석하기보다, 입력이 여러 layer를 통과하면서 activation·attention·출력 확률이 어떻게 달라지는지 함께 관찰해야 합니다. 또한 attention weight는 특정 입력에서 계산되는 attention score이며, 학습된 model parameter 전체와는 다른 개념입니다.
| 사이트 | 시각화·시뮬레이션 내용 | 직접 확인할 것 | 난이도 |
|---|---|---|---|
| TensorFlow Playground | 작은 neural network를 브라우저에서 직접 학습하며 neuron, layer, weight, bias, activation, learning rate와 decision boundary를 시각화 | layer·neuron 수와 learning rate를 바꾸고 loss와 연결선 weight가 어떻게 변하는지 비교 | 입문 |
| Transformer Explainer | GPT-2 기반 Transformer가 tokenization, embedding, self-attention, MLP, softmax를 거쳐 다음 token을 예측하는 과정을 단계별로 표현 | 직접 문장을 입력하고 attention weight, 중간 계산, temperature 변경에 따른 token 확률 변화를 관찰 | 입문~중급 |
| LLM Visualization | GPT 계열 model의 embedding matrix, layer normalization, self-attention, projection, MLP와 matrix multiplication을 3D로 탐색 | 파란 cell로 표시되는 weight와 초록 cell의 계산 값이 layer를 따라 어떻게 전달되는지 추적 | 중급 |
| CNN Explainer | 이미지 분류 CNN의 convolution kernel, feature map, activation, pooling, fully connected layer와 예측 확률을 상호작용 방식으로 설명 | kernel weight가 이미지 영역에 적용되어 edge·texture 같은 feature map을 만드는 과정 확인 | 입문~중급 |
| Netron | ONNX, PyTorch, TensorFlow Lite, Keras, Safetensors 등 실제 model 파일의 computational graph와 tensor·parameter 구조 확인 | layer 연결, 입력·출력 shape, operator, parameter 크기를 살펴보고 model architecture를 읽는 연습 | 중급 |
| BertViz | BERT·GPT-2 등 Transformer의 layer·head별 attention pattern과 query·key 상호작용을 Jupyter·Colab에서 시각화 | 같은 문장을 head별로 비교하고 각 token이 어느 token에 attention을 배분하는지 탐색 | 중급 |
| Distill — Visualizing Weights | hidden layer weight를 그대로 보는 것이 왜 어려운지와 neuron 사이의 의미 있는 상호작용을 해석하는 방법 설명 | “큰 weight 하나 = 중요한 개념 하나”로 단순 해석하면 안 되는 이유 이해 | 중급~심화 |
- TensorFlow Playground: data → weight 조정 → loss 감소 → decision boundary 형성의 관계를 봅니다.
- CNN Explainer: 학습된 kernel이 입력에서 특징을 추출하는 방식을 확인합니다.
- Transformer Explainer: token, embedding, attention, 다음 token 확률의 흐름을 따라갑니다.
- LLM Visualization: Transformer 내부 matrix multiplication과 parameter를 더 세밀하게 탐색합니다.
- Netron·BertViz: 실제 model architecture와 입력별 attention pattern을 분석합니다.
- 기본 data에서 재생 버튼을 눌러 loss가 줄어드는 과정을 봅니다.
- hidden layer와 neuron 수를 줄이고 같은 data를 학습시킵니다.
- activation을 ReLU와 Tanh로 바꿔 decision boundary를 비교합니다.
- learning rate를 너무 작거나 크게 바꿔 수렴 속도와 불안정성을 관찰합니다.
- noise와 regularization을 조정해 과적합(Overfitting)과 일반화(Generalization)의 차이를 확인합니다.
- 짧은 영문 문장을 입력하고 token이 단어·subword로 나뉘는지 확인합니다.
- embedding과 positional information이 더해지는 과정을 봅니다.
- attention matrix에서 각 token이 이전 token에 배분하는 비율을 비교합니다.
- temperature를 낮추거나 높여 다음 token의 probability distribution과 결과 다양성을 비교합니다.
- 같은 시작 문장에서 단어 하나만 바꾸고 attention과 예측 token이 어떻게 달라지는지 관찰합니다.
⚠️
시각화는 복잡한 model을 이해하기 위한 축약된 표현입니다. 작은 교육용 model의 동작을 실제 상용 LLM 전체와 동일하다고 일반화하면 안 됩니다. 특히 attention pattern만으로 model의 인과적 “생각”이나 판단 근거를 단정하지 말고, 구조와 계산 흐름을 이해하는 자료로 활용하세요.
AI를 활용하기 좋은 개발 업무
| 개발 단계 | AI 활용 | 사람이 반드시 확인할 것 |
|---|---|---|
| 요구사항 | 사용자 이야기, acceptance criteria, 예외 상황 초안 | 실제 사용자 목적과 범위 |
| 학습·탐색 | 개념 설명, 공식 문서 탐색 키워드, 예제 비교 | 출처·버전·적용 환경 |
| 설계 | 데이터 모델, API 초안, 대안·트레이드오프 정리 | 보안, 성능, 운영 복잡도 |
| 구현 | 반복 코드, 함수 뼈대, 변환 로직, 주석 초안 | 정확성, 라이선스, 의존성, 코드 스타일 |
| 디버깅 | 오류 메시지 해석, 원인 가설, 확인 순서 | 실제 로그·재현 결과 |
| 테스트 | 정상·경계·예외 테스트 케이스 생성 | 요구사항 누락과 실제 테스트 실행 |
| 리뷰 | 잠재 버그, 가독성, 중복, 보안 체크리스트 | 최종 승인과 변경 영향 |
| 문서화 | README, API 설명, 변경 요약, 운영 절차 초안 | 실제 명령·URL·환경과 일치 여부 |
| DevOps | Dockerfile·CI workflow 초안, 로그 분석 | Secret, 권한, 배포 대상, rollback |
GitHub는 Copilot을 인간 개발자의 대체물이 아니라 보조 도구로 사용하고, 생성 코드와 코드 리뷰 결과를 사람이 검토·테스트할 것을 권고합니다. 참고: GitHub Copilot 책임 있는 사용 · Copilot Chat 주의사항
안전한 AI 개발 워크플로우
- 작업을 작게 자릅니다. “앱 전체를 만들어줘” 대신 한 기능·한 파일·한 테스트 단위로 요청합니다.
- 문맥을 제공합니다. 목표, 기술 스택, 관련 코드, 오류 전문, 제약, 완료 기준을 포함합니다.
- 계획을 먼저 받습니다. 수정 파일과 접근 방식을 확인한 뒤 코드를 생성합니다.
- diff를 검토합니다. AI가 바꾼 파일·의존성·설정·삭제 내용을 확인합니다.
- 직접 실행합니다. build, test, lint, type check, 보안 검사를 수행합니다.
- 작게 commit합니다. 검증된 변경만 별도 commit으로 남깁니다.
- 사람이 승인합니다. 보안·데이터·배포·비용에 영향이 있는 작업은 자동 승인하지 않습니다.
⚠️
AI에 입력하지 말아야 할 것: 실제 비밀번호·API Key·Token, 고객 개인정보, 비공개 소스 전체, 계약·재무 기밀, 운영 DB 원본. 조직 정책과 서비스의 데이터 처리 조건을 먼저 확인하세요.
재사용 가능한 개발 프롬프트
역할: [예: Python 백엔드 개발 멘토]
목표: [완성할 기능을 한 문장으로]
현재 환경: [언어/버전/프레임워크/OS]
관련 문맥: [파일 구조, 코드, API 명세, 오류 전문]
제약: [수정 금지 영역, 사용 가능한 라이브러리, 보안 조건]
요청:
1. 먼저 원인 또는 구현 계획을 설명한다.
2. 변경할 파일과 이유를 제시한다.
3. 최소 변경 코드만 작성한다.
4. 정상·경계·예외 테스트를 제시한다.
5. 불확실한 API는 추측하지 말고 확인 필요로 표시한다.
완료 기준: [실행 명령과 기대 결과]
출력 형식: 계획 → 코드 변경 → 테스트 → 위험·확인사항입문자용 종합 실습 프로젝트
과제: 개인 학습 기록 API 또는 간단한 할 일 관리 앱
- 화면 또는 CLI에서 항목을 추가·조회·수정·삭제합니다.
- JSON API와 상태 코드를 사용합니다.
- SQLite 등 관계형 DB에 저장하고 SQL로 조회합니다.
- Git branch와 Pull Request로 기능을 나눕니다.
- 입력 검증, 오류 처리, 로그, 단위 테스트를 포함합니다.
- Docker로 실행 환경을 구성합니다.
- GitHub Actions에서 test와 lint를 실행합니다.
- AI에는 요구사항 분해, 함수 초안, 테스트 아이디어, 오류 분석을 맡기되 모든 변경을 직접 검증합니다.
최종 체크리스트
- 코드를 보지 않고도 입력·처리·출력 흐름을 설명할 수 있다.
- 오류를 재현하고 로그·디버거로 원인을 좁힐 수 있다.
- HTTP 요청과 API 응답을 Postman 등으로 검증할 수 있다.
- SQL로 기본 CRUD와 JOIN을 수행할 수 있다.
- Git branch·commit·Pull Request로 변경을 관리할 수 있다.
- 테스트와 lint를 실행하고 실패 원인을 확인할 수 있다.
- Docker로 다른 환경에서도 프로젝트를 실행할 수 있다.
- Secret과 개인정보를 코드·로그·AI 프롬프트에서 분리한다.
- AI 생성 코드의 동작·보안·라이선스를 검토한다.
- 공식 문서와 실제 실행 결과를 최종 근거로 사용한다.
핵심 사이트 모음: MDN · Python Docs · VS Code Docs · Pro Git · GitHub Skills · Postman Docs · SQLBolt · Docker Docs · GitHub Actions · OWASP · roadmap.sh
주요 기업의 코딩 테스트 경향과 준비 가이드
📌
기업별 시험 방식·문항 수·시간·사용 언어·AI 도구 허용 여부는 채용 시기와 직무에 따라 바뀝니다. 아래 내용은 준비 방향을 잡기 위한 경향이며, 실제 응시 전에는 반드시 해당 채용 공고와 응시 안내를 최종 기준으로 확인하세요.
| 기업·유형 | 공개 자료에서 확인되는 특징 | 준비 포인트 | 참고 자료 |
|---|---|---|---|
| 삼성 SW 직군 | 공식 안내 기준 C·C++·Java·Python 중 선택, 2문제·240분의 실기형 테스트 | 긴 지문을 정확히 모델링하고 시뮬레이션·완전탐색·BFS/DFS를 실수 없이 구현하는 연습 | 삼성 채용 프로세스 · SW Expert Academy |
| 카카오 계열 | 신입·인턴 코딩 테스트 문제와 해설을 기술 블로그에 지속 공개하며 회차에 따라 다단계 테스트 운영 | 문자열·해시·정렬·그래프·탐색·구현을 복합적으로 적용하고, 기출 해설로 출제 의도와 복잡도를 분석 | 2026 카카오 1차 해설 · 2026 카카오 2차 해설 |
| NAVER 계열 | 직무·공고별 평가 방식이 달라질 수 있으며 기술 직무별 요구 역량을 상세히 구분 | 지원 직무의 언어·플랫폼·CS 기본기를 확인하고 범용 알고리즘과 직무 연관 문제를 함께 준비 | NAVER Tech Career |
| LINE 계열 | 공개 채용 콘텐츠에서는 알고리즘 경시대회형 난도보다 요구사항 이해, CS 이론, 적절한 해결책과 실제 구현 능력을 강조 | 문제 조건을 명확히 해석하고 읽기 쉬운 코드로 정확히 구현하는 연습 | LINE 코딩 테스트 출제 방향 · 기출 해설 |
| 현대오토에버 | 포지션에 따라 코딩 테스트 또는 과제 테스트를 운영하며, 이후 면접에서 코딩 테스트 리뷰가 포함될 수 있음 | 정답뿐 아니라 풀이 근거·복잡도·대안·코드 선택 이유를 말로 설명하는 연습 | 신입 합류 과정 |
| 일반 대기업·플랫폼·금융 IT | 온라인 알고리즘 테스트, SQL 테스트, 과제형 구현, 라이브 코딩을 직무별로 조합하는 경향 | 공고에서 플랫폼·언어·감독·검색 허용·SQL/과제 포함 여부를 먼저 확인 | 프로그래머스 고득점 Kit |
- 문제 이해: 입력·출력, 제약 조건, 예외 상황을 정확히 해석합니다.
- 해결 전략: 완전탐색이 가능한지 판단하고 더 적절한 자료구조·알고리즘을 선택합니다.
- 시간·공간 복잡도: 입력 크기에서 코드가 제한 시간과 메모리 안에 동작하는지 설명합니다.
- 구현 정확성: index, 경계값, 초기화, 중복, 자료형 범위 실수를 줄입니다.
- 검증 능력: 예제만 통과하는 데 그치지 않고 반례와 극단값을 직접 만듭니다.
- 코드 품질: 의미 있는 변수명과 함수 분리로 풀이 의도를 드러냅니다.
- 설명 능력: 면접에서 접근법, 대안, 실패 원인과 개선점을 설명합니다.
| 우선순위 | 주제 | 반드시 숙지할 내용 |
|---|---|---|
| 1 | 기본 구현 | 입출력, 문자열, 배열·리스트, 정렬, 좌표·격자, 조건 분기 |
| 1 | 해시·집합 | 빈도 계산, 중복 제거, 빠른 검색, key-value 모델링 |
| 1 | 스택·큐 | LIFO·FIFO, 괄호, 작업 순서, BFS용 queue |
| 1 | 완전탐색 | 경우의 수 생성, 재귀, 순열·조합, pruning |
| 1 | BFS·DFS | 그래프·격자 탐색, 연결 요소, 최단 이동 횟수 |
| 2 | 이분 탐색 | 정렬된 값 검색, 정답 범위에 대한 parametric search |
| 2 | Heap | 우선순위 queue, 최소·최대값의 반복 추출 |
| 2 | Greedy | 현재 선택이 전체 최적해를 보장하는 조건 설명 |
| 2 | Dynamic Programming | 상태 정의, 점화식, 초기값, memoization·tabulation |
| 2 | 최단 경로 | Dijkstra의 적용 조건과 우선순위 queue 사용 |
| 3 | 심화 그래프 | Union-Find, MST, 위상 정렬 |
| 직무별 | SQL | SELECT, JOIN, GROUP BY, aggregate, subquery, window function |
| 입력 규모의 대략적 범위 | 먼저 검토할 복잡도 |
|---|---|
N ≤ 20 | O(2^N), 순열·조합·backtracking 가능성 검토 |
N ≤ 500 | O(N^3)은 언어·상수에 따라 주의, O(N^2) 검토 |
N ≤ 10,000 | 보통 O(N^2)는 위험, O(N log N) 목표 |
N ≤ 1,000,000 | O(N) 또는 O(N log N) 검토 |
이는 절대 기준이 아닙니다. 테스트 케이스 수, 언어 실행 속도, 메모리 제한과 연산의 상수를 함께 봐야 합니다.
| 주차 | 학습 내용 | 완료 기준 |
|---|---|---|
| 1주 | 응시 언어 확정, 표준 입출력, 문자열·배열, 정렬 | 쉬운 문제를 문법 검색 없이 구현 |
| 2주 | 해시·집합, 스택·큐, 기본 완전탐색 | 각 자료구조의 선택 이유 설명 |
| 3주 | 재귀, 순열·조합, BFS·DFS | 격자·그래프 탐색을 직접 구현 |
| 4주 | 이분 탐색, Heap, Greedy | 복잡도와 Greedy 성립 근거 설명 |
| 5주 | Dynamic Programming, 최단 경로 | 상태·점화식·초기값을 먼저 작성 |
| 6주 | 기업별 기출·유사 문제, SQL·직무 문제 | 목표 기업 형식으로 2회 이상 풀이 |
| 7주 | 제한 시간 모의 테스트, 오답 유형 보완 | 시간 배분과 문제 선택 기준 확립 |
| 8주 | 실전 환경 반복, 면접용 풀이 설명 | 풀이·복잡도·반례를 말로 설명 |
- 문제를 읽고 입력·출력과 제한 조건에 표시합니다.
- 작은 예제를 손으로 추적해 규칙을 확인합니다.
- 가장 단순한 풀이와 예상 복잡도를 먼저 적습니다.
- 제한 조건을 만족하지 못하면 병목을 자료구조나 알고리즘으로 개선합니다.
- 함수와 자료구조를 정한 뒤 구현합니다.
- 예제 → 최소값 → 최대값 → 중복 → 정렬·역순 → 불가능한 경우 순으로 테스트합니다.
- 제출 후 틀렸다면 무작정 코드를 바꾸지 말고 가설과 반례를 기록합니다.
- 빠른 입력·출력과 기본 template
- 문자열 분리·결합·변환
- 배열·리스트·해시·집합·stack·queue·heap 사용법
- 정렬과 사용자 정의 comparator 또는 key
- 재귀 한도와 iterative 구현의 차이
- 정수 overflow, 부동소수점 오차, 나머지 연산
- 얕은 복사·깊은 복사와 mutable object
- 언어별 시간·메모리 특성과 허용 표준 라이브러리
- 시작 5~10분 동안 전체 문제와 제약 조건을 훑고 예상 난도를 분류합니다.
- 가장 확실한 문제부터 풀어 점수를 확보합니다.
- 20~30분 동안 진전이 없으면 풀이 가정을 다시 확인하거나 다른 문제로 이동합니다.
- 마지막 15~20분은 새 풀이보다 경계값·초기화·출력 형식 검증에 사용합니다.
- 부분 점수가 있는 시험이라면 모든 문제의 쉬운 하위 조건을 확인합니다.
⚠️
실제 시험에서 인터넷 검색, 개인 코드, IDE, 자동완성, 생성형 AI 사용 가능 여부는 기업마다 다릅니다. 허용되지 않은 AI·검색·외부 코드를 사용하면 부정행위가 될 수 있습니다. 응시 안내에 명시된 도구만 사용하고, 연습 단계에서도 AI가 만든 풀이를 그대로 제출하지 말고 직접 설명·재구현·테스트하세요.
- 프로그래머스 고득점 Kit: 국내 기업에서 자주 다루는 유형별 연습
- 백준 온라인 저지: 다양한 난이도와 방대한 문제
- solved.ac: 백준 문제의 난이도·학습 경로 관리
- SW Expert Academy: 삼성형 문제와 모의 SW 역량 테스트
- LeetCode 75: 해외 기술 면접용 핵심 문제
- SQLBolt: SQL 기초를 브라우저에서 실습
- 지원 기업의 최신 공고에서 시간, 문항 수, 언어, 감독 방식을 확인했다.
- 동일한 온라인 judge와 유사한 editor 환경에서 모의 테스트를 했다.
- 주력 언어의 입력·출력과 핵심 자료구조를 검색 없이 작성할 수 있다.
- 자주 틀리는 index, overflow, 초기화, 중복 처리 목록을 점검했다.
- 문제마다 시간·공간 복잡도를 설명할 수 있다.
- 예제 외에 최소·최대·중복·불가능한 반례를 직접 만든다.
- 응시 장소, 네트워크, 카메라, 신분증과 허용 도구를 확인했다.
- AI·검색·외부 자료 사용 규정을 확인했다.