2mukee Lab

정보보안기사에 대해 알아보자

2mukee — Sat, 11 Jul 2026 11:40:21 +0900

정보보안기사 (Engineer Information Security)

국가기술자격 / 한국인터넷진흥원(KISA) 출제기준 기반 / 한국방송통신전파진흥원(KCA) 시행
정보시스템 및 네트워크의 보안 위협을 예방하고 정보 자산을 안전하게 보호하기 위한 전문 인력을 인증하는 국가기술자격증
보안 정책 수립부터 네트워크 보안, 시스템 보안, 암호학, 애플리케이션 보안, 침해사고 대응까지 전반적인 정보보안을 다루며, 국내 대표 정보보안 자격증 중 하나

기본 정보

항목	내용
자격명	정보보안기사
등급	기사
시행기관	한국방송통신전파진흥원(KCA)
출제기준	한국인터넷진흥원(KISA)
자격 종류	국가기술자격
응시 방식	필기 + 실기
난이도	★★★★★
활용 분야	보안관제, 침해대응, 보안컨설팅, 개발보안, 시스템보안 등

응시 자격

다음 응시 자격 중 하나를 충족 해야함

응시 조건
관련학과 4년제 졸업(예정)
전문대 졸업 + 실무 경력
산업기사 취득 + 실무 경력
동일·유사 직무 경력

시험 구성

구분	내용
필기	객관식 4지선다
문항수	과목당 20문항 (총 100문항)
합격 기준	과목별 40점 이상 + 평균 60점 이상
실기	필답형
출제 유형	서술형, 계산형, 단답형, 사례형
시험 시간	약 150분

필기 시험 과목

과목	주요 내용	자주 출제되는 내용
시스템 보안	운영체제 구조, Linux, Windows, UNIX, 계정관리, 권한관리, 접근통제, 로그관리, 파일시스템, 프로세스, 메모리관리, 시스템 취약점	SetUID, Sticky Bit, ACL, PAM, sudo, SELinux, Windows Registry, 서비스 관리, 프로세스 권한
네트워크 보안	TCP/IP, OSI 7계층, Routing, Switching, VLAN, NAT, VPN, Firewall, IDS, IPS, Proxy, Load Balancer	TCP 3-way / 4-way Handshake, SYN Flooding, Smurf, LAND, Ping of Death, DDoS, HTTP, HTTPS, FTP, SSH, SMTP, DNS, DHCP, SNMP
애플리케이션 보안	SQL Injection, XSS, CSRF, SSRF, XXE, Command Injection, Directory Traversal, Session, Cookie, JWT, OAuth, Password Hash, Salt, MFA, OWASP Top 10	웹 취약점 및 인증 방식
정보보안 일반	ISMS, ISO27001, 개인정보보호법, 전자서명법, 정보통신망법, 출입통제, CCTV, UPS, 생체인증, 위험분석, 자산관리, 위협, 취약점, 위험평가	관리적·물리적 보안 및 위험관리
암호학	AES, DES, 3DES, SEED, ARIA, RSA, ECC, DH, SHA, SHA-2, SHA-3, MD5, SHA-1, PKI, 인증서, CA, OCSP, CRL	암호 알고리즘 및 전자서명

실기 시험

주요 출제 내용
로그 분석
네트워크 패킷 분석
침해사고 대응
보안 정책 작성
접근통제 정책
암호 방식 비교
공격 대응 절차

자주 나오는 공격

공격 기법	설명
SQL Injection	SQL문을 조작하여 DB를 공격
XSS	웹 페이지에 악성 스크립트 삽입
CSRF	사용자의 권한을 이용한 요청 위조
Buffer Overflow	버퍼를 초과하여 메모리 변조
Race Condition	동시 접근으로 발생하는 오류
Directory Traversal	상위 디렉터리 접근 공격
Command Injection	운영체제 명령 실행
SSRF	서버가 다른 서버에 요청하도록 유도

보안 장비

장비	역할
Firewall	접근 제어
IDS	침입 탐지
IPS	침입 차단
WAF	웹 공격 차단
VPN	암호화 통신
Proxy	중계 서버
UTM	통합 보안 장비
SIEM	로그 통합 분석
EDR	단말 보안
NDR	네트워크 탐지
XDR	통합 위협 대응

반드시 암기해야 하는 포트 번호

서비스	포트
FTP	20, 21
SSH	22
Telnet	23
SMTP	25
DNS	53
DHCP	67, 68
HTTP	80
POP3	110
IMAP	143
HTTPS	443
SMB	445
RDP	3389

대표 암호 알고리즘

구분	대표 알고리즘	장점	단점
대칭키	AES, DES, 3DES, SEED, ARIA	빠른 속도	키 관리가 어려움
공개키	RSA, ECC, ElGamal	키 분배가 쉬움	처리 속도가 느림
Hash	SHA-256, SHA-512, SHA-3, bcrypt, Argon2	복호화 불가능	-

보안 인증

인증	설명
ISMS	정보보호 관리체계 인증
ISMS-P	정보보호 + 개인정보보호 인증
ISO 27001	국제 정보보안 관리체계

공부 비중 추천

과목	비중
시스템 보안	★★★★★
네트워크 보안	★★★★★
암호학	★★★★☆
애플리케이션 보안	★★★★☆
정보보호 관리	★★★☆☆

순서	학습 내용
1	운영체제
2	네트워크
3	암호학
4	웹 보안
5	시스템 보안
6	법규 및 관리
7	기출문제 반복

순서	학습 방법
1	TCP/IP 완벽 이해
2	Linux 명령어 암기
3	Windows 보안 이해
4	암호 알고리즘 비교
5	공격 기법 암기
6	대응 방법 암기
7	기출문제 최소 5~10회 반복
8	실기 서술형 답안 작성 연습

SQLP를 준비하는 mySQL 개발자를 위한 오라클 SQL와 mySQL의 차이

2mukee — Sat, 11 Jul 2026 11:23:13 +0900

1. NULL 처리

Oracle	MySQL / MariaDB	설명
NVL(expr1, expr2)	IFNULL(expr1, expr2)	NULL이면 다른 값 반환
NVL2(expr, value1, value2)	IF(expr IS NULL, value2, value1)	NULL 여부에 따라 반환
COALESCE()	COALESCE()	동일 (표준 SQL)

Oracle

