혼자 커서로 개발하면서 끄적인 노트 공유한다.



1.

커서는 잘 될 때는 이렇게 까지 잘된다고? 싶을 정도로 잘되지만,

한번 어긋나면 문제만 키우는 경향이 있음.


개발 할 때,

컴퓨터 입장에서 생각해야 하는 것은

손코딩이나 커서나 똑같음.

프로그램이 사람 말을 명확히 못알아 들으니까,

프로그래밍 언어를 사용함.


마찬가지로,

커서에게 지시를 내릴 때는, 우리 입장에서 생각하지 말고,

커서 입장에서 생각해서, 지시를 내려주면 기똥차게 일을 잘함.


동일한 프로그래밍이지만,

자연어로 코딩한다고 접근해야 함.
커서에선 프롬프트 엔지니어링이 바로 코딩이다.


항상 커서가 어디까지 이해하고 있을 지 생각해보고 지시할 것.




2.

커서의 핵심 약점은 파레토 법칙임.


90%의 코드는'딸깍'으로 해결되지만,

안되는 10%의 코드를 해결하는데,
자동화로 세이브한 이상의 시간이  필요하다는 거.


즉, AI로 개발할 떄는

파레토 법칙이 훨씬 강하게 적용된다는 거다.


잘 되는 90%의 코드에 신경쓰지 말고,
10%의 오류를 방지하도록 신경쓸 것




3.

경쟁 코딩에서 소넷은 세계 50위 안에 드는 수준의 프로그래머임.

다시 말해 closed-ended question으로 지시를 내려준다면,

커서는 세계 50위 수준의 프로그래머로서 우리 지시를 따라준다는 것.


그럼 커서에게 최적화된 개발 프로세스는?

`코테 문제 100문제를 내서 앱을 개발하는 것`


기존 방식을 적용하려 하지 말것.




4.

커서에 컨텍스트를 제공할 때 주의점은

MD을 너무 길게 작성하지 않는 것.

컨텍스트가 너무 길어지면 LLM의 급격한 성능 저하가 발생할 가능성이 있음.




5.

내가 커서보다 잘하는 것이 있음.

사람이 이해하기 쉬운, 아키텍처 작성은 내가 커서보다 잘함.

그래서 아키텍처는 내가 작성함.

그리고 커서는 세부 내역을 채워넣도록 함.




6.

커서에게 지시한 내용은 반드시 보관하고,
한번 리뷰하도록 하자.


만족스러웠던 프롬프트,

실패한 프롬프트로 분류한 뒤


지속적으로 프롬프트를 비교하고 개선해나가야 함.


좋은 프롬프트를 쓰는 능력이 곧 훌륭한 개발 능력임





무작위로 끄적인 노트ㅇㅇ