2편 — 손으로 박은 값들의 역습: 연결고리, 요청의 홍수, 그리고 공통코드

 

 

Dev Story · 2편 — 공통코드

손으로 박은 값들의 역습 —
연결고리, 요청의 홍수, 그리고 공통코드

끝없는 "이것도 되나요?" 앞에서, 무엇을 코드에 박고 무엇을 열어둘지 배운 이야기

1편에서 저는 "완벽한 구조 말고 최소부터"를 택했죠. 막상 첫 시스템을 만들기 시작하니, 코드 문법보다 훨씬 무서운 것들이 저를 가르쳤습니다.

1 처음엔 다 코드에 박았다

CRM에서 접수 건은 여러 '상태'를 지나갑니다 — 접수, 처리중, 완료 같은 것들이요. 분류도, 단계도 마찬가지고요. 처음 만드는 저는 이걸 가장 빠른 방법으로 처리했습니다. 그냥 코드 안에 직접 적어 넣었죠.

// 상태도, 분류도… 죄다 코드에 그대로 박아둠 상태 = ["접수", "처리중", "완료"] 분류 = ["하드웨어", "소프트웨어"]

당장은 잘 돌아갔습니다. 문제는 그 다음에 찾아왔어요.

---

2 진짜 벽 — 모든 게 얽혀 있고, 요청은 끝이 없었다

막상 만들어 보니, 어려운 건 문법이 아니었습니다. 두 가지가 저를 계속 무너뜨렸어요.

• ① 모든 게 얽혀 있었다 (연결고리) — 상태 하나, 분류 하나가 목록·드롭다운·색깔 표시·검증까지 여기저기 연결돼 있었습니다. 한 군데를 건드리면 엉뚱한 데가 터졌어요. "이게 왜 여기랑 연결돼 있지?"의 연속이었죠.
• ② 요청이 끝이 없었다 — 쓸 사람들에게 "뭐가 필요하세요?" 물으면 — "이런 거 있으면 좋겠어요!", "이것도 되나요?" — 끝없이 던졌습니다. 다 만들어 주려니 머리가 터졌고, 더 큰 문제는 어디까지 해주고 어디서 쳐내야 할지를 몰랐다는 거였습니다.

이때 뼈저리게 배웠습니다 — 왜 '설계'와 '기획'이 중요한지.

만들기 전에 "무엇을 만들고, 무엇은 안 만들지"를 정해두지 않으면, 쏟아지는 요청과 얽힌 연결고리에 끌려다니다 끝납니다. 코드를 잘 짜는 것보다, 무엇을 짤지 정하는 게 먼저였어요. 첫 프로젝트가 저에게 준 가장 비싼 수업이었습니다.

---

3 박아둔 값은, 나중에 못 바꾼다

그 와중에 제가 코드에 박아둔 값들이 발목을 잡았습니다. 나중에 "이건 쓰는 곳마다 다르게 부르고 싶다"는 걸 알게 돼도, 값이 코드에 박혀 있으니 제가 일일이 코드를 열어 고쳐야 했어요.

솔직히 고백하면, 처음 만들 땐 "이런 값은 데이터베이스에 빼두고 꺼내 쓰자" 같은 깔끔한 답을 떠올리지도 못했습니다. 같은 걸 몇 번씩 고치고, 한참 헤맨 뒤에야 비로소 길이 보였어요. (비개발자의 첫 프로젝트는 원래 이렇게 더디게 배웁니다.)

---

4 해결 — '공통코드' 한 곳으로 모으기

그래서 공통코드라는 테이블 하나를 뒀습니다. "이런 종류의 목록은 전부 여기서 관리한다"는 한 곳이요. (이런 구조를 떠올리고 방향을 잡는 건 제 몫이었지만, 실제로 코드로 옮기는 건 AI 팀과 함께였습니다.)

// 공통코드 테이블 — '종류'와 '값'만 있으면 끝 종류(code_type) 값 ───────────────────────── 상태 접수 상태 처리중 상태 점검대기 ← 코드 안 건드리고 '한 줄 추가' 분류 하드웨어 분류 소프트웨어

