1. 오늘 배운 내용

73일차에는 AI 에이전트의 보안 강화부터 바이브 코딩을 활용한 도구 개발, 그리고 웹 애플리케이션의 프론트엔드와 백엔드가 분리된 배경까지 폭넓게 살펴봤다.

앞부분에서는 LLM이 생성한 답변에 개인정보나 내부 정보가 포함되지 않도록 검증하는 방법을 다뤘다. 이후에는 개발자가 직접 필요한 도구를 기획하고 구현하는 실습으로 이어졌다. 마지막에는 바이브 코딩으로 무언가를 만드는 것에서 그치지 않고, 실제 사용자를 찾고 제품을 운영하는 과정까지 생각해 봤다.

2. 핵심 개념 정리

2-1. LLM 워크플로우의 최종 출력 필터

AI 에이전트가 질문에 적절한 답변을 생성하더라도, 그 답변에 개인정보나 내부 정보가 포함되어 있다면 그대로 사용자에게 전달해서는 안 된다.

이를 방지하기 위해 최종 응답이 외부로 전달되기 직전에 한 번 더 검사하는 출력 필터를 적용할 수 있다.

• 전화번호, 이메일, 직원 식별 정보 등 개인정보 패턴 검사

• API 키나 내부 비밀 코드 등 민감한 정보의 노출 방지

• 필요한 경우 민감한 문자열을 마스킹하거나 응답 차단

• 차단한 이유와 처리 결과를 감사 로그로 기록

강의에서는 개인정보 마스킹과 필터링을 테스트하는 과정에서 일부 테스트가 실패하는 상황을 확인했다. 단순히 필터를 추가하는 것만으로 끝나는 것이 아니라, 정상적인 답변을 잘못 차단하는 오탐과 민감한 정보를 놓치는 미탐을 함께 점검해야 한다는 점이 중요하다.

2-2. Fail-Closed와 보안 테스트

보안 검사를 수행하는 구성 요소가 실패했을 때 어떻게 처리할지도 중요한 설계 요소다.

• Fail-Open: 검사에 실패하더라도 요청을 통과시킨다.

• Fail-Closed: 검사에 실패하면 요청을 차단한다.

보안이 중요한 워크플로우에서는 판별 모델이 공격 여부를 확실하게 판단하지 못하거나 검사 자체에 실패했을 때, 요청을 통과시키지 않는 Fail-Closed 방식을 고려할 수 있다.

또한 정상 요청과 공격 요청을 테스트 케이스로 만들어 반복 실행하고, 실패한 사례를 바탕으로 규칙과 코드를 개선해야 한다. 강의에서는 이러한 보안 테스트를 단계적으로 확장하고, 최종 출력 필터와 감사 로그를 추가하는 흐름을 살펴봤다.

2-3. 바이브 코딩으로 만드는 개발자용 보안 검사 도구

오늘 실습 주제로 제시된 도구는 T-Scan이라는 이름의 로컬 보안 검사 도구였다.

개발자가 Git 저장소에 코드를 커밋하기 전에 API 키나 개인정보가 포함되어 있는지 검사하는 것이 목적이다.

주요 요구사항은 다음과 같다.

• 지정한 폴더와 하위 폴더를 재귀적으로 검사한다.

• .env 파일의 API 키나 비밀번호뿐 아니라 다른 파일에 복사된 동일한 값도 탐지한다.

• 주민등록번호, 전화번호, 이메일 등 개인정보 패턴을 검사한다.

• 탐지된 파일명과 줄 번호를 표시한다.

• 민감한 값 전체를 출력하지 않고 일부 문자만 남겨 마스킹한다.

• 날짜나 주문번호처럼 비슷하게 보이는 일반적인 숫자를 과도하게 탐지하지 않는다.

• 테스트용 가짜 키나 예외 처리 대상을 구분할 수 있도록 한다.

• Git 커밋 전에 검사를 실행하고, 위험한 항목이 발견되면 커밋을 중단하는 방식으로 확장할 수 있다.

기존 명령어인 grep이나 ripgrep(rg)로도 문자열을 검색할 수 있지만, 이번 과제는 이를 넘어 민감 정보 유형을 구분하고, 결과를 안전하게 표시하며, 개발 과정에 연결할 수 있는 작은 도구를 직접 설계하는 데 초점이 있었다.

강의에서 강조한 점은 도구를 만드는 것뿐 아니라 요구사항을 구체적으로 정의하는 과정도 중요하다는 것이다. 무엇을 찾을지, 어떤 결과를 보여줄지, 어떤 오탐을 줄여야 할지 명확하게 정리해야 AI 코딩 에이전트가 원하는 결과에 가까운 도구를 만들 수 있다.

2-4. 바이브 코딩은 구현 이후가 더 중요하다

강의에서는 헬스장에서 복근 사진을 촬영하면 AI가 점수를 매기고 맞춤 운동 계획을 제공하는 앱 사례를 소개했다.

이 사례에서 주목할 점은 단순히 AI로 앱을 만들었다는 사실이 아니다. 아이디어를 발견하고, 초기 구현을 시도하고, 방향을 수정한 다음 실제 고객에게 도달할 방법을 찾았다는 점이다.

제품을 만들 때 고려해야 할 흐름은 다음과 같다.

1. 문제 발견: 사람들이 실제로 불편해하거나 필요로 하는 것이 무엇인지 찾는다.

2. 수요 검증: 본격적으로 개발하기 전에 잠재 고객의 반응을 확인한다.

3. 제품 구현: AI 코딩 도구를 활용해 필요한 기능을 빠르게 만든다.

4. 배포와 운영: 앱을 배포하고 사용자 관리, 데이터 저장, 결제 등의 환경을 구성한다.

5. 고객 확보와 수익화: 목표 고객이 있는 채널을 찾고 적절한 가격 및 구독 모델을 설계한다.

강사는 앱 개발에 활용할 수 있는 데이터베이스·백엔드 서비스, 구독 결제, 분석 도구 등의 사례도 언급했다. 바이브 코딩으로 구현 비용이 낮아진 만큼, 처음 만든 결과물에 집착하기보다는 사용자 반응을 확인하고 필요하다면 방향을 수정하는 태도가 중요하다.

조회수나 다운로드 수만 보는 것이 아니라, 실제로 고객이 비용을 지불할 만큼 필요로 하는 제품인지 확인해야 한다는 점도 핵심이다.

2-5. 프론트엔드와 백엔드가 분리된 이유

후반부에는 웹 애플리케이션의 구조와 기술 발전 과정을 설명했다.