SELECT NVL(name, 'Unknown')
FROM member;

MySQL

SELECT IFNULL(name, 'Unknown')
FROM member;

표준 SQL

SELECT COALESCE(name, 'Unknown')
FROM member;

2. 조건문

Oracle

DECODE(job,
       'MANAGER', '관리자',
       'SALESMAN', '영업',
       '기타')

MySQL

CASE job
    WHEN 'MANAGER' THEN '관리자'
    WHEN 'SALESMAN' THEN '영업'
    ELSE '기타'
END

SQLP에서는 CASE를 더 많이 사용한다.

3. 현재 날짜

Oracle	MySQL
SYSDATE	NOW()
CURRENT_DATE	CURRENT_DATE

Oracle

SELECT SYSDATE
FROM dual;

MySQL

SELECT NOW();

4. 문자열 연결

Oracle

SELECT first_name || last_name
FROM member;

MySQL

SELECT CONCAT(first_name, last_name)
FROM member;

5. LIMIT

Oracle (12c 이상)

SELECT *
FROM member
FETCH FIRST 10 ROWS ONLY;

MySQL

SELECT *
FROM member
LIMIT 10;

6. OFFSET

Oracle

SELECT *
FROM member
OFFSET 20 ROWS
FETCH NEXT 10 ROWS ONLY;

MySQL

SELECT *
FROM member
LIMIT 20,10;

-- 또는
LIMIT 10 OFFSET 20;

7. ROWNUM

Oracle

SELECT *
FROM member
WHERE ROWNUM <= 10;

MySQL

LIMIT 10;

8. AUTO_INCREMENT

Oracle

CREATE SEQUENCE member_seq;

INSERT INTO member
VALUES(member_seq.NEXTVAL,'Kim');

MySQL

id INT AUTO_INCREMENT PRIMARY KEY

9. DUAL 테이블

Oracle

SELECT SYSDATE
FROM dual;

MySQL

-- MySQL에서는 DUAL이 없어도 된다.
SELECT NOW();

10. 날짜 더하기

Oracle

SYSDATE + 1

MySQL

DATE_ADD(NOW(), INTERVAL 1 DAY)

11. 날짜 차이

Oracle

SYSDATE - hire_date

MySQL

DATEDIFF(NOW(), hire_date)

12. 문자열 길이 (동일)

LENGTH(name)

13. 대문자/소문자 (동일)

UPPER(name)

LOWER(name)

14. 문자열 자르기 (동일)

SUBSTR(name,1,3)

-- MySQL에서는 아래 쿼리도 가능
SUBSTRING(name,1,3)

15. 문자열 위치

Oracle

INSTR(name,'A')

MySQL

LOCATE('A',name)

-- 또는
INSTR(name,'A')

16. REPLACE (동일)

REPLACE(name,'A','B')

17. TRIM (동일)

TRIM(name)

18. ROUND (동일)

ROUND(salary)

19. CEIL / FLOOR (동일)

CEIL()

FLOOR()

20. MOD (동일)

MOD(10,3)

21. CAST (동일)

CAST(age AS CHAR)

22. TO_CHAR

Oracle

TO_CHAR(salary)

MySQL

CAST(salary AS CHAR)

23. TO_DATE

Oracle

TO_DATE('2025-01-01','YYYY-MM-DD')

MySQL

STR_TO_DATE('2025-01-01','%Y-%m-%d')

24. TO_NUMBER

Oracle

TO_NUMBER('100')

MySQL

CAST('100' AS SIGNED)

25. 실행계획

Oracle

EXPLAIN PLAN FOR
SELECT ...

MySQL

EXPLAIN
SELECT ...

26. MERGE

Oracle

MERGE INTO ...

MySQL

INSERT ...
ON DUPLICATE KEY UPDATE

27. UPDATE JOIN

Oracle

MERGE

-- 또는
UPDATE
(
    SELECT ...
)

MySQL

UPDATE A
JOIN B
ON ...
SET ...

28. DELETE JOIN

Oracle

DELETE
WHERE EXISTS(...)

MySQL

DELETE A
FROM A
JOIN B

29. Sequence

Oracle

member_seq.NEXTVAL

member_seq.CURRVAL

MySQL

AUTO_INCREMENT

30. Window Function

Oracle

ROW_NUMBER()

RANK()

DENSE_RANK()

LAG()

LEAD()

MySQL

8 이상 부터 동일하게 지원

31. Common Table Expression

Oracle

WITH temp AS (...)

MySQL

8 이상 부터 동일하게 지원

32. EXISTS (동일)

WHERE EXISTS (...)

33. IN (동일)

WHERE id IN (...)

34. ANY / ALL (동일)

> ANY()

> ALL()

35. 집계 함수 (동일)

SUM()

AVG()

COUNT()

MAX()

MIN()

36. GROUP BY (동일)

GROUP BY

37. HAVING (동일)

HAVING COUNT(*) > 10

38. JOIN (동일)

INNER JOIN

LEFT JOIN

RIGHT JOIN

FULL OUTER JOIN

-- FULL OUTER JOIN은 Oracle만 지원 (mySQL 미지원)

39. 계층형 조회

Oracle

CONNECT BY

START WITH

MySQL

WITH RECURSIVE

40. Pivot

Oracle

PIVOT

MySQL

CASE

SQLP에서 반드시 익혀야 하는 Oracle 문법

NVL
DECODE
CASE
ROWNUM
FETCH FIRST
DUAL
TO_CHAR
TO_DATE
TO_NUMBER
SEQUENCE
CONNECT BY
MERGE

SQLP에 대해 알아보자

2mukee — Sat, 11 Jul 2026 11:15:52 +0900

SQLP (국가공인 SQL 전문가 / SQL Professional)

국가공인 민간자격 / 한국데이터산업진흥원(K-DATA) 시행
데이터베이스 설계부터 SQL 최적화, 실행계획 분석, 인덱스 설계, 옵티마이저 및 성능 튜닝 능력을 검증하는 국내 최고 수준의 SQL 전문가 자격증

대상
DBA(Database Administrator)
데이터 엔지니어
백엔드 개발자
데이터베이스 성능 튜닝 담당자
시니어 개발자

시험 정보

