본문 바로가기
Dev/Ect

신입 개발자 기술 면접 공부하기 - 네트워크 / 운영체제 / 공통

by yeonise 2022. 11. 27.

해당 글은 망나니 개발자님의 포스트를 정리한 글입니다.

1. HTTP 프로토콜에 대하여

: HTTP(Hyper Text Transfer Protocol)이란 데이터를 주고받기 위한 프로토콜로 서버/클라이언트 모델을 따릅니다.

HTTP는 상태 정보를 저장하지 않는 Stateless와 클라이언트의 요청에 맞는 응답을 보낸 후 연결을 끊는 Connectionless이 특징입니다.

  • 장점
  • 통신간의 연결 상태 처리나 상태 정보를 관리할 필요가 없어서 서버 디자인이 간단하다.
  • 각각의 HTTP 요청에 독립적으로 응답만 보내주면 된다.
  • 단점
  • 이전 통신의 정보를 모르기 때문에 매번 인증을 해주어야 한다.
  • 이를 해결하기 위해 쿠키나 세션을 사용하여 데이터를 처리한다.

2. HTTP와 HTTPS의 차이점

: HTTP는 평문 데이터를 전송하는 프로토콜이기 때문에 중요한 정보를 주고받으면 다른 사람에 의해 조회될 수 있습니다.

이러한 문제를 해결하기 위해 HTTP에 암호화가 추가된 프로토콜이 HTTPS입니다.

 

HTTPS에는 대칭키 암호화와 비대칭키 암호화가 모두 사용됩니다.

비대칭키 암/복호화는 비용이 매우 크기 때문에 서버와 클라이언트가 주고받는 모든 메시지를 비대칭키로 암호화하면 오버헤드가 발생할 수 있습니다. 그래서 서버와 클라이언트가 최초 1회 대칭키를 공유하기 위한 과정에서 비대칭키 암호화를 사용하고 이후에 메시지를 주고받을 때에는 대칭키 암호화를 사용합니다.

  1. 클라이언트가 서버로 최초 연결을 시도한다.
  2. 서버는 공개키(인증서)를 브라우저에게 넘겨준다.
  3. 브라우저는 인증서의 유효성을 검사하고 세션 키를 발급한다.
  4. 브라우저는 세션 키를 보관하고 서버의 공개키로 세션 키를 암호화하여 서버로 전송한다.
  5. 서버는 개인키로 암호화된 세션 키를 복호화하여 세션 키를 얻는다.
  6. 클라이언트와 서버를 동일한 세션 키를 공유하므로 데이터를 전달할 때 세션 키로 암/복호화를 진행한다.

 

HTTPS는 SSL을 입은 HTTP라고 할 수 있습니다.

* SSL(Secure Socket Layer) 인터넷을 통해 전달되는 정보를 보호하기 위해 개발한 통신 규약

HTTP는 원래 TCP와 직접 통신하지만 HTTPS에서 HTTP는 SSL과 통신하고 이 SSL이 TCP와 통신함으로써 암호화와 증명서, 안전성 보호를 이용할 수 있게 됩니다.

3. 쿠키와 세션의 차이점

: 쿠키는 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일입니다.

HTTP에서 클라이언트의 상태 정보를 PC에 저장했다가 필요시 정보를 참조하거나 재사용할 수 있습니다.

세션은 일정 시간 동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술입니다.

즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 합니다.

 

  쿠키(Cookie) 세션(Session)
저장 위치 클라이언트(사용자 PC) 웹 서버
저장 형식 text Object
만료 시점 쿠키 저장시 설정(브라우저가 종료되어도 만료시점이 지나지 않으면 삭제되지 않는다.) 브라우저 종료시 삭제(기간 지정이 가능하다.)
사용하는 자원 클라이언트 리소스 웹 서버 리소스
용량 제한 총 300개(하나의 도메인 당 20개, 하나의 쿠키 당 4KB) 서버가 허용하는 한 용량 제한이 없다.
속도 세션보다 빠르다. 쿠키보다 느리다.
보안 세션보다 취약하다. 쿠키보다 좋다.

