내 일기장

[Insty] 북미 리전으로의 마이그레이션 (내용 추가 예정)

whkim98 — Tue, 10 Feb 2026 18:55:34 +0900

PM님께서 북미에 있는 지인 분들에게 Insty를 알리자 반응이 꽤 있어 북미에서의 서비스를 먼저 진행하기로 결정했다.

현재는 우리 서비스의 트래픽이 적은 시점이라 속도 측면에서는 그냥 두어도 상관없으나 최상의 서비스를 제공하기 위해서는 북미리전으로의 마이그레이션이 필요하다고 생각되어 진행하기로 했다.

어두처럼, 트래픽이 적은 시점이라 멀티리전을 구성하는 것은 비용으로 보나 운영 복잡도로 보나 효율적이지 않을 것으로 보여 일단은 북미 단일 리전으로 구성하기로 했다.

CloudFront origin을 이용한 배포를 하고 있었기 때문에 생각보단 간단했다.

1. RDS를 통해 DB를 사용하고 있었기 때문에 스냅샷 생성 후 북미리전으로 복제 및 revert

2. EC2 리소스(web, ai, bastion host) AMI 생성 후 북미리전으로 복제 및 create

3. s3 버킷 북미리전 생성 후 데이터 이관

4. vpc / subnet / internet gateway / routing table 등의 재구성

5. load balancer (ALB) 재구성 및 엔드포인트 설정(health check)

6. 보안그룹 재설정

7. cloud front 원본 수정

8. RDS 리전 변경에 따른 lambda endpoint 수정

9. mediaconvert endpoint 수정

~~적다 보니 많네;;~~

마이그레이션 과정에서 스냅샷 데이터 복제, DB revert, AMI 보관 등에서 비용이 발생하기 때문에 비용최적화를 생각하며 마이그레이션 하는 전략을 짜는게 좀 골치아팠다. 특히 트래픽이 적은 시점이었기 때문에 “안전하지만 비싼 방식”보다는 “짧은 시간 안에 끝내는 방식”을 선택해야 했다.

[Insty] Next.js 보안으로 인한 악성파일 이슈

whkim98 — Tue, 23 Dec 2025 14:46:31 +0900

Hello,

We've received a report(s) that your AWS resource(s)

AWS ID: xxxxx Region: ap-northeast-2 EC2 Instance Id: xxxxx

has been implicated in activity that resembles a Denial of Service attack against remote hosts; please review the information provided below about the activity.

Please take action to stop the reported activity and reply directly to this email with details of the corrective actions you have taken. If you do not consider the activity described in these reports to be abusive, please reply to this email with details of your use case.

If you're unaware of this activity, it's possible that your environment has been compromised by an external attacker or a vulnerability is allowing your machine to be used in a way that it was not intended.

We are unable to assist you with troubleshooting or technical inquiries. However, for guidance on securing your instance, we recommend reviewing the following resources:

Amazon EC2 Security Groups User Guide:
https://docs.aws.amazon.com/

어느날 서비스 중인 AWS EC2 인스턴스에 대해 AWS측에서 메일이 왔다.

내용을 요약하면,

EC2 인스턴스 (dev 인스턴스) 가 외부 서버에 대량 트래픽을 보내고 있다는 내용.
AWS에서는 인스턴스 서버를 통해 DDOS로 의심되는 공격이 진행됐다고 판단하여 메일을 보낸 것이다.

cloudtrail을 통해 확인해 봤을 때 이상 API가 호출된 것은 없고 인스턴스 내의 네트워크 트래픽에도 문제는 없었다. 따라서, 처음엔 큰 문제라고 생각하지는 않았고 내부에서 비밀번호나 키페어의 오류로 ssh 접근을 계속 시도했거나 로직에서 무한루프가 굉장히 오래 돌았다거나 하는 이유라고 생각했다.

또한, 우리 서비스는 영상 업로드 시 AI 분석을 통해 썸네일 이미지와 해당 영상의 중요한 부분을 프리뷰로 만드는 기능이 있는데 이 기능에 문제가 생겨 영상 관련한 테스트를 꽤나 오래 했었다. 이게 문제인가.... 하고 생각하던 순간

너무 문제가 없어서 일시적으로 발생했다가 종료되었을수도 있다고 생각을 했으나 또 하나의 가능성은 redis같은 서버리스 형태나 docker 컨테이너에서 트래픽 발생했을 가능성을 염두해 두고 확인한 결과

