PROJECT AT A GLANCE
같은 기능이어도,
장비마다 호출과 적용 방식이 달랐습니다.
- 2024.07~08 · 카카오엔터프라이즈 클라우드서비스엔지니어링팀
- OpenStack·Metal3 코드 및 서버 정보 수집 흐름 분석
- FastAPI·Redfish 기반 관리 API 개발, 물리 장비 테스트와 문서화
01 / CONTEXT & ROLE
기존 시스템을 이해하는 것부터 시작했습니다.
데이터센터 관리자를 위한 물리 서버 관리 사내 API를 개발했습니다. 기존 OpenStack·Metal3 시스템의 코드와 서버 정보 수집 흐름을 분석하고, 추가 정보 수집 기능을 확장했습니다.
이와 함께 FastAPI와 Redfish를 사용해 하드웨어 조회와 제어 기능을 구현했습니다. 기존 수집 흐름 분석과 관리 API 개발을 구분하고, 실제 장비에서 제조사별 동작 차이를 확인했습니다.
02 / API & HARDWARE
하드웨어 조회와 제어를 API로 제공했습니다.
관리 기능의 공통 책임과 제조사별 처리 로직이 실제 물리 서버에 연결되는 개념도입니다.
- 기존 OpenStack·Metal3 정보 수집 흐름을 분석하고 추가 수집 기능을 확장했습니다.
- FastAPI·Redfish 관리 API에서는 공통 기능과 제조사별 차이를 객체지향으로 모듈화했습니다.
하드웨어 정보 조회
- CPU · Memory
- Storage · Network
- BIOS 설정 조회
설정 변경과 장비 제어
- BIOS 설정 · CPU 스레드 수 조정
- Firmware Update
- Power 제어
03 / DESIGN DECISION
같은 기능과 다른 구현을 분리했습니다.
Redfish를 사용해도 제조사마다 Endpoint, 응답 구조와 적용 방식이 달랐습니다. 관리자가 원하는 기능을 기준으로 공통 책임을 정리하고, 장비별 차이는 벤더별 처리 로직으로 나눴습니다.
| 확인한 차이 | 공통 기능의 책임 | 벤더별 처리의 책임 |
|---|---|---|
| Endpoint | CPU·Memory·Storage·Network 조회와 제어 기능 제공 | 장비 제조사에 맞는 Endpoint 호출 |
| 응답 구조 | 관리 기능에서 필요한 정보 다루기 | 제조사별 응답 구조에 맞춰 정보 처리 |
| 설정 적용 방식 | 변경 요청과 실제 적용 상태를 구분 | 장비별 동작 차이 확인과 적용 검증 |
구현 책임을 설명하는 개념 비교입니다. 실제 내부 코드·클래스명이나 특정 디자인 패턴을 재현한 것은 아닙니다.
차이가 생기는 지점을 모듈의 책임으로.
실제 물리 서버에서 호출·응답·적용 방식을 확인하고, 공통 기능과 벤더별 처리 범위를 구분해 구현했습니다.
04 / VERIFICATION
요청 성공과 설정 적용을 따로 확인했습니다.
BIOS 변경 API의 반환값만으로 실제 설정이 바뀌었다고 판단하지 않았습니다. 재부팅 또는 Power Cycle 이후 상태를 다시 확인했습니다.
변경 요청·응답
Redfish로 BIOS 설정 변경 요청
확인 대상: API 반환값재부팅·Power Cycle
물리 서버의 적용 동작 확인
장비에서 검증설정 상태 재확인
변경한 값이 실제 반영됐는지 확인
확인 대상: 적용 결과검증 판단 외부 API와 물리 장비를 연결할 때는 응답의 성공과 장비 상태의 일치를 구분해야 했습니다.
05 / RESULTS & HANDOFF
기능과 장비별 차이를 함께 인계했습니다.
CPU·Memory·Storage·Network 조회와 BIOS·Firmware·Power 제어 기능을 구현했습니다. 인턴 종료 전 API 사용법, 제조사별 차이점과 테스트 내용을 문서화해 후속 개발자가 활용할 수 있도록 했습니다.
이 경험에서 배운 것은 기존 코드의 맥락을 읽는 방법과 외부 규격의 실제 동작을 검증하는 태도입니다. API 설계뿐 아니라 적용 결과와 인계 자료까지 개발의 범위로 생각하게 됐습니다.