34일차 회고｜MCP 서버·기상청 API·API 연동｜AI 오케스트레이션 개발자 국비지원

1. 오늘 배운 내용

오늘은 MCP 서버를 실제 데이터와 연결하고, 다른 프로그램에서 사용할 수 있는 형태로 만드는 과정을 집중적으로 실습했다.

특히 기존에 가짜 데이터(Mock Data)로 동작하던 MCP 서버를 실제 API와 데이터베이스에 연결하는 방향을 배웠고, 우리 팀은 그중 날씨 MCP 서버를 담당하기로 했다.

오늘 수업에서 가장 중요하게 느낀 것은 단순히 코드를 많이 작성하는 것이 아니라,

어떤 구조로 만들 것인지 먼저 정하고, AI에게 정확하게 요구한 뒤 결과물을 직접 검토하는 것

이었다.

---

2. MCP 서버를 독립적인 프로젝트로 이해하기

수업에서는 MCP 서버를 기존 프론트엔드나 백엔드 프로젝트 안에 복잡하게 넣는 것이 아니라 독립적인 프로젝트로 생각해야 한다고 설명했다.

예를 들어 MCP 서버가 여러 개라면 다음처럼 각각 독립적으로 구성할 수 있다.

MCP Server 1
 └─ Weather

MCP Server 2
 └─ Hotel / Tourist Attraction

각 MCP 서버는 다른 컴퓨터나 서버로 옮겨서 실행할 수도 있기 때문에 서로 강하게 결합하지 않는 것이 중요하다.

이번 실습에서도 기존 프론트엔드와 백엔드를 크게 수정하기보다는 MCP 서버 자체를 독립적으로 만들고 실행하는 것에 집중했다.

---

3. 이번 실습에서 가장 중요했던 것: 단순하게 만들기

수업에서는 계속해서 처음부터 복잡하게 만들지 말 것을 강조했다.

특히 Codex 같은 AI 코딩 도구를 사용하면 내가 직접 작성할 때보다 훨씬 많은 코드가 한 번에 만들어질 수 있다.

하지만 코드가 많고 기능이 많다고 좋은 프로젝트가 되는 것은 아니었다.

오히려 지금 단계에서는

• 디렉터리 구조가 이해하기 쉬운가?
• 코드가 너무 복잡하지 않은가?
• 필요한 기능만 들어가 있는가?
• 환경변수가 코드에 하드코딩되어 있지는 않은가?
• 내가 코드를 보고 구조를 설명할 수 있는가?

같은 부분이 더 중요했다.

그래서 AI에게 코드를 요청할 때도 "초보자가 이해할 수 있는 가장 단순한 구조로 만들어 달라"는 조건을 먼저 전달하는 것이 중요하다는 것을 배웠다.

---

4. 내가 담당한 날씨 MCP 서버

우리 팀에서는 여러 MCP 서버 중 날씨 MCP 서버를 담당하게 되었다.

목표는 크게 두 가지였다.

MCP 서버 기능

1. 특정 지역의 현재 날씨 조회
2. 특정 지역의 다음 주 날씨 예보 조회

처음에는 Open-Meteo와 기상청 공공데이터 중 어떤 것을 사용할지 고민했다.

Open-Meteo를 사용하면 상대적으로 간단하게 구현할 수 있지만, 이번 프로젝트에서는 기상청 공공데이터를 직접 사용해보는 것을 선택했다.

공공 API를 직접 연결해보는 과정 자체가 좋은 학습이 될 것이라고 생각했기 때문이다.

---

5. 기상청 API를 직접 연결해보기

기상청 공공데이터포털에서 단기예보 조회서비스 일반 인증키를 발급받았다.

이번 활용신청에는 다음 API들이 포함되어 있었다.

• 초단기실황조회
• 초단기예보조회
• 단기예보조회
• 예보버전조회

현재 날씨를 구현하기 위해 우선 사용한 것은 다음 두 API다.

초단기실황
getUltraSrtNcst

초단기예보
getUltraSrtFcst

여기서 재미있었던 부분은 현재 날씨를 하나의 API만 호출해서 완성할 수 없었다는 것이다.

초단기실황에는 기온, 습도, 강수량, 강수형태 등의 정보가 있지만 우리가 원하는 하늘상태(SKY)가 없었다.

그래서 초단기예보를 추가로 호출해서 SKY를 가져오는 방식으로 구성했다.

---

6. SKY가 없어서 API를 하나 더 사용하게 된 이유

현재 날씨 결과에 하늘상태를 포함시키고 싶었다.

예를 들어,

기온 32.3℃
습도 57%
강수 없음
맑음