root 781284 ash /dev/stink.sh
root 1351954 ash /dev/health.sh
root 1351957 /dev/fghgf -c /dev/ijnegrrinje.json -B
root 861697 /tmp/kamd64
root 810542 ./ddd

와 같은 프로세스들이 "프론트엔드" 컨테이너에서 발견되었다.

이런 프로세스들이 프론트엔드 컨테이너에 존재한다는게 말이 안된다.. 특히 "stink.sh" 라는 파일명만 봐도 알 수 있듯이 악성파일이라는 느낌이 왔고 내용을 보니

while true; do
    for proc_dir in /proc/[0-9]*; do
        pid=${proc_dir##*/}

        if strings "/proc/$pid/exe" 2>/dev/null | grep -Eq 'xmrig|rondo|UPX 5'; then
            kill -9 "$pid"
            continue
        fi

        result=$(ls -l "/proc/$pid/exe" 2>/dev/null)

        case "$result" in
            *(deleted)* | *xmrig* | *hash* | *watcher* | */dev/a* | *softirq* | *rondo* | *UPX 5.02* )
                kill -9 "$pid"
                ;;
        esac
    done

    sleep 45
done

채굴목적으로 보이는 다른 프로세스를 주기적으로 찾아서 무차별 강제 종료하는 스크립트이다.

그럼 좋은게 아닌가 할 수 있는데 원인을 해결하지 않는 것이기 때문에

프로세스가 생기고 죽이고를 무한반복하게 되는 것이다. 채굴 악성코드는 서로 경쟁을 하기 때문에 자기의 것만 살리기 위해 다른 프로세스를 죽이는 스크립트를 같이 생성한다고 한다.

그리고 오탐의 여지가 많아 정상 서비스도 죽일 수 있기 때문에 이 자체가 DoS인 것이다.

또한, 확인해 보니 12/3 next.js에서 공식적으로 보안 이슈를 발표했다.

내용의 일부분으로

영향을 받는 Next.js 버전
App Router에서 React 서버 구성 요소를 사용하는 애플리케이션은 다음 버전에서 실행될 때 영향을 받습니다.

Next.js 15.x
Next.js 16.x
Next.js 14.3.0-canary.77 이상 canary 릴리스
Next.js 13.x, Next.js 14.x

안정 버전, Pages Router 애플리케이션 및 Edge Runtime은 영향을 받지 않습니다.수정된 버전
다음 Next.js 패치 버전에서 해당 취약점이 완전히 해결되었습니다.

15.0.5
15.1.9
15.2.6
15.3.6
15.4.8
15.5.7
16.0.7
또한 Next.js 15 및 16용 패치된 카나리 릴리스를 출시했습니다.

완전 우리 서비스에 해당하는 내용이었다 ㅋㅋ..

타임라인을 정리해 보자면

보안 사고 히스토리 타임라인

2024-12-06 12:44

insty-frontend 컨테이너 생성

프론트엔드 컨테이너 배포

2024-12-07 ~ 2024-12-09

외부 공격자 침입

외부에서 xxxx번 포트 스캔 수행
취약점 exploit 성공 → 컨테이너 침해

악성 행위

다음 파일 다운로드 및 실행
- /dev/stink.sh
- /tmp/kamd64
- /dev/fghgf
백그라운드 크립토 마이너 설치
봇넷 에이전트 설치

2024-12-09 17:50

C2(Command & Control) 서버 명령 실행

해커 C2 서버에서 “공격 시작” 명령 수신
외부 대상에 대해 약 200,000 SYN Flood 발생
결과:
- AWS Abuse Report 수신

요약

초기 침입 경로: 외부 xxxx 포트 노출
침해 대상: insty-frontend 컨테이너
공격 유형:
- 암호화폐 채굴 (Crypto Mining)
- 봇넷 감염
- DDoS(SYN Flood) 공격 가담
영향:
- 외부 공격 트래픽 발생
- AWS Abuse Report 접수

이와 관련해서 github action runner가 offline으로 바뀌며 CI/CD도 불가능한 상태가 되었다.

이 문제로 인해, AWS 팀에서 아예 outbound를 막아 놓은 상황으로 보였다.(EC2에서 Github Action 서버로 나가는 outbound HTTPS가 아예 막혀 있고, BE github runner도 offline 상태로 보이나 EC2에선 켜져 있음)

컨테이너 내부에서 악성파일이 생성되고 있었기 때문에 컨테이너, 이미지만 재배포를 진행하려 했으나 도커는 격리된 환경일 뿐 결국 호스트 서버가 뚫렸다고 보는게 맞다고 판단하여 EC2 재배포를 진행하기로 결정했다.

