오늘의 공유 글
사용 AI: 방 공개
모델: 방 공개
구독 여부: 방 공개
프로젝트 소개: 클라-서버 간 통신 프로세스 구축
추가 기술스택: C#, Java, DotNetty, Netty, PostgreSQL, gstack, kcp프로토콜 등
내용/의견:
DB연동을 AI에게 시키고 검토를 진행했다. 한번에 잘 해줄까 기대를 하긴 했었지만, 직접 검토를 해보니 구조적, 코드적으로 말도 안되는 부분이 많았다. 결국 오늘 하루는 리팩토링 및 오류 수정에 시간을 다썼다. gstack을 이용해 최대한 계획을 수립하고, 1차 검토를 AI에게 맡겼는데도 이정도이다.
한 사이클의 업무를 완료하고 다음 작업을 새 세션에서 진행할 때, 이전 세션 작업과의 의존성은 적을수록 좋다. 이전 세션에서 로그인 기능을 구현했고, 새로운 세션에서 전투 시스템을 구현해야 한다고 해보자. 새 세션에서 로그인 구현내용을 알아야 할까? 이처럼 기능 개발 단계에서는 세션 간 의존성을 극한으로 줄일 수 있다(구조 설계를 매우 잘 해놨다는 가정하에). Context, Token 사용량 측면에서도 이득을 많이 볼 수 있는 것이다.
하지만 초반 아키텍처 구현은 세션 간 의존성을 줄이기가 매우 어렵다. 클라-서버 통신은 구현을 완료한 상태에서, DB연동을 구현하는 작업을 한다고 해보자. DB 연동을 위해 SqlSession을 생성해야 한다. 서버가 시작될 때 생성해야 하는 부분이다. 또한 각종 Repository를 등록하고, mapper 클래스도 생성될 것이다. 이를 위해 기존의 코드들이 조금씩 여러 군데에서 바뀔 수 있는 Cross-cutting problem이 발생하게 되는 것이다.
지금 구현되어있는 코드들이 모두 조금씩 바뀌는 아키텍처의 구현이라면, 현재 세션은 이전 구현내용을 모두 알아야 한다. 하지만 AI가 그만한 Context를 다 읽고 제대로 구현을 할 수 있을까? 그 결과가 오늘 하루종일 검토를 하도록 만들었다. 그럼 초기 아키텍처 설계 및 구현 부분에서, 어떻게 AI를 사용하여 자동화를 진행할 수 있을까? 이건 아마 앞으로도 해결하기 어려운 난제가 아닐까. 개발자(아키텍트)가 대체되지 않을 이유가 될 수도 있다.
그렇다고 아키텍처 구현 단계에 AI를 사용하지 말라는 것이 아니다. AI는 설계를 하는 과정, 계획을 세우는 단계에서 빼먹은게 없는지, 보완할 점은 없는지에 대한 방향성을 제시하여 우리가 인지할 수 있게 해준다. 이건 굉장히 도움되는 과정이다. 좋은 점은 이용하고, 부족한 점은 확실히 알고 제어해야만 규모 있는 프로젝트를 완성해낼 수 있을 것이다.
AI 관련 뉴스와 정보는 이미 차고 넘칩니다. 우리에게 지금 필요한 것은 "그래서 그거 진짜 써보니 어때?"에 대한 실전 답변입니다.
본 방은 단순한 링크 공유를 지양하고, 개개인이 AI를 프로젝트나 실무에 적용하며 겪은 구체적인 시행착오와 인사이트를 나누는 공간입니다.
✅이런 분들을 환영합니다:
AI로 실제 서비스를 만들거나 업무 자동화를 구축해 보신 분
특정 모델의 한계점과 장점을 기술적으로 파헤치고 싶으신 분
남의 경험을 통해 시행착오를 줄이고 성장을 가속화하고 싶으신 분
참여 링크:
