바이브코딩과 웹개발구조 어떤 방식이 좋은가?
요즘 API 방식으로 만드는것이 유행? 인듯 싶어
인원이 적은 규모에선 저건 아닌데 싶어 내 생각이 틀린것인가 확인차 인공두뇌와 상의를 좀 해봤는데 자신이 맞다고 생각하는쪽으로 진행을 하는것이 맞다고 봅니다.
질문의 예를 하나 들자면 추상화 시키고 상속도 있는 상태에서 오류가 있는데 원인을 찾기 위해서 부모 찾아 헤메는 사람이 있던데 이게 맞는거냐?
내가 봤을땐 안해도 되는것을 왜? 해서 시간을 버리는지. 복잡한것이 단순한것보다 문제가능성이 높은가 낮은가
확장성의 경우 프로그램을 쓰는 이유가 확장성인데...
URL 보면 가끔 이런 형태로 보이는 경우가 있지요. 왜? /V1/, /V2/ 이렇게 버전별로 만들어 졌을까요?
확장성이란것은 초기 기획한 단계에서 생각한 범위내에서만 가능 가다고 보는것이 맞으며 사실상 확장성의 한계 입니다.
지금 윈도우11 사용하는데 예전에 윈도우7 여기서 쓰던것 기반으로 확장해서 만들었을까요?
처음부터 새로 만들었을까요?
자연두뇌이든 인공두뇌이든 복잡하고 흐림을 많이 찾아 가야 하는것은 유지 보수 측면에서 좋은 것은 아니며 만들때도 그렇다고 생각합니다.
하지만 매일매일 수정이 각자 다른 사람을 통해 이뤄지고 확인해야 하고 그렇다면 많이 쪼개져 있고 각각 파일에 대한 충돌이 일어나지 않아야 합니다.
여기서 작다는 기준이 참 애매 할 수 있다는 것입니다.
그래서 기준을 파일의 생성, 수정이 몇사람을 통해서 이뤄지냐가 사실상 더 큰 기준으로 잡아야 하는것이 맞습니다.
* 유지보수 기준
계층과 추상화가 많다는 이유만으로 유지보수가 좋다고 판단을 할 수도 있지만 프로젝트에서 유지보수가 쉽다는 의미는 다음과 같습니다.
- 파일을 찾기 쉽다
- 한 페이지 흐름을 바로 이해한다
- 수정 범위를 예측하기 쉽다
- 값이 어디서 들어와 어디로 나가는지 보인다
- 숨은 자동 동작이 적다
- 의존하는 파일 수가 적다
* 절차형 Include - 자유도가 높은 전통적인 방식
- 단순한 구조
- 적은 파일 수
- 적은 계층
- 직접 보이는 흐름
- 낮은 추적 비용
- 쉽게 수정 가능한 코드
- 적은 개발자 사이트에 특히 적합함
- 규모가 커지면 코드 중복이 생기기 쉬움
- 데이터 처리와 화면 코드가 섞일 수 있음
- 개발 규칙이 없으면 파일마다 구조가 달라질 수 있음
bootstrap include
↓
GET/POST 입력
↓
데이터 준비 또는 DB 조회
↓
header.php include
↓
페이지 HTML
↓
footer.php include
* 계층형 애플리케이션 구조(Layered Architecture) - 역할과 책임을 분리
- 코드의 역할이 명확함
- 기능별 테스트가 쉬움
- 규모가 커져도 관리하기 좋음
- DB 변경이나 비즈니스 로직 변경에 대응하기 좋음
- 계층이 많아지면 파일 수가 증가함
- 간단한 기능도 여러 파일을 거쳐야 함
- 코드 흐름을 추적하는 비용이 커질 수 있음
Controller
↓
Service
↓
Repository
↓
View
↓
Layout
* 템플릿 렌더링 구조(View/Layout Rendering Architecture) - 화면을 View와 Layout과 Partial로 조립하는 방식
- 공통 화면을 재사용하기 좋음
- header footer 메뉴 등을 한곳에서 관리 가능
- 페이지별 View가 깔끔해짐
- Partial을 이용해 반복 UI를 재사용할 수 있음
- 화면 구조를 변경하기 쉬움
- render 흐름을 알아야 전체 HTML 구조를 이해할 수 있음
- Partial이 많아지면 화면 하나를 보기 위해 여러 파일을 열어야 함
render()
↓
view
↓
layout
↓
partial
상황과 용도에 맞게 사용하는 것이 가장 중요하며 위 3가지를 간략하에 이미지로 만들면 아래와 같이 됩니다.
간단한 것이 속도도 빠르고 좋은것이며 각각 쪼개 놓은 파일을 보면 작지만 실제 처리는 모든것을 합친것이 실행되는것이기 때문에 속도는 느리고 메모리는 더 많이 차지 하게 되고 인공두뇌 활용시 토큰도 더 많이 소요 될 수 밖에 없습니다.
실무에서 속도가 느린 페이지가 있을 수 있는데 개선을 하려면 엄청난 전처리 과정이 필요해 그런데 빠르게 우선 TTFP를 개선시겨야 하는거야 그럼 어떤 구조가 좋을까?
▷ Layered Architecture Controller가 검색 Service 호출을 기다린 뒤 View를 렌더링하지 않게 하는 것입니다.
이 구조에서는 검색이 끝날 때까지 상단 메뉴조차 못 봅니다.
/search
↓
Controller
↓
SearchService
↓
Repository
↓
DB 검색 1.5초
↓
View
↓
Layout
↓
HTML 응답
* 개선된 방식은 쉽게 할 수 있는것을 참 재미 있게 하죠~
/search
↓
Controller
↓
View
↓
Layout
↓
상단 메뉴 + 검색폼 + 빈 결과영역
↓
HTML 즉시 응답
↓ 브라우저에서 별도 호출
/api/search
↓
SearchController
↓
SearchService
↓
SearchRepository
↓
DB 검색
↓
검색 결과 반환
▷ 인공두뇌 활용해도 내가 잘 알고 있어야 합니다.
한번 정한것을 계속 우기면서 맞다고 하는 인공두뇌가 있는 반면 바로 태세전환하는 인공두뇌도 있습니다.
- 아래와 같은 답변이 끝에 있길레
절차형으로 가다가 규모가 커졌을 때 함수 이름 충돌과 전역 네임스페이스 오염이 누적되는 문제는 실제로 있습니다.
접두사 규칙으로 상당 부분 막을 수 있지만 파일이 50개를 넘어가면 그때는 네임스페이스라도 도입할지 다시 판단하실 지점이 올 겁니다.
- 질문을 아래와 같이
파일 50개가 아니라 서비스 50개 아닐까?
보통의 사이트에선 일부 결제 회원관련된것 말고 독립적인경우가 많아.
맞습니다. 제가 틀렸습니다. 파일 개수를 기준으로 말한 건 잘못된 지표였습니다.
50개 파일이 서로를 모르는 50개면 아무 문제가 없습니다.
상품목록과 고객센터 FAQ는 평생 만날 일이 없어요.
각자 자기 데이터만 조회해서 자기 화면을 그리고 끝납니다.
함수 이름이 100개든 300개든 접두사만 다르면 충돌할 일도 없고 네임스페이스를 도입할 이유도 없습니다.
위험은 파일 수에 비례하지 않고 상태를 공유하는 지점의 개수에 비례합니다.
사이트가 커져도 이 지점은 거의 늘지 않아요.
5개짜리 사이트나 100개짜리 사이트나 결제 흐름은 하나 인증 흐름은 하나입니다.