AMI로 새 인스턴스 생성 시 악성파일이 그대로 같이 설치되기 때문에 수동으로 마이그레이션을 진행해야 했다.

다행히 거의 모든 CI/CD 및 웹 설정을 깃헙을 통해 진행하고 있었기 때문에 백업할 내용이 많지는 않았다.

웹서버로 nignx를 사용하고 있었기 때문에 nginx의 설정 파일들에 대한 백업, 배포 관련한 키페어 파일이 있었다.

각종 env나 DockerFile 등은 프로젝트 내부에 있기 때문에 백업할 필요가 없었다.

이제 마이그레이션 순서로

1. EC2 생성 및 원본 교체

2. 서버 기본 세팅 (apt 업데이트, 도커 설치, 도커 컴포즈 설치, nginx 설치 및 백업 파일 복구)

3. 깃헙 컨테이너 레지스트리 로그인

4. 그리고 제일 중요한 self-hosted-runner 재설치

workflow의 yml에서 어떤 라벨명을 사용하는지 확인이 필요했으며 이에 따른 네이밍과 조직 단위로 사용할 수 있게 설정하는 등 꽤나 오래 걸렸던 것 같다. 어쨌든 runner 까지 설정을 마치고 이제 더미 커밋&푸쉬를 통해서 CI/CD가 정상적으로 작동하는지만 확인하면 되는데....

프론트엔드는 문제없이 진행됐지만 백엔드를 푸쉬하니 엄청난 네트워크 트래픽 폭증과 함께 서버 및 도메인 접속에 지연이 되고 결국 서버다운으로 이어지는 문제가 발생했다.

기존에 개발서버는 t2.micro를 사용하다가 시간지연의 문제를 느끼고 있던 터라 마이그레이션 하는 김에 t3.micro로 업그레이드 하고자 했는데 개선은 커녕 서버다운이라니;;

굉장히 당혹스러웠다. 찾아보니 t2는 느려도 멈추지는 않지만 t3는 스로틀링에 걸려 과부하 시 멈춰버리는 특징이 있다고 한다.

그래서 그런가.. 하고 t2로 다시 인스턴스 재설정 후 깃헙액션을 실행하니 동일한 현상으로 서버다운이 되었다.

그래서 생각한 건 메모리 문제일 수 있겠다고 생각했다. micro인스턴스는 기본적으로 1GB 메모리 사양이다.

따라서 확인해 보니 아무 작업을 하지 않을 때에도 8~900MB의 메모리를 사용 중이었다. 이러니 백엔드는 스프링부트 + redis + 도커 + runner가 동시에 발생하기 때문에 oom이 걸려 터지는 것이었다.

따라서, t3.small로 업그레이드하여 2GB 메모리 사양으로 변경 후 진행하니 아무 지연없이 CI/CD 깃헙액션이 정상 작동하였고 서버 마이그레이션 작업이 완료되었다.

[Cloud] WARNING: UNPROTECTED PRIVATE KEY FILE!

whkim98 — Sat, 11 Oct 2025 22:00:29 +0900

간혹 서버에 접속할 때

WARNING: UNPROTECTED PRIVATE KEY FILE!

해당 내용이 출력되며 서버 접속이 거부될 때가 있다.

OpenSSH 클라이언트는 pem 파일이 오직 나만 읽을 수 있어야 사용한다.
파일에 BUILTIN\Users 같은 다른 사용자/그룹의 ACL이 조금이라도 남아 있으면 “키가 보호되지 않았다(Unprotected private key)”고 보고 키를 무시하게 된다.

해결법

Windows

1) 소유권 확보 (필요시)
takeown /f "example.pem"

2) 상속 제거 (핵심!) → 부모 폴더에서 내려오는 (I) 권한 제거
icacls "example.pem" /inheritance:r

3) 다른 사용자/그룹 권한 제거
icacls "example.pem" /remove:g "BUILTIN\Users" "NT AUTHORITY\Authenticated Users" "Everyone" "BUILTIN\Administrators" "NT AUTHORITY\SYSTEM"

4) 현재 사용자(Administrator)에게만 읽기 권한 부여 (재설정)
icacls "example.pem" /grant:r "$env:USERNAME:R"

5) (선택) 소유자 명시적으로 현재 사용자로 설정
icacls "example.pem" /setowner "$env:USERNAME"

6) 확인
icacls "example.pem"

MAC/LINUX