4. 웹 동작 방식에 대하여

  1. 사용자가 브라우저에 URL을 입력한다.
  2. DNS 서버에 도메인 이름으로 서버의 진짜 주소를 찾는다.
  3. HTTP 프로토콜을 사용하여 HTTP 요청 메시지를 생성한다.
  4. TCP/IP 연결을 통해 HTTP 요청이 서버로 전송된다.
  5. 서버는 HTTP 프로토콜을 활용해 HTTP 응답 메시지를 생성한다.
  6. TCP/IP 연결을 통해 요청한 컴퓨터로 전송한다.
  7. 도착한 HTTP 응답 메시지는 웹 페이지 데이터로 변환되고, 웹 브라우저에 의해 출력되어 사용자가 볼 수 있게 된다.

5. TCP와 UDP의 차이점

: TCP는 연결형 서비스로 3-way handshaking 과정을 통해 연결을 설정합니다. 때문에 높은 신뢰성을 보장하지만 비교적 속도가 느리다는 단점이 있습니다. TCP는 4-way handshaking 과정을 통해 연결을 해제합니다.

UDP는 비연결형 서비스로 3-way handshaking을 사용하지 않기 때문에 신뢰성이 떨어지는 단점이 있습니다. 하지만 수신 여부를 확인하지 않기 때문에 속도가 빠릅니다.

TCP는 신뢰성이 중요한 파일 교환과 같은 경우에 쓰이고 UDP는 실시간성이 중요한 스트리밍에 자주 사용됩니다.

 

프로토콜 종류 TCP UDP
연결 방식 연결형 서비스 비연결형 서비스
패킷 교환 방식 가상 회선 방식 데이터그램 방식
전송 순서 전송 순서를 보장한다. 전송 순서가 바뀔 수 있다.
수신 여부 확인 수신 여부를 확인한다. 수신 여부를 확인하지 않는다.
통신 방식 1 : 1 통신 1 : 1 또는 1 : N 또는 N : N 통신
신뢰성 높다 낮다
속도 느리다 빠르다

6. OSI 7 Layer에 대하여

  1. 물리 계층 Physical Layer : 데이터를 전기 신호로 바꾸어주는 계층
  2. 데이터링크 계층 DataLink Layer : 데이터의 물리적인 전송과 에러 검출, 흐름 제어를 담당하는 계층
  3. 네트워크 계층 Network Layer : 패킷을 목적지까지 가장 빠른 길로 전송하기 위한 계층
  4. 전송 계층 Transport Layer : 최종 수신 프로세스로 데이터의 전송을 담당하는 계층
  5. 세션 계층 Session Layer : 컴퓨터끼리 통신을 하기 위해 세션을 만드는 계층
  6. 표현 계층 Presentation Layer : 데이터의 형식을 정의하는 계층
  7. 응용 계층 Application Layer : 사용자와 직접 상호작용하는 응용 프로그램들이 포함된 계층

7. HTTP Method에 대하여

: HTTP Method는 클라이언트가 서버에게 '사용자의 목적을 알리는 수단'입니다.

  • GET : 데이터 조회
  • POST : 요청 데이터 처리 (일반적으로 데이터 등록에 사용)
  • PUT : 데이터 변경 (해당 데이터가 없는 경우 새로 생성)
  • PATCH : 일부 데이터만 변경
  • DELETE : 데이터 삭제

8. GET과 POST의 차이점

: GET은 데이터를 조회하기 위해 사용되는 방식으로 데이터를 헤더에 추가하여 전송합니다. URL에 데이터가 노출되기 때문에 보안적으로 중요한 데이터를 포함해서는 안됩니다.

POST는 데이터를 추가 또는 수정하기 위해 사용되는 방식으로 데이터를 바디에 추가하여 전송하는 방식입니다. 완전히 안전하지는 않지만 URL에 데이터가 노출되지 않아 GET보다는 안전한 편입니다.

9. Stateful 세션 기반 인증 방식의 단점

: 세션 기반 인증은 클라이언트로부터 요청을 받으면 클라이언트의 상태 정보를 저장하므로 Stateful한 구조를 갖습니다.

반면, 토큰 기반 인증은 상태 정보를 서버에 저장하지 않으므로 Stateless한 구조를 갖습니다.

 

