서론
고객이 요청한 프로그램을 개발은 다음의 과업을 이루면 된다.
- 고객의 요구사항을 정확하게 이해해야 한다.
- 고객이 바라는걸 찾아갈 수 있게 도와줘야 한다.
- 신뢰 관계를 구축하고, 소통을 자주한다.
- 책임을 지고 내 역할을 완수한다.
그리고 한 번쯤은 멘탈이 갈리게 된다.(과연 한 번일까?)
고객도 일부러 그러지는 않는다.
상상력에 한계가 있는 인간의 죄이지, 나쁜 사람은 아닐 것이다. (나쁜 사람 같다면, 모쪼록 행복하길 빈다..)
정답은, 소통을 많이하고 신뢰 관계를 쌓는 것.
상대의 생각과 내 생각을 동기화 시키기 위해서 소통을 많이 해야한다.
그리고 신뢰를 바탕으로, 조율과 협상을 해내고
프로젝트를 완수 시켜내야 한다!
내가 이해 한 고객의 요청사항은 다음과 같다.
RAG에 PDF를 넣으면, 이미지와 표를 잘 활용하지 못한다고 한다.
그래서 이미지나 표를 분리해서 가지고 있고, 이에 대한 설명을 텍스트로 추가하여
이미지는 참조로써 사용한다고 한다.
그래서 PDF를 라벨링 할 수 있는 GUI를 개발해달라는 요청이 들어왔다.
그리고 제약조건은 PyQt를 사용할 것.
Proto-type으로 소통하기
인간이 가진 상상력의 정밀도는 사람마다 다르며, 한계가 명확하다.
내가 상상한 것이, 고객의 상상과 최대한 비슷해야 수정이 적어진다.
개발을 하고, 생각을 동기화하려고 하면 비용이 많이 들기 때문에 프로토 타입을 사용한다.
그리고 동영상을 촬영하고, 바로 공유하고 피드백을 받는다.
소통하고 조율하기
위의 프로토 타입을 녹화하고, 공유 목적과 유의사항을 기입하여 공유한다.
그리고 내가 이해한게 맞는지 검증하고, 피드백을 받는다.
피드백은 댓글로 남겨둔다. 내가 보기 위함이기도 하고, 상대가 보기 위함이기도 하다.
코드이든, 화이트보드이든, 영상이든
프로토 타입 본인의 역할은 다 했다. 이제 관리하지 않는다.
예광탄 코드 발사
프로토 타입은 POC(Proof of Concept)의 역할을 수행하고 끝이다.
그리고 이제 실제 프로젝트에 들어갈 코드를 작성해야 한다.
일단 굴러가게 만들고, 잘 굴러가게 만드는게 마음이 편하다.
아키텍처를 설계할까 했으나, 어림도 없다 Dirty-code를 일단 발사한다.
최소 기능은 LLM으로 돌아가게 우선 만들고, 버그를 잡는다.
그리고 코드를 리팩토링 해 나가면서, 아키텍처를 잡아간다.
혹시 맞았나..?
일단 돌아가는 코드로, 소통을 한다.
그리고 이 코드를 기반으로 고민을 해서 기초적인 설계를 해서 출발한다.
고객이 예광탄에 적중했는가?(이제 실탄을 쏘라)
GitHub - Tagite/ParseDF
Contribute to Tagite/ParseDF development by creating an account on GitHub.
github.com
결론
개발자는 개발 뿐 아니라, 의사소통을 잘 해야한다.
그리고 기술에 매몰돼서 본질을 놓치지 말아야 한다.
고로 개발은 어렵다!