1) ACL(접근 제어 목록) 제거 — ACL이 남아 있으면 OpenSSH가 "unprotected private key"로 인식함
chmod -N example.pem

2) 확장 속성 제거 — iCloud/Quarantine 등 mac 특유 메타데이터 삭제
# 예: com.apple.quarantine, com.apple.macl 등
xattr -c example.pem

3) 권한을 최소화 (소유자만 읽기 가능)
chmod 400 example.pem

4) 부모 폴더 권한도 점검 (보통 ~/.ssh 권장)
chmod 700 "$(dirname "$(realpath example.pem)")"

5) 확인
ls -l@ example.pem

[Insty] 인프라 구성도 및 파이프라인 설계 의도(지속 수정)

whkim98 — Thu, 2 Oct 2025 16:35:53 +0900

Insty 전체 아키텍처의 인프라 구성도이다.

1. 외부 진입(DNS, SSL)

Route 53: insty.ai.kr 과 같은 도메인에 대한 호스팅 존.

이때 레코드를 설정하게 되는데 크게 A / NS / SOA / CNAME으로 나눌 수 있다.

A	NS	SOA	CNAME
CloudFront의 배포 도메인 (AWS에서 자동 지정) 개발/스테이징 환경을 위한 별도 CloudFront 배포가 있다는 것을 의미.	AWS 네임서버 정보 Route53에서 발급해 준 네임서버 주소들로 전세계의 DNS가 해당 네임서버를 먼저 질의하게 됨.	호스팅존의 기본 설정 (갱신주기, 네임서버 권한 등) 자동으로 생성되는 레코드로 직접 건드릴 일은 없음.	ACM의 인증서 검증용 자동 레코드 HTTPS 통신을 위한 SSL/TLS 인증서를 의미. ACM은 자동 갱신을 지원하기 때문에 만료일을 신경쓰지 않아도 됨.

결국, 사용자는 insty.ai.kr에 접속하면 CloudFront 배포로 연결된다.

2. CloudFront(콘텐츠 전송)

글로벌 CDN + 보안 게이트웨이 역할을 한다.

이때 CDN이란, Content Delivery Network의 약자로 웹이나 앱의 정적 데이터(이미지, 영상 등)를 사용자와 가까운 서버에서 빠르게 전달하기 위한 전송 네트워크를 의미한다.

동작 원리

origin 서버: 실제로 웹서비스를 호스팅하는 서버.
edge location 서버: 전 세계 여러 지역에 분산된 캐시 서버.
사용자가 웹에 접속을 하게 되면 CDN이 사용자의 지리적으로 가까운 edge location 서버를 선택.
캐시된 콘텐츠가 있으면 제공.
없으면 origin 서버에서 가져와 edge location 서버에 저장 후 다음 요청부터는 바로 전달.

이때 캐시된 콘텐츠의 의미는 자주 쓰는 데이터를 미리 저장해 두었다가
필요할 때 빠르게 꺼내 사용하는 것을 의미함.

즉, origin 서버에 있는 웹파일을 CDN 서버가 복사해서 저장해 둔 데이터를 의미.

그리고 캐시는 무한정 유지되지는 않는다. TTL 지정을 통해 해당 시간이 지나면 위 과정을 다시 거치게 된다.

멀티 오리진 라우팅을 통해 트래픽을 분배시키는 것도 가능하다.

최종적으로는 모든 사용자의 요청은 CloudFront를 통해 배포되게 된다.

CloudFront는 AWS의 핵심 서비스 중 하나로 따로 자세한 포스팅을 추가해야겠다.

3. ALB

CloudFront에서 전달한 동적 API 요청을 처리하게 된다. ALB는 L7의 로드밸런서로 단순 IP나 포트 뿐만이 아니라

요청 경로나, 헤더, 메소드 등을 분석하여 요청을 적절한 서버 그룹에 라우팅하게 된다.

4. VPC 리소스

애플리케이션
- EC2 컨테이너 호스팅
  - 프론트: SSR(Next.js 등), 정적 데이터는 CloudFront + S3에서 직접 배포.
  - 백엔드: API 서버(Spring Boot, Node.js 등), 메타데이터 관리.
  - AI 서비스: 영상/이미지 분석, 인퍼런스 처리.
- Redis
  - 세션 캐시, 작업 큐, 빠른 데이터 조회 용도.

[Cloud] SaaS, IaaS, PaaS

whkim98 — Sat, 20 Sep 2025 15:48:05 +0900

클라우드에 대해 공부하기 전에 이 3가지 개념을 알아야 한다고 생각한다.