Stateful 세션 기반 인증 방식을 사용하면

  • 사용자가 증가하면 서버에 과부하를 줄 수 있어 확장성이 낮습니다.
  • 해커가 훔친 쿠키를 이용해 요청을 보내면 서버는 올바른 사용자가 보낸 요청인지 알 수 없습니다.

따라서 단일 도메인이라면 세션 기반 인증을 사용하고, 아니라면 토큰 기반 인증을 사용하는 것이 적합합니다.

세션을 관리할 때 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있기 때문에 여러 도메인에서 관리하는 것은 어렵기 때문입니다. (CORS 문제)

10. JWT 토큰에 대하여

: JWT는 JSON 포맷을 이용하는 Claim 기반의 웹 토큰이며, 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달합니다. JWT는 헤더(header).내용(payload).서명(signature)으로 구성되며 각 파트를 점(.)으로 구분합니다.

 

  • 헤더 (Header) : 토큰의 타입과 해시 암호화 알고리즘으로 이루어져 있다.
  • 내용 (Payload) : 토큰에 사용자가 담고자 하는 정보를 담는다. 내용에는 Claim이 담겨있으며 JSON(Key/Value) 형태의 한 쌍으로 이루어져 있다.
  • 서명(Signature) : 토큰을 인코딩하거나 유효성 검증할 때 사용하는 고유한 암호화 코드이다. 헤더와 내용의 값을 인코딩한다.
  1. 사용자가 로그인 시 올바른 사용자임을 확인한 뒤, 클라이언트에게 Access Token(JWT)를 발급한다.
  2. 클라이언트는 전달받은 토큰을 저장해 두고, 인증이 필요한 요청마다 토큰을 HTTP 헤더에 담아 보낸다.
  3. 서버에서는 암호화된 토큰을 복호화하여 올바른 요청인지 확인한다.
  4. 인증이 완료되면 서버는 요청에 응답한다.

11. 공인 IP와 사설 IP의 차이점

: 공인 IP는 전 세계에서 유일한 IP로 ISP(인터넷 서비스 공급자)가 제공하는 IP 주소입니다. 외부에 공개되어 있기 때문에 인터넷에 연결된 다른 장비로부터 접근이 가능합니다. 그에 따른 방화벽 등의 보안 설정을 해주어야 합니다.

사설 IP는 어떤 네트워크 안에서 사용되는 IP 주소를 말합니다. 일반 가정이나 회사 내부 등에 할당된 네트워크 IP 주소이며, IPV4의 부족으로 인해 모든 네트워크가 공인 IP를 사용하는 것이 불가능하기 때문에 로컬 네트워크 안에서 라우터를 통해 할당받는 가상의 주소입니다. 별도의 설정 없이는 외부에서 접근이 불가능합니다. 사설 IP 주소만으로는 인터넷에 직접 연결할 수 없고, 라우터를 통해 1개의 공인 IP를 할당하고, 라우터에 연결된 개인 PC는 사설 IP를 각각 할당받아 인터넷에 접속할 수 있습니다.

12. 프로세스와 스레드의 차이점

: 프로세스는 실행 중인 프로그램을 말하며, 완벽히 독립적이기 때문에 메모리 영역을 다른 프로세스와 공유하지 않습니다.

프로세스는 최소 1개의 스레드를 가지고 있습니다.

 

스레드는 프로세스 내에서 Stack만 따로 할당받으며, 그 외의 메모리 영역(Code, Data, Heap)을 공유하기 때문에 다른 스레드의 실행 결과를 즉시 확인할 수 있습니다. 스레드는 프로세스 내에 존재하며 프로세스가 할당받은 자원을 이용하여 실행됩니다.

13. 멀티 프로세스와 멀티 스레드의 특징

: 멀티 프로세스는 하나의 프로세스가 죽어도 다른 프로세스에 영향을 미치지 않고 계속 실행된다는 장점이 있지만 멀티 스레드보다 많은 메모리 공간과 CPU 시간을 차지한다는 단점이 있습니다.

 

멀티 스레드는 멀티 프로세스보다 적은 메모리 공간을 차지하고 문맥 전환이 빠르다는 장점이 있지만 하나의 스레드에 문제가 생기면 전체 스레드가 영향을 받으며 동기화 문제가 생긴다는 단점이 있습니다.

