그렇다면 다음으로 키워야 할 역량은 무엇일까?

모르는 사람들과 프로젝트를 해볼 것

내가 잘 아는 사람들과만 프로젝트를 하면 사고방식이 고착화되기 쉽다. 익숙한 사람과의 작업은 의사소통이 빠르고 편하지만, 그만큼 새로운 관점에 둔감해질 수 있다. 처음 보는 사람들과 협업하면, 내가 당연하다고 여긴 방식이 그렇지 않을 수 있음을 체감하게 된다.

개발 문외한에게 백엔드 지식 설명해볼 것

현재의 나는 부소마고를 재학 중이기에, 주변인들과 개발과 관련된 대화를 할 때, 불편함을 별로 겪지 않는다. 하지만 개발자와만 이야기하면, 기술적인 언어를 당연하게 쓰게 된다. 하지만 현업에서는 개발자와만 대화하는가? 아니다. 기획자, 디자이너, 마케터, 때론 고객과도 직접 소통해야 한다. 기술적인 설명을 그들의 언어로 풀어내지 못하면, 오해가 생기고 결국 잘못된 방향으로 구현될 수 있다. 내가 만든 시스템의 구조와 의도를 비개발자도 이해할 수 있게 설명할 수 있어야, 진짜로 내가 그 기술을 이해하고 있는 것이다.

앞으로의 나

나는 앞으로 위에서 설명한 2가지를 실천하려 한다.

기술만으로는 한계가 있다. 같은 코드라도, 사람을 설득할 수 있는 사람과 그렇지 못한 사람의 결과는 다르다. 결국 도메인을 이해하고, 문제를 정확하게 정의하고, 커뮤니케이션을 통해 합의를 이끌어낼 수 있는 사람이 강하다.

전공자냐 아니냐는 중요하지 않다. 도메인을 깊게 이해하지 않으면, 전공자도 기술자에 머무르고 만다. 문제를 정의하고 해석할 줄 아는 사람만이 진짜 백엔드다.

결국 말하고 싶은 것은 하나다.

소프트 스킬을 키울 것

오늘은 사고가 확장된 것만 같아 기분이 좋은 날이다. 코드를 잘 짜는 것에서 멈추지 않고, 이제는 그 코드가 어떤 사람들과 어떤 문제를 풀기 위해 존재하는지를 더 넓게 바라보게 된 날이다. 성장에는 끝이 없다.

그들은 객체를 신처럼 숭배했다.

그들은 객체의 나라에서 태어나 클래스와 메서드를 경전처럼 배웠다. 그리고 외쳤다.

“관계형 데이터베이스? 그것은 과거의 유물이다.”

그들은 눈부신 추상화의 탑을 올렸다. 서비스, 리포지토리, 엔티티… 의존성과 패턴으로 치장된 신전에서 SQL 따위는 입에 담지도 않았다. 그러나 탑은 무너졌다. JOIN 하나로 끝날 것을, API 세 번 호출하며 CPU를 태웠기 때문이다.

1. SQL: 백엔드 개발의 바닥을 이루는 언어

SQL은 Structured Query Language의 줄임말로, 관계형 데이터베이스에서 데이터를 조작하고 정의하기 위한 언어다. 백엔드 개발자는 데이터와 떨어질 수 없다. 로그인부터 게시물 작성, 통계 집계까지 대부분의 기능은 결국 DB와의 상호작용을 필요로 한다.

이 상호작용의 핵심에 SQL이 있다. 흔한 예를 들면 다음과 같다:

조회: 특정 사용자의 게시글 목록을 최신순으로 정렬해서 가져오기
삽입: 새로운 회원 정보를 DB에 저장
성능 튜닝: 느린 API 응답 시간의 원인을 SQL 쿼리에서 찾고 인덱스를 추가

SQL을 잘 모르면, ORM이 생성하는 쿼리를 무작정 신뢰하게 된다. 이런 신뢰는 위험하다.

SQL은 백엔드 개발자의 '도구'라기보단 '기초 체력'이다.

2. ORM: 백엔드 생산성을 높이는 강력한 추상화 도구

ORM은 Object-Relational Mapping의 약자로, 객체와 테이블 간의 매핑을 통해 SQL 없이도 DB를 다룰 수 있게 해주는 기술이다. 대표적으로 Java 진영에선 JPA(Hibernate), Python에선 SQLAlchemy 등이 있다.

ORM이 제공하는 가장 큰 장점은 다음과 같다:

생산성: 반복적인 SQL 작성 없이 객체를 다루듯 데이터를 조작할 수 있음
유지보수성: 도메인 중심 설계를 할 수 있어 코드가 더 읽기 쉬워짐
추상화: DBMS에 독립적인 코드 작성 가능 (물론 완전히는 아님)

내가 JPA를 처음 썼을 땐 단순한 CRUD 기능을 너무 편하게 짤 수 있어서 감탄했었다. 특히 @Entity나 @Repository 같은 어노테이션만 붙이면 작동하는 구조는 학습 비용 대비 효율이 높다. 이런 추상화는 대규모 프로젝트에서 개발 속도와 안정성을 동시에 높여준다.

3. ORM의 한계: 모든 것을 추상화할 순 없다

하지만 ORM은 만능이 아니다. 특히 성능 측면에선 오히려 문제를 일으킬 수 있다.

N+1 문제: 지연 로딩에서 잘못된 fetch 전략으로 인해 수십 수백 개의 쿼리가 발생
복잡한 쿼리: 집계 함수, 윈도우 함수, 복잡한 조건부 조인 등은 ORM으로 작성하기 불편하거나 불가능
디버깅 어려움: 쿼리가 자동 생성되기 때문에 성능 이슈가 있을 때 원인 파악이 어렵다

ORM만으로 모든 것을 해결하려다 보면, 결국 기술이 아니라 구조에 발목 잡히는 상황이 생긴다. ORM에 대한 이해도가 작으면 여러 문제가 발생할 수 있다. 예를 들어, 컬렉션(리스트)형태의 객체를 조회할 때 N+1 문제를 해결하기 위해 단순 fetch join을 사용하게 되면 카티션 곱 문제가 발생하게 된다. 따라서 @Fetch(FetchMode.SUBSELECT) 를 사용하면 이러한 문제를 해결할 수 있다.

위 문제처럼 ORM은 객체를 다루는 기술이기 떄문에 이해도가 부족하면 성능 이슈가 발생할 수 있다.

4. SQL과 ORM을 균형 있게 쓰는 법

가장 현실적인 접근은 ORM과 SQL을 '상황에 따라' 조화롭게 활용하는 것이다.

단순 CRUD → ORM 사용
복잡한 통계, 집계 → Native Query 성능 최적화 → JPQL + Index + 튜닝된 SQL

예를 들어 Spring JPA에선 @Query(nativeQuery = true)로 SQL을 직접 쓸 수 있고, 필요하면 JdbcTemplate도 함께 쓸 수 있다.

결국 중요한 건 SQL을 잘 알고, ORM을 전략적으로 쓸 수 있는 능력이다. ORM은 뼈대를 세우기 좋지만, 그 뼈대가 어디까지 유연하게 움직일 수 있는지는 SQL 실력에 달려 있다.

마무리

정리하자면, 백엔드 개발자에게 SQL은 기초 체력이고, ORM은 도구다. 둘 다 알아야 한다. 특히 MSA 구조나 고성능 API, 복잡한 데이터 흐름을 다루는 상황이라면 더더욱 그렇다. ORM은 결국 SQL 위에 얹어진 얇은 추상화에 불과하니까.

그런 의미에서 객체지향 설계를 잘 하고 싶다면, SOLID 원칙은 한 번쯤 제대로 고민해볼 만한 기준점이다. 지금부터 SOLID 다섯 가지 원칙을 간단한 예시 코드와 함께 정리해본다. 모든 걸 완벽하게 지키는 건 어렵다. 하지만 최대한 의식하고 적용하려고 노력하는 것, 그게 실력 향상의 길이라고 생각한다.

1. SRP - 단일 책임 원칙

하나의 클래스는 하나의 책임만 가져야 한다.

여러 기능을 하나의 클래스에 우겨 넣으면 나중에 수정할 때 다른 기능까지 깨질 가능성이 높다. 유지보수도 어렵고 테스트도 힘들어진다. 책임을 나누면 기능별로 독립적인 수정이 가능해지고, 테스트 코드도 작게 쪼갤 수 있다.

