원칙과 요구사항이 충돌할 때

ALT

산을 배경으로 한 한국 포스터

📝 한줄 요약

기획 중에 새로운 요구사항이 처음 정한 원칙과 충돌했습니다. 그 순간 “편의상 원칙을 휘는 게 낫다”고 생각하지 않고, “원칙을 바꾼다면 모든 설계를 다시 해야 한다”고 판단해 의사결정 지점을 만들었어요.

Before: 원칙을 정하고 나서 요구사항만 추가
After: 충돌하는 요구사항이 생기면 원칙 개정 여부를 먼저 판단, 그 영향도를 명시

👥 이런 분께 추천

• 프로젝트 규칙이나 원칙을 정했는데 나중에 “이건 어떻게 할까?” 고민이 생기는 분

• 요구사항과 기본 전제가 충돌할 때 어떻게 판단해야 할지 모르는 분

• “편하려고 원칙을 좀 휘는 게 나을까?” 싶지만 찝찝한 분

• AI와 함께 일할 때 규칙의 우선순위를 명확히 하고 싶은 분

🙋 내 스펙 & 환경

진행 방법

1. 처음 정한 원칙: 단독 사용자

기획 시작할 때 프로젝트의 제약을 명확히 했어요.

“이 사이트는 내가 혼자 사용합니다. 계정 가입, 다중 사용자, 역할 권한 같은 것은 필요 없습니다.”

이 원칙은 다른 모든 기술 결정을 좌우했습니다:

• 인증: 복잡한 회원 관리 대신 간단한 비밀번호 하나

• 권한: 모든 데이터는 내 것이므로 권한 체크 불필요

• 공유: 데이터를 남에게 공개할 필요 없음

2. 새로운 요구사항: 다른 사람이 봐야 할까?

기획이 거의 끝났을 때, 이런 생각이 들었어요:

“혹시 나중에 대표님(직장 상사)이 이 사이트를 직접 열어서 봐야 하지 않을까? 보고용 페이지가 있으면 좋지 않을까?”

이 요구사항은 깔끔해 보였지만, 사실 원칙을 완전히 뒤집는 거였어요.

왜냐하면:

• 단독 사용자 전제가 깨짐

• 인증 구조를 완전히 다시 설계해야 함 (누가 뭘 볼 수 있나?)

• 개인정보 노출 범위를 결정해야 함 (어떤 필드까지 공개할 건가?)

• 모든 데이터 모델에 “공개 여부” 플래그가 들어가야 함

그래서 바로 “좋은 아이디어네, 넣자”가 아니라 “이건 원칙 개정이 필요하다”고 판단했어요.

3. 의사결정 질문 던지기

저는 AI와 함께 이렇게 물었어요:

“이 기능을 넣으려면 Constitution의 ‘단독 사용자’ 원칙을 바꿔야 합니다. 바꾸시겠습니까?”

그리고 선택지를 명확히 제시했어요:

옵션 A: 원칙 유지 - 보고용 페이지는 범위 밖. 대표님이 봐야 하면 별도 논의
옵션 B: 원칙 개정 - “단독 사용자이지만 선택적 공개 가능” 로 변경, 모든 설계 재검토

결정은: 옵션 A (원칙 유지, 보고용은 나중에)

4. 왜 옵션 A를 골랐나

이유는:

1. 데이터 보호가 최우선 - 개인정보를 다루는 사이트라서 “공개할까 말까” 고민할 여유가 없음

2. 1차 범위 명확화 - 일단 혼자 쓸 수 있게 1차를 완성하고, 공개 기능은 2차로 미룬다

3. 원칙 개정의 영향도 - 한 번 “선택적 공개”를 넣으면 98개 요구사항 전체를 다시 검토해야 함

그래서 기획 문서에 명시했어요:

“보고용 페이지는 추후 개발 범위. 지금은 단독 사용자 가정 유지. 나중에 공개 기능을 추가하려면 그때 Constitution 개정 필요.”

5. 결과: 기획 명확화

이 과정을 거친 덕분에:

• AI는 “공개 기능을 넣을 때는 다시 물어야겠다”고 기억함

• 나는 “1차에서는 개인용만, 2차에서 공유 기능”으로 범위를 명확히 함

• 요구사항이 꼬이지 않음

배운 점

💡 핵심 교훈

1. 원칙은 편하게 휘어지는 게 아니다

“원칙인데 하나 정도 예외 봐줄 수 있지 않을까?” 이런 생각은 위험합니다.

왜냐하면:

• 첫 예외가 나오면 두 번째도 쉬워짐

• 원칙의 명확성이 흐려짐

• 나중에 “이건 공개했는데 저건 안 한다”는 일관성 문제가 생김

2. 충돌할 때는 “편하게 해석”하지 말고 “명시적으로 판단”하자

좋은 패턴:

새 요구사항 ← 충돌하나?
            ↓ YES
        원칙을 바꿀 건가?
        ↙          ↘
      YES           NO
    (재설계)      (범위 밖 명시)

이렇게 하면 AI와도, 나중의 나와도 헷갈림 없이 소통할 수 있어요.

3. “미루기”도 명시적으로

“나중에 하자”는 모호합니다. 대신:

• “2차 개발 범위: 공유 기능”

• “그때는 Constitution 개정 필요”

• “개정할 때 영향받는 부분: 98개 요구사항 전수 재검토”

이렇게 기록하면 2차에 갈등이 없어요.

🔜 다음에 적용할 것

1. 원칙과 새 요구사항이 충돌하면 즉시 의사결정 — 편하게 지나가지 않기

2. “범위 밖” 명시하기 — 왜 안 하는지, 언제 다시 볼지 문서화

3. 원칙 개정의 비용 명시 — “이걸 넣으면 이 부분들을 다시 해야 한다”

솔직한 소감

처음엔 “보고용 페이지는 좋은 아이디어인데 왜 애를 먹지?” 싶었어요. 그런데 하나하나 추적해보니 원칙 하나가 연쇄적으로 영향을 미치는 게 보였습니다.

“편하게 한 가지만 더 추가하자”는 생각이 얼마나 위험한지 배웠어요. 비개발자라서 오히려 “이게 정말 영향이 있나?” 질문을 자연스럽게 던질 수 있었고, 그 덕분에 설계가 흔들리지 않았던 것 같습니다.

원칙을 정하는 것도 중요하지만, 그 원칙이 흔들릴 때 어떻게 판단하는지가 더 중요하다는 걸 알게 됐습니다.