기본 콘텐츠로 건너뛰기

ai랑 싸울 수록 논리력 레벨이 올라갑니다!(feat. cursor)




MCP를 준비하기 위한 툴을 만들려는데 cursor라는 툴이 좋다고 해서 툴을 받았죠.
Cursor는 여러분들 쓰고 계신가요? 
저역시 나오자마자 쓰는 성격이라기 보다, 
이걸 어떻게 쓰면 좋을까를 조사하다가 
용도가 생각나면 비로소 쓰기 떄문에
그렇게 빠른 편은 아닙니다. 
그래도 요즘은 왜 이제 쓰기 시작했지?
하고 후회하는 경우가 많다보니
조금은 빨리 손을 대려고는 합니다. 

그래도 워낙 귀찮은걸 싫어하다보니
이제야 손을 대기 시작하네요..

Vscode를 주로 쓰기 때문에
Vscode 익스텐션을 찾아봤는데... 
다운로드 수가 별로 많아보이지 않고 공식 익스텐션이 아닌 관계로
공식 툴로 테스트를 하기로 했습니다

Cursor.com 이란 사이트에 들어가서 직접
다운받아 설치해보니 vscode 랑 거의 비슷해서 익히는데 시간은 거의 안걸렸는데요
가장 좋았던것이 오른쪽 화면 에서 텍스트를 입력한 대로 코드가 써 지는 것이었죠

이것저것 해보는데처음에는 생각보다 좋은 품질로 코드가 작성되었네요.. 
mcp 환경을 만들어달라고 했었는데 잘 만들어주더라구요.

여기까지는 많은 콘텐츠에서 cursor의 대단함을 알려주기 위해서 보여주는 내용들과 별 차이가 없을 겁니다. 
하지만 여기저기 봐도 실제 프로젝트에서 쓰고 있는 내용을 못찾았구요, 
실제로 써본 사람들도 자꾸 코드가 바뀌기 때문에 아직은 아니라는 이야기를 하시더라구요.. 

이 사람들이 입을 모아 하는 말이 진실인지 알아보기 위해
실제 프로젝트에 적용해 보았습니다. 
아마 실제로 프로젝트에서 사용한 내용을 보여준 사례는 이번이 처음 아닐까 싶습니다. 

지금 현장에서는 리더가 python을 좋아했기때문에 
난 python을 잘 모르지만 python 코드로 작성하기로 했습니다.
python 2.5에서 3.0으로 넘어가는 과도기에 엄청 고생한 뒤로 안쓴 거 같네요.. 

하지만 막상 실무를 구현하려고 하니까 업무 flow를 분해 해야 했구요..

지금 해야하는 업무가 
excel로 요청이 온 유저 생성 업무를 보고
그에 맞는 excel이 맞는지 확인하고. 
Excel 파일을 기준으로 유저생성 쿼리를 만들고
리더의 승인이 있어야 질제 작업이 들어갈 수 있기 때문에 절차를 나눠서
엑셀파일에서 유저 생성 쿼리를 만드는 프로세스 하나와
승인후 직접 서버에 유저 생성 쿼리를 날리는 것으로 했습니다.

엑셀에서 유저를 생성하는 쿼리는 생각보다 잘 만들어줬습니다.
그리고 승인후 프로세스인 유저 성성 쿼리를 실행하려하니
ssh로 접속후 mysql 실행이라 패스워드 관리가 이슈였네요.

처음에는 패드워드는 보안 이슈가 있으니 하나하나 입력을 받노록 만들었죠
하지만 후미다이(踏み台) 서비에 들어갈때 패스워드를 입력하고 
Db서버 로그인 비번넣고 
생성할 유저의 비번을넣는 것은
생각보다 작업이 많았습니다.

그래서 그냥 자주쓰는 비번은 비번을 모아놓은 파일을 
만들어서 사용하기로 했죠.

bastion 정보랑 MySQL 정보랑 생성할 유저의 비번 관리 파일  정보랑해서
JSON으로 설정파일을 만들고 프로젝트 밖에서 읽어내기로 했죠.

이렇게 만들어보니 그냥 main.py 하나의   파일로 전부 기능을 때려 넣어서 복잡해 졌습니다

기능 하나 수정하다보면. 에러가 발생하고 
수정을 요청하면 
그게 다른 기능의 코드를 재작성해 버려 
또다른 오류를 만들기도 했죠ㅣ
여러번 재작성에 짜증이 나기 시작했습니다. 