항목	내용
자격명	SQLP (SQL Professional)
주관	한국데이터산업진흥원(K-DATA)
시행	데이터자격검정(DataQ)
자격구분	국가공인 민간자격
응시자격	SQLD 보유 또는 학력·경력 요건 충족
시험방식	객관식 + 주관식(서술형)
시험시간	180분 (3시간)
응시료	100,000원
시험횟수	연 2회
합격기준	총점 75점 이상 + 과목별 40% 이상

시험 구성

객관식은 문항당 1점이며, 주관식은 문항당 15점으로 부분점수가 인정

과목	객관식	주관식	배점
데이터 모델링의 이해	10문항	일부 포함	10점
SQL 기본 및 활용	20문항	-	20점
SQL 고급 활용 및 튜닝	40문항	-	40점
주관식(서술형)	-	2문항	30점
합계	70문항	2문항	100점

응시 자격

다음 조건 중 하나 이상을 충족해야함

응시 조건
SQLD(SQL 개발자) 자격증 보유
학사 학위 이상 + 관련 실무 경력
전문학사 + 관련 실무 경력
고등학교 졸업 + 관련 실무 경력
기타 DataQ에서 정한 응시 자격 충족

시험 과목

과목	주요 학습 내용
데이터 모델링의 이해	데이터 모델링, 데이터 독립성, ERD, 엔터티(Entity), 속성(Attribute), 관계(Relationship), 식별자(PK, FK), 정규화, 반정규화, 관계와 조인, 트랜잭션 모델링, CRUD Matrix, NULL 처리, Natural Key, Surrogate Key
SQL 기본 및 활용	RDBMS, SELECT, WHERE, GROUP BY, HAVING, ORDER BY, JOIN, 표준 JOIN, 서브쿼리, 집합 연산, 그룹 함수, 윈도우 함수, Top-N Query, 계층형 질의, PIVOT, 정규표현식, DML, TCL, DDL, DCL
SQL 고급 활용 및 튜닝	SQL 수행 구조(Parse, Execute, Fetch), 실행계획, Explain Plan, SQL Trace, TKPROF, 인덱스 튜닝, 조인 튜닝, 옵티마이저(CBO), Query Transformation, Cursor, Bind Variable, SQL Rewrite, Partitioning, Lock, Deadlock, Isolation Level, 동시성 제어

과목별 핵심 내용

과목	핵심 키워드
데이터 모델링	ERD, 엔터티, 속성, 관계, PK/FK, 정규화, 반정규화
SQL 기본	SELECT, WHERE, JOIN, GROUP BY, HAVING, ORDER BY
SQL 활용	서브쿼리, 집합연산, 윈도우 함수, 그룹 함수, PIVOT
SQL 튜닝	실행계획, 인덱스, 옵티마이저, SQL Rewrite
트랜잭션	Lock, Deadlock, Isolation Level, 동시성 제어

출제 중요도

분야	중요도	비고
데이터 모델링	⭐⭐⭐	기본 이론
SQL 기본	⭐⭐⭐⭐	필수
SQL 활용	⭐⭐⭐⭐	필수
실행계획	⭐⭐⭐⭐⭐	핵심
인덱스	⭐⭐⭐⭐⭐	핵심
옵티마이저	⭐⭐⭐⭐⭐	핵심
SQL 튜닝	⭐⭐⭐⭐⭐	핵심
Join 튜닝	⭐⭐⭐⭐⭐	핵심

일반적인 준비 기간

대상	권장 준비 기간
SQLD 취득 후 실무 경험자	2~3개월
개발 경력 3년 이상	3~4개월
비전공자	6개월 이상

순서	학습 내용
1	데이터 모델링
2	SQL 기본 문법
3	JOIN 및 서브쿼리
4	윈도우 함수 및 그룹 함수
5	실행계획(Explain Plan)
6	인덱스 구조 및 튜닝
7	옵티마이저(CBO)
8	SQL 튜닝 및 Rewrite
9	Lock, Transaction, 동시성 제어
10	기출문제 및 서술형 답안 작성

순서	학습 방법
1	SQLD 내용을 완벽히 복습한다.
2	Oracle 실행계획(Explain Plan)을 반복 분석한다.
3	B-Tree 인덱스 구조를 이해한다.
4	Nested Loop, Hash, Sort Merge Join의 차이를 익힌다.
5	옵티마이저(CBO) 동작 원리를 학습한다.
6	SQL Rewrite 및 성능 개선 사례를 연습한다.
7	기출문제를 반복 풀이한다.
8	서술형 답안을 직접 작성하며 실전 감각을 익힌다.

SQLP 난이도

항목	내용
난이도	★★★★★
추천 대상	DBA, 데이터 엔지니어, 백엔드 개발자
특징	실행계획 분석, 옵티마이저, 인덱스 설계 및 SQL 튜닝 중심
핵심 과목	SQL 고급 활용 및 튜닝
합격 포인트	실행계획 해석, 인덱스 설계, 옵티마이저 이해, 조인 튜닝 능력

프리랜서 개발자에게 필요한 비개발 스킬 Top 10

2mukee — Fri, 10 Jul 2026 22:49:14 +0900

1. 커뮤니케이션 능력

개발 역량 이상으로 중요한 기본 역

일정, 이슈, 우선순위를 상대가 헷갈리지 않도록 명확하게 전달할 수 있어야함

발주처와 팀이 개발자를 신뢰할 수 있는지 판단하는 가장 빠른 기준

2. 일정 관리 능력

프리랜서에게는 개발 실력만큼 중요한 핵심 역량

일정을 예측 가능하게 관리하는 개발자일수록 재계약 가능성도 높아짐

3. 문서화 습관

회의 내용, 작업 범위, 요청 변경사항을 기록 (AI를 활용)

문서화는 커뮤니케이션 누락과 책임 공방을 줄여주는 안전장치

4. 질문하는 능력

제대로 이해하지 못했는데도 이해하는 척 넘어가지 않는 태도가 중요

프로젝트 초반에 핵심 내용을 정확히 확인하면 불필요한 시행착오를 줄일 수 있음

5. 우선순위 판단력

모든 일을 완벽하게 하려 하기보다, 지금 가장 중요한 일을 먼저 처리하는 능력이 필요

일정과 품질 사이에서 현실적인 균형을 잡을 수 있어야함

6. 협상력

단가 뿐만 아니라 작업 범위 조정, 일정 조율, 추가 요청 대응까지 모두 포함

