개념과 격벽에 대한 이해를 팀과 공유하고 합의하는 방법
2
12 asked
안녕하세요 재민님!
좀 오래되긴 했지만, 2년 전쯤에 발표하신 (유튜브에도 자주 언급하신 ㅎㅎ) 개념과 격벽을 통해서 지속 성장 가능한 설계를 만드는 방법에 대해 여쭤보고 싶은 부분이 있어서 질문드립니다!
Q1) 발표에서 개념을 코드로 느끼면서 잡아간다고 하셨는데, 이게 개인의 사고에 많이 의존하는 것 같아서요. 실제 팀에서는 한 사람이 발견한 개념(예: 대출 사례의 '연체' 분리 같은)을 팀원들과 어떻게 합의하고 공유하시나요?
코드 리뷰에서 자연스럽게 되는 건지, 별도의 논의 과정이 있는지 궁금합니다. 팀과 협업하는 관점에서는 설계가 결국 합의의 과정이기도 하다 보니, 이 방식이 팀 규모에서는 어떻게 작동하는지가 특히 궁금했습니다 ㅎㅎ
Q2) 개발을 하다 보면 "설계"라는 과정을 많이 겪게 되는 것 같습니다. API 설계, ERD 설계, 시스템 아키텍처 설계 등등 참 많네요.
발표에서는 분석·설계 없이 바로 구현하면서 개념과 격벽을 잡아가라고 하셨는데, 실제로 새 기능이나 서비스를 시작하실 때 무엇부터 손대시는지 궁금합니다. 개념(도메인 클래스)부터 코드로 잡고 API나 DB 스키마는 나중에 따라오게 하시는 건지, 아니면 이런 것들 중 일부는 최소한으로 먼저 정해두고 시작하시는지, 재민님의 실제 작업 순서가 궁금합니다.
물론 절대적인 정답은 없고 케바케일 것 같긴 합니다. 예를 들면 프론트엔드나 타 팀이 의존하는지 등등에 따라 달라지겠지만요. 재민님만의 어떤 기준 같은게 있는지 궁금합니다.
Q3) AI가 코드를 대신 짜주는 시대가 되다 보니, 회사에서도 코드를 잘 짜는 것 자체의 가치가 점점 낮아지는 분위기인데요. (물론 회사 KPI마다 다르겠지만 ㅎㅎ) 이런 시대에 개념과 격벽을 세우는 역량은 오히려 개발자의 마지막 차별점이 된다고 보시는지, 아니면 이 피드백 루프(구현하며 느끼고 개선하는)마저 AI가 돌게 될 거라고 보시는지, AI 시대에 이 방법론이 가지는 의미를 어떻게 보시는지 궁금합니다.
Answer 1
0
안녕하세요, 인프런 AI 인턴입니다. bebe님.
제미니님의 발표와 강의에 대한 깊이 있는 질문과 고민을 공유해 주셔서 감사합니다. 문의하신 내용에 대해 아래와 같이 답변드리겠습니다.
Q1) 팀과의 합의와 공유
개념과 격벽을 통해 설계를 발전시켜 나가는 과정은 개인의 사고에 달려있지만, 팀 환경에서는 이 과정이 더욱 중요합니다. 이는 궁극적으로 팀의 협력과 공유가 핵심이 되기 때문입니다.
- 코드 리뷰: 주기적인 코드 리뷰를 통해 개인이 발견한 개념들을 자연스럽게 팀과 공유할 수 있습니다. 이를 통해 팀원들은 서로의 인사이트를 얻게 되고, 합의의 과정이 수월해질 수 있습니다.
- 정기적 논의 시간: 별도의 디자인 리뷰 회의 시간을 마련하여 개념과 설계를 공유하고, 합의하는 과정이 필요합니다. 이 과정에서 각각의 아이디어에 대한 피드백을 교환하고 개선방안을 찾을 수 있습니다.
Q2) 설계와 구현의 시작점
제미니님이 말씀하신 ‘분석·설계 없이 바로 구현’ 접근은 초기 단계의 불확실성을 줄이고, 구현의 필요성에 따라 설계를 발전시키는 장점을 가지고 있습니다.
- 도메인부터 시작: 보통 도메인 모델(개념)을 먼저 잡고, 주요 클래스와 책임을 코딩하면서 API와 DB 스키마 설계를 동시에 발전시키는 것이 일반적입니다.
- 필요할 때 최소 설계: 프로젝트의 초기에는 주요 개념을 빠르게 잡고, 시간이 지날수록 필요에 따라 설계 디테일을 추가합니다. 즉, 최소한의 설계를 빠르게 시도하면서 필요한 부분은 나중에 확장하는 방식입니다.
Q3) AI 시대의 역할
AI가 개발의 많은 부분을 담당하게 된 시대에서는 오히려 ‘개념과 격벽’을 세우는 역량이 개발자에게 중요한 차별점이 될 수 있습니다.
- 설계 역량의 중요성: AI가 기술적인 구현의 많은 부분을 자동화할 수 있지만, 시스템의 본질적인 이해와 설계는 아직 사람의 몫입니다. 개념과 격벽을 효과적으로 만드는 능력은 시스템의 장기적인 안정성과 유지보수성을 보장하는 데 필수적입니다.
- AI와 협력: AI는 구현을 돕거나 자동화할 수 있는 역할을 하지만, 피드백 루프(구현과 개선)는 결국 사람의 창의력과 경험을 필요로 합니다.
이와 관련된 추가적인 관점이나 사례를 보시려면, 다음의 기존 게시물들을 참고하시면 도움이 될 것입니다:
- 개념 간 격벽을 침범하는 경우: 개념 분리를 통해 프로젝트의 안정성을 확보하는 방법에 대한 질문과 답변입니다.
- 조회 시 개념간 격벽: 데이터베이스 조회 시 개념과 격벽을 유지하는 접근 방법에 대한 논의가 있습니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
페이징 처리에서 offset/limit에 대한 질문
1
73
1
usecase 사용 기준
1
86
2
궁금한점이 여러개 생겼습니다.
1
97
1
다양한 관점의 코드 경험을 위해 개선하지 않은 코드
1
83
1
histories() 응답에 PointHistory.id를 포함한 이유가 궁금합니다/
1
65
2
SettlementTargetRepository Jquery 질문
1
68
2
부가 기능을 이벤트 핸들러로 분리하는 기준이 있을까요?
1
87
2
엔티티의 pk 를 0으로 초기화하시는 이유가 있을까요??
1
95
2
제미니님 안녕하세요!
1
96
2
개념 간 격벽 분리와 목록 조회 시 발생하는 참조 구조
1
105
2
프로덕트와 프로덕트카테고리 사이의 삭제 정책
1
99
2
새로 개발한다면 구현 순서
1
166
1
의존 방향에 대한 고민
1
147
2
어드민(Back-office)에서 예약 변경 시, '할인 조건 재검증(쿠폰 회수)' vs '기존 혜택 유지' 중 어떤 정책이 일반적인가요?
1
111
2
OrderKeyGenerator 인스턴스화 generate() 질문
1
97
1
외부 API 통합 시 데이터 제어 범위 설계 질문
1
110
1
PG 결제 승인 로직
1
166
2
QnA에서 Join 필드 표현법
1
107
1
결제서비스 콜백 동시성문제 가능성
1
130
2
굿
1
124
1
도메인/엔티티 분리 상황에서 쓰기 작업 하는 방법
1
152
2
도메인 객체와 엔티티 객체 사용
1
158
2
CouponService 의존성 의문
1
113
2
상품 목록 조회 고도화 질문
1
125
2