실제로 고객사에게 문의를 받게 되면 기존 온프레미스 인프라를 클라우드 환경으로의 전환, 구축에 대한 문의를 받게 된다.

하지만 개념이 정확하게 잡히지 않은 상태에서는 고객의 니즈를 파악하기 어려울 것이라는 생각이 들어 정확한 개념 정리를 해야겠다는 생각을 했다.

모두가 정의하는 것이 다르겠지만 나같은 경우는 클라우드를

"IT 물리 자원을 구매할 필요없이 IT자원을 필요한만큼 빌리고 사용한만큼만 값을 지불하는 서비스"

라고 정의하고 싶다.

당연히 비용효율이 높아지고 확장성, 유연성도 올라간다.

별도 물리 장비 설치에 힘을 쓰지 않아도 되고 마우스 딸깍질 몇 번이면 나의 서버를 구성할 수 있기 때문이다.

이런 "렌탈" 기능 뿐만 아니라 요즘 글로벌 CSP는 많은 AI 서비스들까지 제공을 하고 있으며,

다양한 써드파티 솔루션들까지 제공되고 있기 때문에 현대 인프라에서 자주 사용되고 있다고 생각한다.

1. SaaS(Sofrware As A Service)

기업내 필요한 소프트웨어를 언제든 가져다 쓸 수 있게 해준다.

소프트웨어를 웹처럼 사용할 수 있게 되며 Gmail, 네이버클라우드, Zoom 등이 있다.

2. IaaS(Infrastructure As A Service)

위 설명과 같이 IT 자원(서버, 스토리지 등)을 빌려주는 서비스로

흔히 알고 있는 AWS, NCP, GCP, Azure 등이 있다.

3. PaaS(Platform As A Service)

IaaS와 마찬가지로 인프라를 호스팅하고 운영 체제와 미들웨어까지 제공을 한다.

* 미들웨어: 운영 체제와 애플리케이션 사이에서 운영 체제가 제공하지 않는 기능을 제공하는 소프트웨어

AWS Elastic Beanstalk, NHN Cloud RDS 등과 같은 서비스가 있다.

좀 더 쉽게 말하자면 이미 만들어진 소프트웨어를 나의 환경에 맞춰 커스터마이징 가능하게 제공하는 것이라고 이해해도 될 것 같다.

[AWS] AWS-SAA 공부 방법 및 취득 후기

whkim98 — Wed, 17 Sep 2025 22:09:28 +0900

8.10 AWS-SAA 자격을 취득했다.

공부기간은 약 40일? 정도 됐던 것 같다.

단순 보여주기식으로 자격을 취득하려는 것이 아닌, 실제 AWS 아키텍처 설계 역량과 제공되는 서비스들에 대해 습득을 해보고 싶었기 때문에 실습도 병행했다.

1. Udemy 온라인 강의 (도움정도 上 )

여타 다른 분들과 다를 거 없는 공부 방법을 채택했다.

https://www.udemy.com/

공식적인 한국어지원 강의이기 때문에 자막 번역이 아주 잘 되어있다.

다만, 강의량이 워낙 많기 때문에 실습까지 병행한다면 나처럼 굉장히 많은 시간이 소요될 수 있음 ㅋㅋ..

따라서, 빠르게 자격 취득을 원하는 분들은 재생속도를 높여 빠르게 듣는 걸 추천한다.

2. 덤프문제

AWS는 워낙 글로벌한 CSP이기 때문에 덤프문제가 아주 많다.

많은 분들이

https://www.examtopics.com/exams/amazon/aws-certified-solutions-architect-associate-saa-c03/

Free & Accurate Amazon AWS Certified Solutions Architect - Associate SAA-C03 Practice Questions | ExamTopics

Get ready to prepare like you’ve never prepared before As we often say at ExamTopics, work smarter not harder. You are about to see a study guide that took hours of hard collection work, expert preparation, and constant feedback. That’s why we know thi

www.examtopics.com

examtopics를 통해 문제풀이를 하는 것으로 보였다.

하지만 나는 댓글창에 수많은 논의가 있는 것이 오히려 자격 취득 공부에 방해가 될 것 같다는 생각이 들었다.

그래서

https://limreus.tistory.com/194

[AWS/SAA-C03] SAA-C03 합격 후기 및 덤프 공유

준비1) Examtopics 하나로도 충분하다고 느낌2) 첨부한 해설집(덤프)을 참조해 여러번 풀어보면서 답을 외우는 형식으로 준비함(비밀번호: aws1602)3) 준비기간은 약 3주. 684개의 문제를 3회 풀어봄4) 덤

