공정 노드 TSMC 주요 핵심 기술 경쟁사 주요 기술 TSMC 대비 강점 포인트
2nm (N2) GAAFET, BSPDN, 고급 EUV, SRAM 수율 향상 인텔: RibbonFET (GAAFET 변형), 삼성: 2세대 GAAFET, MBCFET 조기 상용화,
수율 안정,
BSPDN 기반 전력 관리 우수
3nm (N3) FinFlex 아키텍처, 신형 FinFET, HPC·모바일 최적화 삼성: 3nm GAAFET, 인텔: 3nm RibbonFET 높은 생산 능력,
다중 PPA 최적화,
폭넓은 고객사 확보
4nm (N4) N5 개선판, 고효율 FinFET, EUV 최적화 삼성: 4nm 유사 GAAFET 기술 적용 생산 안정성 및 수율 우수,
대규모 양산 경험
5nm (N5) EUV, 고효율 FinFET, 모바일·HPC 균형 삼성: 5nm GAAFET, 인텔: 7nm 일부 조기 양산,
다수 고객사 확보,
수율 및 품질 우수
6nm (N6) N7 기반 진화형 FinFET, 전력 효율과 성능 향상 삼성, 인텔 중간 공정 안정적 중간 공정 공급,
가격 대비 성능 경쟁력
7nm (N7) FinFET, 고밀도 배선, HPC 최적화 인텔: 7nm RibbonFET 개발 중 대량 생산 경험,
광범위한 고객 지원
10nm (N10) FinFET, 저전력 설계, 안정성 개선 삼성: 10nm 이상 공정  
12nm (N12) FinFET, 저전력, 중급 성능 균형 - 중견 공정 시장에서 가격·성능 밸런스 우위
16nm HKMG, 저전력, 자동차·산업용 안정성 인텔 14nm, 삼성 14nm 공정 제조 안정성, 자동차 산업 인증과 양산 경험
28nm HKMG, 멀티게이트 트랜지스터, 저전력 집중 삼성 28nm 공정 높은 웨이퍼 가용량, 넓은 글로벌 고객 네트워크
40nm 이상 전통적 planar 트랜지스터, 산업용/오래된 제품용 - 안정된 산업용 공급, 긴 수명

 




애플, 엔비디아, AMD 주식을 사는 효과겠네 ㅎ

 

공정 노드 대표제품/고객 매출 비중(포션) 2023 매출(USD) 출시/적용 연도 키포인트 신규 기술
3nm (N3) Apple 약 23~25% 약 29억 2023~2024 최첨단 모바일/HPC FinFlex, 차세대 FinFET
3nm (N3) NVIDIA 약 11%     AI/HPC 가속기 CoWoS 고급 패키징
3nm (N3) AMD 약 11%     서버 CPU/AI HPC 최적화
5nm (N5) Apple 약 23~25% 약 69억 2020 모바일/HPC 주도 EUV, 고효율 FinFET
5nm (N5) Qualcomm 약 8%     모바일/AP 저전력, 포트폴리오 확대
5nm (N5) MediaTek 약 9~10%     AP/모바일 보급형 최적화
5nm (N5) NVIDIA, AMD 각각 11% 이하     서버/AI 고성능/패키징 강화
7nm (N7) Intel, AMD 각 7~11% 약 42억 2018~ HPC, x86 서버 FinFET
7nm (N7) NVIDIA 약 11%     AI/HPC 고성능 생산
28nm 이하 다수 (자동차 등) 합계 25% 이하 약 35~52억 2011~ 자동차, IoT 안정생산 저전력/HKMG