초기의 서버 중심 웹 애플리케이션에서는 화면을 표시하는 코드와 업무 규칙, 데이터베이스 접근 코드가 한 파일에 섞여 있는 경우가 많았다. 이런 구조는 기능이 늘어날수록 수정과 유지보수가 어려워지고, 여러 개발자가 같은 파일을 수정할 때 충돌이 발생하기 쉬웠다.

이러한 문제를 줄이기 위해 역할을 분리하는 구조가 발전했다.

• 프론트엔드: 사용자가 보는 화면과 사용자 입력을 담당한다.

• 백엔드: 업무 규칙을 처리하고 요청에 응답하며, 데이터와 외부 시스템을 다룬다.

• 데이터 저장소: 데이터베이스 등을 통해 필요한 정보를 저장하고 조회한다.

• API: 프론트엔드와 백엔드 등 서로 다른 구성 요소가 정해진 방식으로 데이터를 주고받도록 한다.

강의에서는 PHP 등 서버 사이드 스크립트의 역사, REST API의 등장, Node.js를 통한 서버 측 JavaScript 활용, SPA(Single Page Application)의 특징 등을 연결해 설명했다.

특히 바이브 코딩이 발전하더라도 소프트웨어의 구조를 이해하는 일이 사라지는 것은 아니다. AI가 코드를 만들어 주더라도 화면, 업무 로직, 데이터 저장소가 어떤 역할을 하는지 알아야 결과물을 검토하고 수정할 수 있다.

3. 오늘의 실습과 시연

T-Scan 보안 검사 도구

강의에서는 요구사항을 바탕으로 보안 검사 도구를 만드는 과정을 살펴봤다. 전사문에는 한 수강생이 Codex를 활용해 요구사항과 구현 명세를 먼저 정리하고, 설치형 프로그램 대신 터미널에서 실행할 수 있는 TUI(Text User Interface) 형태로 방향을 수정했다고 설명하는 부분이 있다.

또한 검사 결과에서 민감한 값을 마스킹해 표시하는 방식과 폴더를 지정해 검사하는 흐름을 시연했다. 결과를 한꺼번에 출력하는 대신 스트리밍 방식으로 중간 결과를 보여주는 개선 방향도 언급됐다.

다만 이 내용은 전사문상 강의 중 공유된 구현 사례이며, 내가 직접 동일한 도구를 구현하거나 테스트를 완료했다고 볼 근거는 없다.

사다리 타기 프로그램

시간이 남는 수강생을 위한 바이브 코딩 과제로 사다리 타기 프로그램도 제안됐다.

• 참가자 수 입력

• 참가자 이름 또는 번호 설정

• 결과 항목 입력

• 사다리 가로줄 생성

• 시작 버튼을 눌러 이동 경로와 결과 확인

터미널에서 동작하는 TUI 방식과 Python 기반 UI, 웹 페이지 방식 등 여러 구현 방법이 언급됐다. 강의 후반에는 실제로 만든 사다리 프로그램의 화면과 동작을 공유하며, 같은 요구사항이라도 도구와 구현 방식에 따라 결과물이 달라질 수 있음을 보여줬다.

4. 프로젝트와 협업에 관해 생각해 볼 점

오늘 강의에서는 단위 프로젝트와 최종 프로젝트를 앞두고, 팀 안에서 자신의 역할을 찾는 태도도 강조됐다.

팀 프로젝트에서는 일부 인원만 구현을 맡고 나머지는 참여하지 않는 상황을 피해야 한다. 작은 기능이라도 역할을 나누고, 각자가 맡은 부분을 구현하거나 검증하는 경험을 쌓는 것이 중요하다.

또한 업무를 지시받을 때까지 기다리기보다 프로젝트에 필요한 일을 스스로 찾아 제안하는 태도가 필요하다는 이야기도 있었다.

이는 바이브 코딩을 활용할 때도 마찬가지다. AI에게 코드를 생성해 달라고 요청하는 것에서 끝나지 않고, 무엇을 만들지 정의하고 결과를 확인하며 다음 개선점을 찾아야 한다.

5. 새롭게 연결해 볼 내용

오늘 수업에서 다룬 내용은 서로 다른 주제처럼 보이지만 하나의 흐름으로 연결된다.

• 보안: AI가 생성한 결과에 민감한 정보가 포함되지 않도록 검증한다.

• 개발 도구: 반복적인 검사 작업을 자동화하는 도구를 직접 설계한다.

• 제품 기획: 사용자의 문제를 발견하고 실제로 필요한 기능을 만든다.

• 아키텍처: 구현된 기능이 프론트엔드, 백엔드, 데이터 저장소에서 어떤 역할을 하는지 이해한다.

• 협업: 팀에서 필요한 일을 찾고 작은 단위로 나누어 함께 완성한다.

결국 AI가 코드 작성의 많은 부분을 도와주더라도, 무엇을 만들고 어떤 기준으로 검증하며 어떻게 사용자에게 전달할지는 개발자가 판단해야 한다.

6. 복습할 부분

• Fail-Open과 Fail-Closed가 실제 워크플로우에서 어떻게 다르게 동작하는지 설명하기

• 개인정보 마스킹과 민감 정보 탐지에서 오탐·미탐이 발생하는 이유 정리하기

• T-Scan의 요구사항을 기능 단위로 나누고, 커밋 전 검사 흐름을 설계해 보기

• 제품의 수요 검증과 구현, 배포, 고객 확보가 어떻게 연결되는지 정리하기

• 프론트엔드, 백엔드, API, 데이터 저장소의 역할을 구분하고 설명하기

• Node.js와 SPA가 기존 웹 애플리케이션 구조에서 어떤 변화를 가져왔는지 복습하기

7. 오늘의 회고

오늘은 AI를 활용해 기능을 만드는 방법뿐 아니라, 만든 결과물을 어떻게 검증하고 실제로 활용할 것인지까지 생각해 볼 수 있는 시간이었다.

보안 워크플로우에서는 답변을 생성하는 것만으로 충분하지 않으며, 최종 결과에 민감한 정보가 남아 있는지 확인하고 실패 상황까지 고려해야 한다. 개발 도구를 만드는 과제에서도 단순히 문자열을 검색하는 기능보다 정확한 탐지, 안전한 출력, 오탐 감소 등 실제 사용 환경에서 필요한 조건을 구체적으로 정의하는 일이 중요했다.

바이브 코딩으로 제품을 만드는 사례에서는 구현 자체가 최종 목표가 아니라는 점도 인상적인 주제였다. 제품을 완성하더라도 실제 사용자가 필요로 하지 않거나 적절한 고객에게 도달하지 못하면 의미 있는 결과로 이어지기 어렵다.