limreus.tistory.com

이 블로그에 공유되어 있는 pdf 문제로 학습을 진행했다.

문제는 examtopics에 있는 문제이지만 답과 해설 로 단순화된 문제집 느낌이라 오히려 좋았다.

3. 실습

https://aws.amazon.com/ko/?nc2=h_home

클라우드 컴퓨팅 서비스-Amazon Web Services(AWS)

Amazon Web Services는 안정성이고 확장 가능하며 저렴한 클라우드 컴퓨팅 서비스를 제공합니다. 무료로 가입하여 사용량에 따라 요금을 지불하세요.

aws.amazon.com

첫 계정 생성을 하게 되면 12개월간 프리티어로 AWS를 이용할 수 있다. (일부 서비스 및 제한 기간이 초과되면 과금 주의)

앞서 말한 것과 같이 AWS 아키텍처 설계 역량과 제공되는 서비스들에 대해 습득을 원했기 때문에 실습까지 함께 병행했으며 확실히 큰 도움은 되지만 시간이 오래 걸리기 때문에 빠른 자격 취득을 원한다면 생략해도 될 과정으로 보인다.

클라우드 및 네트워크 기반 지식이 아예 전무하다면 조금은 어려울 수 있을 시험이지만

어느정도 알고 있는 정도라면 한 번에 취득할 수 있을 시험으로 보인다.

해당 자격증이 실무 능력까지 인정이 될 수는 절대 없겠지만 기반 지식을 쌓는데에는 큰 도움이 된 것 같아서 비싼 돈 들여서 취득한 보람이 있는 것 같다.

[정보처리기사] 비전공자 필기 합격 후기

whkim98 — Fri, 21 Feb 2025 10:46:27 +0900

아직 CBT 시험 특성 상 시험 종료 후 바로 결과가 나오기 때문에 합격이라는 것은 알지만 공식적으로는 결과가 나오지 않은 상태이다.

3월 중순에 결과가 나오니 그때 첨부하도록...

우선 나는

1. 소프트웨어 설계 65

2. 소프트웨어 개발 75

3. 데이터베이스 구축 70

4. 프로그래밍언어 활용 70

5. 정보시스템 구축 관리 70

으로 총점 70 합격이었던 것 같다. 아마도..?

우선 나는 비전공자이지만, 이 전에 SQLD, ADsP를 취득한 상태였기 때문에 3과목은 정말 쉬웠다.

또한, 개발 교육 이수 경험도 있었고 컴활 1급을 취득하며, CBT시험에 대한 공부법도 나름 알고 있었기 때문에

다른 비전공자 분들에 비해서는 조금은 유리했다고 생각한다.

하지만 기본적으로 전공자가 당연히 유리할 것으로 보여졌다.

공부법

https://www.comcbt.com/

최강 자격증 기출문제 전자문제집 CBT

전자문제집, CBT, 컴씨비티, 씨비티, 기사, 산업기사, 기능사, 컴활, 컴퓨터활용능력, 1급, 2급, 워드, 정보처리, 전기, 소방, 기계, 사무자동화, 정보기기, 제과, 제빵, 한국사, 공무원, 수능, 필기,

www.comcbt.com

10일간 공부를 했고, CBT 시험은 우선 여기서 문제 박치기 하면서 익히는게 좋다고 생각한다.

1. 우선 문제 박치기를 하며 모든 기출 문제를 푸는데, 조금의 헷갈림도 없이 모르는 문제는 답을 고르지 않고 넘어간다.

2. 맞은 문제든 틀린 문제든 해설을 쭉 읽으며 넘어간다.

그냥 이걸 계속 반복한다. 그러다 보면 눈에 익게 되고 답이 보이게 된다.

참고로, 정처기는 20년도부터 개정이 되어 정보처리기사(구) 라고 되어 있는 항목은 풀지 않았다. 하지만, 일부 같은 과목은 도움이 된다고 하니 같은 과목에 한해서는 풀어봐도 좋을 것 같다.

또한, 위 사이트에는 22년 1차까지 밖에 문제가 없을텐데 나머지 24년도 까지의 문제는

https://www.sinagong.co.kr/pds/001001001/books

시나공

컴활, 정보처리, 워드프로세서 등 IT 자격증 전문. 해설 포함 CBT, 최신 기출 자료 무료, 실기 채점 프로그램 제공

www.sinagong.co.kr