``` 이 HTML 코드는 공정별 대표 제품과 고객사별 매출 비중, 2023년 USD 매출, 출시 연도, 핵심 키포인트 및 신규 기술을 표로 보여줍니다. 3nm와 5nm 등 주요 공정에서 고객별 매출 비중을 상세히 나누어 포함했습니다. 출처 퍼플렉시티 AI




참고자료 . 퍼플렉시티 AI 답변자료입니다. 

미국에서도 3나노 생산중 맞나?

다시 찾아보니, 미국 애리조나 팹에서

25년부터 5nm 칩 시작
26년부터 2공장에서 3nm 칩 생상 계획중
29년부터 3공장에서 2nm 칩 생상 예정

공정 노드 팹 위치(나라) 상태 상세 위치 및 내용
2nm 대만 현재 가동 중 신주(바오산) Fab 20, 초기 양산 및 파일럿 생산 중
2nm 미국(애리조나) 건설 중 애리조나 2번째 팹(P3), 2026년 이후 양산 목표
3nm 대만 현재 가동 중 신주, 타이난 Fab 여러 곳에서 최첨단 양산
3nm 미국(애리조나) 현재 가동 중 애리조나 Fab 21, 3nm 생산 중
3nm 미국(애리조나) 확장 계획 3nm 라인 추가 확장 중
4nm 대만 현재 가동 중 신주, 타이난 등 Fab에서 양산
5nm 대만 현재 가동 중 신주, 타이난 Fab 여러 곳에서 양산
5nm 미국(애리조나) 현재 가동 중 애리조나 Fab 21, 5nm 생산 중
5nm 미국(애리조나) 확장 계획 5nm 생산 라인 확장 중
6nm 대만 현재 가동 중 신주, 타이중 등 Fab에서 중급 공정 양산
6nm 일본(구마모토) 현재 가동 중 구마모토 Fab 23, 6nm급 라인 중심
6nm 중국 현재 가동 중 난징, 상하이 Fab에서 일부 6nm 이상 공정 운영
6nm 일본(구마모토) 확장 계획 6nm 라인 추가 확장 중
6nm 독일(드레스덴) 신규 계획 12~28nm급 신규 팹 건설 중 (2027년 완공 예정)
7nm 대만 현재 가동 중 신주, 타이난 Fab에서 주력 생산
7nm 미국(워싱턴) 현재 가동 중 워싱턴 카마스 Fab에서 7nm 생산
7nm 미국(워싱턴) 확장 계획 7nm 라인 확장 검토 중
10nm 대만 현재 가동 중 신주, 타이난 Fab 일부
10nm 미국(워싱턴) 현재 가동 중 워싱턴 Fab에서 일부 라인 운영
10nm 미국(워싱턴) 확장 계획 10nm 라인 확대 검토
12nm 대만 현재 가동 중 신주, 타이중 Fab에서 중급 공정
12nm 일본(구마모토) 현재 가동 중 구마모토 Fab에서 중급 공정
12nm 중국 현재 가동 중 난징, 상하이 Fab 일부
12nm 일본(구마모토) 확장 계획 라인 추가 예정
16nm 대만 현재 가동 중 타이중, 신주 Fab 등에서 생산
16nm 일본 현재 가동 중 구마모토 Fab에서 일부
16nm 중국 현재 가동 중 일부 구공정 팹 운영
16nm 일본(구마모토) 확장 계획 신규 라인 추가
28nm 대만 현재 가동 중 타이중, 신주 Fab 등
28nm 일본 현재 가동 중 구마모토 Fab 일부
28nm 중국 현재 가동 중 난징, 상하이 팹 일부
28nm 일본(구마모토) 확장 계획 신규 라인 추가
40nm 이상 대만 현재 가동 중 구공정 팹, 주로 산업용
40nm 이상 중국 현재 가동 중 구공정 팹 일부 운영
40nm 이상 - 계획 없음 -

``` 이 HTML 표는 일본(구마모토) 팹 위치 행에 연한 회색 배경색(#f0f0f0) 음영 처리되어 구분됩니다. 필요시 스타일 조정 가능합니다. 출처




AI로 코딩하기. 바이브코딩

방법론이 있네

프롬프트를 역시 잘해야되는데, 생각의 관점을 바꿔야함.

일차원적인 요구가 아니라.

체계적인 준비된 요구를 해야됨.

일을 시키더라도 빡세게 시켜야됨.

예) 어떠어떠한 앱을 만들어줘 가 아니라.

일반인이 앱을 만들어줘가 아니라, 전문 개발자 입장에서 앱을 만들어줘 해야됨.

전문가의 입장에서 특정 요건의 앱을 만들기 위함. PRD 문서(요구사항정의서)를 작성해죠하고

그 문서를 좀더 보강한 다음.

문서에 기반한 디테일한 요구사항으로 AI 에게 개발해달라고 요청한다.

충분한 정보를 줘야된다.

기획단계를 충분히 가져간다.