또한 웹 아키텍처의 역사를 살펴보면서 AI가 코드를 작성하는 시대에도 기존 기술의 구조와 역할을 이해하는 것이 중요하다는 점을 확인했다. 코드가 생성되는 속도가 빨라질수록 결과물을 판단하고 검증하는 기준이 필요하기 때문이다.

앞으로 단위 프로젝트와 최종 프로젝트를 진행할 때는 단순히 주어진 기능을 구현하는 데 그치지 않고, 내가 맡을 수 있는 역할을 먼저 찾고 요구사항을 구체화하는 것부터 시작해 보고 싶다. 다만 이번 수업에서 소개된 도구와 사례를 실제로 어느 수준까지 구현하고 검증했는지는 별도로 확인하면서 학습 내용을 정리할 필요가 있다.

#AI오케스트레이션 #바이브코딩 #LLM보안 #프롬프트인젝션 #개인정보마스킹 #TUI #개발자동화 #프론트엔드 #백엔드 #국비지원개발자

10월 3주차에는 AI 에이전트 워크플로우의 설계와 검증부터 바이브 코딩을 활용한 애플리케이션 개발, RAG 검색 품질 개선까지 학습 범위를 확장했다. 67일차부터 71일차까지의 일일 회고를 바탕으로, 이번 주에 다룬 기술을 나열하는 데 그치지 않고 각 개념이 어떻게 연결되는지 정리했다.

1. 이번 주 학습 요약

이번 주 학습을 관통하는 주제는 AI가 코드를 만들고 작업을 수행하도록 하는 것에서 나아가, 그 결과를 검증하고 안정적으로 운영할 수 있는 구조를 설계하는 것이었다.

초반에는 Docker Compose와 n8n을 활용해 서비스 실행 환경과 AI 에이전트 워크플로우를 살펴봤다. 이어서 요구사항을 개발 명세로 구체화하고, CLI 기반 코딩 에이전트를 활용해 구현 계획을 세우는 방법을 학습했다.

이후에는 멀티 에이전트의 역할 분리, 오류 발생 시 처리 방식, 공통 로직의 모듈화와 회귀 테스트 등 실제 운영을 고려한 설계로 주제를 넓혔다. 후반부에는 RAG 검색 품질을 평가하고 개선하는 방법, 로컬 문서 검색 도구의 구조, Python 기반 애플리케이션과 프론트엔드·백엔드 분리까지 살펴봤다.

이번 주의 흐름을 정리하면 다음과 같다.

• 실행 환경: Docker Compose로 서비스와 컨테이너 관리하기

• 워크플로우 설계: n8n으로 작업 흐름과 조건별 분기 구성하기

• AI 기반 개발: 요구사항·명세·구현 계획을 바탕으로 코딩 에이전트 활용하기

• 안정성 확보: 예외 처리, 역할 분리, 테스트와 실행 기록으로 검증하기

• 검색 품질 개선: RAG의 검색 결과와 근거를 평가하고 개선하기

• 애플리케이션 구조화: 공통 기능 재사용과 프론트엔드·백엔드 분리 고려하기

2. AI 에이전트는 만드는 것보다 제대로 동작하게 하는 것이 중요하다

이번 주에는 n8n 기반의 IT 지원 에이전트와 업무 자동화 워크플로우를 중심으로, AI 에이전트가 어떤 과정을 거쳐 결과를 만드는지 살펴봤다.

IT 지원 에이전트에서는 FAQ 검색과 티켓 조회를 구분하고, 사용자의 요청에 따라 적절한 도구를 선택하는 구조를 다뤘다. 회의록을 활용하는 워크플로우에서는 필수 자료가 누락된 경우를 처리하고, 여러 에이전트가 협력하는 구조에서는 각 역할의 책임과 결과 검토 과정을 구분하는 것이 중요했다.

특히 Writer와 Reviewer처럼 작성과 검토를 분리하면 결과를 한 번 생성하는 것으로 끝내지 않고, 검토 결과에 따라 수정하거나 재시도할 수 있다. 다만 재시도가 무한히 반복되지 않도록 횟수를 제한하고, 해결되지 않는 문제는 담당자가 확인하도록 설계해야 한다.

이때 중요하게 연결되는 개념이 Fail Open과 Fail Closed다.

• Fail Open: 일부 작업에 실패해도 가능한 결과를 활용하거나 나머지 처리를 계속하는 방식이다.

• Fail Closed: 필수 검증이나 보안 절차에 실패하면 처리를 중단하는 방식이다.

두 방식 중 어느 하나가 항상 정답인 것은 아니다. 실패한 작업의 결과를 계속 활용해도 되는지, 검증되지 않은 결과가 외부로 전달되면 위험한지를 기준으로 선택해야 한다.

또한 최종 결과만 확인해서는 내부 처리 과정에서 발생한 문제를 찾기 어렵다. 단계별 실행 기록과 각 에이전트의 입출력을 확인하면 어떤 단계에서 실패했는지, 재시도가 발생했는지, 오류가 적절하게 처리됐는지 파악할 수 있다.

결국 AI 에이전트의 완성도는 답변을 생성하는 능력뿐 아니라 실패를 감지하고, 잘못된 결과를 차단하며, 문제가 발생했을 때 적절한 경로로 처리하는 능력에도 달려 있다.

3. 바이브 코딩의 핵심은 요구사항과 검증 기준을 명확하게 만드는 것

이번 주에는 Codex, Claude Code, Gemini 등의 CLI 기반 코딩 에이전트를 활용하는 개발 방식도 다뤘다.

AI에게 자연어로 요청하면 코드를 생성할 수 있지만, 요청이 모호하면 결과 역시 기대와 달라질 수 있다. 따라서 원하는 기능을 구체적인 요구사항으로 정리하고, 구현 범위와 제약 조건을 명시하는 과정이 중요하다.

예를 들어 워크플로우의 구조를 시각화하는 프로그램을 만든다면 단순히 '워크플로우를 보기 쉽게 만들어 달라'고 요청하는 것만으로는 부족하다.

노드의 역할과 연결 관계를 표시할 것인지, 특정 노드를 선택했을 때 설정을 보여줄 것인지, 연결 오류를 감지할 것인지, 외부 API 없이도 동작해야 하는지 등을 구체화해야 한다. 이렇게 요구사항을 나누면 구현할 기능뿐 아니라 결과를 평가할 기준도 명확해진다.

이번 주에 다룬 개발 문서와 작업 흐름은 다음과 같이 정리할 수 있다.

