AI로 외국인환자 유치하기AI에게 코딩을 맡겨도, 알아두면 좋은 개발 용어들
핵심 요약
- 모든 개발 용어를 외울 필요는 없다. 다만 몇 가지를 알아두면 AI가 무엇을 하고 있는지, 어디까지 끝냈는지, 다음 단계에서 무엇을 확인해야 하는지 판단하기 쉬워진다.
- AI에게 작업을 맡기는 순간부터 실제 서비스에 반영하기까지, 자주 등장하는 용어를 흐름에 따라 정리했다.
- PR을 만들었다고 머지가 끝난 것은 아니며, 커밋했다고 원격 저장소에 올라간 것도 아니다.
- 용어를 조금 알게 되면 AI에게 요청하는 문장도 구체적으로 바뀐다.
인공지능 에이전트의 도움으로 바이브코딩을 하다 보면 낯선 단어를 자주 만난다.
“브랜치를 만들었습니다.”
“커밋하고 푸시하겠습니다.”
“빌드는 통과했지만 E2E 테스트가 실패했습니다.”
코드를 만들어 달라고 했는데, 결과를 이해하려면 또 다른 언어를 배워야 하는 것처럼 느껴진다.
모든 개발 용어를 외울 필요는 없다. 다만 몇 가지를 알아두면 AI가 무엇을 하고 있는지, 어디까지 끝냈는지, 다음 단계에서 무엇을 확인해야 하는지 판단하기 쉬워진다.
AI에게 작업을 맡기는 순간부터 실제 서비스에 반영하기까지, 자주 등장하는 용어를 흐름에 따라 정리했다.
AI에게 일을 설명할 때 사용하는 말
| 용어 | 쉬운 설명 | 사용 예시 |
|---|---|---|
| 프롬프트 · Prompt | AI에게 전달하는 요청이나 지시다. | “회원가입 화면을 만들고, 입력 오류가 있으면 안내 문구를 보여줘.” |
| 명세 · Specification, Spec | 만들어야 할 기능과 조건을 구체적으로 적은 것이다. | “이메일은 필수이며, 이미 가입된 주소라면 중복 안내를 표시한다.” |
| 컨텍스트 · Context | AI가 작업을 판단할 때 참고하는 정보다. 대화, 코드, 문서, 도구 실행 결과 등이 포함된다. | 기존 디자인과 로그인 방식을 먼저 읽게 한다. |
| 토큰 · Token | AI가 글과 코드를 처리하는 단위다. 글자 수나 단어 수와 정확히 같지는 않다. | 긴 문서와 코드를 많이 전달하면 처리하는 토큰도 늘어난다. |
| 컨텍스트 윈도 · Context Window | AI가 한 번의 처리에서 다룰 수 있는 정보량의 한도다. | 긴 작업에서는 중요한 결정과 현재 상태를 따로 정리해 전달한다. |
| 에이전트 · Agent | 목표에 따라 다음 행동을 정하고, 도구를 사용하며 작업을 진행하는 AI 시스템이다. | 파일을 읽고 수정한 뒤 테스트 결과를 보고 다시 고친다. |
특히 컨텍스트는 영구적인 기억과 구분해서 이해하면 좋다. 대화가 길어지면 도구에 따라 이전 내용이 요약되거나 일부가 제외될 수 있다. AI에게 일을 이어 맡길 때는 현재 목표, 결정된 조건, 남은 문제를 짧게 정리해 주는 편이 유용하다.
만들고 있는 서비스의 구조를 설명하는 말
예를 들어 신청 화면이 나타나고, 사용자가 내용을 입력하고, 제출한 정보가 저장되는 기능을 생각해 보자. 화면과 저장 처리는 서로 연결되지만 역할이 다르다.
| 용어 | 쉬운 설명 | 사용 예시 |
|---|---|---|
| 프런트엔드 · Frontend | 사용자가 보는 화면과 그 화면에서 일어나는 상호작용을 담당한다. | 버튼, 입력창, 메뉴, 오류 안내를 만든다. |
| 백엔드 · Backend | 서버 쪽에서 데이터 처리와 서비스 규칙 등을 담당한다. | 제출한 내용을 확인하고 저장하거나 접근 권한을 검사한다. |
| API | 프로그램이 다른 프로그램의 기능이나 데이터를 정해진 방식으로 이용하는 접점이다. | 화면에서 서버에 신청 내용을 전달한다. |
| 데이터베이스 · Database, DB | 데이터를 체계적으로 저장하고 조회하는 시스템이다. | 회원, 상품, 신청 내역을 저장한다. |
| 스키마 · Schema | 데이터의 항목, 형식, 관계 등을 정한 구조다. | 신청 내역에 신청번호, 날짜, 처리 상태를 두기로 정한다. |
| 컴포넌트 · Component | 화면이나 기능을 구성하는, 재사용할 수 있는 부품이다. | 여러 페이지에서 같은 신청 버튼을 사용한다. |
| 라이브러리 · Library | 필요한 기능을 가져다 쓸 수 있도록 만들어 놓은 코드 모음이다. | 날짜 계산이나 차트 표시 기능을 가져다 쓴다. |
| 프레임워크 · Framework | 애플리케이션을 만드는 기본 구조와 작업 방식을 제공하는 틀이다. | 정해진 구조에 맞춰 페이지와 서버 기능을 작성한다. |
| 의존성 · Dependency | 프로젝트가 동작하거나 개발되기 위해 필요로 하는 다른 코드나 도구다. | 사용하는 라이브러리의 특정 버전이 필요하다. |
이 구분을 알면 “화면은 만들어졌지만 저장 API는 아직 연결되지 않았다”는 설명을 이해할 수 있다. 화면이 보이는 상태와 정보가 실제로 저장되는 상태를 나누어 확인하는 것이다.
변경 내용을 기록하고 합치는 말
| 용어 | 쉬운 설명 |
|---|---|
| 깃 · Git | 코드의 변경 이력을 기록하고 관리하는 도구다. |
| 깃허브 · GitHub | Git 저장소를 온라인에 보관하고, 변경 검토와 협업을 지원하는 서비스다. |
| 저장소 · Repository, Repo | 프로젝트 파일과 변경 이력을 관리하는 공간이다. |
| 브랜치 · Branch | 기존 이력에서 갈라져 별도로 변경을 이어 가는 작업 흐름이다. |
| 워크트리 · Worktree | 같은 저장소의 다른 브랜치를 별도 폴더에서 작업할 수 있게 하는 Git 기능이다. |
| 디프 · Diff | 변경 전후에 무엇이 추가·수정·삭제됐는지 보여주는 차이다. |
| 커밋 · Commit | 선택한 변경을 Git 이력의 한 지점으로 기록하는 것이다. 파일 저장과는 별도다. |
| 푸시 · Push | 로컬 저장소의 커밋 등을 원격 저장소에 반영하는 작업이다. |
| 풀 · Pull | 원격 저장소의 변경을 가져와 현재 브랜치에 통합하는 작업이다. |
| 풀 리퀘스트 · Pull Request, PR | 변경 내용을 검토하고 합쳐 달라는 요청이다. |
| 머지 · Merge | 서로 다른 개발 이력을 합치는 작업이다. |
| 충돌 · Conflict | 변경을 자동으로 합칠 수 없어 어떤 내용을 남길지 판단해야 하는 상태다. |
여기서는 파일 저장 → 커밋 → 푸시 → PR → 머지가 각각 다른 행동이라는 점을 기억하면 된다. PR을 만들었다고 머지가 끝난 것은 아니며, 커밋했다고 원격 저장소에 올라간 것도 아니다. 여러 AI에게 동시에 작업을 맡길 때는 워크트리라는 말을 만날 수 있다. 각 작업을 별도 폴더에서 진행하는 데 도움이 되지만, 나중에 변경을 합치고 검토하는 과정은 여전히 필요하다.
코드를 어디에서, 어떤 설정으로 실행하는가
| 용어 | 쉬운 설명 | 알아두면 좋은 점 |
|---|---|---|
| IDE | 코드 편집, 실행, 오류 확인 등을 돕는 통합 개발 환경이다. | 개발 작업을 하는 작업실이라고 생각하면 된다. |
| 터미널 · Terminal / CLI | 터미널은 글자로 명령을 입력하는 창이고, CLI는 명령어로 프로그램을 조작하는 방식이다. | AI가 설치·실행·검사 명령을 수행할 때 자주 등장한다. |
| 로컬 · Local / localhost | 로컬은 현재 작업하는 컴퓨터의 환경이다. localhost는 접속하는 컴퓨터 자신을 가리킨다. | 내 컴퓨터의 localhost 주소는 다른 사람에게 보내도 같은 화면으로 연결되지 않는다. |
| 개발 환경 · Development | 기능을 만들고 수정하며 확인하는 환경이다. | 개발 환경도 외부 데이터나 서비스에 연결될 수 있다. |
| 스테이징 · Staging | 운영 반영 전에 최종 점검하기 위해 마련하는 환경이다. | Git에서 커밋할 변경을 골라 두는 ‘스테이징’과는 다른 뜻이다. |
| 프로덕션 · Production | 실제 사용자가 이용하는 운영 환경이다. | 여기의 변경은 실제 사용자에게 영향을 줄 수 있다. |
| 환경변수 · Environment Variable | 실행 환경에서 프로그램에 전달하는 설정값이다. | 서버 주소나 기능 설정 등을 환경마다 다르게 지정한다. |
| API 키 · API Key | 서비스에 따라 호출 주체를 식별하거나 API 접근을 인증하는 데 사용하는 값이다. | 비밀 키는 공개 코드나 브라우저에 전달되는 코드에 포함하면 안 된다. |
“로컬에서 정상 작동했다”는 말은 확인한 환경의 범위를 알려준다. 실제 서비스에서도 작동하는지는 운영 환경의 설정과 연결 상태를 포함해 확인해야 한다. 환경변수에 넣었다는 사실만으로 비밀값이 안전해지는 것도 아니다.
문제를 찾고 제대로 작동하는지 확인하는 말
| 용어 | 쉬운 설명 | 사용 예시 |
|---|---|---|
| 버그 · Bug | 프로그램이 의도한 대로 작동하지 않는 결함이다. | 제출 버튼을 두 번 누르면 신청이 중복 저장된다. |
| 디버깅 · Debugging | 문제를 재현하고 원인을 찾아 수정하는 과정이다. | 중복 저장이 화면 때문인지 서버 처리 때문인지 확인한다. |
| 로그 · Log | 프로그램이 남기는 실행 기록이다. | 요청이 언제 들어왔고 어디에서 실패했는지 살펴본다. |
| 단위 테스트 · Unit Test | 작은 기능 단위를 따로 검사한다. | 할인 금액 계산이 맞는지 확인한다. |
| 통합 테스트 · Integration Test | 여러 부분이 연결됐을 때의 동작을 검사한다. | 신청 처리와 데이터 저장이 함께 작동하는지 확인한다. |
| E2E 테스트 · End-to-End Test | 사용자가 수행하는 흐름을 처음부터 끝까지 검사한다. | 로그인하고 신청서를 제출해 완료 화면까지 도달한다. |
| 린트 · Lint | 코드를 실행하기 전, 정해진 규칙 위반이나 의심스러운 패턴 등을 검사한다. | 사용하지 않는 변수나 실수하기 쉬운 표현을 찾는다. |
| 타입 검사 · Type Check | 데이터 종류와 사용 방식이 맞는지 검사한다. | 숫자가 필요한 곳에 문자열을 전달했는지 확인한다. |
| 회귀 테스트 · Regression Test | 수정 후 기존 기능이 망가지지 않았는지 확인한다. | 회원가입 수정 뒤 기존 로그인도 다시 확인한다. |
| 리팩터링 · Refactoring | 외부에서 관찰되는 동작을 유지하면서 코드 내부 구조를 개선하는 작업이다. | 반복 코드를 하나로 모아 수정하기 쉽게 만든다. |
“테스트 통과”라는 보고를 받으면 무엇을 어떤 조건에서 테스트했는지도 함께 보면 좋다. 계산 기능 검사와 실제 브라우저에서 신청을 완료하는 검사는 확인하는 범위가 다르다. 테스트에서 가짜 응답을 사용했다면 실제 외부 서비스 연결까지 검증한 것은 아닐 수 있다. 린트와 타입 검사도 유용하지만 사용자가 원하는 기능이 완성됐다는 보장은 아니다. 코드 규칙을 지키면서도 신청 결과를 잘못 표시하는 프로그램은 만들 수 있다.
완성한 코드를 서비스에 반영할 때 사용하는 말
| 용어 | 쉬운 설명 | 알아두면 좋은 점 |
|---|---|---|
| 빌드 · Build | 소스 코드를 실행하거나 배포할 형태로 준비하는 과정이다. | 빌드 성공과 실제 기능의 정상 작동은 별도로 확인한다. |
| 배포 · Deploy | 준비한 프로그램을 실행할 환경에 반영하는 작업이다. | 테스트 환경에 배포할 수도, 실제 운영 환경에 배포할 수도 있다. |
| 호스팅 · Hosting | 웹사이트나 서비스가 실행되고 접속될 수 있도록 운영 환경을 제공하는 것이다. | 코드를 보관하는 저장소와 서비스가 실행되는 환경은 역할이 다르다. |
| CI · Continuous Integration | 코드 변경을 자주 통합하면서 빌드와 테스트 같은 검사를 자동으로 수행하는 개발 방식이다. | 변경을 공유할 때 자동 검사가 실행되도록 구성한다. |
| CD · Continuous Delivery / Deployment | 변경을 배포 가능한 상태로 유지하거나, 검사를 통과한 변경을 자동 배포하는 방식을 뜻한다. | CD가 어느 뜻으로 쓰이는지, 실제 배포까지 자동인지 확인한다. |
| 롤백 · Rollback | 문제가 생겼을 때 이전 버전이나 상태로 되돌리는 작업이다. | 코드 버전을 되돌려도 이미 변경된 데이터까지 자동 복구되는 것은 아니다. |
푸시나 머지 뒤에 자동 배포가 실행되도록 설정한 프로젝트도 있다. 따라서 “푸시하겠습니다”라는 설명을 들으면, 그 작업에 배포가 연결되어 있는지도 알아두는 편이 좋다.
MCP
AI 도구를 연결하다 보면 “MCP”라는 말도 만나게 된다. MCP는 AI 애플리케이션이 외부 데이터와 도구에 연결할 때 사용하는 공개 표준이다. 연결된 도구의 기능과 권한에 따라 자료를 읽거나 작업을 수행할 수 있다.
질문이 달라진다
용어를 조금 알게 되면 AI에게 요청하는 문장도 구체적으로 바뀐다.
“다 됐어?” 대신 이렇게 물을 수 있다.
“코드 수정, 테스트, 커밋, 푸시, 배포 중 어디까지 완료했는지 구분해서 알려줘. 실제로 확인한 기능과 아직 확인하지 못한 부분도 함께 설명해 줘.”
수정 전에는 작업 범위를 확인할 수 있다.
“이번 요청으로 바뀌는 화면과 기능을 먼저 설명해 줘. 기존 기능에 미치는 영향과 완료 여부를 확인할 방법도 정리해 줘.”
결과를 검토할 때는 변경 내용을 이해하는 데 집중할 수 있다.
“디프를 기준으로 무엇을 왜 바꿨는지 쉬운 말로 설명해 줘. 문제가 생기면 되돌리는 방법도 알려줘.”
개발 용어를 배우는 가장 실용적인 순간은 이런 질문을 할 때다. AI의 작업 설명에서 현재 상태를 읽고, 다음 행동을 판단할 수 있게 된다.