물론 "하나의 책임"이란 게 상황마다 다르다. 무조건 기능 하나만 있어야 한다는 게 아니라, 그 클래스가 담당하는 변화의 이유가 한 가지여야 한다는 의미로 이해하면 좋다.

2. OCP - 개방 폐쇄 원칙

*확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다. * 코드를 확장할 땐 새로운 기능을 추가하는 쪽으로 가야지, 기존 코드를 고치는 쪽으로 가면 유지보수가 힘들어진다.

예를 들어 새로운 결제 수단이 추가됐을 때, 기존 if 문을 계속 추가하는 방식은 OCP를 위반하는 구조다. 반면 새로운 클래스만 추가하면 되는 구조라면 OCP를 잘 지킨 거다.

확장성 있는 구조를 위해선 추상화, 즉 인터페이스나 추상 클래스를 잘 활용해야 한다.

3. LSP - 리스코프 치환 원칙

부모 타입을 사용하는 곳에 자식 타입을 넣어도 문제가 없어야 한다.

상속 구조를 만들 땐 항상 이 원칙을 염두에 둬야 한다. 부모 클래스에 정의된 규칙이 자식 클래스에서도 당연히 지켜질 거라고 기대하게 된다. 그런데 자식이 그 기대를 깨면 문제가 된다.

이 원칙을 지키지 않으면 다형성이 깨지고, 코드를 이해하거나 사용하는 데 혼란이 생긴다. 필요하다면 기능을 인터페이스로 쪼개서 각각 다른 타입으로 나누는 것도 방법이다.

4. ISP - 인터페이스 분리 원칙

클라이언트가 사용하지 않는 메서드에 의존하지 않게 해야 한다.

인터페이스가 너무 많은 기능을 담고 있으면, 어떤 구현체는 일부 기능만 필요함에도 불구하고 불필요한 메서드까지 구현해야 한다. 이건 명백한 낭비고, 유지보수 포인트가 늘어나는 원인이 된다.

필요한 기능만 쏙쏙 분리해서 최소한의 인터페이스를 제공하는 게 좋다.

5. DIP - 의존 역전 원칙

상위 모듈은 하위 모듈에 의존하면 안 되고, 둘 다 추상화에 의존해야 한다.

구체 클래스에 의존하는 구조는 테스트하기 어렵고 변경에 취약하다. 반면 추상화에 의존하면 구현체만 갈아끼우는 식으로 테스트나 확장이 가능하다.

DIP를 지키기 위해선 결국 의존성 주입이 필요하다. 직접 생성하지 말고 외부에서 주입받는 구조를 만드는 게 핵심이다.

설계 사상

SOLID, KISS, YAGNI, DRY, LoD 등.. 많은 설계 사상이 있다. 설계 사상은 개발자의 정신이고, 디자인 패턴은 이러한 설계 사상의 유산이다.

설계 사상은 절대적인 것은 아니나, 나같은 주니어 개발자들한테 성장의 밑거름이 될 것이다.

처음부터 SOLID 다 지키면서 개발하는 사람은 없다.

하지만 계속 의식하고 연습하다 보면, 어느 순간 자연스럽게 그렇게 설계하고 있는 자신을 보게 될 거다.

왜 안 되는지 궁금하면, 일단 한 번 안 지켜보고 개발해보면 된다. 그럼 안 지켜야 할 이유보다, 지켜야 할 이유가 먼저 보일 거다.

웹서버: "정적인 건 내가 한다"

웹서버는 말 그대로 웹 페이지를 띄워주는 서버다. HTML, CSS, JS, 이미지 같은 정적 파일을 서빙한다. 예시: Apache, Nginx 역할: “브라우저가 요청한 HTML 파일? 여기 있다.”

한 문장으로 요약하자면: 요청 들어오면, 파일 찾아서 넘겨주는 애. “가볍게 처리할 수 있는 건 가볍게 처리하자.”

WAS: "동적인 건 내 차례야"

WAS는 Web Application Server다. 프로그램을 실행시켜 동적인 데이터를 응답하는 서버다.

예시: Tomcat, JBoss 역할: “로그인 요청? 그럼 DB랑 얘기 좀 해볼게.”

요청이 단순한 파일이 아니라 로직 실행이 필요할 때 등장한다. 웹서버가 요청을 넘겨주면, WAS가 실제 처리를 한다.

“정적은 넘기고, 동적은 계산하라.”

API 서버: "데이터만 주고받자"

API 서버는 프론트엔드와 백엔드가 데이터를 주고받는 중간 다리다. HTML 같은 UI는 주지 않는다. 대신 JSON 같은 순수 데이터만 주고받는다. 사용 예시: 모바일 앱, SPA 프론트엔드와 연결 구조: 프론트에서 요청 → API 서버 → DB 조회 → 응답(JSON) 실제로는 WAS가 API 서버 역할을 하는 경우가 많다. 즉, 역할이 완전히 독립된 건 아니다. 경계는 흐릿할 수 있다.

“보여주는 건 프론트의 몫, 나는 값만 넘긴다.”

REST API: "규칙을 지키는 대화"

REST는 하나의 설계 철학이다. 자원을 URI로 표현하고, HTTP 메서드로 행위를 나타낸다.

예시:

GET /users/1         사용자 1번 정보 조회  
POST /users          사용자 생성  
PUT /users/1         사용자 1번 수정  
DELETE /users/1      사용자 1번 삭제

REST의 핵심은 일관성과 예측 가능성이다. "URI만 봐도 무슨 일을 하려는지 알 수 있게 만들자"는 철학. ** “혼란 없는 설계가 좋은 설계다.”**

RESTful API: "REST 철학을 끝까지 밀어붙인 버전"

REST를 따르긴 따르는데, 애매하게 따르는 경우가 많다. RESTful API는 REST의 원칙을 철저히 지킨 API를 뜻한다.

지켜야 할 대표 원칙들: URI에는 명사만 쓴다 (/getUserInfo X, /users O) 소문자만 사용하고, 언더스코어 대신 하이픈 사용 HTTP 메서드는 의미에 맞게 사용 (조회는 GET, 생성은 POST 등) 상태를 서버에 저장하지 않는다 (Stateless)

“제대로 따르지 않을 거면, 애초에 따르지 마라.” 마지막으로, 개념을 구분하면 사고가 정리된다. 사고가 정리되면 설계가 쉬워진다. 설계가 쉬워지면 구현은 덤이다.

“애매함을 없애면, 실수도 줄어든다.”

컨테이너는 스스로를 가둔다. 그러나 네트워크는 그 감옥에 다리를 놓는다. 연결은 의지다.

가상 네트워크

물리적인 장치 없이 소프트웨어만으로 구성된 네트워크이다. Docker 컨테이너 간의 통신을 관리하고 격리하기 위한 기능을 제공하는 것이다. 같은 호스트 내에서 실행 중인 컨테이너 간 연결할 수 있도록 돕는 논리적 네트워크 개념이다.

가상 인터페이스

네트워크 인터페이스(Network Interface) 란 컴퓨터나 장치가 네트워크와 상호작용하기 위한 연결점이며, 데이터를 주고받을 수 있는 하드웨어 또는 소프트웨어 구성 요소입니다. 네트워크 인터페이스는 컴퓨터와 네트워크 간의 통신을 가능하게 하며, 데이터 전송과 수신을 처리합니다.

알다시피, 도커는 소프트웨어 프로그램이다. 이전 글에서 보았던 네트워크 인터페이스는 랜카드를 이용하여 통신을 하였다. 도커에서는 eth0과 veth라는 가상 네트워크 인터페이스를 두어 통신한다. veth는 일반적인 네트워크 인터페이스와는 달리 패킷을 전달받으면, 자신에게 연결된 다른 네트워크 인터페이스로 패킷을 보내주는 식으로 동작하기 때문에 항상 쌍으로 생성해줘야 한다. 한 쪽에서 다른 쪽으로 패킷을 전송할 수 있으며, 한 쪽에 다운된 경우 나머지 한 쪽도 정상적으로 기능하지 않는 것이 특징입니다. 도커에서는 실행중인 컨테이너 수 만큼 veth 로 시작하는 인터페이스가 생성됩니다.

도커 네트워크 드라이버

도커 네트워크 드라이버는 Native와 Remote로 나뉜다. Native Driver는 Bridge, Host, None, Overlay를 사용하고, Remote Driver는 3rd party 드라이버로 외부에서 잘 만들어진 드라이버를 사용한다. 이 중 우리가 살펴볼 네트워크 드라이버는 총 3가지로 Native Driver에 속하는 Bridge, Host, None이다.