"안됩니다" 보다는 "이 방식이라면 가능합니다" 라고 제안할 수 있는 요령과 역량 필요

7. 관계 관리 능력

결국 다음 일을 만들어주는 것은 사람

8. 문제 공유 타이밍

문제가 생겼을 때 혼자 끌어안고 버티지 않는 태도가 필요

일정이 무너지기 전에 리스크를 먼저 공유하는 감각이 중요

문제를 잘 공유하는 것은 실력보다 신뢰를 지키는 최우선 요소

9. 자기 관리 능력

자기관리는 생산력을 지탱하는 기본 체력

업무 루틴, 집중력, 컨디션 관리까지 포함

자유로운 환경에서 일할수록 자기관리 능력은 더욱 중요

10. 브랜딩 감각

자신이 어떤 개발자인지 한 줄로 설명할 수 있으면 매우 좋다

"어떤 문제를 잘 해결하는 개발자인가"를 명확하게 보여주는 능력이 필요

브랜딩은 단가 상승과 더 좋은 기회로 연결되는 중요한 요소

Reference

https://okky.kr/spaces/freelancer-dev/1559499

프리랜서 개발자에게 필요한 비개발 스킬 Top 10 | OKKY 커뮤니티

1. 커뮤니케이션 능력개발 역량만큼, 아니 어쩌면 그보다 더 중요한 기본 역량.일정, 이슈, 우선순위를 상대가 헷갈리지 않도록 명확하게 전달할 수 있어야 함.발주처와 팀이 개발자를 신뢰할 수

okky.kr

37signals의 의사결정 가이드

2mukee — Fri, 10 Jul 2026 22:42:42 +0900

선요약

회사를 사람들의 집단과 결정의 집합이라는 두 가지로 정의

그 사람들이 어떻게 결정하느냐가 곧 비즈니스를 운영하는 기술

매일, 온종일 반복하는 단 하나의 일이 결정이며, 이를 위한 일반 원칙 모음을 공유

"정말 결정이 필요한가", "올바른 사람이 결정하는가"처럼 결정의 전제 자체를 점검하는 38개 질문으로 구성

가역성, 규모 축소, 직감 대 데이터, 고객 영향 등 여러 각도에서 결정을 바라보는 사고 방식 제시

1. 회사와 의사 결정에 대한 관점

2. 결정의 필요성 자체 점검

왜 결정하려 하는지, 여기서 결정이 필요한지

결정하지 않으면 어떤 일이 벌어지는지

어떤 결정이라도 내리는 편이 나은지, 무결정이 나은지

애초에 틀린 결정이라는게 존재하기는 하는지

3. 누가 결정해야 하는가

올바른 역할이 아니라, 올바른 정보, 맥락, 통찰을 가진 사람이 결정하는지

한 사람이 내려야 할 결정을 여러 사람에게 맡기고 있지는 않은지

4. 지연, 망설임, 타이밍

이 결정이 왜 진작 내려지지 않았는지

이 전에 결정하지 못한 이유는?

무엇이 결정을 지연시키는지

그 망설임이 무엇을 드러내는지

언제까지 결정해야 하는지

일회성 결정인지 반복되는 결정인지

내일 아침까지 기다리면 다른 결정을 내릴 것 같은지

지금 당장 강제로 결정한다면 무엇일지

이 결정을 90일 전에 내렸다면 오늘 어디에 있을지

5. 대안, 관점, 직감

다른 사람이라면 왜 다른 결정을 내릴지, 반대편 시각이 어떨지

또 다른 의견이 도움이 될지, 방해가 될지

첫 직감이 무엇이었는지, 지금은 그 직감을 데이터로 정당화하여 맴돌지 않은지

주로 데이터 기반 결정인지, 직감 기반 결정인지 구분

6. 규모, 가역성, 단순화

결정을 더 작게 만들 수 있는지

하나의 큰 결정을 셋으로 쪼갤 수 있는지

결정을 얼마나 쉽게 되돌릴 수 있는지

고려 대상에서 일부를 제거해 결정을 더 쉽게 만들 수 있는지

7. 미래, 결과의 가시성

즉각적 영향을 제외하면 1년뒤 이 결정을 어떻게 느낄지

결정 후 기대되는 점과 두려운 점은 무엇인지

결정이 옳았는지, 의미가 있기는 했는지를 언제 알 수 있을지

결과가 맨눈으로 보일지, 현미경이 필요할지, 후자라면 그것이 의미가 있는지

8. 영향, 파급효과, 업무량

이 결정이 어떤 다른 결정들에 영향을 줄지

다른 결정의 필요를 없엘지, 오히려 더 만들지

여유 없는 사람들에게 업무를 늘릴지, 줄일지

외부의 누군가가 의존하는 사안인지, 자체적으로 만든 결정인지

고객에게 미치는 영향과 우리에게 미치는 영향을 비교

X,Y,Z를 고려하지 않으면 후회할 부분이 있는지

무엇이 쉬워지고 무엇이 어려워지는지

단기적 쉬움이 장기적 어려움인지 혹은 그 반대인지

9. 근거, 원칙, 비용

지난번 비슷한 결정에서 무슨 일이 있었는지

어떤 정보가 빠져 있어서 다른 결정으로 이어질지

이 결정으로 어떤 원칙을 굽히게 되는지

노력 대비 보상이 그만한 가치가 있는지

결국 이 결정이 돈에 관한 것인지

Reference

https://news.hada.io/topic?id=30872

37signals의 의사결정 가이드 | GeekNews

회사를 사람들의 집단과 결정의 집합이라는 두 가지로 정의, 그 사람들이 어떻게 결정하느냐가 곧 비즈니스를 운영하는 기술 매일, 온종일 반복하는 단 하나의 일이 결정이며, 이를 위한 일반

news.hada.io

extends가 진짜 의미하는 것

2mukee — Fri, 10 Jul 2026 22:32:37 +0900

선요약

- 타입스크립트의 모든 타입은 unknown부터 never까지 계층을 이루며, 좁은 타입에서 넓은 타입으로만 안전하게 할당됨

- 객체 타입은 이름이 아니라 구조를 기준으로 호환성을 판단하며, extends 역시 결국 "할당 가능한가?"를 검사하는 문법

- Conditional Type, 제네릭 제약, 타입 좁히기는 모두 같은 타입 계층과 호환성 규칙 위에서 동작하는 개념

