고은연로그 고은연로그

이 글은 2025년 10월 27일 제 벨로그 https://velog.io/@koeunyeon/BIG-BALL-OF-MUD-%ED%95%9C%EA%B5%AD%EC%96%B4%ED%8C%90 에 썼던 글을 티스토리로 옮긴 것입니다.BIG BALL OF MUD 라는 논문이 있습니다. 무려 1997년 (지금으로부터 무려 28년전)에 발표되었고 1999년에 정식으로 책에 수록된 글이죠.소프트웨어 개발의 '이상(아름다운 아키텍처)'과 '현실(시장 압박과 기술 부채)' 사이의 괴리를 다루는 글입니다.저는 개인적으로 이 논문을 무척이나 좋아하는데요. 저도 여타 개발자들과 비슷하게 이상주의자와 현실 주의자 사이 어딘가에서 살아가고 있기에, 매 순간 이상을 따를 지 아니면 현실에 순응해야 할 지 고민하기 때문인 듯 합니..

1초만에 실행되던 쿼리가 12초가 됐습니다.같은 화면, 같은 쿼리인데 주민번호 컬럼에 암호화 함수 하나 씌웠을 뿐이었습니다. 그것만으로 조회 속도가 10배 넘게 느려졌습니다.오픈 2주 전아시는 분은 아시겠지만, 감리는 최종 감리 외에도 중간 감리가 있는 경우가 있습니다. 그러니까 개발중에 와서 잘 되고 있나 확인하는 거죠.아니 개발중인데 당연히 엉망이지 이양반아...당연히 감리분도 그냥 본인 할 일 하는 겁니다. 대부분 공공기관 같은 곳에는 법적으로 강제로 해야 하는 경우가 많습니다.중간감리 지적사항이 떨어졌습니다. 개인정보 암호화 미적용. 주민번호와 계좌번호가 평문으로 저장되어 있다는 내용이었습니다.알고 있었습니다. 일정이 빠듯해서 나중에 하려고 미뤄둔 것이었는데, 감리가 먼저 잡았습니다.암호화 자체는..

이 글은 2022년 5월 20일 제 벨로그 https://velog.io/@koeunyeon/%EA%B0%9C%EB%B0%9C%EC%9E%90%EA%B0%80-%EC%A2%8B%EC%95%84%ED%95%98%EB%8A%94-%EA%B8%B0%ED%9A%8D%EC%84%9C-%EC%93%B0%EB%8A%94-%EB%B2%95 에 썼던 글을 티스토리로 옮긴 것입니다.1. 서설이 글은 생각나는대로 계속 업데이트합니다. 현재 최종 버전은 2023.06.08. 입니다.이 글은 제가 좋아하는 타입의 기획서를 나열한 것입니다. 개인 취향일 수도 있으므로 가볍게 읽으셔도 됩니다.개발은 뭐라고 하는지 하나도 모르겠고 디자인은 재능이 없는 것 같으니 그나마 (조별발표때 써 봤던) 파워포인트로 문서나 만드는 기획자를 해 ..

이 글은 2022년 5월 20일 제 벨로그 https://velog.io/@koeunyeon/%EC%96%B4%EC%84%A4%ED%94%88-%EC%95%A0%EC%9E%90%EC%9D%BC 에 썼던 글을 티스토리로 옮긴 것입니다.폭포수와 애자일"모든것을 미리 정해놓고 한번에 개발하자!" 는 폭포수(워터폴) 개발론은 한가지 문제가 있습니다. 너무 큰 걸 만들다보니 고객들이 만들어진 시스템의 전체 모습을 그리기가 어려워져 버린 것입니다.그래서 "폭포수를 개울물만큼 쪼개놓고 계속 반복하면서 피드백을 받을 수 있게 하자"라는 애자일이 등장했습니다. 신세계였어요.전체 시스템 생각하기애자일이 대두되면서, 경험이 많은 개발자들이 미처 예상하지 못한 사태가 발생했습니다. 바로 "실무 개발자들이 전체 시스템을 머리속..