Bridge

포트를 연결해 컨테이너 애플리케이션의 Port 를 외부에 노출하는 방식이 bridge 네트워크이다. 아무런 네트워크 드라이버를 지정하지 않으면 default 로 docker0 이라는 bridge 네트워크를 사용한다.

Host

host 네트워크는 도커가 제공해주는 가상 네트워크 인터페이스(veth) 을 사용하는 것이 아니라 이름 그대로 host의 네트워크에 붙어서 사용한다. 그래서 bridge 네트워크 처럼 포트 바인딩을 할 필요가 없으며 호스트 네트워크에 접근하면 컨테이너 또한 접근할 수 있다.

None

None 네트워크는 해당 컨테이너가 네트워크 기능이 필요 없을 때, 혹은 커스텀 네트워크를 사용해야 되는 경우가 있을 때 네트워크 드라이버를 none 으로 설정하고 사용할 수 있다. 즉 외부 네트워크와의 연결이 단절된다.

도커 네트워크 구조

앞서 언급했던 것처럼 도커 컨테이너도 결국 네트워크를 구성한다. 따라서 컨테이너마다의 IP와 포트가 존재한다. 도커는 호스트로부터 실행되는 컨테이너에 172.17.0.x 의 IP 을 순차적으로 할당한다.

도커 컨테이너에 아무런 설정을 하지 않는다면 외부에서 접근할 수 없으며 오로지 해당 도커 컨테이너를 구동시킨 호스트에서만 접근 가능합니다.

그러면 도커 컨테이너는 외부와 통신할 수 없는걸까?

외부 네트워크에 컨테이너 어플리케이션을 노출하기 위해서는 eth0의 IP/PORT 을 호스트의 IP/PORT에 바인딩시켜야한다.

즉, eth0에 대응되는 vethXXXX이라는 이름의 veth interface와 브릿지 네트워크에 컨테이너의 interface가 바인딩되는 형태로 통신합니다.

*veth 인터페이스는 사용자가 직접 생성할 필요는 없고 컨테이너가 생성될 때 도커 엔진이 자동으로 생성된다. * 도커 컨테이너가 실행될 때 네트워크 드라이버를 따로 지정하지 않으면 docker0라고 하는 브릿지 네트워크를 기본으로 사용하게된다. *이 브릿지 네트워크의 역할은 veth와 호스트의 eth0의 다리 역할을 합니다. *

내가 작성한 네트워크 시리즈 글을 읽고있는 중이라면 이러한 형태를 보았을 것이다. 포트끼리 연결하고 바인딩한다? 그렇다 이는 포트포워딩이다.

도커 네트워크 문법

도커 네트워크 명령어

네트워크 목록 확인

docker network ls

네트워크 생성

docker network create <네트워크명>

네트워크 삭제

docker network rm <네트워크명>

컨테이너에 네트워크 연결

docker network connect <네트워크명> <컨테이너명>

컨테이너에서 네트워크 분리

docker network disconnect <네트워크명> <컨테이너명>

네트워크 상세 정보 확인

docker network inspect <네트워크명>

“주소는 진실이고, 이름은 망각이다. 세상은 끊임없이 IP를 바꾸지만, 나는 이름으로 그것을 불러낸다. 이름이 사라지면, 연결도 끊긴다.”

DNS란?

도메인 네임 시스템(Domain Name System, DNS)은 호스트의 도메인 이름을 호스트의 네트워크 주소로 바꾸거나 그 반대의 변환을 수행할 수 있도록 하기 위해 개발되었다.

DNS의 동작과정

1. 웹 브라우저에 도메인을 입력하면 Local DNS에게 요청을 보낸다.
2. 만약 Local DNS에게 캐싱되어 있는 응답이 있다면 그대로 응답한다.
3. 캐싱되어 있지 않다면 Local DNS가 Root DNS에게 요청을 보낸다.
4. Local DNS는 Root DNS에게 TLD DNS 서버의 주소를 응답받는다.
5. Local DNS는 해당 TLD DNS 서버에게 요청을 보낸다.
6. TLD 서버는 해당 도메인 이름의 Authoritative DNS Server의 IP 주소를 반환한다.
7. Local DNS는 Authoritative DNS Server에게 요청을 보낸다. Authoritative DNS Server는 해당 도메인 이름에 대한 IP 주소를 가지고 있다. 이를 반환하게 된다.
8. Local DNS 서버는 해당 도메인을 캐싱한다.
9. 이후 도메인과 매핑되어있는 아이피 주소로 이동하게 된다.

“우리는 모두 누군가의 포트다. 정신적 연결을 기다리는 열린 소켓…”

포트란?

포트는 논리적인 접속장소를 뜻하며, 인터넷 프로토콜인 TCP/IP를 사용할 때 클라이언트 프로그램이 네트워크 상의 특정 서버 프로그램을 지정하는 방법으로 사용한다. 위 그림을 보면 한 서버 인스턴스에서 두 서버를 실행 중이다. 클라이언트들이 IP 주소와 포트를 이용하여 접근하고 있다. 만약 포트가 없었다면 어떻게 두 서버를 구별할까? IP 주소만으로는 어느 서버로 요청을 보내는지 알 수 없다.

다음은 자주 사용되는 포트이다.

네트워크 인터페이스란?

컴퓨터와 네트워크 사이의 상호 연결 지점을 의미한다. 네트워크 인터페이스는 실제로 물리적 실체를 가질 수도 있고, 소프트웨어만으로도 구현될 수 있다. 일반적으로는 물리적인 네트워크 인터페이스를 뜻한다. 따라서 조금 더 자세히 알아보겠다.

네트워크 인터페이스 카드

네트워크 인터페이스 카드는 컴퓨터에 전용 네트워크를 제공하는 회로기판이다. 네트워크 인터페이스 카드는 OSI 7계층 중 물리 계층(1계층)과 데이터링크 계층(2계층)에 속한 장비로, 기본적으로 네트워크에서 컴퓨터로 전달된 전기신호를 Bit로 변환하는 역할을 한다. 그리고 프로세서에 인터럽트 요청을 보내 Bit를 CPU까지 전달하는 역할을 한다. 반대로 전송할 Bit를 전기신호로 변환하기도 한다.

포트포워딩

포트 포워딩이 왜 필요할까?

사설 IP를 가진 컴퓨터는 공인 IP를 가진 공유기를 거쳐 인터넷을 할 수 있게 된다는 것은 저번 글에서 기술하였다. 만약 위와 같은 그림에서 외부에서 컴퓨터 1의 웹서버에 접근하기 위해서는 어떻게 해야할까? 컴퓨터 1의 IP는 불변하지 않고 유일하지 않은 사설 IP이기 때문에 IP를 알려줄 수도 없다. 그래서 공인 IP를 알려줘야 한다. '공인 IP:포트 주소'를 입력하더라도 컴퓨터 1에 다다를 수는 없다. 공인 IP의 포트 주소로 들어오더라도 연결은 공유기에 도달하면 끝난다. 왜냐하면 공인 IP로 들어온 포트 주소의 연결을 컴퓨터 1, 2, 3 중 어디로 보내줘야 할 것인지를 판단할 수 없기 때문이다. 따라서 미리 경로들을 지정해줘야한다. 감이 왔을 것이라고 생각된다. 이렇듯 *공인 IP의 포트가 어떤 사설 IP로 전송하게 되는지를 설정하는 것이 포트포워딩이다. *

참고

	NAT	포트포워딩
형식	아웃바운드	인바운드
패킷 속 도착지 여부	True	False
NAT의 패킷에는 도착지(Destination)의 정보가 포함되어있다.
하지만 포트포워딩의 패킷에는 도착지(Destination)의 정보가 포함되어있지 않다.
NAT는 아웃바운드 형식이고,
포트포워딩은 인바운드 형식이다.

"모든 패킷은 목적지를 향한다. 그러나 때로는 경로를 잃은 채 방황한다. 그것이 우리의 삶이다."

공인망과 사설망

공인 IP (Public IP)

인터넷 사용자의 로컬 네트워크를 식별하기 위해 ISP(인터넷 서비스 공급자) 가 제공하는 IP 주소이다. 외부에 공개되어 있는 IP 주소이다.

• 공인 IP는 전세계에서 유일한 IP 주소를 갖는다.

사설 IP (Private IP)

일반 가정이나 회사 내 등에 할당된 네트워크의 IP 주소이며 로컬 IP, 가상 IP라고도 한다. IPv4의 주소부족으로 서브넷팅된 IP이기 떄문에 *라우터에 의해 로컬 네트워크상의 PC나 장치에 할당된다.**

