연재: AI 시대의 SE·프로그래머를 위한 AI 벽치기(Wall-hitting) 실전 입문 제3회 - 구현 전 AI와 설계 리뷰를 위한 벽치기

연재: AI 시대의 SE·프로그래머를 위한 AI 벽치기 (Wall-hitting) 실전 입문

전 5회 | 제3회 / 5 이 연재는, AI를 「정답을 내는 기계」가 아니라, 「전제를 파고들고, 선택지를 늘리며, 판단을 검증하는 파트너」로 사용하기 위한 실전 시리즈입니다.

구현을 시작한 후에 설계의 미흡함을 깨달은 적이 없으신가요?

「동작하는 것은 만들었지만, 기능을 추가하려고 하니 구조가 파탄 났다」

「나중에 되돌아보니, 다른 방법이 더 좋았다」

「왜 이 설계로 했는지, 스스로도 기억나지 않는다」

지난 기사에서는 모호한 아이디어를 요구사항으로 바꾸는 벽치기 템플릿을 소개했습니다. 이번에는 요구사항이 확정된 후의 **설계 페이즈 (Design Phase)**에서 AI와 어떻게 벽치기를 할 것인가를 다룹니다.

• 설계에서 벽치기가 유효한 이유
• 설계안 비교 템플릿
• 과잉 설계 (Over-engineering)를 방지하는 벽치기 패턴
• ADR (Architecture Decision Record)로의 변환
• 벽치기 실례 ("알림 기능의 아키텍처 선정"을 주제로)

먼저 결론부터 말씀드립니다.

설계 벽치기는 AI에게 유일한 정답을 결정하게 하는 작업이 아닙니다. 다음을 시각화하는 작업입니다.

시각화하는 것	효과
선택지	「다른 방법도 있다」는 것을 깨달을 수 있음
...
설계 판단을 「기록하여 남기는 것」이 개인 개발에서도 팀 개발에서도 나중에 가장 큰 가치를 가집니다.

설계에서 벽치기가 특히 유효한 이유는, 설계에는 유일한 정답이 없기 때문입니다.

요구사항 정의에서는 「무엇을 만들 것인가」를 결정하지만, 설계에서는 「어떻게 만들 것인가」를 결정합니다. 「어떻게 만들 것인가」에는 항상 여러 선택지가 있으며, 어떤 것이 최적인지는 전제·제약·미래의 변화에 따라 달라집니다.

혼자 생각하면 처음에 떠오른 안안에 집착하기 쉽습니다. AI와 벽치기를 함으로써 다른 선택지나 리스크가 보입니다.

알림 기능의 설계를 해주세요.

AI는 그럴싸한 설계를 내놓지만, 다음과 같은 문제가 있습니다.

• 자신의 프로젝트 제약 (기술 스택, 팀 규모, 운용 체제)이 반영되지 않음
• 일반적인 「모범 답안」이 되기 쉬워, 과잉 설계가 될 수 있음
• 왜 그 설계인지, 판단 근거가 남지 않음

여러 설계안을 나란히 놓고 비교하기 위한 패턴입니다.

다음 기능에 대해 설계안을 비교해 주세요.
기능:
- 사용자 알림 기능 (승인 요청, 처리 완료, 에러 알림)
...

자신의 설계안이 「과하게」 되어 있지 않은지 리뷰하게 하는 패턴입니다.

이 설계안이 과잉 설계가 되어 있지 않은지 리뷰해 주세요.
현재 설계안:
{설계안의 개요}
...

설계 판단의 결과를 ADR (Architecture Decision Record)로 기록하는 패턴입니다.

다음 설계 상담의 결과를 ADR로 변환해 주세요.
상담 내용:
{벽치기의 요약}
...

ADR을 작성해 두면, 「왜 이렇게 되어 있는가」를 나중에 자신이나 팀 멤버가 확인할 수 있습니다.

지난 기사에서 요구사항을 정리한 「개인용 AI 태스크 관리 도구」에 알림 기능을 추가하는 상황을 가정합니다.

당신은 설계 리뷰어로서 벽치기에 참여해 주길 바랍니다.
목적:
- AI 태스크 관리 도구에 알림 기능을 추가하는 설계를 결정하고 싶음
...

🤖 AI (설계 리뷰어):

비교표:

안	구현 비용	월간 비용	알림 도달성	확장성	채택해야 할 조건
A: Slack Webhook	◎ 낮음	무료	○ 즉시	○ 다른 채널 추가 가능	평소 Slack을 사용하는 경우
B: SendGrid	○ 중간	무료 범위 있음	△ 지연 있음	◎ 다수 수신처 대응	이메일 알림을 선호하는 경우
C: Discord Webhook	◎ 낮음	무료	○ 즉시	△ 비즈니스 이용이 어려움	개인 개발로 완결되는 경우

전제에 대한 지적:

• 「알림」의 입도(Granularity)가 미정의됨. 모든 상태 변경 시 알림을 보낼 것인가, 승인 대기 시에만 보낼 것인가?
• 알림이 도달하지 않았을 경우의 폴백 (Fallback)이 고려되지 않음
• 향후 팀에서 사용할 경우, Discord는 비즈니스 용도로는 부적합하다는 인상이 있음

조건부 제안:

• 개인 이용이며 Slack을 일상적으로 사용한다면 →
  A: Slack Webhook