1. SPEC.md에 필요한 기능과 제약 조건을 정리한다.

2. IMPLEMENTATION_PLAN.md에 구현 단계를 나눈다.

3. AGENTS.md에 프로젝트 공통 개발 규칙을 작성한다.

4. 계획에 따라 기능을 구현한다.

5. 테스트와 실행 결과를 확인하고 필요한 부분을 수정한다.

이 문서들은 각각 목적이 다르다. 스펙은 무엇을 만들어야 하는지 정의하고, 구현 계획은 어떤 순서로 작업할지 정리하며, 공통 규칙은 코딩 에이전트가 프로젝트 전반에서 지켜야 할 기준을 전달한다.

모든 작업에 반드시 같은 문서를 적용해야 하는 것은 아니지만, 프로젝트가 복잡해질수록 명세와 작업 계획을 먼저 정리하는 편이 변경 사항을 관리하기 쉽다.

여러 코딩 에이전트의 결과를 비교하는 과정에서도 같은 원칙이 적용된다. 도구마다 생성하는 코드와 파일 구조, 설명의 깊이, 테스트 범위가 다를 수 있기 때문에 특정 도구의 결과를 그대로 정답으로 받아들이기보다 실제 요구사항을 충족하는지 확인해야 한다.

이번 주 학습을 통해 바이브 코딩은 단순히 AI에게 코드를 작성하게 하는 방법이 아니라, 요구사항을 구체화하고 AI의 작업을 관리하며 결과를 검증하는 개발 방식으로 이해할 수 있었다.

4. 공통 로직의 모듈화와 회귀 테스트

워크플로우가 복잡해지고 기능이 늘어날수록 모든 기능을 개별적으로 구현하고 관리하는 방식에는 한계가 생긴다. 이번 주에는 공통 로직을 분리해 재사용하고, 변경으로 인해 기존 기능이 영향을 받지 않는지 확인하는 방법을 다뤘다.

예를 들어 유지보수 공지, 보안 공지, 교육 공지는 목적과 필수 문구가 다르지만 글자 수 확인이나 필수 조건 검증 같은 공통 작업을 수행한다.

이때 공통 검증 로직은 별도의 모듈이나 서브워크플로우로 분리하고, 공지 유형에 따른 차이는 설정으로 관리할 수 있다. 이렇게 하면 새로운 공지 유형이 추가되더라도 기존 코드를 반복해서 작성할 필요가 줄어든다.

모듈을 분리할 때는 입력과 출력의 규칙도 중요하다.

• 입력 계약: 모듈이 어떤 데이터를 받아야 하는가?

• 처리 로직: 전달받은 데이터를 어떤 기준으로 처리하는가?

• 출력 계약: 어떤 형식으로 결과를 반환하는가?

공통 모듈을 수정할 때는 이 모듈을 사용하는 다른 기능에도 영향이 생길 수 있다. 예를 들어 기존에는 true 또는 false를 반환하던 기능이 새로운 버전에서 allow, warning, block을 반환하도록 변경되면 기존 호출 코드가 예상대로 동작하지 않을 수 있다.

이런 문제를 방지하려면 변경된 기능뿐 아니라 기존 기능도 다시 테스트해야 한다. 이것이 **회귀 테스트(Regression Test)**의 핵심이다.

회귀 테스트는 새로운 기능을 추가하거나 기존 코드를 수정한 뒤, 이전에 정상적으로 동작하던 기능이 여전히 올바르게 작동하는지 확인하는 테스트다.

이 개념은 RAG 검색 품질을 개선할 때도 연결된다. 검색 설정을 변경해 특정 질문의 결과가 좋아졌더라도, 다른 질문의 검색 품질이 나빠지지는 않았는지 함께 확인해야 한다.

즉, 모듈화는 코드 중복을 줄이는 방법이고 회귀 테스트는 변경으로 인한 부작용을 확인하는 방법이다. 두 가지를 함께 적용해야 기능을 확장하면서도 기존 동작을 안정적으로 유지할 수 있다.

5. RAG 검색 품질과 근거 검증

이번 주 후반부에는 RAG(Retrieval-Augmented Generation, 검색 증강 생성)의 검색 품질을 평가하고 개선하는 방법을 살펴봤다.

RAG는 관련 문서를 검색한 뒤 검색 결과를 바탕으로 LLM이 답변을 생성하는 구조다. 하지만 RAG를 구현했다고 해서 질문에 필요한 정보가 항상 검색되거나 답변이 정확해지는 것은 아니다.

검색 결과가 여러 개 반환되더라도 실제 답변에 필요한 근거가 포함되어 있는지는 별도로 확인해야 한다.

이번 주에 다룬 주요 개선 방향은 다음과 같다.

• 검색 결과 평가: 질문에 필요한 문서가 상위 검색 결과에 포함되는지 확인한다.

• 청킹 방식 비교: 일정한 길이로 문서를 나누는 방식과 Markdown의 제목·섹션 구조를 활용하는 방식을 비교한다.

• 쿼리 재작성: 사용자의 일상적인 표현을 규정이나 문서에서 사용하는 용어에 맞게 바꿔 검색을 개선한다.

• 회귀 테스트: 검색 설정을 바꾼 뒤 기존 질문에서도 품질이 유지되는지 확인한다.

• 출처 확인: 답변에 사용된 문서와 관련 구간을 확인할 수 있도록 구성한다.

특히 청킹은 문서를 검색하기 적절한 단위로 나누는 과정이다. 문서를 지나치게 크게 나누면 검색 결과에 불필요한 내용이 포함될 수 있고, 지나치게 작게 나누면 문맥이 끊길 수 있다. 문서의 구조와 실제 질문의 유형을 고려해 적절한 단위를 선택해야 한다.

또한 검색 결과의 순위만으로 답변의 정확성을 보장할 수는 없다. 유사도가 높은 문서가 반환되더라도 질문에 필요한 내용이 실제로 존재하지 않을 수 있기 때문이다.

이 점은 앞서 배운 워크플로우의 실패 처리와도 연결된다. 근거가 부족한 상황에서 AI가 임의로 답변을 생성하거나, 검증되지 않은 결과를 정상적인 응답으로 처리하면 안 된다. 답변할 근거가 없다면 그 사실을 명확히 안내하거나 담당자에게 연결하는 경로가 필요하다.

6. 로컬 문서 검색과 애플리케이션 구조 설계

RAG 학습은 n8n 워크플로우에만 머무르지 않고 로컬 문서 검색 도구를 설계하는 방향으로 확장됐다.