*서브넷팅이란?

원본 네트워크를 여러개의 네트워크로 분리하여 네트워크 할당하는 작업이다.

사설IP 주소는 다음 3가지 주소대역으로 고정된다. 각각의 주소대역은 클래스 나뉘고, 클래스마다 할당할 수 있는 IP의 갯수가 다르다.

• 클래스 A: 10.0.0.0/8
• 클래스 B: 172.16.0.0/12
• 클래스 C:192.168.0.0/16

사설 IP 주소 후반부에 있는 '/n'은 해당 주소를 판별할 때 총 32bit의 IP주소 중 첫 몇 bit까지 읽어내야 하는지를 뜻한다. 이를 CIDR 표기법이라고 한다. 위와 같이 하나의 옥텟은 8비트로 이루어져 있으며, 일반적으로 사용하는 IPv4의 주소는 4개의 옥텟으로 이루어져 있다. 따라서 CIDR는 0~32, 총 32비트까지 사용이 가능하다.

CIDR가 '/24'의 경우 위와 같이 앞에서부터 24비트 이후에 오는 4번째 옥텟을 전부 사용할 수 있다는 표현이다. 하나의 옥텟은 8비트로, 2의 8제곱인 256개이기 때문에 192.168.0.0/24일때, 192.168.0.0 ~ 192.168.0.255까지 사용이 가능하다.

옥텟이란?

정보 전달의 단위. 현재의 컴퓨터에서는 1바이트(Byte)가 8비트(bit)로 구성되어 있지만, 바이트의 정의상 반드시 8비트일 필요는 없었다. 과거에는 1바이트가 8비트가 아닌 컴퓨터도 실제로 존재하였다. 그런데, 때로는 정확하게 8비트임을 명시해야 하는 경우가 존재하는데, 이때 사용하는 용어가 옥텟이다.

특히 네트워크 관련된 분야에서는 서로 연결되는 두 대의 장비가 1바이트=8비트라는 보장을 할 수 없으므로, 옥텟이라는 표현을 사용하여 확실하게 8비트임을 명시한다.

다음은 공인 IP와 사설 IP의 차이점이다.

사설 IP 주소만으로는 인터넷에 직접 연결할 수 없다. 라우터를 통해 1개의 공인 IP만 할당하고, 라우터에 연결된 개인 PC는 사설 IP를 각각 할당 받아 인터넷에 접근할 수 있게 된다.

NAT

NAT는 사설망에서 외부 통신을 하는 방법 중 하나이다.

사설 IP만 가지고는 인터넷에 접속할 수 없기 때문에 NAT(Network Adress Translation)이란 개념이 등장한다. 보통, 사설 IP -> 공인 IP, 공인 IP -> 사설 IP로 변환하여 사설망이 외부 통신을 할 수 있게 된다. 즉, 사설 IP를 사용하고 있는 컴퓨터가 공인 IP에 해당하는 외부 세계와 통신을 할 수 있게 된 것이다.

프로세스

프로세스는 현재 실행 중이거나 곧 실행 가능한 PCB를 가진 프로그램이다. PCB에 대해 알아보기 앞서, 프로그램과 프로세스의 차이점에 대해 알아보자. 프로그램은 디스크에 저장된 수동적 실체이다. 잘 와닿지 않을 수 있는데 그냥 정적인 코드 덩어리라고 생각하면 된다. 프로세스는 프로그램 카운터와 프로세스 제어 블록(PCB)을 가지며, 실행 흐름을 제어하는 능동적 실체이다. 쉽게 생각하면 메모리에 적재되기 전에는 프로그램이고, 적재된 후에는 프로세스가 되는 것이다. 프로세스는 프로세서에 의해 수행되는 프로그램 단위로, 다음과 같은 특징을 가진다.

• 실행 중인 프로그램
• 비동기적 프로그램
• 살아 있는 프로그램
• 프로세스 제어 블럭(PCB)를 가지는 프로그램
• 언제든지 실행 가능한 프로그램

프로세스의 메모리 구조

프로세스의 메모리는 정적(코드, 데이터), 동적(힙, 스택) 영역으로 구성되었다. 1. 코드(Code)영역 : 실행 가능한 프로그램 코드 영역, CPU가 프로세스 실행 시 해당 내역 참조 2. 데이터 (Data)영역 : 전역변수, 정적 변수, 작업 공간 등을 담음 3. 힙(Heap)영역 : 동적 메모리(malloc(), free()) 등에 사용되는 변수를 담는 영역 4. 스택(Stack)영역 : 지역변수, 인자 리스트, 복귀 주소, 스택 프레임 등을 담음

프로세스 제어 블록 (PCB)

PCB는 운영체제가 프로세스를 관리하기 위한 정보가 담긴 자료구조이다.

PCB의 주요정보

• 프로세스 상태
• 프로세스 ID
• 프로그램 카운터
• 레지스터 정보
• 메모리 관리 정보
• 계정 정보
• 입출력 정보

  PCB의 역할

• 프로세스 상태 저장
• 문맥 교환

프로세스 상태

• ** 생성 상태 (new)**
• • PCB가 생성되는 상태
• 준비 상태 (ready)
• • 프로세서(CPU) 할당을 기다리는 상태
• 실행 상태 (run)
• • 프로세스가 CPU를 할당 받아 실행 중인 상태
• 대기 상태 (wait)
• • 특정 자원이 필요하며 대기 중인 상태
• 지연 준비 상태 (Suspend ready)
• • 준비 상태에 있던 프로세스가 메모리 부족으로 인해 하드디스크로 스왑됨.
• • 메모리가 확보되면 다시 준비 상태로 전이됨.
• 지연 대기 상태 (Suspend ready)
• • 대기 상태에서 메모리 부족으로 인해 스왑된 상태
• • 요청한 자원이 할당되면 지연 준비 상태로 전이됨

프로세스 상태 전이

디스패치(dispatch) : 준비 상태 -> 실행 상태 할당 시간 초과(time runout) : 실행 상태 -> 준비 상태 블록(block) : 실행 상태 -> 대기 상태 웨이크업(wake up) : 대기 상태 -> 준비 상태

프로세스와 스레드

프로세스

• 실행 중인 프로그램을 의미하며, 독립적인 메모리 공간을 가진다.
• 운영체제에 의해 관리되며, 서로 다른 프로세스 간에는 메모리르 공유하지 않는다.
• 하나 이상의 스레드를 포함할 수 있으며, 각각의 프로세스는 별도의 실행 흐름을 가진다.

스레드

• 프로세스 내에서 실행되는 작은 실행 단위
• 같은 프로세스 내에서 메모리와 자원을 공유하며, 다중 작업을 수행할 수 있다.

커널 스레드

• 운영체제 커널이 직접 관리하는 스레드
• 시스템 호출을 통해 커널에서 스레드를 생성하고 관리한다.

  사용자 스레드

• 사용자 공간에서 관리되는 스레드
• 커널에 직접적인 개입없이 사용자 수준에서 생성 및 관리 가능

느낀점

내가 아는 스레드는 운영체제와 밀접한 스레드 보다는 자바 문법상으로 배우는 스레드의 느낌이 강했는데, 스레드에 대해 공부하고 나니 사고가 확장되는 것 같다.

4시간을 온전히 문제 해결에 쏟았지만, 여전히 문제가 해결되지 않았고, 심지어 그 해결책이 웹 검색을 통해 겨우 나왔다. 그 원인이 뭘까? 바로 트랜잭션 문제였다.

문제의 핵심

Redis에서는 트랜잭션을 사용하면 명령어가 커맨드 버퍼에 저장되고, 트랜잭션이 커밋 또는 롤백될 때까지 결과가 반환되지 않는다. 그래서 트랜잭션이 아직 진행 중인 상태에서 값을 조회하게 되면, 커맨드 버퍼에 남아있는 값은 아직 반영되지 않은 상태여서 null이 반환된다.

왜 null이 반환되는 걸까?

트랜잭션이 진행 중일 때, Redis는 명령어를 즉시 실행하는 게 아니라 먼저 버퍼에 저장한다. 그리고 트랜잭션이 끝날 때까지 그 값은 다른 명령에서 조회할 수 없다. 결국, 트랜잭션 커밋이 완료되기 전에 값을 조회하면 예상치 못한 null이 반환되는 것이다.

해결책

