큰 딸깍
- 바이브 코딩화면이나 기능을 통째로 만들어보기
- 프로토타이핑일단 만들어보고 아이디어 확인
- 아이디에이션여러 아이디어를 뽑고 방향 잡아보기
- 예를 들면“이런 서비스 하나 만들어줘.”
딸깍의 시대
코드는 AI가 짜는데, 개발자는 뭘 하지?
구현은 빨라졌는데, 이제 뭘 고민해야 할까?
큰 딸깍, 작은 딸깍
딸깍 → 확인 → 수정 요청 → 다시 딸깍
결국 어려운 건, 이게 제대로 된 건지 확인하는 것
작은 딸깍
- AI 코딩 보조내가 흐름을 잡고 부분적으로 맡기기
- 작업 단위함수, 클래스, 테스트 등
- 예를 들면“이 함수 예외 처리 좀 해줘.”
AI가 잘하는 것, 어려워하는 것
문제도 명확하고, 평가 방법도 명확하면 맡기기 좋음
이런 조건이면 잘함
- 문제가 명확할 때뭘 만들어야 하는지 정해져 있음
- 평가 방법이 명확할 때맞는지 틀린지 확인 가능
- 범위가 좁을 때작은 작업, 익숙한 패턴
어려워하는 것
- 아키텍처여러 접근 방식 중 우리한테 맞는 선택
- 비즈니스 맥락회사 사정, 사용자, 우선순위
- 운영 복잡성리소스, 장애, 배포, 다른 시스템과의 연결
AI로 코딩해도 변하지 않는 것
AI가 짰어도, 결국 우리가 이해하고 고쳐야 하는 코드
가독성
- 이름이나 흐름이 이해되는가?
- 내가 이 코드를 설명할 수 있는가?
유지보수(=확장성)
- 요구사항이 바뀌면 고칠 수 있는가?
- 수정하면 어디까지 영향이 가는가?
문제 해결
- 원래 해결하려던 문제가 맞는가?
- 돌아가는 것 말고, 실제로 도움이 되는가?
이제 더 넓게 고민해야 함
구현이 빨라진 만큼, 그다음 고민을 더 일찍 해야 함
기능 구현 → 유지보수·확장성 → 시스템·비즈니스
기능 구현 (주니어)
- 요구사항대로 동작하게 만들기
- “이거 어떻게 구현하지?”
시스템 구조 (미들)
- 유지보수, 확장성, 운영까지 고민
- “이 구조로 계속 가도 되나?”
비즈니스 (고급·시니어)
- 필요한 기능인지, 우선순위는 뭔지
- “이걸 만들어서 뭐가 좋아지지?”
예를 들면, 알림 기능
구현에 아낀 시간을 이런 고민에 쓰면 좋겠음
“알림 기능 만들어줘.”
AI로 하는 부분
- API알림 조회, 읽음 처리
- DB스키마, 저장·조회 쿼리
- 큐메시지 넣고 처리하는 코드
- 프론트엔드알림 목록, 읽음 상태
엔지니어가 고민하는 부분
- 구조이벤트 기반? 동기 / 비동기?
- 실패 처리재시도는? 중복 알림은?
- 성능얼마나 늦어도 되나? 사용자가 늘면?
- 목적·평가왜 필요한가? 효과는 어떻게 확인?
마무리
과거에도, 현재에도, 아마 미래에도
엔지니어는 코드 자체를 작성하는 게 목표가 아님
코드를 통해 문제를 해결하는 사람
결국 더 잘해야 하는 것
- 해결책제대로 된 방법인지 판단
- 트레이드오프얻는 것과 잃는 것 비교
- 엔지니어링 판단우리 상황에 맞는 선택
- 비즈니스 성과실제로 뭐가 좋아졌는지 확인
웹개발 기초
프론트엔드부터 데이터베이스까지 전체 그림 한 번 보기
웹서비스는 뭘로 만들고, 어떻게 돌아갈까?
웹서비스란?
설치해서 쓰는 게 아니라, 주소로 접속해서 쓰는 프로그램
웹서비스
- 예를 들면네이버, 구글, 유튜브
- 브라우저로 씀
- 서버 클라이언트 구조
- 서버 클라이언트 사이는 인터넷
장점
- 접근성브라우저만 있으면 전세계 어디서든
- OS 의존성Windows, macOS, Android, ...
- 배포서버만 고치면 모두가 바로 새 버전
한계
- 네트워크인터넷 연결이 안되면...
- 의존성크롬에선 되는데 사파리에선 안 되기도
- 반응성무거운 그래픽이나 실시간 처리는 네이티브 앱이 나음
- driver 개발 같은건 불가능
프론트엔드, 백엔드, 데이터베이스
화면은 프론트, 처리는 백엔드, 기억은 DB
프론트엔드
- 브라우저 위에서 동작하는 UI/UX
- 사용자가 보고 직접 누르는 화면
- 입력 받고, 결과 보여주기
- 브라우저가 어떻게 도는지 알면 좋음HTML, CSS, JavaScript
백엔드
- 요청 받아서 실제로 일하는 쪽
- 로직, 권한, 외부 서비스 연동
- 프론트가 쓸 API를 만들어줌
데이터베이스
- 데이터를 저장하고 꺼내오는 곳
- 사용자, 게시글, 주문처럼 계속 남아야 하는 것들
- 데이터 정합성 보장
웹서비스는 어떻게 동작할까?
요청 보내고, 응답 받고
이 동작의 반복과 변주
브라우저화면 · 사용자 입력
HTTP 요청
HTTP 응답
백엔드요청 처리 · 비즈니스 로직
쿼리
데이터
데이터베이스조회 · 저장
프레임워크란?
라이브러리는 내가 부르고, 프레임워크는 내 코드를 불러줌
라이브러리
- 필요한 기능만 가져다 쓰는 도구 모음
- 흐름은 내가 정하고, 필요할 때 호출
- 날짜 계산, HTTP 통신, 데이터 변환 같은 것
프레임워크
- 제어의 역전 (IoC, Inversion of Control)흐름을 내가 아니라 프레임워크가 쥐고 있음
- 기본 구조랑 실행 흐름을 미리 깔아둠
- 정해진 자리에 코드를 넣으면 알아서 실행
- 라우팅, 설정, 생명주기를 대신 관리
- 필요한 시점에 내가 쓴 코드를 불러줌
프레임워크의 장점과 단점
장점
- 반복되는 코드를 안 짜도 됨
- 프로젝트 구조가 알아서 통일됨
- 검증된 기능을 그냥 가져다 씀
- 문서랑 사례가 많아서 검색하면 나옴
단점
- 일단 그 프레임워크 사용법부터 배워야 함 (산을 두 번 넘는 셈)
- 안이 어떻게 도는지 모르면 문제 생겼을 때 막힘
- 버전 올라가면 따라가야 함
- 작은 서비스엔 과함
영역별 주요 프레임워크
만들 서비스에 맞는지, 팀이 쓸 줄 아는지부터 보기
잘 모르면 클로드한테 “국밥 스택으로 골라줘”
프론트엔드
- 기본HTML, CSS, JavaScript, TypeScript
- UI · 앱 구성React, Vue, Angular, Next.js, Nuxt
백엔드
- JavaSpring Boot
- JavaScript·TypeScriptExpress, NestJS
- PythonDjango, FastAPI
데이터베이스
- 관계형 DBPostgreSQL, MySQL
- NoSQLMongoDB, Redis
- 데이터 연결JPA·Hibernate, Prisma, Django ORM
영역별 주요 용어
프론트엔드
- Event loop · Web API
- CSR · SSR
- 라우팅 · SPA
- 반응형
- 접근성
백엔드
- API · RESTful
- 멱등성
- 인증 · 인가
- 쿠키 · 세션 · 토큰(JWT)
- OAuth
- CORS · CSRF
- 미들웨어 · DI
- 캐시
- Async · Polling · epoll
인프라
- Docker · Docker Compose
- Nginx
- SSL · TLS
- DNS
- 배포 · CI/CD
- 로드 밸런서
각 영역을 볼 때의 마음가짐
프론트엔드사용자 경험
- 클라이언트 지향개발자가 편한 화면 말고, 사용자가 이해하는 화면
- 예쁜 것만이 아니라 접근성이랑 사용성까지
백엔드안정성과 확장성
- 요구사항은 무조건 바뀜바뀔 데를 추상화로 감싸두기
- 기능 하나가 아니라 전체 흐름이랑 터지는 경우를 보기
데이터베이스데이터 정합성
- 데이터랑 로그는 구분오래 남길 것 vs 잠깐 볼 것
- 서비스가 다 깨져도 마지막까지 남는 건 결국 데이터