추가

상세기능명세서를 만들어줘 해도됨.

UI/UX 문서도 만들어달라한다.

최종적으로 종합된 앱기획서를 만들어달라고 한다.

→ 요건 저장해놓고 내 자산으로 갖고 간다.

이제 최종 앱기획서를 바탕으로 코드를 생성해달라고 한다.

단, 전문개발자가 아닌 이상, 각각의 코드파일이 아니라,

하나의 파일에 모두 종합해서 넣어달라고 한다.

그러면 퍼블리싱이 그만큼 쉽다.

여러번의 프롬프트를 통해 계속 해서 수정해나가는 것도 방법이지만.

디테일한 기획 및 전문가의 프로세스를 통해서,

얻어낸 기획문서를 이용하여 한번에 앱 코드를 생성해달라는 것이,

오히려 시간과 노력을 절약할 수 있고,

인간으로써 뭔가 의미있는 일을 했다는 보람도 있을 것 같다.

중간과정을 생략해버리고 결과만 얻는다면, 거기서 배움도 없고 깨달음도 없을 것이다.

요약 • **AI로 코딩(바이브코딩)**을 할 때는 단순히 "앱을 만들어줘" 식의 요구가 아니라, 체계적이고 준비된 요구를 해야 한다. • 프롬프트 작성 시 일차원적 접근이 아닌, 전문가의 시각에서 구체적인 요구사항을 제시해야 한다. • 예를 들어, 일반인의 언어가 아니라 **전문 개발자 입장에서 PRD(요구사항정의서)**를 먼저 작성하고, 이를 보강해 상세한 요구사항으로 AI에게 요청해야 한다. • 기획 단계를 충분히 거치고, 필요하다면 상세 기능 명세서, UI/UX 문서 등도 요청해 최종 앱 기획서를 만든다. • 이 기획서를 자산으로 저장해두고, 최종적으로 앱 코드를 한 파일로 생성해달라고 요청하면 퍼블리싱이 쉬워진다. • 여러 번 프롬프트를 수정하는 방법도 있지만, 전문가 프로세스에 따라 기획문서를 완성한 뒤 한 번에 코드를 생성하는 것이 시간과 노력을 절약할 수 있다. • 결과만 얻는다면 배움과 깨달음이 없으니, 중간 과정을 충분히 경험하는 것이 중요하다.

덧붙이고 싶은 내용 • **AI 활용의 핵심은 "명확한 의도와 정보 제공"**에 있다. AI는 사용자가 제공한 정보의 범위 내에서만 최적의 결과를 내놓을 수 있으므로, 요구사항을 구체적으로 정리하는 습관이 중요하다. • 협업과 피드백 과정도 간과하지 말아야 한다. 중간 산출물을 검토하고, 필요한 부분을 수정·보완하는 과정을 통해 완성도를 높일 수 있다. • 기획서 작성 능력은 AI 시대에 더욱 중요한 역량이 된다. 이는 단순히 코딩을 잘하는 것보다, 문제를 정의하고 구조화하는 능력이 더 큰 가치를 갖게 됨을 의미한다. • 최종 산출물에만 집중하지 말고, 과정에서 얻는 인사이트와 성장에 주목하는 것이 장기적으로 더 큰 도움이 된다.




 

 부팅순서 ~2003버전까지

1 BIOS POST 실행 / HW레벨 문제검사, 경고음
2 BIOD CMOS설정사항을 읽어 시스템에 적용
3 MBR 로드 (저장매체의 첫번째 섹터 512바이트 영역, 부팅매체의 기본파일시스템 정보가 들어있음)
(저장매체의 첫번째 섹터를 호출하여 부트코드를 실행)
4 NTLDR실행
부팅파티션에
있는 프로그램
간단한
파일시스템을 실행하고, boot.ini파일을 읽어 가능한 부팅옵션을 보여준다.
5 NTDETECT실행
하드웨어
검사 레지스트에 반영함 HKEY_LOCAL_MACHINE
6 ntoskrnl.exe 실행
커널로드
, 초기화
서비스로드
(세션관리자서브시스템 smss, 32서브시스템) 

서브시스템시작