그래서 기능별로 파일을 분리시켜 달라고 했더니
이쁘게 분리 해주더랍니다

문제는 여기서부터였는데요.
분리된 파일의 한쪽을 수정요청 했는데
갑자기 수정할 필요가 없는 파일이 수정되는겁니다.
그래서 이 파일은 원복시켜라 라고 하니까
또 원복은 잘해주네요.
문제 없으려니히고 계속 수정하다가
기능을 첫 화면에서 독립적으로 
나누어야겠다고 생각을 했습니다

그래서 main.py 파일을 router 처럼
메뉴리스트 외엔 전부 파일을 나누고
나뉜 파일들은 독립적으로 그 파일만 실행해도
각자의 기능을 수행할 수 있게 해달라고 했습니다

눈치 채신 분들도 계시겠지만
이게 MSA 설계가 되는것이지요.

필요 기능을 세분화하고
세분화된 기능은  독립적으로 사용가능합니다
그리고 그 세분화된 기능들은 조합만으로
하나의 워크플로를 만들 수 있는거구요
통으로 복사해도 필요 기능만 활성화 할 수 있으니
자유롭게 기능을 만들어갈 수 있는 겁니다

이렇게 기능을 우선 세분화하고 리스팅했습니다
여섯개가 되었네요.
새로운 기능을 추가할때마다 새 파일로만들라고
하지 많으면 매번 main.py 에 파일을 만들어 버리더랍니다.

게다가 제대로 한번 꼬이면 무슨짓을해도
바로전 실패했던 코드랑 그 전 실패했던 코드의 무한 반복을 합니다.
무한 실패 코드 반복을 하는거죠

게다가 자꾸 main.py 파일의 메뉴의 개수가
줄었다 늘었다 합니다.
복구를 시키면 복구는 해주지만
슬슬 짜증이 한계에 다달났죠

그래서 물어봤습니다.

개발코드 작성룰을 파일로 만들면
내가 지시하는 모든 내용에 이 파일을 전제로 처리해
줄 수 있느냐?

그랬더니 Development ruleMd 라는 파일을
만들고 그동안 내가 공통적으로 지시했던 내용을
정리해 주터랍니다.

그 뒤부터는 내가 자꾸 빼먹고 지시를 해도
이 넘이 그 룰을 베이스로 만들어 주더랍니다.

첨부터 알려줄 것이지 !

라고 생각한 순간… 

AI는 물어보는 사람의 수준 만큼만 대답해준다는
것을 새삼 또 느끼게 되더랍니다.

내가 접속 가능한 서버들을 계속 추가하면
여러 서버에 동시에 명령을 날리고
그 결과를 evidence 라는 폴더에
다 넣어주는 툴이 완성 되었습니다.

그 밖에도 소스코드를 드래그 해서 ctrl+l 을 누르면
채팅으로 선택한 코드만 원하는대로 변경을 하거나 할 수 있구요, 
파일을 드래그 해서 해당 파일의 특별한 부분만 바꿔달라면 
그 파일만 바꾼다거나 하는 여러가지 
제한적인 사용 방법도 있으므로 사용하기 편하구요, 
에러가 나면 에러를 통으로 긁어서 던지면
에러가 알기 힘든 경우 예외 상황 및 절차를 
저 세세하게 분리해서 표시해주기 때문에
최종적으로 문제가 된 부분을 찾아 해결이 쉬워지게 됩니다. 
이런 식으로 하나씪 해결해 갔지요..

때마침 mysel의 SQL mode 라는 변수값과
서버버전, charged 등을 표시해 달라는
요구를 받았네요.
이젠  서버 하나하나 들어갈 필요없이
선택만 하면 바로 실행해 줍니다.

Cursor라는 툴이 나오기 전부터 
저는 파일 명명 규정에서 부터
업무의 기본적인 룰, 정보 에스컬레이션 체계, 
운영워크 플로를 관리하고 문서화를 해왔기 때문에
Cursor라는 툴을 사용하는데도 
룰북을 만들어 사용을 하니 
제가 의도한 대로 디렉토리 구조와 
문서화까지 잘 해주고 있네요.

이 툴에 익숙해지는데 거의 8시간은
걸린 것 같은데 지금 의뢰 처리는
평소 하던대로해도 한 시간도 걸리지 않은
간단한 것들이죠.