unknown과 never

타입 계층도의 맨 꼭대기에는 unknown이, 맨바닥에는 never가 위치

이 두 타입은 계층의 양극단을 이루는 특별한 존재

unknown

모든 타입의 슈퍼 타입 (최상위 타입)

어떤 값이든 unknown 타입 변수에 할당 가능

외부 API로 부터 어떤 형태의 데이터가 들어올지 알 수 ㅇ벗는 상황에서 유용하게 사용

모든 값을 받아들일 수 있따는 점에서 any와 비슷해 보이지만,

unknown 타입의 값은 다른 타입 변수에 할당 할 수 없음

즉, 들어오는 것은 자유롭지만 나가는 것은 엄격하게 제한됨

never

모든 타입의 서브 타입 (최하위 타입)

절대 존재할 수 없는 값을 나타내며, 어떤 값도 never 타입 변수에 할당할 수 없음

실제로 never 타입이 되는 대표적인 경우는 항상 예외를 던지거나 무한 루프를 도는 함수의 반환 타입

하지만 never 자체는 모든 타입에 할당할 수 있음

any

any는 상하 관계로 설명할 수 있는 타입이 아닌, 타입 검사 자체를 우회하는 특별한 타입

모든 타입에 할당 할 수 있고, 모든 타입으로 부터 할당받을 수 있음

unknown과 never가 계층 규칙을 철저히 따르면서 안정성을 보장하는 반면, any는 그 규칙 자체를 비활성화함

any를 사용하면 타입 검사가 사실 상 무력화됨

타입스크립트를 사용하는 가장 큰 이유가 타입 안정성인데, any는 안정성을 스스로 포기하는 선택

따라서 가능한 한 unknown으로 대체하고 타입 좁히기를 통해 안전하게 사용함을 권장

기본 타입들의 위치

unknown과 never 사이에는 string, number, boolean 같은 원시 타입이 존재하고,

그 아래에 리터럴 타입이 존재

타입 호환성

업 캐스팅

좁은 타입을 넓은 타입에 할당하는 것

다운 캐스팅

넓은 타입을 좁은 타입에 할당하는 것

extends

extends는 주로 "할당 가능한가?"를 검사하는데 사용됨

Conditional Type의 extends

type IsString<T> = T extends string ? true : false;

T가 string의 서브타입인가?를 의미

즉, T가 string에 할당 가능한가를 묻는 것

타입 계층도에서 T가 string 보다 더 좁은 위치에 있으면 참

"hello"가 true가 되는 이유는 리터럴 타입이 원시 타입의 서브타입이기 때문

Exclude의 구현에도 같은 원리가 적용

제네릭 제약 조건의 extends

function getLength<T extends { length: number }>(arg: T): number {
  return arg.length;
}

T는 { length: number }의 서브타입이어야 한다는 의미

T가 최소한 length: number 프로퍼티를 가지고 있어야 한다는 의미

Reference

https://yozm.wishket.com/magazine/detail/3807/

타입 계층과 호환성, extends가 진짜 의미하는 것 | 요즘IT

타입스크립트를 사용하다 보면 extends라는 키워드를 다양한 곳에서 만나게 됩니다. Conditional Type에서는 T extends U ? X : Y 형태로, 제네릭에서는 T extends string 같은 제약 조건으로 등장합니다. 두 경

yozm.wishket.com

개발자가 글을 잘 쓴다고 판단할 수 있는 기준

2mukee — Fri, 10 Jul 2026 22:15:12 +0900

1. 목적이 분명한가

좋은 개발자 글은 왜 쓰는 글인지 바로 보임

나쁜 예:
로그인 관련해서 확인한 내용 공유드립니다.

좋은 예:
로그인 실패 시 오류 메시지가 표시되지 않는 문제가 있어 원인과 수정 방향을 공유드립니다.

2. 독자가 바로 이해할 수 있는가

개발자가 잘 쓴다는 것은 자기 머릿속에 있는 내용을 남도 이해할 수 있게 꺼내는 능력

작성자는 프로젝트 맥락을 알고 있으나 독자는 모를 수 있다

그래서 좋은 글은 필요한 배경을 적당히 제공한다

어떤 기능인가
어떤 화면인가
어떤 버전인가
어떤 조건에서 발생했는가
어떤 결과가 나왔는가
무엇을 확인해야 하는가

3. 사실과 의견을 구분하는가

개발자의 글은 정확해야한다

특히 버그 리포트, 장애 보고, 코드 리뷰, 기술 선택 문서에는 사실과 의견을 구분해야한다

사실:
Android 빌드에서 로그인 실패 시 오류 팝업이 표시되지 않습니다.

의견:
현재 UX상 사용자가 실패 원인을 알기 어렵습니다.

추측:
클라이언트에서 실패 응답을 UI로 연결하지 않은 가능성이 있습니다.

4. 애매한 표현을 구체적인 정보로 바꾸는가

개발자의 글에서 가장 흔한 문제는 애매한 표현

나쁜 예:
게임이 느립니다.

좋은 예:
보스전에서 탄환이 500개 이상 생성되면 FPS가 60에서 32로 떨어집니다.

나쁜 예:
거의 완료했습니다.

좋은 예:
기본 이동과 공격 기능은 완료했고, 피격 처리와 사운드 연결이 남아 있습니다.

5. 읽은 사람이 바로 행동할 수 있는가

개발자의 글은 대부분 행동으로 이어져야 한다

버그 리포트를 읽은 사람이 재현할 수 있어야 하고

작업 보고를 읽은 사람은 현재 상태를 판단할 수 있어야 한다

README를 읽은 사람은 프로젝트를 실행할 수 있어야 한다

코드 리뷰 코멘트를 읽은 사람은 무엇을 고쳐야하는지 알아야 한다

나쁜 예:
확인 부탁드립니다.

좋은 예:
Android 빌드에서 잘못된 비밀번호 입력 시 오류 팝업이 표시되는지 확인 부탁드립니다.

6. 구조가 정리되어 있는가

문장이 좋아도 구조가 없으면 읽기 어렵다

- 버그 리포트에 좋은 구조

제목
요약
발생 환경
재현 순서
기대 결과
실제 결과
로그
첨부 자료
추정 원인

- 기술 선택 문서에 좋은 구조