서브시스템시작 자세히
Win32서브시스템은 로그인처리, 계정/패스워드 입력받아 로컬보안인증서버(Lsass.exe) 보낸다
SAM(보안계정관리자) 저장된 정보와 비교하면
다음 Userinit.exe프로세스가 레지스트리 winlogon 참조되는 셸을 실행함.

 

비스타 이후 버전~

1 BIOS POST 실행 / HW레벨 문제검사, 경고음 상동
2 BIOD CMOS설정사항을 읽어 시스템에 적용 상동
3 MBR 로드 (저장매체의 첫번째 섹터 512바이트 영역, 부팅매체의 기본파일시스템 정보가 들어있음)
(저장매체의 첫번째 섹터를 호출하여 부트코드를 실행)
상동
4 윈도우부트 서브시스템 실행
bootmgr.exe 실행 , BCD(부트설정데이터) 읽어 실행

5 Winload.exe 실행
각종
장치 드라이버 로드

6 ntoskrnl.exe 실행
커널로드
, 초기화
서비스로드
(세션관리자서브시스템 smss, 32서브시스템) 

서브시스템시작
상동

서브시스템시작 자세히
Win32서브시스템은 로그인처리, 계정/패스워드 입력받아 로컬보안인증서버(Lsass.exe) 보낸다
SAM(보안계정관리자) 저장된 정보와 비교하면
다음 Userinit.exe프로세스가 레지스트리 winlogon 참조되는 셸을 실행함.
상동

 

 

윈도우 하드웨어-HAL-마이크로커널-각종관리자-응용프로그램
유닉스 하드웨어-커널--응용프로그램

 

유닉스는 개별관리자 프로그램이 없으며, 커널크기도 윈도우의 1/3

그리고 윈도우와 다른점은 셸을 지원

 

유닉스 부팅순서

  1. POST실행
  2. 기본부팅관련 설정 로드
  3. MBR로드
  4. 부트로더실행

Lilo.conf 혹은 grub.conf

  1. Pid 0 프로세스 실행 -> pid 1(init프로세스) 실행 -> inittab파일 읽기



--------------------------------------------------------------------------------------------------------------------------------

파일시스템

운영체제는 저장장치를 클러스터 단위로 관리한다.

FAT12 , 2 12승개, 4096 클러스터

FAT16 , 2 16승개, 65536 클러스터

FAT32 , 2 32, 42억개 클러스터

클러스터당 저장용량 4KB라면

FAT32 17TB

16KB라면 FAT32 최대 68TB 이지만

MS FAT32 최대크기 32GB 제한함. (자세한 이유는 아래 블로그)

https://cappleblog.tistory.com/223

 

암튼 과거에 4KB 저장용량 클러스터는 낭비가 적음. 실제 파일이 저장되고 남은 빈공간이 없다는 .

이게 최근에 와서는 의미가 없어진듯.

암튼 윈도우 11에서 FAT32 32GB 제한을 없앰? -> 2TB까지 가능

-------------------------------------------------------------------------------------------------------------------------------------

FAT 2GB까지 파티션 사이즈로 설정가능

-------------------------------------------------------------------------------------------------------------------------------------

FAT32  32GB

최대파일크기 4GB

리눅스/ 호환성?

접근제어 없음

-------------------------------------------------------------------------------------------------------------------------------------

NTFS

접그제어 제공, 개별파일,폴더 단위

파일 폴더단위 암호화

감사기능

MFT 예약공간 필수(모든 파일 정보가 기록되는곳) Master File Table

최초 파티션 생성 MFT공간 예약되나, 점점 사용하면서,

일반 영역이 차면, 예약공간을 침범하면서 MFT공간 단편화가 발생함

-> 느려짐. (HDD 였을때…)

-> 그래서 15% 여유는 항상 유지하라고 했으나, 요새 SSD에서는 의미 없음.

 

MFT파일 분석하는 프로그램이 있음.

- analyzeMFT 수정판 (by koha)

https://kkoha.tistory.com/entry/analyzeMFT-204

 

Csv 내보내기해서 구경가능

analyzeMFT.exe -f $MFT -o C_MFT.csv -lp

 

MFT파일은 당연히 사용중이므로

forecopy나 FTKImager 등을 이용하여 추출한 파일을 지정

출처: <https://net-gate.tistory.com/104>

 

 

 

이파일만 털어가면...