• 알림 대상의 유연성을 중시한다면 → 알림 인터페이스를 만들고, 첫 구현은 Slack으로 한다

ADR 초안:
`# ADR: 알림 기능의 전송 채널 선정

상태: 채택

배경: 승인 대기 중인 태스크를 놓치는 것을 방지하기 위해 알림 기능을 추가한다.

결정: Slack Incoming Webhook을 사용한다.

대안

• SendGrid (메일): 구현 비용이 높고, 개인 용도로는 오버스펙(Over-spec)
• Discord Webhook: 향후 팀 단위 이용 시 비즈니스적인 느낌이 부족함

이유: 구현 비용 최소, 무료, 개인이 일상적으로 사용하고 있어 도달 확인이 용이함.

영향: Slack에 의존하게 된다. 향후 알림 대상 추가 시에는 추상화(Abstraction)가 필요함.

미결 사항

• 알림 대상의 입도(Granularity) (모든 상태 변경 시 vs 승인 대기 시에만)

• 알림 실패 시의 폴백(Fallback)`

알림의 입도를 결정하지 않았음: '알림을 보낸다'라고만 결정하고, '언제 알림을 보낼지'를 정의하지 않았음
폴백(Fallback)의 결여: 알림이 도착하지 않을 경우의 대책을 생각하지 않았음
향후 확장 방침이 명확해짐: 처음에는 Slack으로 시작하고, 확장이 필요해지면 추상화한다
ADR로서 기록이 남음: 판단 근거와 기각 이유가 남기 때문에, 나중에 다시 확인할 수 있음

설계 벽치기(Wall-hitting)는 다음과 같은 흐름으로 진행하면 안정적입니다.

포인트는, 조건부로 판단하는 것입니다. "A가 최선이다"가 아니라 "X의 조건이라면 A, Y의 조건이라면 B"라고 정리하면, 전제가 바뀌었을 때 판단을 재검토할 수 있습니다.

AI의 설계 제안을 그대로 채택하지 말 것: AI는 일반적인 베스트 프랙티스(Best Practice)를 제안하지만, 자신의 프로젝트에 맞으리라는 보장은 없다. 특히 팀 규모나 스킬셋(Skill-set)은 AI에게 전달하지 않으면 반영되지 않는다.
과잉 설계(Over-engineering)에 주의할 것: AI에게 설계를 물으면 고도의 설계 패턴을 제안할 때가 있다. "지금 규모에 필요한가"를 항상 다시 물어야 한다.
설계 판단은 기록할 것: ADR은 완벽할 필요가 없다. "무엇을 선택했고, 무엇을 버렸으며, 왜 그렇게 했는가"라는 3가지 포인트가 남아 있다면 충분하다.
기밀 정보를 넣지 말 것: 사내 시스템의 설계를 벽치기할 경우, 구체적인 서비스명, 테이블명, API 명세를 익명화한 후 전달한다.

설계 벽치기를 수행하기 전에 다음을 확인해 보세요.

• 후보안을 2개 이상 준비했는가
• 각 안의 장점과 단점을 정리했는가
• 프로젝트의 전제(규모, 팀, 기간)를 AI에게 전달했는가
• 과잉 설계가 되지 않았는지 의심했는가
• "지금 필요한 것"과 "향후 있으면 편리한 것"을 분리했는가
• 판단 근거를 ADR로 남길 준비가 되었는가
• 채택하지 않은 안의 이유를 기록했는가

설계 벽치기는 AI에게 최적의 설계를 결정해 달라고 하는 작업이 아닙니다. 선택지를 나열하고, 트레이드오프(Trade-off)를 정리하며, 판단의 근거를 기록하는 작업입니다.

이번 기사에서 소개한 내용을 되돌아봅니다.

설계에는 유일한 정답이 없다 — 그렇기에 벽치기로 선택지를 가시화한다
3가지 유형(설계안 비교형·과잉 설계 체크형·ADR 생성형)으로 벽치기를 안정화한다
ADR에 기록함으로써 설계 판단이 지적 자산이 된다
조건부로 판단함으로써 전제가 바뀌어도 대응할 수 있다

다음 회차에는, AI에게 통째로 맡기지 않는 코드 리뷰·디버깅 벽치기 기술을 다룹니다.

"AI가 내놓은 코드를 그대로 믿었다가 버그를 심었다", "에러를 붙여넣어도 임시방편적인 답변밖에 나오지 않는다"라는 고민에 대해, AI를 안전하게 사용하는 벽치기 절차를 소개합니다.

이 기사에서는 AI의 답변을 그대로 정답으로 취급하는 것을 권장하지 않습니다.

실무 이용 시에는 기밀 정보를 넣지 말 것, 출력을 검증할 것, 필요에 따라 인간이 판단할 것을 전제로 합니다.

• AI와의 벽치기는 "질문"이 아니라 "사고 프로세스 설계"이다
• 모호한 아이디어를 요구사항으로 바꾸는 AI 벽치기 템플릿
• 구현 전에 AI와 설계 리뷰를 하기 위한 벽치기 절차 ← 이번 회차
• AI에게 통째로 맡기지 않는 코드 리뷰·디버깅 벽치기 기술
• AI와의 벽치기 로그를 지식화하여 포트폴리오로 만든다