지정된 폴더의 Markdown 문서를 검색하는 프로그램을 만든다고 가정하면, 단순히 문서를 읽고 검색 결과를 출력하는 기능 외에도 고려할 부분이 많다.

문서가 추가되거나 수정될 때마다 모든 파일을 다시 처리하면 비효율적일 수 있다. 따라서 변경된 파일만 다시 색인하고, 삭제된 문서의 기존 색인도 정리할 수 있도록 설계하는 것이 중요하다.

검색 결과를 보여줄 때도 단순히 관련 문장만 출력하기보다는 파일명, 관련 구간, 유사도 등을 함께 제공하면 사용자가 결과를 검토하기 쉽다. 필요할 때 원문 전체를 확인할 수 있다면 검색 결과의 신뢰성을 판단하는 데도 도움이 된다.

마지막 교시에서는 Python 기반 애플리케이션 개발과 프론트엔드·백엔드 분리, 프로젝트 공통 규칙을 관리하는 방법도 다뤘다.

여기서 중요한 것은 사용자에게 보여주는 화면과 실제 데이터를 처리하는 로직을 구분하는 설계다. 화면 구성과 데이터 처리의 책임을 분리하면 각각의 기능을 수정하거나 확장하기 쉬워질 수 있다.

또한 기존에 작성된 코드를 참고해 새로운 프로그램을 만들 때는 기존 코드와 공통 규칙, 구현 명세를 함께 제공하는 편이 좋다. 코딩 에이전트가 기존 기능을 재사용할 수 있는지 판단하고, 프로젝트의 일관성을 유지하는 데 도움이 되기 때문이다.

다만 이번 주 일일 회고에서 확인되는 내용은 이러한 구조와 개발 흐름을 학습하고 살펴본 것이다. 모든 기능을 직접 구현하고 완성했다는 의미로 확대해서 해석하지는 않는다.

7. 이번 주에 새롭게 연결된 개념

이번 주 학습에서 의미 있었던 부분은 개별적으로 배웠던 기술들이 하나의 개발 과정으로 연결된다는 점이다.

이 흐름은 모든 프로젝트가 반드시 동일한 순서로 진행된다는 뜻은 아니다. 다만 이번 주에 배운 개념을 하나로 연결해 보면, AI 기반 개발에서도 요구사항 정의부터 구현, 검증, 예외 처리까지 일반적인 소프트웨어 개발의 기본 원칙이 중요하다는 점을 확인할 수 있다.

8. 어려웠던 점과 앞으로 보완할 부분

이번 주에 다룬 내용은 개별 기술을 사용하는 방법뿐 아니라 여러 구성 요소가 함께 동작하는 시스템을 어떻게 설계하고 검증할 것인지에 관한 것이었다.

워크플로우의 노드가 많아질수록 각 노드의 역할과 데이터 전달 관계를 파악해야 한다. 공통 모듈을 수정할 때는 다른 기능에 미치는 영향을 확인해야 하고, RAG에서는 검색 결과와 실제 답변의 근거가 일치하는지도 살펴봐야 한다.

이런 문제는 단순히 코드를 생성하거나 한 번 실행하는 것만으로 해결하기 어렵다.

앞으로 보완할 부분은 다음과 같다.

• 요구사항을 작은 기능 단위로 나누고 테스트 가능한 기준으로 작성하기

• 워크플로우의 실행 기록과 입출력을 따라가며 오류가 발생한 위치 파악하기

• 공통 로직을 변경할 때 입력·출력 계약과 기존 호출자 확인하기

• 정상 사례뿐 아니라 자료 누락, 잘못된 입력, 검증 실패 사례도 테스트하기

• RAG의 검색 결과와 답변 근거를 별도로 평가하기

• AI가 생성한 코드의 변경 사항과 실제 실행 결과를 직접 확인하기

위 항목은 이번 주에 다룬 내용을 바탕으로 정리한 복습 및 개선 과제다. 실제로 모든 항목을 수행해 해결했다는 의미는 아니다.

9. 다음 주 계획

다음 주에는 이번 주에 학습한 내용을 실제 구현과 검증 관점에서 더 확실하게 연결하는 데 집중하고 싶다.

첫째, 코딩 에이전트에 작업을 맡기기 전에 요구사항과 완료 조건을 명확하게 정리하는 습관을 갖추고 싶다. 구현 결과가 나왔다는 사실보다 처음 정의한 조건을 충족했는지 확인하는 것이 중요하기 때문이다.

둘째, 워크플로우와 RAG를 구성할 때 정상 동작뿐 아니라 실패했을 때의 처리 경로도 함께 살펴보고 싶다. 특히 근거가 없는 답변이나 검증되지 않은 결과가 정상적인 결과로 처리되지 않도록 확인하는 기준이 필요하다.

셋째, 기능을 수정할 때 기존 기능까지 함께 검증하는 습관을 기르고 싶다. 새로운 기능이 추가될수록 회귀 테스트와 공통 모듈의 관리가 중요해지기 때문이다.

마지막으로 AI가 생성한 코드를 단순히 받아들이는 데서 끝내지 않고, 코드의 구조와 실행 흐름을 직접 설명할 수 있는 수준까지 이해하는 것을 목표로 삼고 싶다.

10. 이번 주 회고

이번 주에는 Docker Compose와 n8n을 통한 실행 환경 및 워크플로우 구성부터 바이브 코딩, 멀티 에이전트 설계, 모듈화와 회귀 테스트, RAG 검색 품질 개선까지 폭넓게 다뤘다.

각 기술은 서로 다른 문제를 해결하지만 공통적으로 요구사항을 명확하게 정의하고, 작업을 적절히 나누며, 결과를 검증해야 한다는 원칙으로 연결된다.

AI 코딩 에이전트가 코드를 빠르게 생성할 수 있다는 사실만으로 프로그램의 완성도가 보장되는 것은 아니다. 요구사항이 잘못 전달되거나, 기존 기능과의 호환성이 깨지거나, 검색 근거가 부족한데도 답변이 생성된다면 실제 사용 환경에서는 문제가 발생할 수 있다.

따라서 앞으로는 AI를 얼마나 많이 활용하는가보다 AI가 만든 결과를 어떤 기준으로 확인하고, 오류를 어떻게 감지하며, 안정적으로 유지할 수 있는 구조를 어떻게 설계하는가에 더 집중하고 싶다.

이번 주에 배운 개념을 단순히 기억하는 데 그치지 않고, 실제 프로젝트에서 요구사항 정의부터 구현과 테스트까지 연결해 활용할 수 있도록 복습해 나가야겠다.

1. 프로그래밍 오버뷰 강의를 시작하며