시나공 자료실에서 다운받을 수 있었다.

나는 책을 구매하지는 않았다. CBT시험 특성 상 개념을 달달 외우고 그럴 필요는 없기 때문이다.

하지만, 대부분 실기까지 치룰 것이기 때문에 책을 구매해도 나쁠 건 없다고 보여진다.

나도 이제 실기 공부를 시작해야겠다.

[정보처리기사] 필기 총정리

whkim98 — Tue, 11 Feb 2025 17:51:25 +0900

https://m.blog.naver.com/wook2124/222102990691

2025 정보처리기사 필기 총정리 (시나공, 수제비)

<정보처리기사 필기, 공부 가이드라인 by. 세현님> 본 정리 글은 정보처리기사 시나공과 수제비 필기...

blog.naver.com

너무 정리가 잘 되어 있는 블로그...

[Spring] Scheduled 어노테이션

whkim98 — Wed, 30 Oct 2024 09:17:30 +0900

@Scheduled

해당 어노테이션을 활용하면 일정 시간 간격 혹은 특정 시간에 원하는 메소드를 실행하도록 해주는 어노테이션이다.

사용법

나같은 경우에는 실제로 원하는 디렉토리의 파일들을 최종 수정시간과 현재 시간을 비교하여 특정 시간만큼 차이가 나면 삭제시키도록 하는 기능을 만들어야 했다.

우선 @Scheduled를 사용하기 위해서는 Application 파일에 @EnableScheduling 를 추가해줘야 한다.(나 Scheduled 쓴다~ 하고 선언하는 것)

그리고는 @Scheduled를 적용할 클래스를 만드는데

@Component
public class FileClean { 

	@Scheduled(fixedRate = 60 * 60 * 1000) // 1시간마다 실행
	public void run() {        
		System.out.println("Scheduled TEST");    
	}
    
}

주의할 점은 @Component 혹은 @Service와 같이 빈에 등록된 클래스여야만 한다.

이렇게만 해주면 설정은 끝이고 조금의 규칙이 있다.

1. 메소드 리턴 타입은 void여야 함

2. 메소드에 파라미터 사용 불가능

또한, Scheduled의 속성으로는

@Scheduled(fixedDelay = 1000) //milliseconds 단위로, 이전 Task의 종료 시점으로부터 정의된 시간만큼 지난 후 Task를 실행

@Scheduled(fixedDelay = "1000") //fixedDelay와 같은데 문자열로 값을 표현하겠다는 의미

@Scheduled(fixedRate = 1000) //milliseconds 단위로, 이전 Task의 시작 시점으로부터 정의된 시간만큼 지난 후 Task를 실행

@Scheduled(fixedRateString = "1000") //fixedRate와 같은데 문자열로 값을 표현하겠다는 의미

fixedRate는 작업의 수행시간과 상관 없이 일정 주기마다 메소드를 호출하는 것.

fixedDelay는 작업을 마친 후부터 타이머가 돌아 메소드를 호출하는 것.

그리고 cron 표현식을 사용하여 작업을 예약할 수도 있다.

@Scheduled(cron = "* * * * * *")

이는 첫 번째 "*"부터

초(0-59) 
분(0-59) 
시간(0-23) 
일(1-31) 
월(1-12) 
요일(0-6) (0: 일, 1: 월, 2:화, 3:수, 4:목, 5:금, 6:토)

* : 모든 조건(매시, 매일, 매주처럼 사용)을 의미
 
? : 설정 값 없음 (날짜와 요일에서만 사용 가능)
 
- : 범위를 지정할 때
 
, : 여러 값을 지정할 때
 
/ : 증분값, 즉 초기값과 증가치 설정에 사용
 
L : 마지막 - 지정할 수 있는 범위의 마지막 값 설정 시 사용 (날짜와 요일에서만 사용 가능)
 
W : 가장 가까운 평일(weekday)을 설정할 때

를 의미한다.

cron 사용 예시

// 매일 오전 10시에 실행 (요일은 신경 쓰지 않음)
@Scheduled(cron = "0 0 10 * * ?")
public void everyDayAtTenAM() {
    System.out.println("매일 오전 10시에 실행");
}

// 매일 오전 9시부터 11시까지 매시간 0분에 실행
@Scheduled(cron = "0 0 9-11 * * ?")
public void everyHourFromNineToEleven() {
    System.out.println("9시에서 11시 사이 매 정각마다 실행");
}

// 월, 수, 금 오전 10시에 실행
@Scheduled(cron = "0 0 10 * * MON,WED,FRI")
public void specificDaysOfWeek() {
    System.out.println("월, 수, 금 오전 10시에 실행");
}