문제를 해결하려면 트랜잭션이 완료된 후에 해당 값을 조회해야 한다. 즉, 트랜잭션 커밋 후에 데이터를 다시 요청하면 정상적으로 값이 반환된다.

결론

리프레시 토큰 로테이트를 구현할 때, 트랜잭션 처리에 대한 이해가 부족해서 발생한 문제였다. Redis에서 트랜잭션을 사용할 때는 그 결과가 커밋되거나 롤백될 때까지 다른 세션에서 해당 값을 조회할 수 없다는 점을 유의해야 한다.

이 글을 읽는 사람들은 Redis를 이용할 때 나처럼 삽질하지 않기를 바란다.

도커는 brew install docker를 통해 설치할 수 있다. 이 글에서는 굳이 설치하는 방법을 서술하지 않으려 한다. 사실 도커를 못들어본 개발자는 없을 것이다. 사용하려면 어떤 개념들을 알아야할까?

본론

컨테이너

컨테이너는 미니 컴퓨터라고 생각해도 된다. 하나의 호스트 OS 위에서 마치 각각의 독립적인 프로그램처럼 관리되고 실행한다. 불필요하게 OS를 만드는 작업 및 인프라를 독립적으로 나눌 필요가 없어서 확장성이 빠르고 좋다.

이미지

이미지는 개발환경을 포장해준 것이라고 생각하면 된다. 개발자가 직접 개발환경을 구축하는 부담을 도커가 대신 하게 된다.

docker pull <image명> 명령어를 통해 손쉽게 개발환경을 가져올 수 있다.

가져올 수 있는 개발환경은 https://hub.docker.com/ 여기서 볼 수 있다. 그 이름과 같이 도커허브는 이미지 정보를 모으는 곳이다.

또한 이미지 다운로드가 진행될 때, 이미지는 레이어 형식으로 저장된다.

레이어란 기존 이미지에 추가적인 파일이 필요할 때 다시 다운로드 받는 방법이 아닌 해당 파일을 추가하기 위한 개념이다.

간단한 명령어들

docker run <이미지명> //run 명령어 실행 시 pull, create, start가 순차적으로 실행되게 된다.
docker ps // 도커 실행 중인 컨테이너 확인
docker ps -a // 도커 모든 컨테이너 확인
dokcer stop <컨테이너명> // 도커 멈추기

내가 어떤 개발자인지 2 ~ 3줄 이내로 작성 나머지 글들을 이 2~3 줄에 신빙성을 가미하기 위해 작성

2. 배포

프로젝트를 한번 하고 방치하는 것이 아니라 배포를 하고 꾸준히 유지보수를 하자 회사는 개발역량뿐만 아니라 서비스 운영 능력까지 봄.

3. 난이도

프로젝트를 막 다 적지말고 자기를 대표할 수 있는 프로젝트 2개정도만 작성하자. 너무 쉬운 난이도의 프로젝트까지는 굳이?

4. 리드미

팀 프로젝트를 하면 레포지토리의 리드미는 팀 중심으로 써지게 된다. fork 해와서 내가 기여한 부분들을 작성하자.

5. 배운점

배운점은 무조건 '고민'이 들어가야한다. 고민을 통해 배운점을 작성해야함

6. 코드

말만 잘하는 것이 아니라 코드로 구현할 줄 알아야함

인접행렬

그래프를 컴퓨터에서 표현하기 위해서는 주로 인접행렬이 쓰인다.

a[i][j] : 노드 i에서 노드 j로 가는 간선이 있으면 1, 아니면 0으로 표현된다. 다음 예를 보자. 위와 같은 그래프는 아래 행렬처럼 표현된다.

그러면 방향이 없는 무향 그래프이면 어떻게 될까? 위 그림들을 보고 인접행렬에 대해 이해했을 것이라 생각한다.

GNN

그러면 그래프를 분석하기 힘든 이유는 무엇일까?

1. 고정된 형태가 아니다.
2. 유클리드 공간에 있지 않다. 좌표계로 표현할 수 없다.
3. 데이터가 커질수록 시각화가 어려워진다.

하지만 단점만 있는 것은 아니다. 그래프는 관계, 상호작용같은 추상적인 개념들을 표현하기에 탁월하다.

GNN의 핵심은 점이 이웃과의 연결에 의해 정의된다는 것이다. 만약 어떤 점의 이웃과 연결을 다 끊으면 그 점은 고립되고 아무 의미를 갖지 않게 된다.

GNN을 통해 그래프의 점들 사이의 관계를 파악하고 두 점 사이에 얼마나 연관성이 있을지 예측할 수 있다.

GNN 동작과정

GNN은 그래프의 구조를 이해하고, 각 노드가 가진 특징을 고려하면서, 이웃 노드의 정보를 반영하여 자신을 업데이트하고 이 과정을 반복하면서 점점 더 많은 정보를 학습하게 됨.

각 노드는 자기 자신과 이웃 노드들의 정보를 합쳐서 새로운 표현을 생성한다. 예를 들어, A라는 노드는 B, C와 연결되어 있다면, A는 B와 C의 정보를 받아들이고 업데이트한다.

이 과정은 여러 번 반복될 수 있으며, 각 노드는 자신의 이웃 정보와 자신의 정보를 바탕으로 새로운 특성을 만듦.

마지막에는 모든 노드가 자신의 특성을 업데이트하고, 그래프 전체의 정보를 고려한 결과를 도출함.

취업

주니어 개발자를 위한 취업 정보 : https://github.com/jojoldu/junior-recruit-scheduler

채용공고 보기 : https://zighang.com/it?utm_source=landing

IT 자격증 캘린더 : https://it-rank.netlify.app/calendar

기술인터뷰 : https://github.com/JaeYeopHan/Interview_Question_for_Beginner

https://github.com/WooVictory/Ready-For-Tech-Interview

https://github.com/devham76/tech-interview-study

로드맵 (참고용) : https://github.com/kamranahmedse/developer-roadmap

아티클

분야별 개발 아티클 모음 : https://github.com/Integerous/goQuality-dev-contents

회사들의 기술 블로그 엿보기 : https://www.codenary.co.kr/

어떤 정보든 카테고리별로 단일화 되어있는 사이트들을 정리합니다 : https://github.com/dding-g/useful-info?tab=readme-ov-file

이를 위해 특성 스케일링을 거쳐줘야 합니다.

특성 스케일링을 거치면 경사하강법에서 Local Minima에 빠질 위험을 줄이고, 스케일이 큰 특성의 영향력이 커지는 것을 방지할 수 있습니다.

특성 스케일링에는 다음과 같은 방법들이 있습니다.

정규화 ( Normlization )

표준화 ( Standardization )

하나씩 알아볼까요?

정규화

• 일반적으로 0 ~ 1의 범위를 가집니다.
• 사이킷런의 MinMaxScaler 추정기를 통해 쉽게 구현할 수 있습니다. feature_range 매개변수를 통해 0 ~ 1이 아닌 범위에 들도록 값을 조정할 수 있습니다.
• 정규화는 데이터 - 최소값 / 최대값 - 최소값 를 통해 스케일을 조정합니다.

from sklearn.preprocessing import MinMaxScaler
min_max_scaler = MinMaxScaler(feature_range=(-1, 1)) # -1 ~ 1로 값의 범위를 조정했습니다.
scaled_data = min_max_scaler.fit_transform(data)

표준화

• 항상 평균이 0 입니다.
• 사이킷런의 StandardScaler 추정기를 통해 쉽게 구현할 수 있습니다.
• 표준화는 데이터 - 평균 / 표쥰편차를 통해 스케일을 조정합니다.

from sklearn.preprocessing import StandardScaler
standard_scaler = StandardScaler()
data_std_scaled = standard_scaler.fit_transform(data)

변환

특성 분포의 꼬리가 두꺼울 때 (평균에서 멀리 떨어진 값이 지수적으로 줄어들지 않는 경우) 스케일링과 표준화는 대부분의 값을 작은 범위로 압축합니다. 하지만 일반적으로 머신러닝 모델에게 그다지 효과적이지 않습니다. 따라서 특성을 스케일링 하기 전에 두꺼운 꼬리를 줄이도록 변환하고 분포가 대략적으로 대칭이 되도록 만들어야 합니다.

오른쪽 꼬리가 두꺼운 양수 특성인 경우에는 일반적으로 특성을 제곱근을 취해 변환할 수 있습니다. (0 ~ 1 사이의 값에서는 특성을 거듭제곱하여 변환할 수 있습니다.)