문제 상황
선택지
비교 기준
장점과 단점
최종 선택
선택 이유
위험 요소
후속 작업

7. 제목만 봐도 핵심이 보이는가

제목은 글의 입구

나쁜 예:
로그인 문제

좋은 예:
Android 빌드에서 로그인 실패 시 오류 팝업이 표시되지 않음

나쁜 예:
성능 개선 보고

좋은 예:
오브젝트 풀링 적용 후 보스전 FPS가 32에서 58로 개선됨

8. 기술적 정확성이 있는가

개발자의 글은 문장이 자연스러워도 기술 정보가 틀리면 좋은 글이 아님

특히 정확해야하는 것들은 아래와 같음

엔진 버전
라이브러리 버전
API 이름
파일 경로
클래스 이름
메서드 이름
설정 위치
명령어
오류 메시지
수치
테스트 결과

9. 필요한 만큼만 친절한가

좋은 글은 불친절하지 않지만, 불필요하게 장황하지도 않다

초급자를 위한 글이면 배경 설명이 필요하고,

팀 내부 작업 보고라면 핵심 상태가 중요하고,

기술 블로그라면 문제 해결 과정이 필요하다

API 문서라면 예외 상황과 응답 형식이 중요하다

즉, 좋은 글은 독자의 수준과 상황에 맞게 설명량을 조절한다

10. 협업을 덜 꼬이게 만드는가

이것이 최종 기준

"이 글이 협업을 더 쉽게 만드는가?"

좋은 개발자 글은 질문과 오해를 줄이고 재현 시간을 줄인다

그리고 수정 방향을 분명하게 만든다

또, 미래의 내가 봐도 이해할 수 있다

결국 개발자가 글을 잘쓴다는 평가는 "글이 멋있다" 보다는 "같이 일하기 편하다"에 가깝다

개발자 글쓰기 평가표

개발자 글쓰기 평가 기준

1. 목적
- 이 글이 왜 쓰였는지 바로 알 수 있는가?

2. 독자 이해
- 처음 읽는 사람도 핵심을 이해할 수 있는가?

3. 구체성
- 애매한 표현 대신 조건, 수치, 대상, 결과가 들어 있는가?

4. 정확성
- 버전, 경로, 코드, 로그, 수치가 정확한가?

5. 구조
- 글의 종류에 맞는 순서로 정리되어 있는가?

6. 행동 가능성
- 읽은 사람이 다음에 무엇을 해야 하는지 알 수 있는가?

7. 사실과 의견 구분
- 확인한 사실, 작성자의 판단, 추측이 구분되어 있는가?

8. 간결함
- 불필요한 문장과 반복 표현이 줄어 있는가?

9. 제목
- 제목만 보고 글의 핵심을 예상할 수 있는가?

10. 협업 효과
- 이 글이 질문, 오해, 재작업을 줄이는가?

한 줄 요약

문제 상황을 정확히 정리해서 다른 사람이 빠르게 이해하고 행동하게 만드는 능력

Reference

https://wikidocs.net/367737

Chapter 07. 개발자가 글을 잘 쓴다고 판단할 수 있는 기준

## 1. 목적이 분명한가 좋은 개발자 글은 왜 쓰는 글인지 바로 보입니다. 예를 들어 글의 목적이 다음 중 무엇인지 명확해야 합니다. ```text 문제 공유 버그 재현 …

wikidocs.net

AI와 함께 일하며 복리처럼 쌓아 성장하는 법

2mukee — Fri, 10 Jul 2026 21:35:14 +0900

1. 컨텍스트를 인프라로 구축

모든 코드를 ~/src에, 지식 작업을 ~/vault(projects/, notes/, kb/ 등)에 정리하면 모델이 grep이나 glob으로 컨텍스트를 검색하기 쉬워짐

조직의 컨텍스트 (Slack, Drive, Mail 등)를 MCP로 모델에 연결 가능

새 세션마다 모델은 백지 상태에서 시작하므로, 프로젝트별 CLAUDE.md를 신입 온보딩 문서처럼 작성해야함

> 약어 용어집, 프로젝트 코드네임, 동명이인 구분 등을 포함

> INDEX.md, TODOS.md 등 특정 주제 노트 순으로 읽기 순서를 지정

메모리 레이어를 두 가지로 분리 운영

~/vault: 프로젝트 상태, 산출물, 도메인 지식 등 사실 정보 저장

~/.claude (CLAUDE.md, skills/, guides/): 선호도, 워크플로, 개인 취향 등 설정 저장

2. 취향을 설정으로 인코딩

~/.claude/CLAUDE.md 활용

모든 세션 시작 시 클로드가 읽는 행동 계약서 역할

디렉터리 별 스코프 구분

글로벌: 행동, 장기 목표, 학습 선호 등 모든 곳에 적용되는 설정

레포 루트: 린팅, 네이밍, PR 컨벤션 등 레포별 규칙

프로젝트 디렉터리: 디렉터리 구조, 도메인 지식 등 프로젝트 특화 컨텍스트

클로드 코드는 하위 디렉터리에서 시작하면 트리를 올라가며 각 CLAUDE.md를 로딩

CLAUDE.md가 길어질 때의 분리 전략

긴 CLAUDE.md는 매 세션마다 전체를 로딩하는 컨텍스트 세금이됨

@import 대신 CLAUDE.md에 "관련 시 읽기" 형태로 가이드 파일 경로만 명시하여 lazy loading 구현

주 1회 이상 반복 작업은 스킬로 전환

스킬 이름, 트리거, 절차를 담은 마크다운 워크플로 파일

/polish, /write, /daily, SKILL.md

스킬 부트스트래핑 방법

작업을 한 번 대화형으로 수행한 뒤, 모델에게 스킬로 만들어 달라고 요청

동일하거나 유사한 작업에 스킬을 실행하고, 출력 교정은 같은 세션 내에서 수행

모델에게 교정과 피드백을 바탕으로 스킬을 업데이트 하도록 요청

트랜스크립트를 통한 스킬 개선

첫 버전은 원본 세션에 과적합(overfit) 되는 것이 정상

SKILL.md를 직접 편집하지 말고, 세션 내에서 교정하여 before-and,after 쌍이 트랜스크립트에 축적 되도록함