같은 결과를 만들고 싶었는데 초단기실황만으로는 SKY를 가져올 수 없었다.

그래서 구조를 다음과 같이 만들었다.

get_current_weather
        │
        ├─ 초단기실황
        │    ├─ 기온
        │    ├─ 습도
        │    ├─ 강수량
        │    ├─ 강수형태
        │    └─ 풍속
        │
        └─ 초단기예보
             └─ SKY

그리고 강수형태가 존재한다면 SKY보다 강수형태를 우선하도록 했다.

비/눈 등이 있음
→ 강수형태를 날씨로 사용

강수가 없음
→ SKY를 날씨로 사용

이 과정을 통해 단순히 API 값을 가져오는 것보다 서로 다른 API의 데이터를 어떻게 조합해서 하나의 의미 있는 결과로 만들 것인지가 중요하다는 것을 알게 되었다.

---

7. 실제 기상청 데이터를 받아보았다

Codex를 이용해 weather.py를 작성하고 실제 기상청 API를 호출해봤다.

서울을 대상으로 테스트했으며 실제 데이터가 정상적으로 반환되는 것을 확인했다.

결과에는 다음과 같은 정보가 포함되도록 했다.

location
temperature_c
humidity_percent
precipitation_1h_mm
precipitation_type
sky
weather
wind_speed_mps
observed_at
sky_forecast_at
source

실제 호출 결과로 서울의 기온, 습도, 강수량, 강수형태, 하늘상태, 풍속 등을 받아오는 것까지 확인했다.

특히 observed_at과 sky_forecast_at을 구분한 것이 의미 있었다.

기온이나 습도는 실황 데이터이고, SKY는 가장 가까운 초단기예보 데이터이기 때문이다.

데이터를 가져왔다고 해서 전부 같은 시점의 관측값이라고 생각하면 안 된다는 것을 알게 되었다.

---

8. API Key를 다루면서 보안도 경험했다

처음 API를 연결하는 과정에서 오류를 확인하기 위해 요청 URL을 출력했는데, 그 과정에서 API Key가 로그에 노출될 가능성이 있었다.

당장 학습 과정에서는 큰 문제가 아니라고 생각할 수도 있지만, 실제 서비스에서는 API Key가 노출되면 안 된다.

그래서 이후에는

• .env에 API Key 저장
• .gitignore에 .env 추가
• 오류 메시지에서 요청 URL 숨기기
• API Key가 로그에 나오지 않도록 처리

하는 방향으로 수정했다.

이번 경험을 통해 "기능이 작동하는 것"과 "안전하게 작동하는 것"은 별개의 문제라는 것을 조금 이해하게 되었다.

---

9. MCP Tool에 실제 날씨 API 연결

처음 MCP 서버를 만들 때는 연결 테스트를 위해 임시 데이터를 반환하도록 했다.

MCP Server
   ↓
Tool 발견
   ↓
Tool 호출
   ↓
임시 응답

그 다음 실제 기상청 API를 연결하면서 구조가 이렇게 바뀌었다.

MCP Client
   ↓
get_current_weather("부산")
   ↓
지역 확인
   ↓
기상청 초단기실황
   +
기상청 초단기예보
   ↓
데이터 조합
   ↓
현재 날씨 반환

현재는 서울, 부산, 인천, 대전, 대구, 광주, 울산, 세종 등의 지역을 지원하도록 만들었다.

---

10. MCP 서버를 팀원에게 공유하는 과정

MCP 서버를 혼자 사용하는 것에서 끝나는 것이 아니라 팀원들이 내 서버를 사용할 수 있도록 네트워크로 공유하는 것도 중요했다.

서버는 다음과 같이 실행했다.

0.0.0.0:8010

여기서 0.0.0.0은 서버가 특정 로컬 주소 하나만 사용하는 것이 아니라 네트워크 인터페이스에서 들어오는 연결을 받을 수 있도록 대기한다는 의미다.

내 컴퓨터에서만 테스트할 때는

http://127.0.0.1:8010/mcp

를 사용할 수 있지만 팀원이 접속할 때는 내 PC의 네트워크 IP를 사용해야 한다.

예를 들어 내 IP가

192.100.200.232

라면 팀원에게 공유할 주소는

http://192.100.200.232:8010/mcp

가 된다.

이를 통해 MCP 서버도 결국 다른 프로그램과 통신하는 하나의 서버라는 것을 조금 더 현실적으로 이해할 수 있었다.

---

11. Codex를 사용하면서 느낀 점

오늘은 Codex를 적극적으로 사용했다.

처음에는 AI에게

"이 기능 만들어줘."