이런 얼마 시간이 안길리는 일은
툴 만드는 시간에 
직접 해버리고 말잖아요?
하지만 동일한 의뢰 처리 시간을 누적시켜가면
이 툴을 만든 효과가 누적되어
저는 점점 시간이 남아들 것이구요

그냥 작업 했던 사람들은
시간이 지나도 자신의 업무 가능량은
늘어나지 않죠.

더욱 중요한것은
저는 오늘 cursor라는 툴을 배우고
실전에서 경험을 했지만
다른 사람들은 평소와같은 나날이었을 겁니다

이 것이 저의 20년을 만들어 온 것이구요
저의 앞으로의 20년은 더욱 발전을 할
계기를 만들어 줄거라 생각합니다

이젠 aws에 로그인을 해주면 
Cursor가 알아서 리소스를 체크해주고, 
해당 리소스에 맞는 terraform 명령 셋을 만들어줍니다. 
내가 필요할 떄 인스턴스의 생성, 기동, 종료도 해 줍니다.

많은 영상에서는 맛보기만 목적으로 만들어서
여기까지 개고생한 경험이 없을지도 모릅니다.

언제나 이야기 하지만 
AI는 지시한 사람의 수준까지만 알려줍니다. 

때문에 cursor가 수준이 너무 낮다고 생각하신 분이 계시다면
자신의 업무 지시 능력과 업무 표준화 능력이 부족하진 않은지
다시한 번 돌아볼 필요가 있다고 봅니다.

---- 정리

커서를 써보고 느낀점은
MSA의 구조설계가 중요하고
개발 rule의 정의가 중요하다
코드 변경 기준 과 관리 방법론이 중요하다

결국 잘 쓰려면
설계와  논리적 설명방법이 가장 중요하다
인 것이었습니다.

생각해보면 새삼스럽지만, 
여러분도 cursor가 
상상하는 대로의 결과를 만들어 줄 때까지
열받아도 포기하지 마시고 
좋은 결과를 내시길 바랍니다.



giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

댓글

이 블로그의 인기 게시물

일본 두바퀴 여행(바이크 편)

영상버전 : https://youtu.be/P3vC17iVu1I 이번에는 일본으로 넘어와서 일본 종주하시는 바이커들을 위한 정보입니다.  일본에서의 2륜의 정의가 면허와 도로교통법이 조금씩 다르다고 합니다.  그래도 그렇게 크게 신경쓸 건 없으니 딱 세 종류로 말씀 드릴께요.  50cc는 원동기 1종이라고 하여 3차선 이상 교차로에서 우회전, 한국에선 좌회전 같이 크게 도는 것이지요..  이게 불가능합니다.  직진 신호로 넘어간 뒤에 방향을 틀고 다시 직진으로 두번 꺾어 가야 하구요,  두 명이 타면 안됩니다.  그리고 맨 가장자리 길로만 가야해서 애매하게 끝에서 두 번째 차선만 직진인 곳들이 있어서 난감할 때가 있지요. 그런데에 직진하면 걸리는 곳이 있다고 합니다. 어느 정도까지 걸리고 안걸리고는 정확히는 모르지만,  직좌 마크가 아닌 좌회전 마크만 있는 곳이 은근히 많으니 조심해야 하겠더라구요.  최고 시속도 30km를 넘기면 안되어 천천히 달려야 합니다.  아뭏든 제약이 엄청나게 많으므로 60cc이상을 가져오시거나 렌트 하시는 것을 추천하구요,  125cc미만은 겐츠키 2종이라고 하여 두 명이 타도 되고, 3차선 이상에서 우회전이 가능합니다.  상당히 제약이 풀리는 대신 고속도로를 탈 수가 없지요.  만약 국도로 천천히 올라오신다면 125cc미만으로도 충분합니다.  실제로 일본인 바이커들 중에서도 국도 종주하는 모습을 많이 볼 수 있구요,  도심에 가면 125cc미만까지만 주차 가능한 바이크 주차장도 꽤 많기 때문에 도심용으로는 메리트가 큰 것 같습니다.  뭐, 125cc대는 곳에 큰 바이크를 대는 경우도 자주 보는데, 아무도 뭐라 안하긴 합니다.  그도 그럴 것이, 일본의 바이크 등록대수는 1031만대 인데도 바이크 전용 주차장은 턱없이 부족하다고 합니다. 바이크 주차장이 저렴하기 때문에 웬만한 ...

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...