-------------------------------------------------------------------------------------------------------------------------------------




 

윈도우 역사, 제품명-출시년도 순서

MSDOS 1.0 1981

MSDOS 2.0 1983
윈도우 1.0 1985

윈도우 NT New Technology
1993
윈도우 95

윈도우 ME 1999
NT 4.0 1996

XP 2001 서버 2000
서버
2003

비스타 2007 서버 2008

윈도우 7 2009

윈도우 8 2012 서버 2012

윈도우10 2015


서버 2016


서버 2019

윈도우11 2021 서버 2022 2021


2023 30주년


서버 2025  2024가을



 

 Get

# default namespace pod조회 $ kubectl get pods
# 모든 namespace pod조회 $ kubectl get pods --all-namespaces
# pod 정보 자세히 보기 $ kubectl get pod -o wide
# pod watch mode로 보기 $ kubectl get pod -w
# default namespace deployment조회 $ kubectl get deploy
# 모든 namespace의 모든 deployment조회 $ kubectl get deploy --all-namespaces
# default namespace service조회 $ kubectl get service
$ kubectl get svc
# 모든 namespace의 모든 service조회 $ kubectl get service --all-namespaces
$ kubectl get svc --all-namespaces
#node 조회 $ kubectl get node

 Create

# test.yaml파일 작성 후 create하면 yaml파일의 내용이 생성 $ kubectl create -f test.yaml
# yaml파일의 문법이 맞는지 확인하기 $ kubectl create -f test.yaml --dry-run=client
# 명령어로 create yaml 파일로 만들기 $ kubectl create deploy test-deploy --image=nginx --dry-run=client -o yaml > nginx.yaml

 Delete

#test.yaml 파일로 생성된 내용 삭제 $ kubectl delete -f test.yaml
# 모든 자원 삭제 $ kubectl delete all --all
# 원하는 파드만 삭제 $ kubectl get pod
$ kubectl delete {pod
이름}

 Describe

# node 정보 $ kubectl get nodes
$ kubectl describe nodes {node
이름}
# pod 정보 $ kubectl get pods
$ kubectl describe pod {pod
이름}

 Exec

# Pod bash로 들어가기 $ kubectl get pods
$ kubectl exec -it {pod
이름} /bin/bash
# 특정 Pod에서 curl 실행하기 $ kubectl get pods
$ kubectl exec {pod
이름} -- curl localhost:8080

 Log

# 특정 pod의 로그 확인 $ kubectl get pods
$ kubectl logs {pod
이름}
# 특정 pod의 로그 tail $ kubectl get pods
$ kubectl logs -f {pod
이름}



'기술(Azure 만...) > [MS]Azure PaaS' 카테고리의 다른 글

App service 플랜 비교(STD vs Premium)  (0) 2024.04.30
Azure Function 정리  (0) 2023.04.13
Azure Postgresql 요약 총정리  (0) 2023.04.04
azure sql databse pass 방화벽 설정  (0) 2022.10.13
Azure Vmware Solution  (0) 2021.09.14

Azure Cloud Shell에서 복구모듈  설치, 해당 명령 안하고, 아래 repair 명령 설치할건지 물어봄. y/n

az extension add -n vm-repair

-g 리소스그룹
-n VM name

az vm repair create -g EX -n advm01 --repair-username azureuser --repair-password 'password!234' --verbose

작동하지 않는 VM에 대한 OS 디스크의 복사본을 만들고,새 리소스 그룹에 복구 VM을 만들고, OS 디스크 복사본을 연결합니다.복구 VM은 지정된 비기능 VM과 크기 및 지역입니다. 모든 단계에서 사용되는 리소스 그룹 및 VM 이름은 비기능 VM에 사용

 

az vm repair run -g EX -n advm01 --run-on-repair --run-id win-hello-world --verbose

복구 VM을 통해 연결된 디스크에서 지정된 복구 스크립트를 실행

복구스크립트는 아래 깃허브에..

https://github.com/Azure/repair-script-library/tree/main/src/windows

 

az vm repair restore -g EX -n advm01  --verbose

복구된 OS 디스크를 VM의 원래 OS 디스크로 교환

 

출처: <https://learn.microsoft.com/ko-kr/troubleshoot/azure/virtual-machines/windows/repair-windows-vm-using-azure-virtual-machine-repair-commands>

 

 

 