라고 하면 알아서 만들어주는 것이 편하다고 생각했다.

그런데 수업을 들으면서 생각이 조금 달라졌다.

AI가 코드를 잘 만들어주는 것과 내가 좋은 개발을 하는 것은 같은 의미가 아니었다.

특히 AI에게 너무 많은 권한을 주면 코드가 금방 복잡해진다.

그래서 지금은 오히려 AI에게 다음과 같이 요구하는 것이 중요하다고 느꼈다.

나는 초보자다.
가장 단순한 구조로 만들어라.
현재 필요한 기능만 구현하라.
불필요한 추상화를 추가하지 마라.
디렉터리 구조를 먼저 설명하라.
코드를 작성한 뒤 내가 이해할 수 있도록 설명하라.

그리고 AI가 만든 코드를 그대로 사용하는 것이 아니라

"이 코드는 왜 이렇게 되어 있지?"

라고 다시 확인하는 과정이 필요했다.

---

12. 오늘 새롭게 이해한 점

오늘 가장 크게 느낀 변화는 AI를 코드를 대신 작성해주는 도구로만 보면 안 된다는 것이다.

예전에는 개발자가 코드를 직접 작성하는 능력이 가장 중요하다고 생각했다.

하지만 AI 코딩 도구를 사용해보니 내가 원하는 결과를 만들기 위해서는 오히려

• 요구사항을 구체적으로 정의하고
• 필요한 데이터를 파악하고
• 프로젝트 구조를 결정하고
• AI에게 정확한 조건을 전달하고
• 결과물을 검토하고
• 잘못된 부분을 다시 수정하도록 요청하는

능력이 중요하다는 것을 느꼈다.

특히 기획과 요구사항 정리가 생각보다 훨씬 중요하다는 점이 인상적이었다.

AI가 코드를 만들어줄 수 있는 상황에서는 "코드를 직접 얼마나 빨리 작성하느냐"보다 무엇을 만들지 정확하게 정의하는 능력이 결과에 큰 영향을 줄 수 있다는 것을 경험했다.

---

13. 아직 부족한 부분

아직 MCP 서버의 전체 구조를 내가 처음부터 완전히 설계할 수 있는 수준은 아니다.

특히 다음 부분은 더 공부해야 한다.

• MCP Server와 Client의 전체 동작 구조
• Streamable HTTP 방식
• 기상청 API의 발표시간과 조회시간 규칙
• 기상청 격자 좌표 nx, ny
• API 응답 데이터 처리
• 네트워크를 통한 MCP 서버 공유
• 서버 운영과 보안

그리고 가장 큰 과제는 AI가 만들어준 코드를 읽고 이해하는 능력이다.

코드를 만들어주는 것은 AI가 상당 부분 도와줄 수 있지만, 결과물이 제대로 만들어졌는지 판단하려면 결국 내가 코드를 읽을 수 있어야 한다.

---

14. 오늘의 회고

오늘은 단순히 MCP 서버 하나를 만드는 것보다 실제 서비스를 구성하는 과정 전체를 조금 경험했다는 점에서 의미가 있었다.

처음에는 가짜 데이터를 반환하는 간단한 MCP Tool이었지만,

MCP Server
→ 실제 API 연결
→ 데이터 조합
→ 보안 처리
→ Tool 연결
→ 네트워크 실행
→ 팀원 공유

까지 단계적으로 확장해봤다.

특히 기상청 API에서 SKY가 빠져 있어서 초단기실황과 초단기예보를 함께 사용하게 된 과정이 기억에 남는다.

그리고 AI 코딩 도구를 사용하면서 코드를 많이 만들어내는 것보다 내가 원하는 구조와 조건을 정확하게 설명하는 것이 중요하다는 것도 직접 느꼈다.

아직 코드를 보면 모르는 부분이 많지만, 적어도 오늘은 "API를 가져와서 MCP Tool로 만들어 다른 프로그램에서 사용할 수 있게 한다"는 전체적인 흐름을 직접 경험했다.

다음 단계에서는 현재 날씨 MCP 서버를 마무리하고, 다음 주 날씨 예보 기능을 기상청 단기예보 API와 연결하는 것까지 진행해볼 예정이다.

---

오늘의 핵심 정리

MCP 서버는 AI가 외부 데이터나 기능을 사용할 수 있도록 연결해주는 하나의 인터페이스가 될 수 있다.

오늘은 이 개념을 가짜 데이터가 아니라 실제 기상청 API를 연결하면서 직접 경험했다.

#AI오케스트레이션 #MCP #MCP서버 #기상청API #공공데이터API #Python #Codex #AI에이전트 #멀티에이전트 #개발자국비지원