#트렌드 #기타
변수와 상수만 알아도 개발이 쉬워지는 이유

개발을 처음 접하면 코드부터 공부해야 할 것처럼 느껴집니다. 함수와 조건문을 배우고, 데이터베이스와 API를 알아야 비로소 무언가를 만들 수 있을 것 같죠. 저도 워드프레스, 노션, 바이브 코딩을 각각 다룰 때는 사용하는 기술이 서로 다르다고 생각했습니다.

그런데 두 영역을 함께 다뤄보니 개발을 이해하는 더 단순한 기준이 보였습니다. 바로 무엇이 바뀌어야 하고, 무엇이 바뀌면 안 되는지를 구분하는 것입니다. 개발 용어로 말하면 변수와 상수의 구분입니다.

 

개발이 어려운 이유는 코드만이 아닙니다

 

변수는 상황에 따라 값이 달라질 수 있습니다. 상수는 정해진 값이나 기준을 유지합니다.

코드에서는 비교적 명확합니다.

 

변수: 고객 이름, 주문 금액, 문의 내용, 검색어

상수: 수수료율, 권한 규칙, 필수 입력 항목, 승인 기준

 

하지만 실제 서비스를 만들면 이 경계가 흐려집니다. 어떤 정보는 사용자가 입력할 때마다 달라져야 합니다. 반대로 어떤 기준은 사용자가 무엇을 입력하더라도 지켜져야 합니다. 이 둘을 구분하지 않으면 기능을 하나 추가할 때마다 예외가 생기고, AI의 답변도 일관성을 잃습니다.

개발이 복잡해지는 순간은 코드를 모를 때만이 아닙니다. 바뀌어야 할 것과 고정해야 할 것을 사전에 정하지 않았을 때입니다. 이걸 정하지 않으면 개발이 산으로 갑니다.

 

2026-08-31_body-01.png

 

프롬프트는 변수에 가까운 영역입니다

 

바이브 코딩과 생성형 AI에서는 자연어로 원하는 결과를 설명합니다. 같은 AI를 사용해도 질문과 맥락이 달라지면 결과도 달라집니다.

 

  • 누구를 위한 결과인가
  • 지금 해결하려는 문제는 무엇인가
  • 앞선 대화에서 무엇을 결정했는가
  • 어떤 형식과 어조가 필요한가
  • 이번 상황에서 특별히 고려할 예외는 무엇인가

 

이런 정보는 작업마다 달라집니다. 그래서 프롬프트의 입력과 대화 맥락은 변수에 가까운 영역입니다. 벡터 검색도 비슷합니다. 벡터는 문장의 의미를 숫자의 위치로 표현해, 질문과 의미가 가까운 자료를 찾는 데 사용합니다. 검색어가 달라지면 선택되는 자료와 답변의 맥락도 달라질 수 있습니다.

다만 프롬프트 자체가 곧 변수이고 벡터가 곧 변수라는 뜻은 아닙니다. 핵심은 이 영역이 정해진 한 가지 값보다 의미와 맥락의 변화를 다룬다는 점입니다. 쉽게 말하면 이 영역은 정답이 없습니다. 오직 해답이 있을 뿐입니다.

 

데이터베이스 구조는 상수에 가까운 영역입니다

 

노션에서 프로젝트 대시보드를 만든다고 생각해 보겠습니다. 프로젝트 이름, 담당자, 마감일, 진행 상태 같은 속성을 먼저 정하고 각각의 정보를 채워 넣습니다. 업무가 진행되면 담당자와 마감일, 상태는 계속 달라집니다.

그러나 데이터를 관리하려면 어떤 속성을 사용할지, 어떤 형식으로 입력할지, 서로 다른 데이터베이스를 어떻게 연결할지에 관한 기준은 유지되어야 합니다.

워드프레스의 데이터베이스도 같습니다. 글, 사용자, 설정, 분류 같은 값은 계속 추가되고 수정되지만, 그 정보를 저장하고 연결하는 구조가 있기 때문에 하나의 시스템으로 작동합니다.

이 원리는 특정 도구에만 적용되지 않습니다. 바이브 코딩에서 자주 사용하는 Supabase도 내부적으로 PostgreSQL이라는 관계형 데이터베이스를 사용합니다. 사용하는 화면과 서비스는 달라도 테이블, 열, 데이터 형식, 관계, 권한을 먼저 설계해야 한다는 원리는 같습니다.

물론 노션 데이터베이스와 PostgreSQL은 기능과 구조가 동일한 제품은 아닙니다. 하지만 정보를 어떤 항목으로 나누고, 어떻게 연결하며, 어떤 규칙으로 관리할지 정한다는 설계 관점에서는 공통점이 있습니다. 테이블 안의 값은 계속 바뀝니다. 그러므로 테이블 자체를 상수라고 부르는 것은 정확하지 않습니다. 대신 테이블을 둘러싼 다음 기준은 상수에 가깝습니다.

  • 어떤 항목을 저장할 것인가
  • 각 항목은 어떤 형식을 가져야 하는가
  • 어떤 정보가 반드시 있어야 하는가
  • 누가 조회하고 수정할 수 있는가
  • 어떤 상태가 되면 다음 단계로 넘어가는가

 

즉 데이터의 값은 변하더라도, 데이터를 담고 다루는 구조와 규칙은 일정하게 유지되어야 합니다. 즉 이영역은 앞에서 살펴본 프롬프트랑 반대로 옳고 그른지 유무를 따지며, 정답의 영역입니다.

 

AI 서비스에는 두 영역이 모두 필요합니다

 

전통적인 웹서비스와 AI 서비스를 비교하면 차이가 더 분명해집니다.

 