복구VM 동일한 스펙으로, 별도 리소스그룹에 생성됨

az vm repair restore -g EX -n advm01  --verbose

복구된 OS 디스크를 VM의 원래 OS 디스크로 교환

 

 

복구VM OS디스크

repair-advm01__OsDisk_1_65178ff7a3a84a8e88a93809df542deb

 

 

복구시 사용된 리소스그룹 전체 지울건지 물어봄 y하면 다지워짐

 

 

 




개인학습 특징

학교학습과 비교하여, 협력적이다?
비순차적이다.
자료에 한정이 없다.
명확한 평가도 없다.
대부분 정답도 없다.
목표가 불분명 있고, 항상 바뀐다.

존헌터, 론다헌터, 프랭크슈미트의 연구결과,
채용 결과적으로 봤을 , 채용 가장 효과적으로 판단해볼 있는 예측변수는?
채용 결과와의 상관성을 파악

기준
0.5
이상 : 강한 효과
0.2이하 : 약한 효과

경력 연차 0.18
학력 0.10
실제 작업 샘플 테스트 0.54
지능테스트 0.51
구조화된 인터뷰
(직무 밀접 질문)
0.51
성실성 0.41
레퍼런스 체크 0.26
나이 -0.01

, 소위말하는  5년차, 10년차라는 경력은  상관관계가 매우 낮았다.
경험이 많다 = 실력이 높다 아님

구조화된 인터뷰 예시
구체적인 프로젝트에서, 동료가 어떤 어려움을 겪었고, 본인은 어떠한 행동을 하셨는지?

이제. 뽑았으면 어떻게 할것인가?
일주일의 시간 중에 자신의 업무능력 향상을 위해 하는 일은? 시간은?

1 단위 회고
1 동안 얼마나 자기계발에 투자하였는지? 확인.
(평소 기록을 해놔야 될듯)

자기 계발
작업/작업방법을 개선할 , 단순히 더하기가 아닌 곱하기 있는 방안을 생각하라? 어렵군

자신이 이미 갖고 있는 것들을 최대한 활용하라.
내가 익힌 지식을 가지고 어떻게 활용 했었는지를 생각하라.
(회고 프로세스를 만들어라)

이미 갖고 있는 지식들을 촘촘히 연결하라.
여러 영역을 넘나들면서 생각하라.
기존과 반대되는 새로운 것이 들어오면 기존 지식과 충돌시켜라.
주기적으로 외부자극을 찾아서 받아라.
작게 자주 실패하라. 실패에서 학습하라. (애자일방법론)

강한 동기가 필요하다.
피드백 해줄 있는 사람 / 질문할 있는 사람이 필요하다.

셀프 피드백
주간보고 노트를 스스로 리뷰
월단위 수행업무를 리뷰
분기단위, 년단위 리뷰 플랜

의도적 수련
적절한 난이도의 수련
지루함이 느껴진다면 난이도를 올리고,
불안함이 느껴진다면 난이도를 낮춘다.
(쉬운문제를 풀고 나서 어려운문제를 푸는게 더욱 효과적이란다)

중간영역인 몰입을 유지하도록 노력해야된다.
본인이 어떤 상태인지 알아차리는 것도 중요함.
"메타인지전략" 이라고도함. 공부잘하는 사람들의 공통적인 특성이란다.

개발자의 경우, 자동화도구를 잠깐 사용하지 않는다던가.
디버깅 주기를 길게 가져가보는방법
지루함이 느껴진다면, 복잡성 있는 코드로 개발하려고 노력하던가.
다른 언어로 동일한 기능을 개발해보던가.등등
개발과 관련된 테스팅 도구를 직접 만들어 써보던가.

예시). 세계레벨의 스케이터가 트리플악셀을 평소에 많이 연습한다.
, 엉덩방아를 많이 찧는다.

실력을 높이는 방법은, 멘토 다른 도구의 도움을 받는 방법

관련하여, 팀장이 해줄 있는 .
몰입영역에 머물 있게 지원
적절한 난이도의 일을 적절한 타이밍에 줘야됨.
높은 난이도에 불안해하는 직원에게는 도움/독려를 줘야지, 핀잔을 주면 안된다.

 

 




+ Recent posts