// 매 15분마다 실행 (0분, 15분, 30분, 45분)
@Scheduled(cron = "0 */15 * * * *")
public void everyFifteenMinutes() {
    System.out.println("매 15분마다 실행");
}

// 매월 마지막 날 자정에 실행
@Scheduled(cron = "0 0 0 L * ?")
public void lastDayOfMonth() {
    System.out.println("매월 마지막 날 자정에 실행");
}

// 매주 토요일에 실행 (주간의 마지막 날)
@Scheduled(cron = "0 0 0 ? * 7L")
public void everyLastSaturday() {
    System.out.println("매월 마지막 토요일 자정에 실행");
}

// 매월 1일에 가장 가까운 평일에 오전 9시 실행
@Scheduled(cron = "0 0 9 1W * ?")
public void nearestWeekdayToFirst() {
    System.out.println("매월 1일에 가장 가까운 평일 오전 9시에 실행");
}

[Spring] AES 암호화 알고리즘

whkim98 — Mon, 28 Oct 2024 08:39:19 +0900

암호화 방식에는 크게 두 가지가 있다.

1. 대칭키 암호화

대칭키는 암호화 및 복호화에 사용하는 키가 동일한 방식이다.

암복호화에 참여하는 쪽에서 해당 키를 통해 데이터에 접근할 수 있게 되며 대표적인 알고리즘으로는 AES, DES, SEED 등이 있다.

대칭키 방식은 비대칭키 방식보다 속도가 빠르다는 장점이 있다. 하지만 키가 하나이기 때문에 키를 교환해야 하는 문제가 발생할 수 있다. 이것은 키를 탈취 당하는 문제가 발생할 수 있고 해당 데이터를 복호화하여 사용하는 사람이 많을수록 키 교환을 따로 해줘야 하기 때문에 관리해야 할 키가 방대해 질 수 있다.

2. 비대칭키 암호화

비대칭키는 암호화하는 키와 복호화하는 키가 서로 다른 방식이다.

일반적으로, 암호화를 위한 키는 공개키, 복호화를 위한 키는 개인키라고 부른다. 공개키는 누구에게나 공개되어 데이터를 전송하기 전 암호화를 가능케 하고 개인키는 특정 데이터를 받는 쪽에서만 가지고 있으며 개인키를 통해 전송받은 데이터를 복호화한다.

비대칭키는 키를 교환할 필요가 없기 때문에 키 탈취 문제가 발생하지 않으며 개인키로만 복호화가 가능하여 기밀성을 제공한다. 하지만 대칭키의 장점인 속도의 측면에서는 효율적이지 못할 수는 있다.

3. AES 알고리즘

AES(Advanced Encryption Standard) 는 고급 암호화 표준의 의미이다. 대칭키 알고리즘을 사용하며

AES-128, AES-192, AES-256 으로 3종류의 알고리즘을 가지고 있다. 숫자의 의미는 암호화 및 복호화에 사용되는 키의 길이를 의미한다.

AES는 안정성과 속도가 뛰어나기 때문에 대중적으로 사용되고 있다.

1) Block Cipher

AES는 128비트의 고정된 블록 단위로 암호화를 진행하게 된다.

주어진 암호화 대상을 128 비트씩 나눠 블록 단위로 암호화를 진행하는데 이것을 Block Cipher라고 부른다.

또 Block Cipher에는 CBC와 ECB로 두 가지 종류로 나뉘게 되는데 보통 CBC 방식이 권장되고 있다.

CBC는 이전 블록에 의존하도록 만드는 방식이며, 여기서 IV라는 개념이 사용된다.

CBC는 앞서 말한 것처럼 이전 블록에 의존하도록 하는 방식인데 첫 번째 블록에서는 이전 블록이 존재하지 않는다.

이때, IV가 사용되게 된다. 생성된 128 비트 IV값을 가지고 첫 번째 블록을 암호화한다.

2) Padding

AES는 128비트의 블록 단위로 암호화를 진행한다. 그렇기 때문에 데이터의 길이는 한 블록의 크기인 128비트의 배수인 것이 가장 좋을 것이다.

하지만 모든 경우에서 128비트의 길이를 가지게 할 수는 없을 것이다. 따라서, 데이터의 길이가 128비트의 배수가 아닌 경우 128비트를 맞추기 위해 마지막 블록에 값을 추가하게 되는데 이 과정을 Padding이라고 한다.