만약 멱법칙 분포처럼 특성 분포의 꼬리가 아주 길고, 두껍다면 특성을 로그 값으로 바꾸는 것이 도움이 될 수 있습니다. 로그값을 취하고나면 가우스 분포(정규 분포)에 가까워집니다.

멱법칙 분포 가우스 분포(정규분포)

꼬리가 두꺼운 특성을 처리하는 또 다른 방법은 특성을 구간화(Buketizing 또는 Binning)하는 것입니다. 분포를 거의 동일한 크기의 버킷으로 나눠 범주화하는 것입니다. 거의 동일한 크기의 버킷을 사용하면 균등 분포인 특성을 만듭니다. 따라서 추가적으로 스케일링을 할 필요도 없어집니다. 또는 버킷 개수로 나누어 0 ~ 1 사이의 범위로 만들 수 있습니다.

특성이 멀티모달 분포(다붕 분포, 정점이 2개이상 나타나는 분포)일때 구간화를 사용하면 도움이 될 수 있습니다.

다만, 범주형 데이터이니 수치형 데이터로 한번 더 변환시켜서 사용해야합니다. 범주형 데이터를 수치형 데이터로 변환시키는 과정은 다음에 설명하겠습니다.

이런 방법을 사용하면 회귀 모델이 특성값의 여러 범주에 대해서 다양한 규칙을 쉽게 학습할 수 있습니다.

멀티모달 분포를 변환하는 또 다른 방법은 특성간의 유사도를 나타내는 특성을 추가하는 것입니다. 유사도 측정은 일반적으로 입력값과 중심점 사이의 거리에만 의존하는 방사 기저 함수를(RBF) 사용합니다.

방사 기저 함수에 대해서는 아직 제대로 이해가 되지 않아 참고 자료를 올려둡니다. https://m.blog.naver.com/sw4r/221497261535

가장 널리 사용되는 RBF는 가우스 RBF입니다. 사이킷런의 rbf_kernel() 함수를 사용하면 유사도를 재는 새로운 가우스 RBF 특성을 손쉽게 만들 수 있습니다.

요약

현재는 기술 과도기에 와있습니다. 생성형 AI의 발전에 따라 머지않아 코딩은 거의 완전 자동화가 될 것이고, UX디자이너가 사실상 프론트엔드 개발자가 될 수도 있을 것입니다. 조금 과장된 표현을 하자면, 코파일럿에 적절한 질문을 할 수 있는 것만으로도 신속하게 앱을 만들거나 솔루션을 배포할 수 있습니다.

개발자가 아닌 사람이 만든 앱이 기업 전반에 급격하게 확산되고 있습니다. 그렇다면 코딩하지 않는 개발자에게는 무엇이 중요해질까요? 서비스형 통합플랫폼 데이터업체 부미(Boomi)의 최고 제품 및 기술 책임자 에드 마코스키는 전통적인 코딩 전문 기술과 함께 로우코드/노코드 플랫폼 활용 능력, AI 기술을 통합하는 방법에 대한 이해, 이런 툴을 사용한 팀 내에서의 효과적인 협업까지 포함하도록 스킬셋이 발전할 것이라고 강조했습니다. 로우 코드와 코파일럿의 조합을 통해 개발자는 프로그래밍 언어를 배우는 데 시간을 할애할 필요 없이 비즈니스 성과를 지원하는 데 집중할 수 있게 됩니다.

소프트웨어 개발에는 많은 반복 작업이 수반됩니다. 이는 부인할 수 없는 사실입니다. 로우코드 플랫폼은 이런 작업을 간소화해 개발자가 더 나은 결과를 도출하고, 핵심 문제 해결에 집중하도록 돕습니다.

--이후 기사 내용은 로우코드/노코드를 통해 할 수 있는 성과들에 대한 글이라 생략하겠습니다--

생각

로우코드·노코드 플랫폼, 생성형 AI가 나날이 발전하는 만큼, 개발에 대한 진입장벽이 많이 낮아질 것이라고 생각합니다. 그에 따라 시간이 지날 수록, 기업들은 개발자들에게 개발 실력보다 비즈니스 프로세스 인지능력과 CS 능력을 더 높은 가치로서 요구할 것입니다. 왜냐하면, 개발실력이 출중하지 않더라도 비즈니스 프로세스 인지능력, 즉 내가 무엇을 만들 것인지, 또는 어떻게 만들 것인지를 인지하는 능력이 있다면, 앞서 글에서 살펴본 노코드/로우코드 플랫폼을 이용하거나 생성형AI의 도움을 받아 서비스를 창출해낼 수 있는 시대에 와있기 때문입니다. 또한 문제에 직면했을 때, 트러블슈팅을 원할히 해결할 수 있도록 도와주는 데 있어서 CS지식이 큰 기여를 한다고 생각합니다.

앞서 말한 것들을 종합하여, 제가 더 출중한 개발자가 되기위해서는 클린코드나 프레임워크 등 기술적인 면모들도 중요하지만 커뮤니케이션 능력과 비즈니스 프로세스 인지 능력을 기르는 데 노력하고 CS적인 지식들을 점진적으로 넓혀나가야할 것입니다.

많은 사람들이 데이터 분석을 공부할 때 피마 인디언 당뇨병 예측으로 시작한다. 나도 본격적으로 데이터 분석을 공부 해보기로 했다.

미국 애리조나주 그랜드캐년에서 사진을 찍으면 가장 잘 나오는 위치인 피마포인트는 그 지역에 살고 있는 인디언 부족 피마의 이름에서 유래한 것이다.

피마 포인트의 경관

피닉스대 연구팀은 1979년에 피마 인디언의 당뇨병 유병률이 다른 어떤 인구 집단보다 높다는 논문을 발표했다. 미국 미네소타주 로체스터와 비교하면 19배나 높을 정도였다.

아메리카 대륙의 인디언들은 조상들이 유라시아 대륙에서 베링해를 거쳐 넘어왔다. 춥고 음식이 부족한 상태에서 목적지도 확실치 않은 채 베링해를 넘어오는 것은 목숨을 건 여정이었다. 음식이 부족한 상태에서 음식을 섭취할 기회가 생기면 저장해 놓아야만 가혹한 환경 조건을 이겨낼 수 있었으므로 저장 능력을 키운 이들만 살아남을 수 있었을 것이다.

연구팀은 멕시코 피마 인디언의 생활 방식이 애리조나에서와 유사해지기 시작하면서 멕시코 피마 인디언의 비만과 당뇨병 유병률이 증가하고 있음을 발견했다. 두 집단이 제2형 당뇨병을 유발할 수 있는 유전자를 공통적으로 가지고 있지만 생활습관의 차이가 비만과 당뇨병 발병에 차이를 가져온 것이다.

인용 : https://m.dongascience.com/news.php?idx=66211

2. 데이터 수집

데이터셋은 캐글의 Pima Indians Diabetes Database를 받았다. 출처 : https://www.kaggle.com/datasets/uciml/pima-indians-diabetes-database

import pandas as pd
data = pd.read_csv("/content/diabetes.csv")
data.head()