이번에는 코드잇(Codeit)의 「01_프로그래밍 오버뷰」 강의를 수강했다.

그동안 Python, FastAPI, 데이터베이스, API 등을 학습하면서 실제 서비스를 개발하는 경험을 쌓았지만, 이번 강의에서는 개별 기술보다 프로그래밍이라는 분야의 전체적인 구조를 다시 살펴볼 수 있었다.

코딩이 무엇인지부터 웹과 모바일 앱이 동작하는 원리, 개발자의 다양한 직무, 프로그래밍 언어 선택 방법, 좋은 코드를 작성하기 위해 필요한 역량까지 폭넓게 다루는 입문 과정이었다.

이미 접해 본 개념도 있었지만, 각각의 기술이 어떤 역할을 하고 서로 어떻게 연결되는지 정리하는 데 초점을 맞췄다.

2. 코딩이란 무엇인가?

코딩의 기본 개념

코딩(Coding)은 컴퓨터가 특정 작업을 수행할 수 있도록 프로그래밍 언어로 명령을 작성하는 과정이다.

컴퓨터는 사람이 일상적으로 사용하는 언어를 그대로 이해하지 못하기 때문에 Python, JavaScript, Java 등의 프로그래밍 언어를 사용한다.

강의에서는 Python의 max() 함수를 예시로 소개했다.

max(27, 45, 36)

이 코드는 세 숫자 중 가장 큰 숫자인 45를 반환한다.

간단한 예제지만, 프로그래밍의 기본적인 흐름을 보여준다.

사람이 명령을 작성하면 컴퓨터가 이를 처리하고 결과를 반환하는 것이다.

코딩을 배우는 이유

코딩은 개발자가 되기 위해서만 배우는 기술이 아니다.

강의에서는 코딩을 활용하는 방향을 크게 세 가지로 설명했다.

1. 기술의 흐름과 프로그래밍의 기본 원리를 이해하기
2. 일상생활이나 업무에서 필요한 프로그램을 직접 만들기
3. 전문적인 소프트웨어 개발자로 진출하기

특히 반복적인 업무를 자동화하거나 자신의 아이디어를 실제 서비스로 구현할 수 있다는 점이 인상적인 활용 사례였다.

3. 프로그램을 구성하는 기본 문법

프로그래밍에서는 복잡한 기능도 여러 기본 개념을 조합해 구현한다.

이번 강의에서는 변수, 함수, 조건문, 반복문을 핵심 요소로 소개했다.

변수와 함수

변수(Variable)는 프로그램에서 데이터를 저장하거나 참조하기 위해 사용하는 이름이다.

함수(Function)는 특정 작업을 수행하는 코드를 묶어 재사용할 수 있도록 만든 것이다.

예를 들어 Python에서는 다음과 같이 사용할 수 있다.

price = 20000

def discount(price):
    return price * 0.9

print(discount(price))

변수에 상품 가격을 저장하고, 함수를 이용해 할인된 가격을 계산하는 예제다.

조건문과 반복문

조건문은 조건에 따라 실행할 코드를 결정하고, 반복문은 같은 작업을 여러 번 실행할 때 사용한다.

for i in range(3):
    print("HELLO WORLD")

위 코드는 HELLO WORLD를 세 번 출력한다.

country = "한국"

if country == "한국":
    print("안녕하세요")
else:
    print("HELLO")

이 코드는 조건에 따라 서로 다른 인사말을 출력한다.

실제 서비스에서는 이러한 기본 문법을 조합해 로그인, 회원가입, 상품 조회, 결제 등의 기능을 구현한다.

위 Python 코드는 강의 개념을 복습하기 위해 재구성한 예제다.

4. 웹 서비스는 어떻게 동작할까?

이번 강의에서 중요한 부분 중 하나는 클라이언트, 서버, 데이터베이스의 관계였다.

클라이언트와 서버

웹 서비스는 기본적으로 클라이언트가 서버에 요청을 보내고, 서버가 이를 처리한 뒤 결과를 응답하는 방식으로 동작한다.

• 클라이언트(Client): 사용자가 직접 이용하는 웹 브라우저나 앱
• 서버(Server): 사용자의 요청을 받아 처리하는 시스템
• 데이터베이스(Database): 서비스에 필요한 데이터를 저장하고 관리하는 시스템

예를 들어 사용자가 쇼핑몰에서 상품 목록을 조회한다면 다음과 같은 과정이 진행된다.

1. 사용자가 상품 조회 버튼을 클릭한다.
2. 클라이언트가 서버에 상품 목록을 요청한다.
3. 서버가 데이터베이스에서 상품 정보를 조회한다.
4. 서버가 조회 결과를 클라이언트에 전달한다.
5. 클라이언트가 상품 목록을 화면에 표시한다.

이러한 구조는 대부분의 웹 서비스에서 공통적으로 활용된다.

프론트엔드와 백엔드

웹 개발은 크게 프론트엔드와 백엔드로 나뉜다.

구분프론트엔드백엔드

프론트엔드는 사용자가 보는 화면을 구현하고, 백엔드는 화면 뒤에서 필요한 데이터를 처리한다.

두 영역은 API를 통해 통신할 수 있다.

API와 DNS

API(Application Programming Interface)는 서로 다른 프로그램이 기능이나 데이터를 주고받을 수 있도록 정의한 인터페이스다.

예를 들어 상품 조회 API는 다음과 같이 표현할 수 있다.

GET /products

클라이언트가 요청을 보내면 서버는 상품 정보를 JSON 형식으로 반환할 수 있다.

DNS(Domain Name System)는 youtube.com처럼 사람이 기억하기 쉬운 도메인 이름을 서버 접속에 필요한 IP 주소로 변환하는 역할을 한다.

즉, 웹사이트에 접속하는 과정에는 화면을 보여주는 기술뿐 아니라 네트워크 통신과 서버 처리 과정도 포함되어 있다.

5. 웹 개발과 모바일 앱 개발의 차이

웹사이트와 모바일 앱은 사용자에게 서비스를 제공한다는 점에서는 비슷하지만, 화면을 구현하는 기술에는 차이가 있다.

웹 개발에서는 주로 HTML, CSS, JavaScript를 사용한다.

반면 모바일 앱은 운영체제에 따라 다른 기술을 사용할 수 있다.

• iOS 앱: Swift
• Android 앱: Kotlin
• 크로스 플랫폼 앱: React Native, Flutter

크로스 플랫폼 개발

iOS와 Android 앱을 각각 개발하면 서로 다른 코드와 개발 환경을 관리해야 할 수 있다.

이러한 부담을 줄이기 위해 사용하는 방식이 크로스 플랫폼 개발이다.