출력이 만족스러우면 모델에게 피드백을 스킬에 병합하도록 요청 > 수 라운드 후 스킬이 수렴

모든 작업에 이 컨텍스트가 필요한 것은 아님

브레인스토밍, 탐색, 초안 작업에는 심플 모드 사용

3. 자율성을 위한 검증

모델이 스스로 작업을 검증할 수 있도록 구성

브라우저 렌더링 출력이면 Claude in Chrome으로 검사

Docker 이미지 빌드 시 에러를 읽고 Dockerfile을 수정 후 재빌드

4. 위임을 통한 확장

점점 더 큰 작업 단위를 위임

짧은 작업과 빠른 피드백의 페어 프로그래밍 방식은 빠른 반복, 탐색적 분석, 프로토타이핑에 적합

더 강력한 모델에는 의도, 제약 조건, 성공 기준을 사전에 설명하고 모델이 end-to-end로 실행하도록 위임해야함

검증할 수 없는 것은 위임할 수 없으므로, 성공 기준과 메트릭 정의가 선행 필요

병렬 세션 운영과 병목 파악

큰 작업 위임으로 동시에 3~6개 세션 병렬 실행 가능

Reference

https://news.hada.io/topic?id=29606

AI와 함께 일하며 복리처럼 쌓아 성장하는 법 | GeekNews

AI와의 협업에서 컨텍스트 제공, 취향 설정, 검증 자동화, 위임 확대, 피드백 루프라는 다섯 가지 원칙을 체계적으로 정리한 실무 가이드 모든 작업 산출물(코드, 문서, 분석, 결정)이 다음 세션의

news.hada.io

바이브 코딩 관련 좋은 글 모음

2mukee — Fri, 10 Jul 2026 21:19:57 +0900

https://www.samsungsds.com/kr/insights/essential-vibe-coding-tools.html

지능형 지식 생태계를 완성하는 바이브 코딩 도구 19선 | 인사이트리포트 | 삼성SDS

정교한 문법 대신 ‘의도’와 ‘느낌’으로 앱을 구축하는 바이브 코딩의 시대가 열렸습니다. 비즈니스 아이디어를 즉시 현실로 구현하며 앱 개발의 민주화를 이끄는 19가지 혁신 도구를 살펴

www.samsungsds.com

https://wikidocs.net/330866

04. 스킬(Skills) 시스템으로 기능 확장하기

## 스킬(Skills) 시스템으로 기능 확장하기 [TOC] > **이 장에서 배울 것**: 커스텀 스킬 YAML을 작성하고, ClawHub에서 스킬을 검색·설치하며, 스킬 …

wikidocs.net

https://wikidocs.net/366542

2-3. DESIGN.md 해부 — 섹션별로 다듬기

`omd:init`이 만들어준 DESIGN.md는 출발점입니다. 이번 장에서는 파일을 직접 열어 각 섹션이 실제 UI 작업에 어떻게 작용하는지 확인하고, 우리 서비스에 맞게 다듬…

wikidocs.net

https://brunch.co.kr/@hailey-kim/17

요즘 디자이너들은 무슨 바이브코딩을 할까?

디자이너의 바이브코딩 트렌드 4가지 | 요새 바이브코딩에 빠졌다. 시작은 작은 토이 프로젝트였다. 디자인 업무를 돕는 피그마 플러그인을 하나 바이브코딩으로 만들어서 사내에 배포해봤는데

brunch.co.kr

https://okky.kr/user/191669/articles/1558278

LLM의 작동원리 (How LLMs work) | OKKY

이 글은 LLM이 어떻게 작동하는지 따라가는 walkthrough임.현대 LLM은 대체로 transformer block을 반복해서 쌓아 만듦.그래서 transformer의 핵심 기계를 이해하면 전체 구조 대부분을 따라갈 수 있음.현대 tr

okky.kr

플랫폼 엔지니어링의 모든 것

2mukee — Fri, 10 Jul 2026 21:15:00 +0900

플랫폼 엔지니어링이 존재하는 이유

과잉 일반화 늪 (Over-General Swamp)

클라우드와 OSS가 큐, 오브젝트 스토어, 데이터베이스, CI 러너, 서비스 메시 등 무한한 프리미티브를 제공하면서 각 애플리케이션 팀이 서로 다른 선택을 하게 됨

모든 서비스가 자체 배포 파이프라인, 재시도 로직, 모니터링 관례, 미묘하게 잘못된 IAM 바인딩을 갖는 "글루 코드의 늪"으로 변질

플랫폼 엔지니어링이 실제로하는 네 가지

개발자가 보는 프리미티브를 제한하여 큐레이션된 방식으로만 사용하도록 유도

반복적 배관 작업을 공유 서비스로 흡수해 애플리케이션 별 글루 코드를 감소

기반 프리미티브 변경 시 플랫폼 팀이 한 번만 처리하여 마이그레이션 비용을 중앙화

개발자가 리눅스 커널 전문가가 되지 않고도 자신이 만든 것을 직접 운영할 수 있도록 지원

DevOps는 "개발자가 운영을 소유하라" 였고, 플랫폼 엔지니어링은 "그 운영을 위한 좋은 도구를 실제 제품으로 제공하겠다"는 것

다섯가지 기둥

큐레이션된 제품 접근 (Curated Prodect Approach)

플랫폼이 지원하는 것과 지원하지 않는 것을 의도를 가지고 결정

팀이 원하는 것을 거절하는 것도 업무의 일부

소프트웨어 기반 추상화 (Software-Based Abstractions)

플랫폼은 위키가 아닌 소프트웨어이며, 인터페이스는 API, CLI, SDK

개발자가 작은 선언적 파일을 작성하는 것만으로 프로덕션급 서비스를 프로비저닝 할 수 있어야함

CNCF 산하 Score 프로젝트가 대표적 사례

워크로드 스펙 하나로 데이터베이스, 토픽, 서비스 계정, 배포를 자동 프로비저닝

(개발자는 내부적으로 Cloud SQL, Pub/Sub, Cloud Run인지 알 필요 없음)

OSS 커스터마이징과 메타데이터 레지스트리

바닐라 Argo CD나 Backstate를 그대로 쓰지않고, 조직에 맞는 플러그인, 기본 정책, 통합을 적용해 운영

메타데이터 레지스트리 (서비스 카탈로그)가 없으면 누가 무엇을 소유하고, 의존 관계가 어떻고, 실제 무엇이 실행 중인지 파악 불가

