나는 백엔드 설정에 45분을 보냈다… 논리 한 줄도 작성하기 전에

Source: Dev.to

지난 주에 새로운 FastAPI 서비스를 띄웠습니다.
45분이 지난 지금도 아직 비즈니스 로직 한 줄도 작성하지 않았습니다.
코딩이 어려워서가 아니라 코드 주변 환경이 모두 엉망이기 때문이죠.

• 누락된 .env 키
• 반쯤 동작하는 Docker
• 동기화되지 않은 DB 마이그레이션
• 조용히 실패하는 내부 서비스 하나

두 개 이상 백엔드를 구축해 본 사람이라면 이 상황을 겪어봤을 겁니다.

우리는 코딩 문제가 아니다

우리는 엔지니어링으로 위장한 설정 문제를 가지고 있습니다.
우리의 대부분 시간은 로직을 작성하는 데 쓰이는 것이 아니라:

• 환경을 다시 구성하기
• 보이지 않는 의존성을 고치기
• 이미 한 번 디버깅한 것을 다시 디버깅하기

“컨텍스트 격차”

Copilot 같은 도구는 코드를 더 빠르게 작성하도록 도와주지만, 백엔드 작업은 파일 수준이 아니라 워크스페이스 수준에서 이루어집니다. 도구들은 다음을 알지 못합니다:

• 우리의 아키텍처
• 실행 중인 서비스들
• 우리의 컨벤션
• 우리의 의존성

그 결과:

• 더 빠른 코드
• 여전히 깨진 시스템

다른 접근 방식을 시도해봤다

이 루프가 지겨워서 다른 아이디어를 실험해 보기 시작했습니다: 워크스페이스가 시스템을 이해한다면? 단순히 구문이나 파일이 아니라 실제 백엔드 상태를 말입니다.

바뀐 점

1. 눈먼 디버깅은 이제 안 한다

• 누락된 .env → 즉시 감지
• 깨진 서비스 → 런타임 전에 플래그 표시
• 의존성 문제 → 초기에 가시화

2. 아키텍처를 존중하는 스캐폴딩

• 깔끔한 구조
• 프로덕션 준비된 설정
• 강제된 컨벤션

3. 변경 영향 인식

리팩터링 전: “이 작업은 3개의 모듈과 2개의 엔드포인트에 영향을 줍니다.”

4. 컨텍스트가 있는 디버깅

로그를 AI에 복사‑붙여넣는 일은 이제 없습니다. 시스템이 이미 오류를 이해하고 있습니다.

우리가 무시하고 있는 전환

우리는 이제 단순히 코드를 작성하는 것이 아니라 시스템을 관리하고 있습니다. 그런데 우리의 도구는 여전히 “이 함수를 작성하라”에 머물러 있고, “이 시스템을 이해하라”는 단계에 도달하지 못하고 있습니다.

다른 사람들은 어떻게 해결하고 있을까?

당신의 백엔드 설정에서 가장 답답한 부분은 무엇인가요?

• 보일러플레이트?
• 디버깅?
• 환경 문제?

실제 워크플로우를 듣고 싶습니다.

https://www.workspai.com/