2026-08-31_table-01.png

 

AI는 변화하는 맥락을 다루는 데 강합니다. 사용자의 표현이 조금씩 달라도 의미를 해석하고, 상황에 맞는 결과를 만들 수 있습니다.

하지만 모든 것을 AI의 판단에 맡길 수는 없습니다. 결제 금액, 개인정보 접근 권한, 필수 데이터, 승인 절차처럼 틀리면 안 되는 것은 코드와 데이터 구조로 고정해야 합니다.

AI가 유연할수록 오히려 상수가 더 중요해집니다. 자유롭게 변할 수 있는 범위가 넓어질수록, 넘어서는 안 될 경계도 분명해야 하기 때문입니다.

 

공학에서는 원래 두 가지를 함께 봅니다

 

저는 신소재공학을 공부하면서 열역학과 기기분석을 배웠습니다. 공학에서는 원재료를 넣는다고 언제나 같은 완제품이 나오는 것이 아닙니다. 온도, 압력, 시간, 조성, 가공 방식 같은 조건에 따라 재료의 성질이 달라집니다. 그리고 나온 결과를 측정하고 분석해 조건이 적절했는지 확인합니다.

 

이 흐름은 개발과 닮았습니다.

입력 → 조건과 처리 → 결과 → 측정과 분석 → 조건 수정

 

여기서 입력값과 가공 조건은 바꿔볼 수 있는 변수입니다. 반면 안전 기준, 측정 방식, 허용 범위처럼 결과를 판단하는 기준은 쉽게 흔들려서는 안 됩니다.

그래서 바이브 코딩을 배울 때도 완전히 낯선 세계처럼 느껴지지 않았습니다. 사용하는 도구는 달랐지만, 조건을 바꾸고 결과를 확인한 다음 다시 수정하는 구조를 유추할 수 있었기 때문입니다.

 

도구가 달라도 설계 원리는 같습니다

 

노션에서 업무 관리표를 만들다가 Supabase로 서비스를 개발한다고 해서 모든 사고방식을 새로 배워야 하는 것은 아닙니다.

먼저 필요한 정보를 항목으로 나눕니다. 항목마다 문자, 숫자, 날짜, 선택값처럼 적절한 형식을 정합니다. 서로 연결할 정보가 있다면 관계를 만들고, 누가 데이터를 보고 수정할 수 있는지도 결정합니다. 구현 방식과 기술적인 깊이는 달라지지만, 데이터베이스를 설계할 때 던지는 질문은 이어집니다.

 

2026-08-31_table-02.png

 

결국 중요한 것은 특정 도구의 메뉴를 외우는 일이 아닙니다. 변하는 데이터와 유지해야 할 구조를 구분하는 눈입니다.

 

먼저 변수와 상수를 나누면 도구가 보입니다

 

새로운 기능을 만들거나 업무를 자동화하기 전에 다음 질문부터 해볼 수 있습니다.

 

  • 사용자와 상황에 따라 달라져야 하는 것은 무엇인가?
  • 결과가 달라도 반드시 지켜야 하는 기준은 무엇인가?
  • AI가 해석하도록 열어둘 부분은 어디까지인가?
  • 데이터베이스의 구조와 코드로 고정할 부분은 무엇인가?
  • 예상 밖의 결과가 나오면 사람이 확인할 지점은 어디인가?

 

이 질문에 답하면 도구의 역할도 자연스럽게 나뉩니다. 의미를 해석하고 표현을 바꾸는 일에는 프롬프트, LLM, 벡터 검색이 어울립니다. 정보를 정확히 저장하고 규칙대로 처리하는 일에는 테이블, 코드, API, 자동화가 필요합니다. 그리고 두 영역의 경계에는 사람의 판단과 검수가 있어야 합니다.
 

2026-08-31_body-02.png

 

개발자는 코드를 쓰기 전에 경계를 정합니다

 

웹핏은 워드프레스뿐 아니라 노션, 자동화, 바이브 코딩을 함께 살펴보면서 화면이나 기능 하나만 보지 않습니다. 고객의 정보가 어디에서 들어오고, 무엇이 달라질 수 있으며, 어떤 기준은 끝까지 유지되어야 하는지를 먼저 봅니다.

웹사이트의 글은 계속 바뀔 수 있습니다. 고객의 질문도 매번 다릅니다. AI가 만드는 답변 역시 상황에 따라 달라집니다. 하지만 브랜드가 지키려는 관점, 고객 정보의 구조, 문의가 전달되는 방식, 사람이 최종 확인해야 하는 기준까지 함께 흔들리면 시스템이 될 수 없습니다.

개발을 잘한다는 것은 모든 값을 자유롭게 바꾸는 능력이 아닙니다. 반대로 모든 것을 단단하게 고정하는 능력도 아닙니다.

 

개발하기전에 변수와 상수를 먼저 고려하세요.

 

변수와 상수만 알아도 개발이 쉬워지는 이유는 문법 하나를 더 알게 되기 때문이 아닙니다. 복잡한 서비스를 두 종류의 문제로 나눠볼 수 있기 때문입니다.

개발을 어렵게 만드는 것은 언제나 코드가 아닙니다. 바뀌어야 할 것과 지켜야 할 것을 구분하지 못하는 것이 더 큰 문제일 수 있습니다. 그 경계를 정하는 순간, 어떤 도구를 어디에 써야 하는지도 보이기 시작합니다.

링크 복사

한상문 웹핏 · CEO

고객의 눈길을 끄는 퍼스널 브랜딩 홈페이지

댓글 0
댓글이 없습니다.
추천 아티클
한상문 웹핏 · CEO

고객의 눈길을 끄는 퍼스널 브랜딩 홈페이지

0