이 글은 2022년 1월 7일 제 벨로그 https://velog.io/@koeunyeon/FastAPI-%EC%8D%A8-%EB%B3%B8-%ED%9B%84%EA%B8%B0 에 썼던 글을 티스토리로 옮긴 것입니다.FastAPI?파이썬을 이용한 웹 개발 세계에서는 FastAPI 가 최근 기술로 각광받고 있는 중입니다. 물론 전통의 풀스택 프레임워크 Django 나 마이크로 프레임워크 Flask에 비할 바는 아닙니다만 프레임워크 개발이 2018년 12월부터 시작되었다는 점을 감안하면 꽤나 빨리 뜨거운 감자가 된 셈이죠.그래서 뱉은 말과 다르게 한번 API 문서를 둘러보고 직접 사용해 보았습니다.엔드포인트 매핑은 플라스크 방식으로이전에도 이런 방식이 있었는지는 잘 모르겠습니다만, 저는 플라스크때 처음으로 데..

결국 우리 둘 다 맞았습니다.상대 시스템 담당자와 전화로 30분을 싸웠습니다."명세서대로 보냈어요.""아뇨, 이렇게 와요.""그럴 리 없어요.""캡처 보냈잖아요.""저쪽에서 잘못 파싱한 거 아니에요?"둘 다 틀리지 않았습니다. 명세서가 애매했을 뿐입니다.필수명세서에는 이렇게 적혀 있었습니다.필드명: customer_id타입: String필수: Y필수가 Y입니다. 값이 반드시 있어야 합니다. 우리는 그렇게 이해했습니다. null이 오면 에러를 던지게 만들었습니다. 당연한 방어 코드였습니다.상대 시스템에서는 다르게 이해했습니다. 필수니까 필드는 반드시 보낸다. 값이 없을 수도 있지만 필드 자체는 있다. "customer_id": "" 이렇게. 빈 문자열.빈 문자열은 null이 아닙니다. 필드는 있습니다. 그..

이 글은 2021년 12월 29일 제 벨로그 https://velog.io/@koeunyeon/%EC%B5%9C%EC%8B%A0-%EA%B8%B0%EC%88%A0%EC%9D%B4-%EC%9A%B0%EB%A6%AC%EB%A5%BC-%EB%A9%8D%EB%93%A4%EA%B2%8C-%ED%95%9C%EB%8B%A4 에 썼던 글을 티스토리로 옮긴 것입니다.최신 기술아, 이런 식으로 작성하는 코드는 마음에 들지 않는데, 더 좋은 방법이 없을까?개발자로 살다보면 이런 경험이 한번쯤은 있을 꺼에요. 그래서 새로운 사상, 사용해보지 않은 언어, 신규 프레임워크를 찾아 헤매게 되죠.정상이에요. 칼퇴근을 위해 같은 일을 더 효율적으로 하는 것은 엔지니어로서의 본능에 가깝다고 생각해요.저는 개인적으로 기술 스택을 여러번 ..

이 글은 2021년 11월 30일 제 벨로그 https://velog.io/@koeunyeon/%ED%81%B0-%EC%A7%84%ED%9D%99-%EA%B3%B5BBOM-%EB%B0%A9%EC%8B%9D%EA%B3%BC-DDD 에 썼던 글을 티스토리로 옮긴 것입니다.최근에 파이썬으로 살펴보는 아키텍처 패턴이라는 책을 보고 있습니다.여러가지 좋은 이야기가 나오는데, 그 중에서 BIG BALL OF MUD(BBOM - 큰 진흙공) 방식에 대한 이야기가 나옵니다.간단하게 말하면 큰 진흙공 방식은 아키텍처가 없는 소프트웨어 시스템을 뜻합니다.즉, 되는대로 만들어지고, 요구사항에 따라 즉흥적인 코드를 만들고, 설계가 없다는 뜻이죠.말만 들으면 BBOM은 우리 모두가 지양해야 할 안티 패턴처럼 보입니다. 그리고..