대표적인 기술은 React Native와 Flutter다.

React Native는 JavaScript나 TypeScript를 활용하고, Flutter는 Dart 언어를 사용한다.

하나의 코드베이스를 여러 운영체제에서 활용할 수 있다는 장점이 있지만, 운영체제별 기능을 구현할 때는 추가 작업이 필요할 수 있다.

이번 내용을 통해 같은 서비스를 만들더라도 웹으로 제공할지, 모바일 앱으로 제공할지에 따라 기술 선택이 달라진다는 점을 정리할 수 있었다.

6. 데이터와 인공지능 분야의 다양한 직무

이번 강의에서는 데이터 관련 개발 직무도 자세히 소개했다.

처음에는 모두 데이터를 다루는 직업처럼 보일 수 있지만, 실제로는 담당하는 역할이 다르다.

직무주요 역할

데이터 엔지니어와 데이터 애널리스트

데이터 엔지니어는 데이터를 안정적으로 수집하고 저장할 수 있는 환경을 구축한다.

데이터 애널리스트는 이렇게 준비된 데이터를 분석해 의미 있는 정보를 찾아낸다.

예를 들어 서비스의 사용자 수가 감소했다면 데이터 애널리스트는 이용 기록을 분석해 변화가 발생한 시점과 원인을 파악하는 데 도움을 줄 수 있다.

데이터 사이언티스트와 머신러닝 엔지니어

데이터 사이언티스트는 통계와 머신러닝을 활용해 데이터를 분석하고 예측 모델을 개발할 수 있다.

머신러닝 엔지니어는 이러한 모델을 실제 서비스에서 사용할 수 있도록 구현하고 운영한다.

머신러닝 리서처는 기존 모델을 개선하거나 새로운 알고리즘을 연구하는 역할을 맡는다.

같은 AI 분야라도 데이터를 준비하는 일부터 분석, 모델 개발, 서비스 적용, 연구까지 다양한 전문 영역이 존재한다는 점을 알 수 있었다.

7. 게임, 블록체인, 임베디드, IoT 개발

소프트웨어 개발은 웹과 모바일 앱, AI 분야에만 한정되지 않는다.

이번 강의에서는 다른 개발 분야도 소개했다.

게임 개발

게임 개발에서는 Unity와 Unreal Engine 같은 게임 엔진을 사용한다.

• Unity: 주로 C# 사용
• Unreal Engine: 주로 C++과 블루프린트 사용

게임 엔진은 그래픽, 물리 처리, 애니메이션 등 게임 개발에 필요한 기능을 제공한다.

블록체인 개발

블록체인은 여러 참여자가 데이터를 공유하고 검증하는 분산원장 기술이다.

대표적인 개념은 탈중앙화(Decentralization)이며, 블록체인을 활용한 애플리케이션을 DApp이라고 한다.

스마트 계약 개발에는 Solidity 같은 프로그래밍 언어를 사용할 수 있다.

임베디드 시스템과 IoT

임베디드 시스템은 냉장고, 세탁기, 자동차처럼 특정 기기 내부에서 동작하는 컴퓨터 시스템이다.

IoT(Internet of Things)는 이러한 기기나 센서 등을 네트워크로 연결해 데이터를 주고받도록 하는 기술이다.

예를 들어 온도 센서가 측정한 데이터를 서버에 전달하고, 그 결과에 따라 에어컨을 제어하는 시스템을 생각할 수 있다.

이러한 분야에서는 C와 C++ 같은 언어가 자주 활용된다.

8. 개발 분야별 프로그래밍 언어와 학습 로드맵

이번 강의에서는 개발 분야에 따라 학습해야 하는 기술이 달라진다는 점을 강조했다.

대표적인 학습 경로를 정리하면 다음과 같다.

개발 분야주요 학습 기술

SQL과 NoSQL

백엔드 개발에서는 데이터베이스를 이해하는 것도 중요하다.

SQL 기반 관계형 데이터베이스에는 PostgreSQL과 MySQL 등이 있다.

NoSQL 데이터베이스에는 MongoDB처럼 문서 형태로 데이터를 저장하는 방식도 있다.

두 방식은 데이터 구조와 활용 목적이 다르므로 서비스의 요구사항에 따라 선택해야 한다.

기술 선택에서 중요한 것

강의에서는 모든 프로그래밍 언어를 배우려고 하기보다 자신이 원하는 개발 분야를 먼저 정하는 것이 중요하다고 설명했다.

또한 희망하는 기업의 채용 공고를 살펴보면 실제로 어떤 언어와 프레임워크를 사용하는지 파악하는 데 도움이 된다.

특히 국내 백엔드 개발에서는 Java와 Spring을 사용하는 기업이 많다는 점도 소개했다.

다만 처음 학습한 언어와 실제 취업 후 사용하는 언어가 반드시 같을 필요는 없다.

프로그래밍의 기본 원리를 이해하면 다른 언어와 기술을 배우는 데에도 도움이 되기 때문이다.

9. 개발자가 아니어도 코딩을 활용할 수 있다

이번 강의에서는 개발자 외의 직무에서도 코딩이 유용하게 사용된다는 점을 소개했다.

대표적인 사례는 업무 자동화와 데이터 분석이다.

Python을 활용한 업무 자동화

반복적으로 수행하는 업무를 Python으로 자동화할 수 있다.

예를 들어 다음과 같은 작업이다.

1. 엑셀 파일에서 데이터 가져오기
2. 필요한 정보만 추출하고 정리하기
3. 결과를 새로운 파일로 저장하기
4. 이메일로 결과 전달하기

매일 같은 작업을 반복해야 한다면 자동화를 통해 시간을 절약할 수 있다.

A/B 테스트와 데이터 분석

A/B 테스트는 서로 다른 두 가지 디자인이나 기능을 사용자에게 보여주고 결과를 비교하는 방법이다.

강의에서는 구독 버튼의 디자인을 변경했을 때 클릭 비율이 달라지는 사례를 소개했다.

이러한 실험은 사용자의 행동 데이터를 바탕으로 서비스를 개선하는 데 활용할 수 있다.

다만 실제 결과를 판단할 때는 표본 크기와 통계적 유의성도 고려해야 한다.

개발자와 비개발자의 협업

소프트웨어 서비스는 개발자 혼자 만드는 것이 아니다.

프로젝트 매니저(PM), 프로덕트 매니저, UX/UI 디자이너 등 다양한 직무가 함께 참여한다.

기획자나 디자이너도 API, 데이터베이스, 프론트엔드와 백엔드의 기본 구조를 이해하면 개발자와 더 구체적으로 소통할 수 있다.