14. 멀티 스레드의 동시성과 병렬성에 대하여

: 동시성은 멀티 작업을 위해 싱글 코어에서 여러 개의 스레드가 번갈아 실행하는 것을 말합니다. 동시에 실행하는 것처럼 보이지만 사실은 빠르게 번갈아가며 실행하고 있는 것입니다.

 

병렬성은 멀티 작업을 위해 멀티 코어에서 한 개 이상의 스레드를 포함하는 각 코어들을 동시에 실행하는 것을 말합니다.

15. 멀티 스레드 환경에서의 주의사항

: 다수의 스레드가 공유 데이터에 동시에 접근하는 경우에 상호 배제 또는 동기화 기법을 통해 동시성 문제 또는 교착 상태가 발생하지 않도록 주의해야 합니다.

16. 데드락에 대하여

: 둘 이상의 프로세스들이 자원을 점유한 상태에서 서로 다른 프로세스가 점유하고 있는 자원을 요구하며 무한정 기다리는 상황을 말합니다. 예를 들어 자원 a를 가진 프로세스 p1과 자원 b를 가진 프로세스 p2가 있을 때, p1은 b를 필요로 하고 p2는 a를 필요로 한다면 두 프로세스는 서로 자원을 얻기 위해 무한정 기다리게 됩니다.

17. 선점형 스케쥴링과 비선점형 스케줄링의 차이점

: 선점형은 하나의 프로세스가 다른 프로세스 대신에 CPU를 차지할 수 있음을 말하며 비선점형은 하나의 프로세스가 끝나지 않으면 다른 프로세스는 CPU를 사용할 수 없음을 의미합니다.

18. 동기와 비동기의 차이점

: 동기는 순차적, 직렬적으로 작업을 수행하고 비동기는 병렬적으로 작업을 수행합니다.

 

예를 들어 서버에서 데이터를 가져와서 화면에 표시하는 작업을 수행할 때, 동기는 서버에 데이터를 요청하고 데이터가 응답할 때까지 다른 작업들은 중단됩니다. 반면 비동기는 서버에 데이터를 요청한 이후 서버로부터 데이터가 응답할 때까지 대기하지 않고 즉시 다음 작업을 이어 수행합니다.

 

정리하면,

동기화는 하나의 작업이 완전히 완료된 후 다른 작업을 수행하는 것을 말하며,

비동기는 하나의 작업 명령 이후 완료 여부와 상관없이 바로 다른 작업 명령을 수행하는 것을 말합니다.

19. Restful API에 대하여

: HTTP 통신을 Rest 설계 규칙을 잘 지켜서 개발한 API를 Restful한 API라고 합니다.

Rest 설계 규칙 - URI는 정보의 자원만 표현해야 하며, 자원의 상태와 행위는 HTTP Method에 명시

20. 프레임워크와 라이브러리의 차이점

: 두 가지를 구분하는 가장 큰 기준은 '제어 흐름에 대한 주도권이 어디에 있는가'입니다.

프레임워크가 전체적인 흐름을 갖고 있으며, 개발자는 그 안의 라이브러리에 대한 흐름을 갖게 됩니다.

21. Call By Value와 Call By Reference의 차이점

: Java는 기본적으로 모든 전달 방식이 call by value입니다.

기본형 변수나 참조형 변수 모두 자기 자신이 갖고 있는 값을 복사해서 전달하기 때문에 call by value 방식이라고 할 수 있습니다.

  • Call By Value - 인자로 받은 값을 복사하여 처리하는 방식
  • 장점 - 값을 복사하여 처리하기 때문에 원래의 값이 보존된다.
  • 단점 - 값을 복사하기 때문에 메모리 사용량이 증가한다.
  • Call By Reference - 인자로 받은 값의 주소를 참조하여 직접 저장하는 방식 
  • 장점 - 복사하지 않고 직접 참조하기 때문에 속도가 빠르다.
  • 단점 - 직접 참조하기 때문에 원래의 값에 영향을 미친다.

22. CORS(Cross-Origin Resource Sharing)에 대하여

: CORS란 도메인이 서로 다른 2개의 사이트가 데이터를 주고받을 때 발생하는 문제를 말합니다.

