웹 프로젝트를 처음 만드는 취업 준비생에게 API를 설명해 달라고 하면 프런트엔드와 백엔드를 연결하는 기능이라고 답하는 경우가 많습니다. 방향은 맞지만 실제 프로젝트에서 로그인 요청이 실패하거나 날씨 정보가 화면에 나타나지 않으면 어디부터 확인해야 하는지는 설명하지 못하기도 합니다. 주소를 입력하면 데이터를 받는 기능으로만 이해했기 때문입니다.
API는 서로 다른 프로그램이 정해진 방법으로 기능과 데이터를 주고받기 위한 연결 기준입니다. 어떤 주소로 무엇을 보내야 하는지, 정상적으로 처리되면 어떤 결과가 돌아오는지, 실패하면 어떻게 알려주는지가 함께 정해져야 합니다. 개념이해에서 끝나지 않고 요청과 응답을 직접 확인해야 실생활 서비스와 프로젝트에서 API가 어떤 역할을 하는지 제대로 이해할 수 있습니다.
API 개념이해는 프로그램 사이의 약속을 아는 것부터 시작합니다
- API는 기능을 사용할 수 있도록 공개된 연결 기준입니다
API는 Application Programming Interface의 줄임말입니다. 한 프로그램이 다른 프로그램의 기능이나 데이터를 사용할 수 있도록 정해 놓은 방법을 의미합니다. 웹 서비스뿐 아니라 운영체제와 라이브러리, 외부 장치에서도 사용되지만 취업 준비 과정에서는 서버와 클라이언트가 HTTP를 통해 데이터를 주고받는 웹 API를 자주 접하게 됩니다.
음식점에서 손님이 주방에 직접 들어가 요리하지 않고 메뉴판을 보고 직원에게 주문하는 장면으로 생각할 수 있습니다. 메뉴판에는 주문할 수 있는 음식과 필요한 선택 항목이 정리되어 있습니다. 손님은 정해진 방식으로 주문하고 주방은 결과를 음식이나 품절 안내로 전달합니다.
이 비유에서 메뉴판은 사용할 수 있는 기능과 요청 방법을 알려주는 문서에 가깝습니다. 주문 내용은 요청, 주방의 처리 결과는 응답으로 볼 수 있습니다. 다만 실제 API에서는 주소와 요청 방식, 인증 정보, 데이터 형식, 상태 코드처럼 더 구체적인 규칙을 사용합니다.
- API는 상대 프로그램의 내부 코드를 모두 알지 못해도 필요한 기능을 사용할 수 있게 합니다. 날씨 서비스가 데이터를 수집하는 내부 방식은 몰라도 정해진 지역 정보를 보내 현재 기온을 받을 수 있습니다.
- 연결 기준이 공개되어 있더라도 모든 사람이 제한 없이 사용할 수 있는 것은 아닙니다. 인증 키나 로그인 정보가 필요할 수 있고, 일정 시간 동안 요청할 수 있는 횟수가 제한되기도 합니다.
- 같은 기능이라도 요청값과 응답 형식이 달라지면 연동하는 프로그램도 수정해야 합니다. 따라서 문서와 버전, 변경 사항을 확인하는 습관이 필요합니다.
- 쇼핑몰의 상품 조회로 흐름을 이해할 수 있습니다
사용자가 쇼핑몰에서 운동화를 검색하면 화면은 검색어를 서버에 전달합니다. 서버는 전달받은 단어가 올바른지 확인한 뒤 데이터베이스에서 관련 상품을 찾습니다. 처리 결과는 상품명과 가격, 이미지 주소, 재고 상태와 같은 데이터로 돌아옵니다.
검색 결과가 없다면 빈 목록을 반환할 수 있고, 요청 형식이 잘못됐다면 오류 정보를 보낼 수 있습니다. 서버 내부에서 문제가 생겼다면 정상 결과와 다른 상태 코드가 전달됩니다. 화면은 받은 결과에 따라 상품 목록이나 결과 없음, 다시 시도 안내를 보여줍니다.
이 과정에서 중요한 점은 화면이 데이터베이스에 직접 접근하지 않는다는 것입니다. 클라이언트는 정해진 연결 규칙에 따라 서버에 필요한 기능을 요청하고, 서버는 내부 처리 결과 중 필요한 내용만 응답합니다.
- 요청 중심 설명: 운동화라는 검색어로 상품 조회 기능을 호출합니다.
- 서버 처리까지 포함한 설명: 전달받은 검색어를 검증하고 데이터베이스에서 조건에 맞는 상품을 조회합니다.
- 사용자 흐름이 담긴 설명: 검색 결과가 있으면 상품 목록을 보여주고, 결과가 없으면 검색 조건을 바꾸도록 안내합니다. 요청에 실패하면 오류 상태를 구분해 사용자가 다시 시도할 수 있도록 처리합니다.
- 내부 기능과 외부 서비스 연결에도 사용됩니다
API는 외부 회사의 데이터를 가져올 때만 사용하는 것이 아닙니다. 하나의 서비스 안에서도 화면과 서버, 여러 서버 기능이 서로 통신하는 데 사용됩니다. 회원 서비스가 사용자 정보를 확인하고 주문 서비스가 회원의 권한과 배송지 정보를 전달받는 구조도 가능합니다.
외부 연결에서는 지도와 날씨, 결제, 소셜 로그인, 문자 발송 기능을 자주 볼 수 있습니다. 서비스를 직접 처음부터 만들지 않고 제공된 기능을 정해진 규칙에 따라 사용할 수 있습니다. 개발 시간은 줄일 수 있지만 외부 서비스의 응답 지연과 사용 제한, 요금, 장애 가능성도 고려해야 합니다.
- 지도 API를 이용하면 주소 검색과 위치 표시, 경로 안내 기능을 서비스에 추가할 수 있습니다. 사용자가 입력한 주소를 좌표로 바꾸거나 특정 위치를 지도에 표시하는 방식으로 활용됩니다.
- 결제 API는 결제 요청과 승인 결과를 주고받는 데 사용됩니다. 금액과 주문 정보를 정확히 전달하고 성공, 취소, 실패 상태를 구분해야 하며 같은 결제가 중복 처리되지 않도록 주의해야 합니다.
- 소셜 로그인은 외부 서비스가 확인한 사용자의 정보를 전달받아 가입과 로그인을 처리합니다. 제공받을 수 있는 정보의 범위와 인증 정보의 보관 방법도 함께 살펴봐야 합니다.
- 문서를 읽는 능력도 API 활용의 일부입니다
처음 사용하는 API는 문서를 통해 주소와 요청 방식, 필요한 값, 인증 방법, 응답 구조를 확인해야 합니다. 예제 코드를 그대로 복사하기보다 각 값이 왜 필요한지 이해하는 것이 중요합니다.
문서에서 먼저 확인할 내용은 사용할 기능의 주소와 요청 방식입니다. 필수로 보내야 하는 값과 선택값을 구분하고, 데이터를 주소에 포함하는지 본문에 담는지도 살펴봐야 합니다. 정상 응답과 오류 응답의 예시가 있다면 함께 비교해야 합니다.
프로젝트에서 외부 API를 사용했다면 사용했다는 사실만 기록하지 않는 것이 좋습니다. 어떤 기능을 선택했고 어떤 값을 보냈는지, 응답에서 필요한 항목을 어떻게 추출했는지, 요청이 실패할 때 무엇을 처리했는지를 남겨야 실제 경험으로 활용할 수 있습니다.
요청과 응답 구조를 이해하면 오류 원인을 더 정확하게 찾을 수 있습니다
- 요청에는 주소 외에도 여러 정보가 포함됩니다
웹 API 요청에는 일반적으로 어떤 기능을 사용할지 나타내는 주소와 요청 방식이 포함됩니다. 조회와 생성, 수정, 삭제처럼 목적에 따라 GET, POST, PUT 또는 PATCH, DELETE 등의 방식을 사용할 수 있습니다. 다만 실제 의미와 사용 규칙은 제공하는 서비스의 문서를 기준으로 확인해야 합니다.
헤더에는 데이터 형식과 인증 정보처럼 요청을 처리하는 데 필요한 부가정보가 담길 수 있습니다. 본문에는 회원가입 정보나 주문 내용처럼 서버에 전달할 데이터가 들어갑니다. 주소 뒤에 검색어와 페이지 번호 같은 조건을 붙이는 경우도 있습니다.
- GET은 주로 정보를 조회할 때 사용합니다. 상품 목록과 게시글, 사용자에게 공개된 데이터를 가져오는 상황에서 볼 수 있습니다.
- POST는 새로운 데이터를 만들거나 처리를 요청할 때 자주 사용합니다. 회원가입과 주문 생성, 파일 업로드처럼 서버의 상태가 달라지는 기능에 활용됩니다.
- PATCH나 PUT은 기존 데이터를 변경할 때, DELETE는 삭제를 요청할 때 사용할 수 있습니다. 이름만 암기하지 말고 프로젝트의 기능이 어떤 변화를 만드는지 연결해 이해해야 합니다.
- 응답에는 결과 데이터와 처리 상태가 함께 담깁니다
서버는 요청을 처리한 뒤 데이터와 상태 코드를 응답합니다. 상태 코드는 요청이 정상적으로 처리됐는지, 입력이나 인증에 문제가 있는지, 서버 내부에서 오류가 발생했는지를 빠르게 구분하도록 도와줍니다.
200번대는 일반적으로 정상 처리를 나타내고, 400번대는 요청값이나 인증과 권한처럼 클라이언트 측에서 확인할 문제가 있을 때 사용됩니다. 500번대는 서버에서 처리 중 문제가 생긴 상황과 관련됩니다. 같은 범위 안에서도 의미가 다르기 때문에 숫자 전체를 외우기보다 프로젝트에서 자주 만나는 상태부터 이해하는 것이 좋습니다.
성공 응답에는 요청한 데이터나 처리 결과가 담깁니다. 오류 응답에는 오류를 구분할 수 있는 코드와 메시지, 필요한 경우 잘못된 입력 항목이 포함될 수 있습니다. 화면은 이 정보를 이용해 사용자에게 적절한 안내를 보여줍니다.
- 로그인 실패를 모두 같은 오류로 처리한 사례
프런트엔드 프로젝트에서 로그인 요청이 실패하면 모든 상황에 로그인할 수 없다는 같은 문구를 보여주는 사례가 있었습니다. 이메일 형식이 잘못된 경우와 비밀번호가 틀린 경우, 서버가 응답하지 않는 경우가 구분되지 않아 사용자는 무엇을 수정해야 하는지 알기 어려웠습니다.
준비생은 처음에 로그인 실패는 모두 같은 결과라고 판단했습니다. 그러나 네트워크 응답을 확인해 보니 잘못된 입력과 인증 실패, 서버 오류는 서로 다른 상태와 메시지로 전달되고 있었습니다. 화면에서 응답 정보를 확인하지 않고 실패 여부만 처리한 것이 문제였습니다.
이후 입력 형식이 잘못된 경우에는 해당 입력란을 안내하고, 인증에 실패하면 계정 정보를 다시 확인하도록 표시했습니다. 서버가 응답하지 않으면 잠시 후 다시 시도할 수 있도록 안내했습니다. 요청이 진행되는 동안 로그인 버튼을 비활성화해 반복 요청도 막았습니다.
- 단순한 설명: 로그인 API를 연동하고 성공하면 메인 화면으로 이동하도록 구현했습니다.
- 응답 처리가 보이는 설명: 로그인 성공과 입력 오류, 인증 실패, 서버 오류를 구분해 서로 다른 화면 상태를 표시했습니다.
- 문제해결이 담긴 설명: 모든 실패에 같은 문구를 보여줘 사용자가 원인을 알 수 없는 문제를 발견했습니다. 상태 코드와 오류 응답을 비교해 입력 오류와 인증 실패, 서버 문제를 구분하고 각 상황을 직접 테스트했습니다.
API 연동은 요청을 보내고 데이터를 받는 데서 끝나지 않습니다. 응답의 의미를 해석하고 사용자에게 다음 행동을 안내하는 과정까지 연결되어야 실제 기능이 완성됩니다.
- 요청값 이름이 달라 발생한 팀 프로젝트 오류
팀 프로젝트에서 프런트엔드 담당자는 회원가입 요청에 사용자 이름을 userName이라는 기준으로 전달했지만 백엔드에서는 다른 이름으로 값을 받고 있었습니다. 화면에서는 정상적으로 입력했지만 서버에서는 이름이 비어 있다고 판단해 저장에 실패했습니다.
처음에는 데이터베이스 저장 로직에 문제가 있다고 생각했습니다. 서버 로그에서는 필수값이 없다는 오류가 나타났고, 실제 네트워크 요청을 확인하면서 화면에서 보낸 본문의 항목명과 서버가 기대하는 이름이 다르다는 사실을 발견했습니다.
두 담당자는 회원가입 요청에 필요한 값과 형식, 필수 여부를 다시 정리했습니다. 정상 응답뿐 아니라 이메일 중복과 입력값 오류의 응답 예시도 API 문서에 추가했습니다. 문서를 수정한 뒤 정상 가입과 필수값 누락, 중복 이메일 상황을 함께 테스트했습니다.
- 기존 협업 설명은 화면과 서버를 연결했다는 결과에 머물렀습니다. 어떤 기준으로 요청값을 맞췄는지와 오류가 발생했을 때 무엇을 확인했는지는 나타나지 않았습니다.
- 보완된 경험에는 실제 요청 본문과 서버 로그를 비교해 원인을 찾은 과정이 포함됐습니다. 구두 전달에 의존하지 않고 문서에 요청과 응답 예시를 추가한 행동도 드러났습니다.
- 이 사례는 단순한 연동 오류를 넘어 협업 과정에서 데이터 규칙을 맞추고 다시 검증한 경험으로 활용할 수 있습니다.
- 오류가 발생하면 확인할 순서가 있습니다
API 요청이 실패했을 때 코드를 무작정 바꾸기보다 요청과 응답을 분리해 확인해야 합니다. 먼저 요청 주소와 방식이 문서와 일치하는지 살펴보고, 필수값과 데이터 형식이 올바른지 확인합니다. 인증 정보가 필요하다면 헤더에 제대로 포함됐는지도 점검해야 합니다.
그다음 상태 코드와 오류 메시지를 읽고 서버가 어떤 문제를 알려주는지 확인합니다. 응답 데이터가 왔지만 화면에 나타나지 않는다면 응답의 항목명과 화면에서 사용하는 이름을 비교합니다. 브라우저나 API 테스트 도구의 네트워크 기록을 이용하면 실제로 전달된 정보를 볼 수 있습니다.
- 요청 자체가 전달되지 않았다면 주소와 방식, 네트워크 환경을 먼저 살펴봅니다. 화면 코드만 수정하기 전에 실제 요청이 발생했는지 확인해야 합니다.
- 400번대 응답이라면 필수값과 형식, 인증과 권한을 점검합니다. 오류 메시지에 잘못된 항목이 표시되어 있다면 해당 정보를 먼저 확인하는 것이 좋습니다.
- 500번대 응답이라면 서버 로그와 처리 중 발생한 예외를 확인해야 합니다. 화면에서는 사용자가 다시 시도할 수 있도록 안내하되 내부 오류 내용을 그대로 노출하지 않도록 주의해야 합니다.
실생활 활용을 프로젝트 경험과 면접 답변으로 연결해야 합니다
- 생활 속 서비스는 여러 API를 조합해 작동합니다
배달 애플리케이션에서 주소를 검색하고 음식점을 찾으며 결제 결과를 확인하는 과정에는 여러 연결 기능이 사용될 수 있습니다. 지도 서비스는 주소와 위치 정보를 제공하고, 결제 서비스는 승인과 실패 결과를 전달합니다. 문자나 알림 서비스는 주문 상태를 사용자에게 알려줍니다.
여행 서비스에서는 항공권과 숙박 정보, 환율, 날씨 데이터를 가져올 수 있습니다. 건강관리 서비스는 스마트 기기에서 측정한 정보를 전달받아 기록하고 분석할 수 있습니다. 사용자는 하나의 화면을 보지만 내부에서는 여러 프로그램이 정해진 방식으로 데이터를 교환합니다.
외부 서비스를 활용하면 모든 기능을 직접 만들지 않아도 되지만 의존성이 생깁니다. 사용량 제한과 요금, 응답 속도, 장애, 데이터 형식 변경을 고려해야 합니다. 인증 키가 외부에 노출되지 않도록 관리하는 것도 중요합니다.
- 날씨 정보가 표시되지 않았던 프로젝트 사례
프런트엔드를 준비한 지원자는 사용자의 지역을 선택하면 현재 기온과 날씨를 보여주는 서비스를 만들었습니다. 정상적인 지역명을 입력하면 정보가 표시됐지만 일부 지역에서는 화면이 비어 있었고 잘못된 지역을 입력하면 오류 안내 없이 로딩 상태가 계속됐습니다.
처음에는 제공되는 날씨 데이터에 해당 지역이 없다고 생각했습니다. 실제 응답을 확인해 보니 지역 이름을 찾지 못한 경우 오류 정보가 반환되고 있었지만 화면에서는 성공 응답과 같은 구조로 데이터를 읽으려 했습니다. 일부 지역은 한글 이름을 그대로 전달했을 때 검색 결과가 다르게 나타나는 문제도 있었습니다.
지원자는 정상 응답과 지역 검색 실패, 인증 실패, 요청 제한 상황의 구조를 각각 확인했습니다. 사용자가 입력한 지역을 찾지 못하면 다시 입력하도록 안내하고, 인증이나 사용량 문제는 서비스 오류로 구분했습니다. 요청이 지연될 때 무한히 로딩되지 않도록 재시도 안내도 추가했습니다.
- 연동 결과 중심 설명: 외부 날씨 API를 이용해 지역별 현재 기온을 표시했습니다.
- 처리 과정이 보이는 설명: 지역 검색 결과와 현재 날씨 데이터를 연결하고 로딩과 결과 없음, 요청 실패 상태를 구현했습니다.
- 활용 경험이 담긴 설명: 존재하지 않는 지역에서 오류 응답을 정상 데이터처럼 읽어 화면이 멈추는 문제를 발견했습니다. 성공과 지역 검색 실패, 인증 오류, 요청 제한 응답을 나누어 확인하고 사용자 안내와 재시도 흐름을 추가했습니다.
외부 API를 사용했다는 사실만으로 실력을 보여주기는 어렵습니다. 문서를 읽고 요청값과 응답 구조를 확인하며, 정상 결과뿐 아니라 외부 서비스의 실패 상황까지 처리한 경험이 있어야 합니다.
- 결제 기능은 성공 화면만 확인해서는 안 됩니다
쇼핑몰 프로젝트에서 결제 요청 후 응답이 늦어지자 사용자가 결제 버튼을 다시 눌러 같은 주문에 두 번의 요청이 전달된 사례가 있었습니다. 화면에서는 첫 응답만 성공으로 표시했지만 서버와 결제 기록에는 중복 요청이 남을 가능성이 있었습니다.
이 문제는 버튼을 한 번만 누르도록 안내하는 것으로 해결하기 어렵습니다. 화면에서는 요청 중 버튼을 비활성화하고 진행 상태를 보여줘야 합니다. 서버에서는 이미 처리된 주문과 결제 요청인지 확인하고 같은 요청이 반복되더라도 중복 승인이 발생하지 않도록 기준을 마련해야 합니다.
- 결제 요청 전에는 상품과 주문금액이 화면 값과 서버 값에서 일치하는지 확인해야 합니다. 사용자가 화면의 값을 변경하더라도 서버에서 최종 금액을 검증할 수 있어야 합니다.
- 성공 응답뿐 아니라 사용자 취소와 결제 실패, 응답 지연, 처리 결과를 바로 알 수 없는 상황도 고려해야 합니다. 화면의 결과와 실제 결제 상태가 다르지 않은지 다시 확인하는 과정이 필요합니다.
- 외부 서비스에서 전달하는 인증 정보와 비밀키를 화면 코드에 직접 넣으면 안 됩니다. 공개되어도 되는 값과 서버에서 안전하게 관리해야 하는 값을 구분해야 합니다.
- API 경험은 포트폴리오에서 구체적으로 보여줘야 합니다
포트폴리오에 지도 API 연동, 날씨 API 활용이라고만 적으면 준비생이 예제 코드를 따라 했는지 실제로 요청과 응답을 이해했는지 판단하기 어렵습니다. 어떤 기능을 위해 선택했고 어떤 값을 전달했으며 응답에서 무엇을 사용했는지 적어야 합니다.
오류를 해결한 경험이 있다면 발생 조건과 확인한 상태 코드, 응답 메시지, 수정 후 테스트 결과를 함께 정리합니다. 외부 서비스에 장애가 발생하거나 사용 제한을 초과했을 때 화면과 서버가 어떻게 대응하는지도 좋은 점검 내용이 됩니다.
- 활용 결과만 적은 포트폴리오: 지도 API를 연동해 주변 매장을 표시했습니다.
- 직접 수행한 역할이 보이는 포트폴리오: 사용자의 위치를 좌표로 변환하고 거리 기준으로 주변 매장을 조회해 지도에 표시했습니다.
- 문제와 검증이 담긴 포트폴리오: 위치 권한을 거부하거나 좌표를 얻지 못한 경우 화면이 멈추는 문제를 발견했습니다. 권한 허용과 거부, 위치 확인 실패, 주변 매장 없음 상황을 구분하고 대체 검색 방법을 제공했습니다.
- 면접에서는 정의와 프로젝트 경험을 함께 설명해야 합니다
API가 무엇인지 질문받았을 때 프로그램 사이의 연결 기준이라고 정의한 뒤 프로젝트에서 사용한 장면을 이어서 설명하면 좋습니다. 요청과 응답, 인증과 오류 처리 중 자신이 직접 확인한 내용을 근거로 제시해야 합니다.
API 연동 경험을 묻는 질문에는 외부 서비스를 사용했다는 결과보다 문서를 읽고 필요한 요청값을 구성한 과정과 응답에서 필요한 데이터를 추출한 내용을 설명할 수 있습니다. 오류가 발생했을 때 주소와 방식, 요청값, 상태 코드, 응답 구조를 어떤 순서로 확인했는지도 좋은 답변이 됩니다.
- 개념 중심 답변: API는 서로 다른 프로그램이 기능과 데이터를 주고받기 위한 인터페이스입니다.
- 프로젝트 연결 답변: 날씨 서비스에 지역 정보를 요청하고 응답에서 기온과 날씨 상태를 추출해 화면에 표시했습니다.
- 면접에 활용할 답변: 지역을 찾지 못한 오류 응답을 정상 데이터처럼 처리해 로딩이 끝나지 않는 문제를 발견했습니다. 네트워크 기록에서 상태 코드와 응답 구조를 확인하고 성공, 지역 검색 실패, 인증 오류를 구분해 사용자 안내를 추가했습니다.
정의와 직접 경험을 연결하면 암기한 지식에서 벗어나 실제로 사용하고 문제를 해결한 근거를 보여줄 수 있습니다.
- conclusion
API는 프로그램이 서로의 내부 코드를 모두 알지 않아도 정해진 방법으로 기능과 데이터를 주고받게 해주는 연결 기준입니다. 웹 프로젝트에서는 주소와 요청 방식, 헤더와 본문을 이용해 필요한 정보를 보내고, 서버는 상태 코드와 결과 데이터를 응답합니다.
현재 자신의 이해와 프로젝트는 다음 내용을 중심으로 점검할 수 있습니다.
- API를 호출했다는 결과만 적지 말고 어떤 주소와 요청 방식을 사용했는지, 어떤 값을 보냈으며 응답에서 어느 항목을 활용했는지 설명할 수 있어야 합니다. 문서의 예제 코드를 복사한 범위와 직접 수정한 부분도 구분하는 것이 좋습니다.
- 오류가 발생하면 화면 코드만 바꾸지 말고 실제 요청과 응답을 확인해야 합니다. 주소와 방식, 필수값과 인증 정보, 상태 코드와 오류 메시지, 데이터 구조를 순서대로 비교하면 원인을 더 정확하게 좁힐 수 있습니다.
- 외부 서비스를 활용했다면 성공 상황뿐 아니라 잘못된 입력과 인증 실패, 사용량 제한, 응답 지연도 처리해야 합니다. 인증 키 노출을 막고 서비스가 일시적으로 실패했을 때 사용자가 다시 시도할 수 있는 흐름도 필요합니다.
실제 포트폴리오를 검토하면 API를 연동했다고 적었지만 요청값과 응답 구조를 설명하지 못하는 경우가 많습니다. 날씨와 지도 정보를 표시했다는 결과보다 어떤 데이터를 보냈고 무엇을 받아 사용했으며 실패 시 어떻게 대응했는지가 실력의 근거가 됩니다.
API 개념이해는 정의를 외우는 데서 끝나지 않습니다. 요청과 응답을 직접 기록하고 정상, 입력 오류, 인증 실패를 나누어 테스트하면 단순한 연동 기능이 문제해결 경험으로 바뀝니다. 이 기록은 README의 개선 사례가 되고 기술면접에서 자신의 프로젝트를 설명하는 답변으로 이어집니다.
