AI로 코드 쓰기
처음 개발을 할 때는 지피티로 코드를 써가면서 기능을 구현해가기 시작했다. 그때는 좋은 설계가 뭔지에 대해 감이 없었다.
하지만 프로젝트가 진행될수록, ‘코드를 잘 쓰는 것’과 ‘설계를 잘하는 것’은 전혀 다른 문제라는 걸 느끼게 되었다.
설계문서를 쓰고 구현을 시작하면서, 내가 만든 서비스이니 누구보다 도메인 이해가 잘 되어 있을 거라 생각했다.
엔티티를 재설계하다
초반에 엔티티 A, 엔티티 B를 다른 책임이라 보고 다른 엔티티로 분리했다.
그러다보니 외부 api를 호출하고 이를 객체로 매핑하는 과정에서 A, B는 생명주기가 같다는 점을 발견했고 이후 도메인을 재설계했다.
처음 분리는 역할 기준이었지만, 실제 변경 이유는 항상 함께 움직이고 있었다.
SRP를 다시 이해하게 되다
이때 SRP란 무작정 다른 것이라 생각하고 분리하는게 아니라
같이 변한다면 하나로 묶어야한다는 것이다. 즉 같이 변하고, 생명주기가 같다면 의존성이 높다.
또 다른 예시 – 상태와 행동이 함께 변하는 경우
class Category {
private final List<Item> items = new ArrayList<>();
public void addItem(Item item) {
items.add(item);
}
/**
* 카테고리의 상태(items)에 의해
* 자연스럽게 계산되는 값이므로
* 별도 서비스가 아닌 엔티티 책임으로 둔다.
*/
public double averageScore() {
int totalScore = items.stream()
.mapToInt(Item::score)
.sum();
return items.isEmpty() ? 0 : (double) totalScore / items.size();
}
}
record Item(int score) {}
변경 이유를 기준으로 보면,
averageScore 계산은 Category의 상태 변화에만 영향을 받았다.
이 경험 이후로, SRP는 ‘역할을 나누는 것’이 아니라 ‘같이 변하는 것을 묶는 것’이라는 말이 내게는 더 정확하게 느껴졌다.
이렇게 도메인의 이해 + OOP 사고를 해야 더 알맞은 설계, 알맞은 구현을 할 수 있다.
이는 시니어가 될 수록 더 중요한 사고라고 생각한다.
개발자는 코드만 잘 쓰는게 아니라 설계도 하고 고객에게 제품 설명도 하고, 기술 선정도 해야한다. 이러려면 결국 도메인의 이해 + 서비스 이해가 잘 이루어져야 하는 것 같다.
시니어가 될 수록 소통, 협업, 도메인 이해, OOP적 사고가 중요해져서 결국 기본기, 코드 외적인 부분이 중요해지는 것 같다.
소프트웨어 장인 책을 회고하며
소프트웨어 장인 이라는 책을 읽을 당시에는 장인 정신의 핵심이 열정이라고 강조되었는데, 이제 열정의 의미가 다르게 보인다.
결국 내가 이해하게 된 장인 정신은 열정 그 자체라기보다, 설계와 판단에 책임을 지려는 태도였다. 그리고 설계와 판단을 잘하기 위해서는 도메인에 대한 이해와 본인이 어떤 기능을 만드는지에 대한 이해가 중요한 것 같다.
AI를 쓰는 지금일수록, 무엇을 자동화하고 무엇을 직접 판단해야 하는지에 대한 기준이 개발자의 역량이 된다고 느낀다.