예를 들어 domain-a.com ←→ domain-b.com으로 데이터를 주고받을 때 따로 설정을 해주지 않으면 CORS 에러가 발생합니다.

 

다른 서버의 리소스를 불러오기 위해서는 CORS에 대한 내용을 Response의 Header에 추가해야 합니다.

  • Access-Control-Allow-Origin - 요청을 보내는 페이지의 출처
  • Access-Control-Allow-Methods - 요청을 허용하는 메서드 (default: GET, POST)
  • Access-Control-Max-Age - 클라이언트에서 preflight 요청(서버의 응답 가능 여부 확인) 결과를 저장할 시간
  • Access-Control-Allow-Headers - 요청을 허용하는 헤더

23. 절차 지향 프로그래밍과 객체 지향 프로그래밍의 차이점

: 절차 지향 프로그래밍은 순차적인 처리를 중요시하는 프로그래밍 기법입니다.

대표적인 언어로 C가 있으며 컴퓨터의 처리구조와 유사하기 때문에 실행 속도가 빠른 편입니다.

코드의 순서에 영향을 받기 때문에 순서가 바뀌면 동일한 결과를 보장하기 어렵습니다.

객체 지향 프로그래밍은 실제 세계의 사물들을 객체로 모델링하여 개발을 진행하는 프로그래밍 기법입니다.

대표적인 언어로 Java가 있으며 캡슐화, 상속, 다형성 등과 같은 기법을 이용할 수 있습니다.

절차 지향 언어보다 실행 속도가 느립니다.

24. OAuth 2.0에 대하여

: OAuth 2.0의 동작 흐름은 다음과 같습니다.

  1. 사용자(Resource Owner)가 클라이언트(Application)에게 사용 요청을 보냅니다.
  2. 클라이언트는 권한 서버(Authorization Server)에 권한 부여 승인 코드를 요청합니다.
  3. 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 사용자에게 보여줍니다.
  4. 사용자가 로그인하면 권한 서버는 위에서 전달받은 권한 부여 승인 코드의 redirect-url로 Authorization Code를 전달합니다.
  5. Authorization Code는 권한 서버에서 제공하는 API를 통해 Access Token으로 교환됩니다.
  6. 클라이언트가 Resource Server에 Access Token을 사용하여 보호된 자원을 요청합니다.
  7. Resource Server에서 요청한 자원을 전달합니다.

25. 동적 쿼리에 대하여

: 실행 시 특정 조건이나 상황에 따라 쿼리 문장이 변경되어 실행되는 쿼리문을 동적 쿼리라고 합니다.

컴파일 시 SQL 문장을 확정할 수 없는 경우 또는 실행 시점에 따라 Where 절이 달라질 때 사용합니다.

26. CSRF(Cross-site Request Forgery)에 대하여

: 사이트 간 요청 위조의 약자로 웹 애플리케이션 취약점 중 하나입니다.

공격자가 의도한 대로 사용자가 행동하게 하여 특정 웹페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격 방법을 의미합니다.

 

1. 사용자의 요청에 referer를 확인하여 도메인이 일치하는지 확인하는 방법으로 공격을 방어할 수 있습니다.

* 요청 헤더(request header)에서 referer 정보를 확인할 수 있다.

* 같은 도메인에서 들어오는 접속은 허용하나 다른 도메인에서 호출하는 것은 차단하는 개념

2. 상태를 변화시키는 POST, PUT 등의 요청에 csrf 토큰이 포함되어야지만 요청을 처리하는 방법으로 공격을 방어할 수 있습니다.

27. 대칭키 / 비대칭키 암호화 방식에 대하여

: 대칭키와 비대칭키는 양방향 암호화 방식의 종류입니다.

대칭키는 암호화와 복호화에 같은 암호키를 쓰는 알고리즘입니다.

이는 중간에 누군가 암호키를 가로채면 정보가 유출될 수 있다는 단점이 있습니다.

이런 문제를 보완한 방식이 비대칭키이며, 암호화와 복호화할 때 서로 다른 키를 쓰는 알고리즘입니다.

타인에게 절대 노출되어서는 안 되는 개인키와 공개적으로 개방되어 있는 공개키를 쌍으로 이루고 있는 형태입니다.