![](https://velog.velcdn.com/images/comodoking_0128/post/1e37888e-65cd-4de6-b062-d3e61ccd73c4/image.png)
#### 데이터셋 확인
Pregnancies: 임신 횟수
Glucose: 포도당 부하 검사 수치
BloodPressure: 혈압(mm Hg)
SkinThickness: 팔 삼두근 뒤쪽의 피하지방 측정값(mm)
Insulin: 혈청 인슐린(mu U/ml)
BMI: 체질량지수(체중(kg)/키(m))^2
DiabetesPedigreeFunction: 당뇨 내력 가중치 값
Age: 나이
Outcome: 클래스 결정 값( 0 또는 1 )



### 3. 데이터 분석 및 인사이트 도출


>```python
data['Outcome'].value_counts()

음성이 양성보다 상대적으로 많다.

data.info()

모두 768개의 값으로 결측값은 존재하지 않는다.

data.describe()

BMI 지수의 평균이 32에 육박하는데 이는 과체중에 해당하는 범위이다.

import seaborn as sns
correlation_matrix = data.corr()
sns.heatmap(correlation_matrix, annot=True, cmap='Blues', fmt='.1f')

상관관계 히트맵을 그려본 결과, 당뇨병과 포도당 부하 검사 수치가 가장 큰 상관관계를 갖는 것을 알게 되었다.

import matplotlib.pyplot as plt
import seaborn as sns
plt.figure(figsize=(10, 6))
sns.histplot(data=data, x='Glucose', hue='Outcome', kde=True, bins=30)
plt.title('Diabetes and Glucose Load Test Histogram')
plt.xlabel('Glucose Load Test Value')
plt.ylabel('Frequency')
plt.show()

음성군들은 포도당 부하 검사 수치 50 ~ 130 정도의 밀집해있고, 양성군들은 130이상을 넘기고 밀집해있다.

4. 모델 학습

로지스틱 회귀를 사용하여 예측해보기로 했다.

from sklearn.model_selection import train_test_split
from sklearn.linear_model import LogisticRegression
x = data.iloc[:, :-1]
y = data.iloc[:, -1]
train_input , test_input, train_target, test_target = train_test_split(x, y, test_size=0.2, stratify=y)
lr = LogisticRegression(max_iter=500)
lr.fit(train_input, train_target)

5. 모델 평가 및 개선

평가함수

from sklearn.metrics import confusion_matrix, accuracy_score, precision_score, recall_score, f1_score, roc_auc_score
def get_clf_eval(test_target, pred=None, pred_proba=None):
    confusion = confusion_matrix(test_target, pred) #혼동행렬
    accuracy = accuracy_score(test_target, pred) # 정확도
    precision = precision_score(test_target, pred) # 정밀도
    recall = recall_score(test_target, pred) # 재현율
    f1 = f1_score(test_target, pred) # F1 점수
    if pred_proba is not None:
        roc_auc = roc_auc_score(test_target, pred_proba[:, 1])  # ROC AUC (예측 확률 사용)
    else:
        roc_auc = roc_auc_score(test_target, pred) 
    print("Confusion Matrix:\n", confusion)
    print("Accuracy: ", accuracy)
    print("Precision: ", precision)
    print("Recall: ", recall)
    print("F1 Score: ", f1)
    print("ROC AUC: ", roc_auc)

평가

pred = lr.predict(test_input)
get_clf_eval(test_target, pred)

성능이 크게 떨어지지는 않지만 아쉬운 감이 있다.

그래서 머신러닝의 국밥 그레디언트 부스팅을 이용해 다시 한번 학습시켜보았다.

그레디언트 부스팅

from sklearn.ensemble import GradientBoostingClassifier
gb = GradientBoostingClassifier(n_estimators=100, learning_rate=0.1, max_depth=3)
gb.fit(train_input, train_target)
pred = gb.predict(test_input)
get_clf_eval(test_target, pred)

로지스틱 회귀를 사용한 모델보다 성능이 개선된 모습을 보여준다.

제일 먼저 히스토그램 기반 그레디언트 부스팅을 사용해보았지만 데이터셋이 작은 탓인지 그레디언트 부스팅보다 성능이 낮은 모습을 보여주었다.

6. 결과 시각화 및 커뮤니케이션

로지스틱 모델과 그레디언트 부스팅 모델을 비교해보겠다.

models = ['Logistic Regression', 'Gradient Boosting']
accuracy = [accuracy_score(test_target, lr.predict(test_input)), accuracy_score(test_target, gb.predict(test_input))]
precision = [precision_score(test_target, lr.predict(test_input)), precision_score(test_target, gb.predict(test_input))]
recall = [recall_score(test_target, lr.predict(test_input)), recall_score(test_target, gb.predict(test_input))]
f1 = [f1_score(test_target, lr.predict(test_input)), f1_score(test_target, gb.predict(test_input))]
roc_auc = [roc_auc_score(test_target, lr.predict_proba(test_input)[:, 1]), roc_auc_score(test_target, gb.predict_proba(test_input)[:, 1])]
metrics_df = pd.DataFrame({
    'Model': models,
    'Accuracy': accuracy,
    'Precision': precision,
    'Recall': recall,
    'F1 Score': f1,
    'ROC AUC': roc_auc
})
metrics_df.set_index('Model', inplace=True)
metrics_df.plot(kind='bar', figsize=(10, 6))
plt.title('Model Performance Comparison')
plt.ylabel('Score')
plt.show()

그레디언트 부스팅 모델이 전반적으로 성능이 우수하지만 특히 재현율에서 성능이 월등히 좋다는 것을 알 수 있다.

from sklearn.metrics import ConfusionMatrixDisplay
fig, axes = plt.subplots(1, 2, figsize=(12, 6))
# 로지스틱 회귀 혼동행렬 시각화한 것
cm_lr = confusion_matrix(test_target, lr.predict(test_input))
ConfusionMatrixDisplay(cm_lr, display_labels=['True', 'False']).plot(ax=axes[0], cmap='Blues')
axes[0].set_title('Logistic Regression')
# 그레디언트 부스팅 혼동행렬 시각화한 것
cm_gb = confusion_matrix(test_target, gb.predict(test_input))
ConfusionMatrixDisplay(cm_gb, display_labels=['True', 'False']).plot(ax=axes[1], cmap='Reds')
axes[1].set_title('Gradient Boosting')
plt.tight_layout()
plt.show()

위 이미지에서 로지스틱 회귀는 119개, 그레디언트 부스팅은 125개의 데이터를 예측 성공한 것을 볼 수 있다.

⚡️ 피드백 환영합니다 ⚡️

직접 찾아보며 하는 것은 처음이다 보니 오류가 많을 수 있습니다. 오류를 발견하시면 알려주시면 감사하겠습니다!

from sklearn.metrics import confusion_matrix, accuracy_score, precision_score, recall_score, f1_score, roc_auc_score

def get_clf_eval(y_test, pred=None, pred_proba=None):
    confusion = confusion_matrix(y_test, pred) #혼동행렬
    accuracy = accuracy_score(y_test, pred) #정확도
    precision = precision_score(y_test, pred) #정밀도
    recall = recall_score(y_test, pred) #재현율
    f1 = f1_score(y_test, pred) #F1점수

    print("Confusion Matrix:\n", confusion)
    print("Accuracy: ", accuracy)
    print("Precision: ", precision)
    print("Recall: ", recall)
    print("F1 Score: ", f1)

모델을 평가하기 위해 찾아보니 위와 같은 경우가 많았다. 뭐가 뭔지 하나씩 뜯어보겠다.

혼동행렬

어떤 개인이나 모델, 검사도구, 알고리즘의 진단·분류·판별·예측 능력을 평가하기 위하여 고안된 표

코로나 19를 주제로 하여 예를 들어 보자. 어떤 사람이 코로나 감염이 의심되어 검사를 했을 때, 검사 결과는 양성 혹은 음성으로 나올 것이다. 여기서 양성이 나왔다는 것은 그 사람이 코로나에 감염되었다고 예측한다는 의미이고, 음성은 코로나에 감염되지 않았다고 예측한다는 의미가 된다. 문제는 현실이 진단 결과와 다를 수 있다는 데 있다. 의료진의 뒷목을 잡게 만드는 상황은 두 가지로, 검사 결과가 양성인데 실제로는 감염되지 않았던 경우, 그리고 검사 결과는 음성인데 실제로는 감염자였던 경우다. 이런 상황들이 많을수록 그 검사 키트는 못 믿을 물건이 되고 만다. 그렇다면 검사 키트를 만드는 업체에서는 이런 두 가지 상황은 최소한으로 줄이면서, 감염자는 정확히 양성으로, 비감염자는 정확히 음성으로 판정할 수 있는 검사 키트를 만들고자 할 것이다.

혼동행렬은 모델의 예측 결과를 실제값과 비교하여 분류 모델의 성능을 평가하는 도구로, 2개의 클래스(양성, 음성)에 대해 4개의 값을 계산한다:

True Positive (TP): 실제 양성 클래스인 데이터 중에서 모델이 양성이라고 예측한 수 True Negative (TN): 실제 음성 클래스인 데이터 중에서 모델이 음성이라고 예측한 수 False Positive (FP): 실제 음성 클래스인 데이터 중에서 모델이 양성이라고 잘못 예측한 수 False Negative (FN): 실제 양성 클래스인 데이터 중에서 모델이 음성이라고 잘못 예측한 수 혼동행렬을 통해 각 클래스에 대해 모델이 어떻게 예측했는지 시각적으로 확인할 수 있다.

출처 https://namu.wiki/w/%ED%98%BC%EB%8F%99%ED%96%89%EB%A0%AC

정확도

정확도는 전체 샘플의 개수들 중에서 얼마나 나의 알고리즘이 정답이라고 예측한 샘플이 포함되었는지의 비율을 의미한다. 예를 들어서, 내 알고리즘이 90% 정확하다면, 100개의 샘플들 중에서 90개만 정확하게 분류 하는 것이다.

높은 정확도는 모델이 잘 작동한다고 판단할 수 있다. 하지만 데이터가 불균형할 경우, 예를 들어 한 클래스의 비율이 매우 높을 때는 정확도가 높아도 모델이 불균형을 잘 반영하지 못할 수 있다. # 이를 샘플링 편향이라 함.

정밀도

정밀도란 모델이 True라고 분류한 것 중에서 실제 True인 것의 비율이다.

정확도와 정밀도의 차이로는, 정확도는 전체 샘플에 대해서 모델이 올바르게 예측한 비율이고 정밀도는 오로지 양성 샘플에 대해서 올바른 비율로 각자가 대상하는 데이터 범위가 다르다.

Positive 정답률, PPV(Positive Predictive Value)라고도 불린다.

재현율

재현율이란 실제 True인 것 중에서 모델이 True라고 예측한 것의 비율이다.

Precision이나 Recall은 모두 실제 True인 정답을 모델이 True라고 예측한 경우에 관심이 있으나, 바라보고자 하는 관점만 다르다. 정밀도는 모델의 입장에서, 그리고 재현율은 실제 정답의 입장에서 정답을 정답이라고 맞춘 경우를 바라보고 있다.

F1 점수

정밀도와 재현율 모두 완벽한 평가지표가 아니다. F1점수는 어느 한쪽으로 치우치지 않고, 정밀도와 재현율을 결합한 지표이다. F1 점수는 정밀도와 재현율의 조화 평균으로, 0과 1사이의 값이며 1에 가까울 수록 모델의 성능이 좋다는 것을 나타낸다.

빠른 CPU를 만들기 위해 CPU를 쉬지않게 만들어보겠다.

-챕터 1 : 명령어 파이프라인-

명령어 파이프라인을 알아보기 앞서, 하나의 명령어가 처리되는 전체 과정을 비슷한 시간 간격으로 나누어 보자. 명령어 처리 과정을 클럭 단위로 나누어 보면 일반적으로 다음과 같이 나눌 수 있다.

1 . 명령어 인출 2 . 명령어 해석 3 . 명령어 실행 4. 결과 저장

여기서 중요한 점은 같은 단계가 겹치지만 않는다면 CPU는 각 단계를 동시에 실행 할 수 있다.

무슨 말인지 한번 살펴보자.

CPU는 명령어를 다음과 같이 처리한다.

하지만 명령어 파이프라이닝 기법을 사용하면 다음과 같이 처리할 수 있다.

처음보다 효율적으로 처리할 수 있단 것을 알 수 있다.

파이프라이닝이 높은 성능을 가져오기는 하지만, 특정 상황에서는 성능 향상에 실패하는 경우도 있다! 이러한 상황을 파이프라인 위험이라고 한다.

-챕터 2 : 파이프라인 위험-

파이프라인 위험에는 크게 데이터 위험, 제어 위험, 구조적 위험이 있다.

-챕터 2-1 : 데이터 위험-

데이터 위험은 명령어 간 데이터 의존성에 의해 발생한다. 모든 명령어를 동시에 처리할 수는 없다.

어떤 명령어는 이전 명령어를 끝까지 실행해야만 실행할 수 있는 경우가 있다.

예를 들어 다음과 같은 명령어가 있다. R은 레지스터를 뜻함.

명령어 1 : R1 = R2 + R3 명령어 2 : R4 = R1 + R5

명령어 1를 실행해야만 명령어 2를 수행할 수 있다. 만약 명령어 1의 실행이 끝나기 전에 명령어 2를 인출하면 원치않은 R1 값을 읽어들일 수 있다. 따라서 명령어 2는 명령어 1의 데이터에 의존적이다. 이처럼 데이터 의존성에 의해 파이프라인이 제대로 작동하지 않는 것을 데이터 위험이라고 한다.

-챕터 2-2 : 제어 위험-

제어 위험은 주로 분기 등으로 인한 프로그램 카운터의 갑작스러운 변화에 의해 발생한다. 기본적으로 프로그램 카운터는 현재 실행 중인 명령어의 다음 주소를 가르킨다. 하지만 프로그램 실행 흐름이 바뀌어 ex) 인터럽트 명령어가 실행되면서 프로그램 카운터 값에 갑작스러운 변화가 생긴다면 명령어 파이프라인에서 이미 처리 중이던 명령어들은 쓸모가 없어지게 된다. 이를 제어 위험이라고 한다. 참고로 이를 해결하기 위해 사용하는 기술 중 하나가 분기 예측이다. 분기 예측은 프로그램이 어디로 분기할지 미리 예측한 후 그 주소를 인출하는 기술이다.

-챕터 3 : 슈퍼스칼라-

오늘날의 대부분의 CPU에서는 여러 개의 파이프라인을 이용한다. 이처럼 CPU 내부에 여러 개의 명령어 파이프라인을 포함한 구조를 슈퍼스칼라라고 한다. 슈퍼스칼라 구조로 명령어 처리가 가능한 CPU를 슈퍼스칼라 프로세서 또는 슈퍼스칼라 CPU라고 한다.

슈퍼스칼라 프로세서는 이론적으로 파이프라인 개수에 비례하여 프로그램 처리 속도가 빨라진다. 하지만 실제로는 파이프라인 위험 등의 문제들을 직면할 수 있어 반드시 파이프라인 개수에 비례하여 처리 속도가 빨라지지는 않는다. 이 때문에 슈퍼스칼라 CPU는 파이프라인 위험을 방지하기 위해 고도로 설계되어야 한다.

-챕터 4 : 비순차적 명령어 처리-

오늘날 CPU 성능 향상에 큰 기여를 한 기법이자 대부분의 CPU가 차용하는 기법이다. 지금까의 파이프라이닝, 슈퍼스칼라는 순차적으로 진행되었다. 하지만 파이프라인 위험과 같은 문제들로 인해 이따금씩 명령어를 곧바로 처리하지 못하기도 하였다. 만약 모든 명령어를 순차적으로만 처리한다면 이런 예상치 못한 상황에서 명령어 파이프라인은 멈춰버리게 된다.

사진에서도 2번 명령어가 처리되기 전까지 모든 명령어가 지연되는 상황이다. 괜히 데이터 의존성도 없는 명령어들까지 피해를 보는 실정이다.

그렇기에 명령어를 순차적으로만 실행하지않고 순서를 바꿔 실행해도 무방한 명령어를 먼저 실행하여 명령어 파이프라인이 멈추는 것을 방지하는 기법, 비순차적 명령어 처리 기법을 사용한다.

데이터 의존성이 있는 3번 명령어를 순서를 바꿔 뒤늦게 실행함으로써 효율적으로 병렬 처리를 할 수 있게 되었다.

이처럼 비순차적 명령어 처리가 가능한 CPU는 명령어들이 어떤 명령어와 데이터와 의존성을 가지고 있는지, 순서를 바꿔 실행할 수 있는 명령어에는 어떤 것들이 있는지를 판단할 수 있어야 한다.

-정리-

오늘은 CPU 내부에서 명령어를 병렬처리하여 성능을 높히는 법을 알게되었다.

선형조사법은 클러스터링 문제, 이차조사법은 2차 클러스터링 문제를 겪고있었습니다. 따라서 이중해싱법은 클러스터링 문제를 해결한 조사방법입니다. 오버플로우가 발생함에 따라 항목을 저장할 다음 위치를 결정할 때, 원래 해시 함수와 다른 별개의 해시 함수를 이용하는 방법입니다.

코드 구현

#include <stdio.h>
int i,k,n=8;
int doublehash(int key) //별개의 해시함수
{
    if(key>20) return 4;
    else return 5;
}
int hash(int key)
{
    return key%n;
}
int main()
{
    int key;
    int list[8]={0,0,10,3,2,5,0,0};
    scanf("%d",&key);
    int index=hash(key);
    while(1)
    {
        if(list[index]==0)
        {
            list[index]=key;
            break;
        }
        else
        {
            k++;
            index=(hash(key)+doublehash(key)*k)%n;
        }
    }
    printf("%d",index);
    return 0;
}

체인법

선형 조사법이 탐색 시간이 많이 걸리는 이유는 충돌 때문에 해시 주소가 다른 키하고도 비교를 해야 하는데 있습니다. 만약 해시 주소가 같은 키만을 하나의 리스트로 묶어둔다면 불필요한 비교는 하지 않아도 될 것입니다. 이러한 부분 덕분에 체인법은 성능이 좋습니다. 하지만 리스트의 공간이 따로 필요하게 됩니다.