Backstage가 이 레이어의 사실상 표준 OSS 프레임워크로, 270개 이상 프로덕션에서 운영

광범위한 사용자 기반 서비스

내부 플랫폼은 소수의 매우 목소리 큰 고객을 보유하지만, 중간 값 개발자의 중간 값 작업을 잘 지원하는 것이 목적

엘리트 사용자만을 위해 구축하면 나머지 팀이 플랫폼을 우회하면서 섀도우 플랫폼이 탄생

파운데이션으로 운영

플랫폼이 다운되면 회사가 다운되므로, 24/7 온콜, 실제 SLO, 실제 변경 관리, 지원 부담이 수반

"도구"가 아닌 "바닥" 역할이며, 위에 구축되는 모든 것이 바닥이 견딘다고 가정

시작 시기와 방법

플랫폼 팀을 너무 일찍 만들지 말 것

엔지니어 10명 규모에서는 플랫폼 팀이 아닌 협력이 필요

(한 명이 배포 스크립트, 다른 한명이 테라폼을 관리하고, 관례에 합의하면 충분)

기존 인프라 조직 전환

인프라/SRE 팀을 플랫폼 조직으로 전환할 때 가장 어려운 부분은 기술이 아닌 문화

인프라 담당자는 "안된다"의 게이트키퍼 역할이지만, 플랫폼 담당자는 "쉬운 예스를 제공하는 사람"이 되어야함

PM을 위에 뿌리고 끝내는 것이 가장 흔한 실패 모드이며, 이는 플랫폼이 아닌 연극을 만들어냄

플랫폼 팀 구축

네 가지 역할

소프트웨어 집중이 과하면 아름다운 포털이 실제 부하에서 무너지고, 시스템 집중이 과하면 견고한 클러스터를 아무도 티켓 없이 사용 불가

- Software Engineer

API, SDK, 포털 등 플랫폼의 제품 표면 구축

- Systems Engineer

쿠버네티스, 리눅스, 네트워킹, 클라우드 컨트롤 플래인 등 기반 프리미티브에 정통

- Reliability Engineer

운영 품질, 온콜, SLO, 관측성에 집중

- Systems Specialist

데이터베이스, 보안, 네트워킹 등 깊은 도메인 전문가

채용

고객 공감을 최우선으로 채용해야함

좌절한 앱 개발자와 통화 후 문제를 명확히 이해하고 나올 수 없는 엔지니어는 적합하지 않음

공감 없는 기술적 탁월함은 정확하지만 아무도 쓰지 못하는 플랫폼을 만들어냄

소프트웨어 역할에는 동일한 레벨 매트릭스를 쓰되, 시스템 스페셜리스트는 시장 가치와 스킬이 소프트웨어 엔지니어 래더에 깔끔하게 매핑되지 않으므로 유연한 직함 적용

관리자 및 기타 역할

- 훌륭한 플랫폼 엔지니어링 관리자의 세 가지 공통 특성

> 실제 플랫폼 운영 경험

> 장기 멀티 쿼터 프로젝트 배포 경험

> 디테일에 대한 집착

PM, 테크니컬 라이터, 개발자 애드보킷, 지원 엔지니어 모두 중요하지만 엔지니어링 팀이 충분히 성숙한 후에 채용

실제 우선순위

1순위

지원 범위를 결정하고 문서화하며 방어

2순위

위키가 아닌 소프트웨어 추상화에 투자 (Score, Crossplane, 자체 SDK 등 실제 API가 있는 소프트웨어)

3순위

메타데이터 레지스트리 구축 (Backstage 등으로 무엇이 어디서 실행되고 누가 소유하는지 파악)

4순위

가장 시끄러운 팀이 아닌 중간값 팀을 위해 구축

5순위

SLO, 온콜, 지원 티어 등 운영을 일급 기능으로 취급

6순위

시스템 역량만큼 공감 능력을 기준으로 채용

7순위

격주 성과·도전, 투명한 로드맵, 솔직한 이해관계자 관리 등 무자비한 소통

8순위

필요 없는 것을 종료, 통합, 거절

Reference

https://news.hada.io/topic?id=29603

플랫폼 엔지니어링의 모든 것: 왜 필요하고, 어떻게 구축하며, 성공은 어떤 모습인가 | GeekNews

내부 엔지니어를 사용자로 삼아 내부 제품을 구축·운영하는 조직적 규율로서, 단순히 DevOps 리브랜딩이나 Kubernetes 클러스터 관리와는 본질적으로 다른 영역 2025 DORA 보고서에 따르면 조직의 90%

news.hada.io

2mukee Lab

정보보안기사에 대해 알아보자

정보보안기사 (Engineer Information Security)

기본 정보

응시 자격

시험 구성

필기 시험 과목

실기 시험

자주 나오는 공격

보안 장비

반드시 암기해야 하는 포트 번호

대표 암호 알고리즘

보안 인증

공부 비중 추천

추천 공부 순서

추천 공부법

SQLP를 준비하는 mySQL 개발자를 위한 오라클 SQL와 mySQL의 차이

1. NULL 처리

Oracle

MySQL

표준 SQL

2. 조건문

Oracle

MySQL

3. 현재 날짜

Oracle

MySQL

4. 문자열 연결

Oracle

MySQL

5. LIMIT

Oracle (12c 이상)

MySQL

6. OFFSET

Oracle

MySQL

7. ROWNUM

Oracle

MySQL

8. AUTO_INCREMENT

Oracle

MySQL

9. DUAL 테이블

Oracle

MySQL

10. 날짜 더하기

Oracle

MySQL

11. 날짜 차이

Oracle

MySQL

12. 문자열 길이 (동일)

13. 대문자/소문자 (동일)

14. 문자열 자르기 (동일)

15. 문자열 위치

Oracle

MySQL

16. REPLACE (동일)

17. TRIM (동일)

18. ROUND (동일)

19. CEIL / FLOOR (동일)

20. MOD (동일)

21. CAST (동일)

22. TO_CHAR

Oracle

MySQL

23. TO_DATE

Oracle

MySQL

24. TO_NUMBER

Oracle

MySQL

25. 실행계획

Oracle

MySQL

26. MERGE

Oracle

MySQL

27. UPDATE JOIN

Oracle