이제 화면의 모든 드롭다운은 이 한 테이블에서 값을 읽어옵니다. 흩어져 박혀 있던 값들이 한 곳으로 모이니, 그 지긋지긋하던 연결고리도 한결 단순해졌어요.

---

5 핵심 — 틀은 코드로 박고, 이름은 자유롭게

여기서 중요한 건 "데이터냐 코드냐" 같은 철학이 아니었습니다. 제가 실제로 한 건 이거예요.

공통코드라는 '틀'은 코드로 단단히 박아두고, 그 안에 들어가는 '이름(항목)'은 자유롭게 바꿀 수 있게 열어뒀다.

왜냐고요? 그래야 관리자가 자기 회사에 맞는 항목으로 직접 채워 쓸 수 있으니까요. 어떤 회사는 상태를 접수 / 수리 / 완료로, 다른 회사는 상담 / 처리 / 종결로 — 코드(틀)는 그대로 두고 이름만 각자 맞추는 겁니다.

그리고 이건 어쩌다 그렇게 된 게 아니라 처음부터 그렇게 계획한 것이었습니다. 언젠가 여러 회사가 각자 자기 옷처럼 맞춰 쓰는 모습을 염두에 뒀거든요. — 이게 시즌 2의 'SaaS' 이야기로 이어지는 작은 씨앗입니다.

---

반응형

6 이번 편의 산출물 — '요청, 어디까지 받을까' 쳐내기 체크리스트

비개발자가 처음 시스템을 만들 때, 쏟아지는 요청 앞에서 길을 잃기 쉽습니다. 저는 이런 기준으로 "지금 할지 / 미룰지 / 쳐낼지"를 갈랐어요.

☑ 요청 쳐내기 체크리스트

☐ 이게 없으면 핵심 업무 흐름이 안 돌아가나? (그렇다면 먼저)

☐ 한 사람 취향인가, 여러 명이 공통으로 겪는 문제인가?

☐ 지금 꼭 필요한가, 나중에 해도 되나? (대부분은 나중에)

☐ 회사·팀마다 다를 값인가? → 코드에 박지 말고 관리자가 바꾸게(공통코드)

☐ "되나요?"에 다 "네" 하면 연결고리가 폭발한다 — 뼈대부터, 곁가지는 골라서

---

7 AI가 갈린 지점 / 사람이 결정한 지점

🤝 이번 편의 결정

AI(팀)가 도운 것: 쏟아지는 요청을 종류별로 정리해 주고, "이런 값은 공통코드로 빼면 회사마다 이름을 바꿀 수 있다"는 패턴을 짚어 줬습니다.

사람이 결정한 것: ① 무엇을 쳐낼지 — 모든 "되나요?"에 "네" 할 순 없으니, 핵심 뼈대부터. ② 이름을 관리자가 바꾸게 열어둘지 — 회사 맞춤을 미리 계획한 건 제 선택이었습니다.

교훈: 설계·기획은 '기능을 더하는 법'이 아니라, '무엇을 안 할지, 무엇을 남이 바꾸게 열어둘지'를 정하는 일이었습니다. (다음 편은 — 사람이 일일이 적던 '변경 기록'을 시스템이 알아서 남기게 한 이야기.)

---

핵심 한 줄 요약

진짜 벽얽힌 연결고리 + 끝없는 요청, '어디까지'를 몰랐다

배운 것왜 설계·기획이 먼저인가 (무엇을 안 할지 정하기)

해결공통코드 — 틀은 코드로 박고, 이름은 자유롭게

의도관리자가 회사 맞춤으로 — 처음부터 계획한 것

씨앗"여러 회사가 각자 맞춰 쓰기" = 시즌 2 SaaS로

다음 글3편 — 자동 상담이력, "누가·언제·뭘 바꿨나"를 시스템이 알아서 기록

Tags

#공통코드 #하드코딩 #설계 #기획 #요구사항관리 #스코프관리 #DB설계 #CRM #비개발자 #AI협업 #SaaS #웹개발 #티스토리

▼ 티스토리 태그 입력란 복사용

공통코드, 하드코딩, 설계, 기획, 요구사항관리, 스코프관리, DB설계, CRM, 비개발자, AI협업, SaaS, 웹개발, 티스토리