28. TDD(Test-Driven- Development)에 대하여

: 작은 단위의 테스트 케이스를 작성하고 그에 맞는 코드를 작성하여 테스트를 통과한 경우 상황에 맞게 리팩터링 하는 테스트 주도 개발 방식을 말합니다.

자연스럽게 코드의 버그를 줄이고, 간결한 코드를 작성하게 된다는 장점이 있습니다.

 

TDD는 레드 그린 사이클이라는 3가지 과정을 거칩니다.

  1. Red - 어떠한 기능을 검증하는 테스트가 실패하는 코드를 작성하고 , 실제로 실패하는지 확인한다.
  2. Green - 어떠한 기능을 검증하는 테스트가 통과하는 코드를 작성하고, 실제로 통과하는지 확인한다.
  3. Refactor - 앞에서 실패하는 테스트와 성공하는 테스트를 모두 검증했다면, 작성한 코드를 깨끗하고 가독성 좋게 수정한다.
  4. Repeat - 위의 3가지 과정을 반복하여 프로그램을 완성한다.

테스트 코드 작성의 이점

  1. 기능의 추가, 변경, 삭제로 인한 영향도 파악
  2. 예상하지 못한 오류에 대한 피드백
  3. 좋은 설계로 작성되게끔 유도
  4. 기능 정의 문서의 역할
  5. 실수를 줄이는데 도움

29. MSA(MicroService Architecture)에 대하여

: MSA는 1개의 시스템을 독립적으로 배포 가능한 각각의 서비스로 분할하는 것을 말합니다.

각각의 서비스는 API를 통해 데이터를 주고받으며 1개의 큰 서비스를 구성합니다.

모든 시스템의 구성 요소가 한 프로젝트에 통합되어 있는 Monolithic Architecture(모놀리식 아키텍처)의 한계점을 극복하고자 등장하게 되었습니다.

  • 장점
  • 일부 서비스에 장애가 발생해도 전체 서비스에 영향을 미치지 않는다.
  • 각각의 서비스들을 서로 다른 언어와 프레임워크로 구성할 수 있다.
  • 서비스의 확장에 용이하다.
  • 단점
  • 서비스가 분리되어 있어 테스트나 트랜잭션 처리 등이 어렵다.
  • 서비스 간에 API로 통신하기 때문에 그에 대한 비용이 발생한다.
  • 서비스 간의 호출이 연속적이기 때문에 디버깅 및 에러 트레이싱이 어렵다.

30. DDD(Domain-Driven-Design)에 대하여

:

  • 표현 계층(Presentation layer) - 사용자의 요청에 대해 해석하고 응답하는 일을 책임지는 계층 (Controller)
  • Client로부터 request를 받고 response를 return 하는 API 정의
  • 응용 계층(Application layer) - 비즈니스 로직을 정의하고 정상적으로 수행될 수 있도록 도메인 계층과 인프라스트럭처 계층을 연결해주는 역할을 하는 계층 (Service)
  • transaction 관리, DTO 변환, 모듈 간의 연계를 진행
  • 도메인 계층(Domain layer) - 비즈니스 규칙, 정보에 대한 실질적인 도메인 정보를 가지고 있으며 이와 관련된 모든 것을 책임지는 계층 (Entity)
  • Entity를 활용하여 도메인 로직이 진행된다.
  • 업무 사황을 반영하여 상태를 제어하는 역할에 집중한다.
  • 인프라스트럭처 계층(Infrastructure layer) - 외부와의 통신을 담당하는 계층 (Repository)
  • 해당 계층에서 얻어온 정보를 응용 계층 또는 도메인 계층에 전달하는 역할

 

'Dev > Ect' 카테고리의 다른 글

신입 개발자 기술 면접 공부하기 - Java  (0) 2022.11.28
신입 개발자 기술 면접 공부하기 - 자료구조  (0) 2022.11.27
신입 개발자 기술 면접 공부하기 - Backend  (0) 2022.11.21
자료구조 - 배열과 리스트, 구간 합, 스택과 큐  (0) 2022.11.13
오류 탐색 방법, 디버깅 - Debugging  (0) 2022.11.13

관련글

댓글

티스토리툴바