코딩 지식은 직접 개발할 때뿐 아니라 협업 과정에서도 도움이 되는 역량이다.

10. 좋은 개발자가 되기 위해 필요한 능력

강의 마지막 부분에서는 코딩 문법을 배우는 것과 좋은 프로그램을 만드는 것은 다르다고 설명했다.

문제 해결 능력

프로그래밍에서 중요한 것은 문법을 많이 외우는 것보다 문제를 작은 단위로 나누고 해결 방법을 생각하는 능력이다.

원하는 기능이 무엇인지 정의하고, 필요한 작업을 순서대로 구성해야 한다.

라이브러리와 프레임워크 활용

실제 개발에서는 모든 기능을 처음부터 구현하지 않는다.

라이브러리는 재사용 가능한 기능을 제공하고, 프레임워크는 프로그램 개발에 필요한 구조와 규칙을 제공한다.

이러한 도구를 적절히 활용하면 개발 시간을 줄이고 복잡한 기능을 효율적으로 구현할 수 있다.

디버깅(Debugging)

디버깅은 프로그램에서 발생한 오류의 원인을 찾아 수정하는 과정이다.

기본적인 흐름은 다음과 같다.

문제 발생 → 원인 분석 → 코드 수정 → 재실행 및 결과 확인

오류 메시지를 확인하고 문제가 발생한 위치와 원인을 파악하는 능력은 실제 개발에서 중요하다.

리팩토링(Refactoring)

리팩토링은 프로그램의 외부 동작을 유지하면서 내부 코드 구조를 개선하는 작업이다.

반복된 코드를 함수로 분리하거나 복잡한 로직을 단순하게 만드는 것이 대표적인 예시다.

리팩토링을 통해 코드의 가독성과 유지보수성을 높일 수 있다.

확장성과 유지보수성

서비스가 커지고 사용자가 증가하면 기존 코드가 처리해야 하는 작업도 많아진다.

따라서 개발자는 프로그램이 현재 정상적으로 동작하는 것뿐 아니라 앞으로 수정하거나 확장하기 쉬운 구조인지도 고려해야 한다.

이번 강의에서 강조한 내용은 단순히 실행되는 코드를 작성하는 것과 좋은 코드를 작성하는 것은 다르다는 점이었다.

11. 이번 강의를 통해 정리한 내용

이번 프로그래밍 오버뷰 강의는 새로운 문법을 깊이 있게 학습하는 과정이라기보다 프로그래밍 분야 전체를 이해하는 과정이었다.

코딩의 기본 개념에서 시작해 클라이언트와 서버의 관계, 프론트엔드와 백엔드의 차이, 모바일 앱 개발, 데이터와 AI 직무, 게임과 IoT 개발까지 폭넓게 살펴봤다.

특히 이전에 학습했던 Python, FastAPI, 데이터베이스, API가 웹 서비스 구조 안에서 각각 어떤 역할을 하는지 다시 연결해 볼 수 있었다.

또한 개발자의 역할이 단순히 코드를 작성하는 데 그치지 않는다는 점도 중요했다.

요구사항을 이해하고, 문제를 해결하고, 오류를 수정하고, 다른 사람이 이해하기 쉬운 코드를 작성하는 능력까지 개발 역량에 포함된다는 것이다.

12. 앞으로 복습할 부분

이번 강의는 프로그래밍 분야를 전체적으로 소개하는 과정이었기 때문에 각 기술의 세부적인 구현 방법까지 다루지는 않았다.

앞으로는 다음 내용을 중심으로 복습하려고 한다.

• 웹 서비스 구조: 클라이언트, 서버, API, 데이터베이스의 연결 과정
• Python 기본 문법: 변수, 함수, 조건문, 반복문
• 백엔드 개발: API 설계와 데이터베이스 연동
• 데이터 및 AI: 데이터 처리부터 머신러닝 모델의 서비스 적용까지의 과정
• 코드 품질: 디버깅, 리팩토링, 유지보수성, 확장성

특히 코드를 작성할 때 단순히 실행 결과만 확인하는 것이 아니라 왜 이런 구조로 작성했는지 설명할 수 있는 수준까지 이해하는 것이 중요하다고 생각한다.

13. 오늘의 회고

이번 「프로그래밍 오버뷰」 강의를 통해 코딩의 기본 원리부터 개발 분야와 학습 방향까지 전체적인 흐름을 정리했다.

이미 접해 본 기술도 있었지만, 개별 기술을 배우는 것과 그 기술이 전체 소프트웨어 구조에서 어떤 역할을 하는지 이해하는 것은 다른 문제였다.

웹 개발과 모바일 앱 개발의 차이, 데이터 분야의 직무 구분, 개발 언어와 프레임워크의 관계 등을 한 번에 살펴보면서 앞으로 어떤 내용을 더 공부해야 할지 정리할 수 있었다.

무엇보다 기억에 남는 내용은 좋은 개발자가 되기 위해 필요한 것이 단순한 코딩 문법만은 아니라는 점이다.

AI가 코드를 작성하는 데 도움을 줄 수 있는 환경에서도 요구사항을 정확히 이해하고, 생성된 코드의 동작을 검증하고, 오류를 해결하고, 전체 구조를 판단하는 능력은 중요하다.

앞으로는 새로운 기술을 무작정 많이 배우기보다 기본 원리를 이해하고, 직접 구현하고, 문제가 발생했을 때 스스로 원인을 설명할 수 있는 능력을 키우는 방향으로 학습을 이어가고 싶다.

핵심 정리

이번 강의에서 학습한 내용을 정리하면 다음과 같다.

1. 코딩은 컴퓨터에 명령을 전달해 문제를 해결하는 과정이다.
2. 실제 서비스는 클라이언트, 서버, API, 데이터베이스 등 여러 요소가 연결되어 동작한다.
3. 개발 분야에 따라 필요한 프로그래밍 언어와 기술이 달라진다.
4. 코딩은 개발뿐 아니라 업무 자동화, 데이터 분석, 협업에도 활용할 수 있다.
5. 좋은 개발자가 되기 위해서는 문제 해결, 디버깅, 리팩토링, 유지보수 능력이 중요하다.

결국 프로그래밍을 잘한다는 것은 단순히 코드를 많이 작성하는 것이 아니라, 문제를 이해하고 적절한 기술로 해결할 수 있다는 의미에 가깝다.

해시태그

#코드잇 #Codeit #프로그래밍오버뷰 #코딩공부 #개발자공부 #Python #웹개발 #백엔드개발 #AI개발자 #개발회고