루퍼스 2주차의 회고
[회고] 루퍼스 2주 차, 나는 ‘설계’를 했는가, AI의 ‘제안’을 승인했는가?
루퍼스 과정이 어느덧 2주 차를 넘겼다. 이번 주차에는 코드 한 줄 짜지 않았다. 대신 ERD(Entity Relationship Diagram), Class Diagram, Sequence-diagrams, 그리고 기술적 의사결정(Decision Making)들로 시간을 가득 채웠다.
개발의 본질은 코딩 이전에 ‘설계’에 있다는 것을 배우는 귀중한 시간이었다. 하지만 문득 멈춰 서서 모니터에 띄워진 화려한 다이어그램들을 바라보니, 등골이 서늘해지는 부끄러움이 밀려왔다.
“이 구조는 나의 머리에서 나온 것인가, 아니면 AI가 뱉어낸 그럴듯한 템플릿인가?”
설계인가, 승인인가?
테이블 간의 관계를 설정하고(ERD), 객체 간의 책임을 분리하며(Class Diagram), sequence-diagrams를 그려보는 과정은 오롯이 설계자의 논리와 철학이 담겨야 하는 영역이다.
“왜 1:N 관계여야 하는가?” “이 속성은 왜 여기에 위치해야 하는가?”
이런 치열한 고민 끝에 선 하나가 그어져야 한다. 하지만 나는 습관적으로 프롬프트 창을 먼저 열었다.
- “감성 이커머서를 만들건데 요구사항대로 만들어줘.”
- “이 기능을 위한 클래스 다이어그램 그려줘.”
AI는 순식간에 교과서적인 정답을 내놓았고, 나는 그것을 보며 “음, 논리적이네”라고 고개를 끄덕이며 내 설계 산출물로 옮겨 적었다. 이것은 ‘설계’가 아니라 AI의 제안서에 대한 ‘검토’ 및 ‘승인’ 과정에 불과했다.
생략된 사고(Thinking)의 과정
시스템의 청사진을 그리는 가장 중요한 단계에서조차 나는 ‘생각’을 생략하고 있었다. 내가 주도적으로 엔티티를 정의하고, 흐름이 꼬여서 머리를 싸매보고, 동료와 논쟁하며 구조를 변경하는 그 ‘고통스러운 사고의 과정’이 빠져 있다 보니, 결과물은 그럴듯해 보여도 내 것이 아니었다.
누군가 “왜 테이블을 이렇게 쪼개셨나요?”라고 묻는다면, “AI가 그렇게 하는 게 좋다고 해서요”라는 말 외에 자신 있게 설명할 논리가 빈약했다.
설계 단계에서의 편리함은 달콤하지만, 개발 단계에서 치명적인 독이 되어 돌아올 것이다. 뼈대를 이해하지 못한 채 AI가 그려준 대로 집을 짓기 시작하면, 나중에 벽 하나를 옮기는 일조차 두려워질 테니까.
3주 차의 다짐: 불편한 설계자가 되자
그래서 3주 차부터는 ‘불편한 설계자’로 돌아가려 한다. 편리함에 기생하지 않고, 내 논리로 시스템을 장악하기 위한 원칙을 세웠다.
1. 백지에서의 사투 (Whiteboard First)
프롬프트 창을 켜기 전, 반드시 빈 종이와 화이트보드 위에서 나만의 논리로 코드와 흐름을 끄적여 본다. 엉성하더라도 내 머리에서 나온 초안이 있어야 한다. 진짜 생각하는 사고를 기르지 않으면 내가 과연 코드를 더 잘짤 수 있을까? 그리고 인터넷이 없는 환경 혹은 AI가 제한된 환경에서는 어떻게 코드를 짜야할까에 대한 고민도 하게된다.
2. 생성기가 아닌 ‘검증 도구’로 사용하기 (AI as a Critic)
AI에게 “만들어줘(Create)”라고 요청하지 않고, 내가 만든 구조를 보여주며 “이 부분의 잠재적 문제는 뭐야?”라고 질문하겠다. 정답 생성기가 아닌, 까다로운 리뷰어로 AI를 활용하겠다.
3. 의사결정의 주체 되기 (Own the Decision)
기술적 의사결정 과정에서 AI의 근거를 그대로 베끼지 않는다. 그 근거가 타당한지 내 지식으로 다시 검증하고, 반박할 수 없다면 채택하지 않겠다.
뇌가 꼬이고 논리가 막히는 고통을 즐기자. 그 고통의 깊이만큼 내 시스템에 대한 이해도와 확신은 깊어질 것이다.
나는 AI의 오퍼레이터(Operator)가 아니라, 이 시스템의 아키텍트(Architect)가 되어야 한다.